Easytrieve HIGH-VALUES

HIGH-VALUES Is a Byte Pattern

A byte contains eight bits. X'FF' means all eight are one: binary 11111111. HIGH-VALUES repeats that byte across the subject or receiver. A four-byte field therefore contains X'FFFFFFFF' after MOVE HIGH-VALUES. An eight-byte key contains sixteen hexadecimal F digits. The constant expands to the field length, so you do not manually code a different hexadecimal literal for every receiver.

1
2
3
4
5
6
7
8
DEFINE HIGH-KEY W 8 A
DEFINE END-SW   W 1 A
 
MOVE HIGH-VALUES TO HIGH-KEY
 
IF HIGH-KEY HIGH-VALUES
   END-SW = 'Y'
END-IF

After MOVE, all eight bytes of HIGH-KEY are FF. The class test succeeds because every byte matches. If one byte is changed to an ordinary character, the test becomes false.

Field-Class Condition Syntax

The documented pattern is IF field-name [NOT] HIGH-VALUES. It is also available in DO WHILE and DO UNTIL field-class conditions. NOT reverses the result: IF KEY NOT HIGH-VALUES means at least one position differs from FF. The test is not an equality comparison to a named field, so no EQ operator is needed.

1
2
3
4
5
6
7
IF CUSTOMER-KEY HIGH-VALUES
   DISPLAY 'HIGH KEY SENTINEL FOUND'
ELSE
   IF CUSTOMER-KEY NOT HIGH-VALUES
      DISPLAY 'ORDINARY KEY'
   END-IF
END-IF

Single-Byte, MIXED, and DBCS Subjects

Broadcom 11.6 says HIGH-VALUES tests X'FF' in each byte of single-byte and MIXED-format subjects and in each double byte of DBCS subjects. That distinction matters in multilingual files. Do not split a double-byte character field into arbitrary single-byte overlays and assume the same interpretation. Define the field with its actual format so Easytrieve applies the documented class rule.

MOVE HIGH-VALUES

Format 2 of MOVE accepts HIGH-VALUES as the sending data area and one or more receiving fields. The first receiver determines the default sending length, while each target is filled according to the statement rules. Use it when the byte pattern itself is intended, not merely because you want a “large value.”

1
2
3
4
5
6
DEFINE FROM-KEY W 10 A
DEFINE THRU-KEY W 10 A
DEFINE HOLD-KEY W 10 A
 
MOVE LOW-VALUES  TO FROM-KEY
MOVE HIGH-VALUES TO THRU-KEY HOLD-KEY

This initializes an inclusive character-key range from the lowest byte pattern through the highest. Whether a specific access method accepts these sentinels depends on its key rules, collating sequence, and application protocol. Test with representative VSAM or sequential data rather than assuming every database interprets raw FF as a valid key.

HIGH-VALUES Is Not a Numeric Maximum

Packed decimal stores digits in nibbles and a sign in the final nibble. F is not a valid decimal digit in each position. Zoned decimal also expects digit zones. A binary field filled with FF commonly represents -1 in two's-complement signed interpretation, which is the opposite of “largest positive number.” Always choose a type-aware numeric literal when arithmetic follows.

Collating-High Sentinel Keys

Sequential match and merge programs sometimes need a key that sorts after every ordinary business key. At EOF on one file, logic can move HIGH-VALUES to its current key, allowing a comparison loop to continue with the remaining file. This is an algorithmic sentinel, not Easytrieve's EOF status itself. The design is safe only if real input keys can never contain all FF bytes and if comparison uses a compatible collating sequence.

1
2
3
4
5
6
7
8
9
10
11
IF EOF FILE-A
   MOVE HIGH-VALUES TO FILE-A-HOLD-KEY
END-IF
 
IF EOF FILE-B
   MOVE HIGH-VALUES TO FILE-B-HOLD-KEY
END-IF
 
IF FILE-A-HOLD-KEY LT FILE-B-HOLD-KEY
   PERFORM PROCESS-A
END-IF

