Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

ISAM files

ISAM files with indexed or relative file organization can be shared by several users simultaneously by means of the SHARED-UPDATE operand in the SUPPORT parameter of the ADD-FILE-LINK command:

/ADD-FILE-LINK linkname,filename,SUPPORT=DISK(SHARED-UPDATE=YES)

The following table shows which OPEN statements are available to user B after the file has already been opened by user A.


Options permitted for user B

SHARED-UPDATE =YES

SHARED-UPDATE=NO

Options selected
by user A

OPEN
statement

INPUT

I-O

OUTPUT/
EXTEND

INPUT

I-O

OUTPUT/
EXTEND

SHARED-UPDATE=YES

INPUT

X

X


X



I-O

X

X





OUTPUT/EXTEND







SHARED-UPDATE=NO

INPUT

X



X



I-O







OUTPUT/EXTEND







Table 35: OPEN statements permitted for shared updating


X = permitted combinations of OPEN statement and SHARED-UPDATE value


It is clear from the table that the SHARED-UPDATE=YES option is superfluous for INPUT files if all users use OPEN INPUT. If SHARED-UPDATE=YES must nevertheless be specified for input files because at least one user uses OPEN I-O, the locks described below will not be set or released.

The SHARED-UPDATE=YES option makes sense, and is also necessary, only for the simultaneous updating of one or more ISAM files (OPEN I-O) by two or more interactive users.

Updates in batch processing mode must be executed successively in order to avoid both logic errors and excessive runtimes (unnecessary specification of SHARED-UPDATE=YES increases both runtime and CPU time).

If SHARED-UPDATE=YES is specified, WRITE-CHECK=YES will automatically be set also, i.e. the ISAM buffers will be rewritten immediately after each change. This is necessary for reasons of data security and consistency, but causes a considerable increase in the number of I-O operations.

In order to ensure data consistency during simultaneous updating of an ISAM file by several users, the COBOL2000 runtime system utilizes the locking and unlocking mechanism of the DMS access method ISAM. This mechanism locks or unlocks the data blocks that contain the data records referenced by the COBOL statements READ, WRITE, REWRITE or DELETE.

A data block is the multiple of a PAM page (2048 bytes) defined implicitly or explicitly by the BUFFER-LENGTH parameter in the ADD-FILE-LINK command when the file was created (see section "Basic concepts relating to the structure of files").

In the following, a record lock is to be understood as the lockout of the entire block that contains the record.

To permit shared updating of ISAM files, a format extension to the READ or START statement is provided. However, this extension is effective only if SHARED-UPDATE=YES is specified in the ADD-FILE-LINK command and the file was opened with OPEN I-O.

Format extension (for all READ/START formats):


READ  file-name [WITH NO LOCK]...
START file-name [WITH NO LOCK]...


Rules for shared updating

  1. READ or START statement with the WITH NO LOCK phrase:

    If user A specifies the WITH NO LOCK phrase and the appropriate record is present, this record is read or selected irrespective of any lock set by any other user. The record is not locked. A REWRITE or DELETE statement cannot be performed on a record thus read.

    Simultaneously, a user B may read or update the same record.

  2. READ or START statement without the WITH NO LOCK phrase:

    If user A does not specify the WITH NO LOCK phrase and the appropriate record is present, a READ or START statement can only be executed successfully if that record is not already locked by user B. If execution of the statement is successful, the record will be locked. Before the lock is released, user B can only read or select the same or another record in the same block by specifying WITH NO LOCK, but will not be able to update any record in this block. (If user B opened the file using OPEN INPUT, he will still be able to read records in the locked block.)

  3. Updating of records:

    If a record is to be updated using a REWRITE or a DELETE statement, the appropriate record must be read immediately before this by a READ statement (without the WITH NO LOCK phrase). Between this READ statement and the REWRITE or DELETE statement, no further I-O statement may be executed for the same ISAM file. Between these two statements, only READ or START statements with the WITH NO LOCK phrase can be executed for other ISAM files whose ADD-FILE-LINK command contains SHARED-UPDATE=YES and which are open at the same time in the OPEN I-O mode. Statements for other ISAM files (without SHARED-UPDATE=YES and OPEN I-O) can be executed.
    Any violation of these rules will lead to an unsuccessful REWRITE or
    DELETE statement with FILE STATUS 94.

  4. Waiting times in the event of a lock:

    If user A has locked a data record following a successful READ or START statement, and user B attempts to perform a READ or START statement without the WITH NO LOCK phrase on the same data record or any other in the same data block, user B will not immediately be unsuccessful. User B must wait in a queue until the lock is released by user A. Only if the maximum waiting time elapses without the lock being released will the statement be considered unsuccessful and FILE STATUS 93 be set. If the lock is released before the waiting time has elapsed, user B can continue with the successful call.

  5. Releasing a locked record:

    A user maintains a record lock until he executes one of the following statements:

    • Successful REWRITE or DELETE statement for the locked data record

    • WRITE statement for an ISAM file whose ADD-FILE-LINK command contains SHARED-UPDATE=YES and which is open as OPEN I-O (i.e., for the same file that contains the locked record, or for another ISAM file; unlocking is also effected if the INVALID KEY condition occurs)

    • READ or START statement with the WITH NO LOCK phrase for the same file (unlocking is also effected if the AT END or INVALID KEY condition occurs)

    • READ or START statement without the WITH NO LOCK phrase for a record in another data block of the same file (unlocking is also effected if the AT END or INVALID KEY condition occurs)

    • READ or START statement without the WITH NO LOCK phrase for another ISAM file whose ADD-FILE-LINK command contains SHARED-UPDATE=YES and which is open in OPEN I-O mode (unlocking is also effected if the AT END or INVALID KEY condition occurs)

    • CLOSE statement for the same file

    Thus, a statement for an ISAM file can release the record lock on another ISAM file.

