A key-sequenced data set (KSDS) has each of its records identified by a key. The key of each record is simply a field that is in a predefined position within the record. Keys within a KSDS file need not be unique.
The physical sequence of the records depends on the collating sequence of the key field. This also fixes the sequence in which you retrieve records when you browse through the data set. An index relates the key of each record to the record's relative location in the data set. When you add or delete records, this index is updated accordingly.
When you write a KSDS record, you must specify the complete key, and when browsing, you must provide a record identification field (RIDFLD) that is large enough to hold the complete key.
When you use a generic key, you must specify its length in the KEYLENGTH option. You must also specify the GENERIC option on the command. A generic key cannot have a key length that is equal to the full key length. You must define it to be shorter than the complete key.
You can also specify the GTEQ option on particular commands, both for complete keys and for generic keys. The GTEQ option causes the command to position at, or apply to, the matching record that is in the data set. If no match is located, the command then positions at the record that has the next higher key. When accessing a data set by way of an alternative index path, the record that is identified is the one that has the next higher alternative key when a matching record cannot be found.
Even when using generic keys, always use a storage area for the RIDFLD that is equal in length to the length of the complete key. During a browse operation, after retrieving a record, CICS® copies into the RIDFLD area the actual identifier of the record that was retrieved. CICS returns a complete key to your application, even when you specified a generic key on the command. For example, a generic browse through a KSDS returns the complete key to your application on each EXEC CICS READNEXT and EXEC CICS READPREV command.