EOF remains the condition that detects file exhaustion. HIGH-VALUES merely supplies a key value for the comparison algorithm after exhaustion.

HIGH-VALUES and VSAM

Applications may initialize a VSAM browse key with LOW-VALUES for a start or HIGH-VALUES for a terminal bound. The exact access statement and key semantics depend on ESDS, KSDS, RRDS, update mode, and site conventions. HIGH-VALUES does not bypass VSAM key validation. A key containing FF must fit the defined key length and be acceptable to the operation. Check FILE-STATUS after POINT, GET, PUT, or WRITE instead of assuming a sentinel guarantees success.

Detecting Uninitialized or Sentinel Data

Some upstream programs deliberately initialize unused fields to HIGH-VALUES. An Easytrieve validation job can identify those records before attempting numeric conversion or report formatting. Test the raw alphabetic or binary overlay first, record the key, then decide whether to reject, translate, or preserve the sentinel. Converting FF-filled packed fields directly can cause data exceptions.

1
2
3
4
5
6
7
IF RAW-AMOUNT HIGH-VALUES
   ERROR-CODE = 'H01'
   DISPLAY 'AMOUNT CONTAINS HIGH VALUES' CUSTOMER-ID
   GOTO JOB
END-IF
 
VALID-AMOUNT = INPUT-AMOUNT

HIGH-VALUES in Reports

Raw FF bytes are not reader-friendly report content. Depending on translation and printer handling, they may appear as unusual symbols, blanks, or control-like output. Translate a sentinel to an explanatory label in a derived field before PRINT. Keep the original bytes unchanged if they are needed for audit.

1
2
3
4
5
6
7
8
9
DEFINE DISPLAY-STATUS W 18 A
 
IF STATUS-BYTES HIGH-VALUES
   DISPLAY-STATUS = 'HIGH-VALUE MARKER'
ELSE
   DISPLAY-STATUS = 'NORMAL'
END-IF
 
PRINT STATUS-RPT

Comparing HIGH-VALUES with Other Constants

Working Storage Initialization

Working storage does not default to HIGH-VALUES. Alphabetic fields default to blanks and numeric fields default to zero. If a high sentinel is required, move HIGH-VALUES explicitly before its first use. VALUE with an explicit hexadecimal literal can also establish a byte pattern where supported, but MOVE HIGH-VALUES states the intent more clearly and automatically covers the receiver length.

Version and Portability Notes

HIGH-VALUES is a documented reserved word in Broadcom Easytrieve Report Generator 11.6 and older CA-Easytrieve Plus material. The X'FF' definition is stable. What can differ is the external system's interpretation: database keys, sort products, code pages, DBCS formats, and APIs can impose additional rules. Treat the Easytrieve constant semantics as one part of the contract and verify the receiving system separately.

Common HIGH-VALUES Mistakes

1. Calling HIGH-VALUES the largest valid packed decimal number.
2. Performing arithmetic on an FF-filled numeric field.
3. Assuming HIGH-VALUES itself means EOF.
4. Using a sentinel without proving real keys cannot equal it.
5. Printing raw FF bytes instead of a readable derived label.
6. Ignoring FILE-STATUS after using a high VSAM key.
7. Testing whether any byte is FF when the class condition requires every byte.

Explain It Like I'm Five

Think of every byte as a row of eight tiny switches. HIGH-VALUES turns all eight switches on in every box. That pattern is often placed after normal letter keys, so it can act like a sign saying “past all ordinary names.” It is not the biggest amount of money. If a money box expects decimal digits, filling it with switches instead of digits makes the money unreadable.

Exercises

1. Define an eight-byte character key, move HIGH-VALUES to it, and test the result.
2. Explain why X'FFFFFFFF' is unsafe as a packed decimal value.
3. Design an EOF merge sentinel while keeping EOF detection separate.
4. Write validation that routes HIGH-VALUES input records to an error report.
5. Compare HIGH-VALUES, LOW-VALUES, SPACES, and ZERO by stored representation.
6. Describe checks required before using HIGH-VALUES as a VSAM upper key.