Protecting Data When File Access is Shared

If a KSAM file is shared with another process, you need to ensure that the most current data and key index information is retrieved. Locking files controls other processes from accessing the file while a modification routine is processing. Such a modification routine should include the pointer positioning and reading routines that are associated with the modification routine. The FUNLOCK intrinsic allows the file to be shared again, once modifications are complete.

In a shared environment, it is recommended that you lock and unlock the file for pointer-related activities, such as FREAD or FUPDATE intrinsics using FFINDBYKEY or FFINDN intrinsics to locate the proper record.

	NOTE: File locking keeps the file inaccessible to other users for an indeterminate length of time. This could be a potential source of performance problems. A different file structure may be more suitable for applications in a shared environment.

The following example shows how modification routines can be locked effectively by the placement of the FLOCK and FUNLOCK intrinsics.

FLOCK
FREADBYKEY
FUPDATE
FUNLOCK
 
 
FLOCK
FFINDBYKEY
FREAD loop
FUNLOCK

In many interactive processes, it is inefficient to keep a file locked while a user retrieves a record, decides whether it needs to be updated, makes appropriate changes, and writes the new record. In such cases, a simple read could retrieve the record's contents for the online user to see. Once a decision has been made to modify the contents, a new retrieval redisplays the record for updating. By rereading the file, the program will be able to verify that the correct record has been retrieved without locking the file for an excessive amount of time.

FLOCK
FREADBYKEY
FUNLOCK
.
.
.
 Other users can access and modify this record while
 the user decides how to update it.
.
.
.
FLOCK
FREADBYKEY
FUPDATE
FUNLOCK