HPlogo Using KSAM XL and KSAM 64 > Appendix B BASIC/V Intrinsics

KSAM Logical Record Pointer

MPE documents

Complete PDF
Table of Contents
Index

E0300 Edition 4 ♥
E0394 Edition 3

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 index area that identifies the current record in the data area. 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.

Table B-1 Positioning the Logical Record Pointer

Procedure Name Pointer-
Dependent		 Position of Pointer After Execution of Procedure
BKSTARTNO Points to key whose value was specified in call.
BKREADBYKEYNO Points to key whose value was specified in call.
BKWRITENO Points to key whose value is next in ascending key sequence to key value in record just written.
BKREADYES Pointer remains positioned to key value for record just read; unless the 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.
BKDELETEYES Points to next key value in ascending sequence following key value in record just deleted.
BKREWRITEYES 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.

BASIC procedures do not access a KSAM file in physical sequence or by record number; they ignore the physical 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.



Status Parameter

BKCLOSE