HP 3000 Manuals HP 3000 Manuals
KSAM LOGICAL RECORD POINTER
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 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 | Pointer- | Position of Pointer After |
| Name | Dependent | 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.