Notes

  1. If an ISAM file (with SHARED-UPDATE=YES and OPEN I-O) is to be processed in a program, a USE AFTER STANDARD ERROR procedure should be provided for this file. In this procedure, the file status values relating to shared update processing, i.e. 93 (record has been locked by a simultaneous user) and 94 (REWRITE or DELETE statement without preceding READ statement), can be interrogated and then processed accordingly.

  2. It should be noted that when a record is locked using the ISAM block lockout mechanism, all records in the same block are locked to all concurrent users.

  3. A user cannot lock more than one block at a time, i.e. can protect only one block against updating by other users. This is also true if the user has opened several ISAM files (all SHARED-UPDATE=YES) in OPEN I-O mode.

  4. A deadlock (mutual locking of data blocks by different users) is excluded, because only one block of all ISAM files (all SHARED-UPDATE=YES) can be locked for each user.This does not, however, apply if a PAM file is accessed simultaneously with SHARED-UPDATE=YES in I-O mode.

  5. If a READ statement for a record is not immediately followed by a REWRITE or DELETE statement but by an attempt to access some other data block (of the same or any other ISAM file) instead, the record will need to be read again before the REWRITE or DELETE statement is executed. Since the affected data block was unlocked to other users in the period between the READ and REWRITE or DELETE statements, the contents of the original record may have been changed (see ( 9-12 a) ).

    If an access attempt is made to another block or another file without the locking mechanism, the data made available might meanwhile have been changed by concurrent users before the REWRITE or DELETE statement is executed (see ( 9-12 b) ).

  6. In order to prevent a user from working with data that is no longer up-to-date, the WITH NO LOCK phrase should only be used when absolutely necessary.

  7. A locked record (block) will give rise to waiting times when concurrent users try to access the same record or another in the same block. To keep waiting times as short as possible, the lock should be released as soon as possible. If a lock is not released in due time, the waiting time will have elapsed, and the program branches to the appropriate USE procedure, if available (see Example 9-13), or is aborted (message COB9151, FILE STATUS 93 and DMS error code DAAA).

Example 9-12

Reading and rewriting in file ISAM1 when data from file ISAM2 is required before rewriting:

(a)

Without the WITH NO LOCK phrase: Two READ statements for the same file are necessary, but the locking times are shorter:

...
READ ISAM1 INTO WORK1 ————————————————————————————————————————————(1)
  INVALID KEY...
...
READ ISAM2 ———————————————————————————————————————————————————————(2)
  INVALID KEY...
...

Processing of WORK1 taking into account ISAM2REC:

...
READ ISAM1 ———————————————————————————————————————————————————————(3)
  INVALID KEY...

Check for changes to ISAM1REC in meantime; repeat processing if necessary:

...
REWRITE ISAM1SATZ FROM WORK1——————————————————————————————————————(4)
  INVALID KEY...

(1)

Reads a record from ISAM1 and buffers it in WORK1; relevant block in ISAM1 locked

(2)

Reads a record from ISAM2, releases lock in ISAM1, locks relevant block in ISAM2

(3)

Rereads record from ISAM1, releases lock in ISAM2, locks relevant block in ISAM1

(4)

Rewrites record into ISAM1, releases lock in ISAM1


(b)

With the WITH NO LOCK phrase: Only one READ statement is required for this file, but the locking times are consequently longer:

...
READ ISAM1 ———————————————————————————————————————————————————————(1)
  INVALID KEY...
...
READ ISAM2 WITH NO LOCK ——————————————————————————————————————————(2)
  INVALID KEY...
...

Processing of ISAM1REC taking into account ISAMREC:

...
REWRITE ISAM1SATZ FROM WORK1 —————————————————————————————————————(3)
  INVALID KEY...

(1)

Reads a record from ISAM1; relevant block locked

(2)

Reads a record from ISAM2; relevant block not locked

(3)

Rewrites record into ISAM1; lock is released.

Example 9-13

Branch to USE AFTER STANDARD ERROR procedure

   ...
FILE-CONTROL.
    SELECT ISAM1
     ...
    FILE STATUS IS FILESTAT1.
WORKING-STORAGE SECTION.
77  FILESTAT1 PIC 99.
    ...
PROCEDURE DIVISION.
DECLARATIVES.
ISAM1ERR SECTION.
    USE AFTER STANDARD ERROR PROCEDURE ON ISAM1.
LOCK-PAR.
    IF FILESTAT1 = 93
       THEN DISPLAY "RECORD CURRENTLY LOCKED" UPON T
       ELSE DISPLAY "DMS-ERROR ISAM1, FILE-STATUS="
                     FILESTAT1 UPON T.
ISAM1ERR-EX.
    EXIT.  ————————————————————————————————————————————————————(1)
END DECLARATIVES.
CNTRL SECTION.
    ...

(1)

Control is transferred to the statement following the statement that caused the error.
Suitable error recovery measures depend on the application involved.