Controlling Concurrent Access to Files

6.1.9. Controlling Concurrent Access to Files

The manipulation of data files is one of the COBOL language’s great strengths. There are features built-in to the COBOL language to deal with the possibility that multiple programs may be attempting to access the same file concurrently. Multiple program concurrent access is dealt with in two ways – file sharing and record locking.

Not all OpenCOBOL implementations support file sharing and record-locking options. Whether they do or not depends upon the operating system they were built for and the build options that were used when the specific OpenCOBOL implementation was generated.

6.1.9.1. File Sharing

OpenCOBOL controls concurrent-file access at the highest level through the concept of file sharing, enforced when a program attempts to OPEN a file (see section 6.31 ). This is accomplished via a UNIX operating-system routine called “fcntl()”. That module is not currently supported by Windows 19 and is not present in the MinGW Unix-emulation package. OpenCOBOL builds created using a MinGW environment will be incapable of supporting file-sharing controls – files will always be shared in such environments. An OpenCOBOL build created using the Cygwin environment on Windows would have access to “fcntl()” and therefore will support file sharing. Of course, actual Unix builds of OpenCOBOL, as well as MacOS builds 20 , will have no issues using BDB because “fcntl()” is built-in to Unix.

Any limitations you impose on a successful OPEN will remain in place until your program either issues a CLOSE against the file or terminates.

There are three ways in which concurrent access to a file may be controlled at the file level:

19 Windows has other means of providing equivalent functionality to “fcntl()”, but the BDB package was not coded to utilize them. The use of other advanced file I/O packages that support both the UNIX and Windows concurrent-

access routines (such as VBISAM) are currently under investigation by the author.

20 Apple Computer’s MacOS X operating system is based on an open-source version of UNIX and therefore includes support of “fcntl()”.

Sharing Effect Option

ALL When your program opens a file in this manner, no restrictions will be placed on other programs OTHER

attempting to OPEN the file after your program did. This is the default sharing mode.

NO When your program opens a file in this manner, your program announces that it is unwilling to allow OTHER

any other program to have any access to the file as long as you are using that file; OPEN attempts made in other programs will fail with a file status of 37 (“PERMISSION DENIED”) until such time as you

CLOSE the file (see section 6.9 ).

READ Opening a file in this manner indicates you are willing to allow other programs to OPEN the file for ONLY

INPUT while you have it OPEN. If they attempt any other OPEN, their OPEN will fail with a file status of 37.

Of course, your program may fail if someone else got to the file first and OPENed it with a sharing option that imposed file-sharing limitations.

6.1.9.2. Record Locking

Record-locking is supported by advanced file-management software that provides a single point-of-control for access to files (usually ORGANIZATION INDEXED files). One such runtime package capable of doing this is the Berkely Database (BDB) package. The various I/O statements are capable of imposing limitations on the access – by other concurrently-executing programs – to the file record they just accessed. These limitations are syntactically imposed by placing a lock on the record. Other records in the file remain available, assuming that file-sharing limitations imposed at OPEN- time didn’t prevent access to the entire file.

Locks remain in-effect until a program holding the lock terminates, Issues a CLOSE (section 6.9 ) against the file, issues an UNLOCK (section 6.48 ) against the file, executes a COMMIT (section 6.10 ) or executes a ROLLBACK (section 6.37 ).

The record locking options (not all options are available to all statements) are as shown in the following table.

Record

Effect

Locking Option

WITH LOCK Access to the record by other programs will be denied. WITH NO

The record will not be locked. This is the default locking option in effect for all statements. LOCK IGNORING

This option is possible only when reading records – it informs OpenCOBOL that any locks held by LOCK

other programs should be ignored. WITH IGNORE

The two options shown are synonymous. LOCK

WITH WAIT This option is possible only when reading records – it informs OpenCOBOL that the program is willing to wait for a lock held on the record being read to be released.

Without this option, an attempt to read a locked record will be immediately aborted and a file status of 47 will be returned.

With this option, the program will wait for a pre-configured time for the lock to be released. If the lock is released within the preconfigured wait time, the read will be successful. If the pre-configured wait time expires before the lock is released, the read attempt will be aborted and a 47 file status will

be issued. If the OpenCOBOL build you are using was configured to use BDB, record locking will be available by using the

execution-time environment variable DB_HOME (see section 7.2.4 ).