Many of the KSAM procedures use a logical record pointer to indicate the current record in the file. This pointer points to a key value in the key file that identifies the current record in the data file. The particular key used, if the file has more than one key, is the key last specified in the current or a previous procedure call; by default it is the primary key.
Procedures that use pointers are either pointer-dependent or pointer-independent. Pointer-dependent procedures expect the pointer to be positioned at a particular record in order to execute properly. Pointer-independent procedures, on the other hand, execute regardless of where the pointer is positioned and, in most cases, they position the pointer. (Refer to Table 6-3 “Positioning the Logical Record Pointer” for a summary of those procedures that either position the pointer or are dependent on that position.)
Table 6-3 Positioning the Logical Record Pointer
Procedure Name | Pointer- Dependent | Position of Pointer After Execution of Procedure |
|---|
| BKSTART | NO
| Points to key whose value was specified in call. |
| BKREADBYKEY | NO
| Points to key whose value was specified in call. |
| BKWRITE | NO
| Points to key whose value is next in ascending key
sequence to key value in record just written. |
| BKREAD | YES
| Pointer remains positioned to key value for record just
read; unless next call is to BKREAD, or to BKREWRITE
followed by BKREAD, in which case, the pointer is
moved to the next record in key sequence before the
read. |
| BKDELETE | YES
| Points to next key value in ascending sequence
following key value in record just deleted. |
| BKREWRITE | YES
| Pointer remains positioned to key value for record just
modified; unless any key value in record was changed,
in which case, it points to next key in ascending
sequence after the key in the modified record. |
| Note: BASIC procedures do not access a KSAM file in chronological sequence or by record number; they ignore the chronological pointer. |
SHARED ACCESS |
 |
Particular care must be taken when using the logical record pointer during shared access. Since the record pointer is maintained in a separate control block for each open file, one user may cause the record pointer to be inaccurate without other users being aware of it. To avoid this problem, you should always lock the file in a shared environment before calling any procedure that sets the pointer and leave the file locked until all procedures that depend on that pointer have been executed. Thus, if you want to read the file sequentially, delete a record, or modify a record, you should lock the file, call a procedure that sets the pointer (such as BKSTART), and then call BKREAD, BKDELETE, or BKREWRITE. When the operation is complete, you can then unlock the file to give other users access to it.
