ASCENDING KEY and DESCENDING KEY phrases
Data is arranged in ascending or descending order, depending on the keyword specified, according to the values contained in data-name-2. The data-names are listed in their descending order of significance.
The order is determined by the rules for comparison of operands (see Relation conditions). The ASCENDING KEY and DESCENDING KEY data items are used in OCCURS clauses and the SEARCH ALL statement for a binary search of the table element.
Must be the name of the subject entry or the name of an entry subordinate to the subject entry. data-name-2 cannot be a windowed date field. data-name-2 can be qualified.
If data-name-2 names the subject entry, that entire entry becomes the ASCENDING KEY or DESCENDING KEY and is the only key that can be specified for this table element.
If data-name-2 does not name the subject entry, then data-name-2:
Must be subordinate to the subject of the table entry itself
Must not be subordinate to, or follow, any other entry that contains an OCCURS clause
Must not contain an OCCURS clause
data-name-2 must not have subordinate items that contain OCCURS DEPENDING ON clauses.
When the ASCENDING KEY or DESCENDING KEY phrase is specified, the following rules apply:
Keys must be listed in decreasing order of significance.
The total number of keys for a given table element must not exceed 12.
The data in the table must be arranged in ascending or descending sequence according to the collating sequence in use.
The key must be described with one of the following usages:
A key described with usage NATIONAL can have one of the following categories: national, national-edited, numeric-edited, numeric, or external floating-point.
The sum of the lengths of all the keys associated with one table element must not exceed 256.
If a key is specified without qualifiers and it is not a unique name, the key will be implicitly qualified with the subject of the OCCURS clause and all qualifiers of the OCCURS clause subject.
The following example illustrates the specification of ASCENDING KEY data items:
05 EMPLOYEE-TABLE OCCURS 100 TIMES
ASCENDING KEY IS WAGE-RATE EMPLOYEE-NO
INDEXED BY A, B.
10 EMPLOYEE-NAME PIC X(20).
10 EMPLOYEE-NO PIC 9(6).
10 WAGE-RATE PIC 9999V99.
10 WEEK-RECORD OCCURS 52 TIMES
ASCENDING KEY IS WEEK-NO INDEXED BY C.
15 WEEK-NO PIC 99.
15 AUTHORIZED-ABSENCES PIC 9.
15 UNAUTHORIZED-ABSENCES PIC 9.
15 LATE-ARRIVALS PIC 9.
The keys for EMPLOYEE-TABLE are subordinate to that entry, and the key for WEEK-RECORD is subordinate to that subordinate entry.
In the preceding example, records in EMPLOYEE-TABLE must be arranged in ascending order of WAGE-RATE, and in ascending order of EMPLOYEE-NO within WAGE-RATE. Records in WEEK-RECORD must be arranged in ascending order of WEEK-NO. If they are not, results of any SEARCH ALL statement are unpredictable.
Joined: 06 Jun 2008 Posts: 8212 Location: Dubuque, Iowa, USA
COBOL expects the programmer to be reasonably competent. If you put ASCENDING KEY in a table, you are expected to ensure that the values in the table are actually in ascending key sequence. If you do not do so, some actions (such as SEARCH ALL) will return unpredictable results. However, it is not a compile time nor a run time error to do this -- it is merely ignorance on the part of the programmer. COBOL does protect the programmer from some of his (her) stupidity, but by no means is it all guarded against.
The Ascending key clause in a table description - is only useful when you ALSO use the INDEXED BY clause that will specify an INDEX-ITEM name -- AND THEN it only comes into play when you use the SEARCH ALL instruction within the program. There is no way, other than the code that YOU write to prevent your table from be incorrectly sequenced.