Input/output considerations for files shared in a job or an activation group

 

Here are the considerations for processing a database file that is shared in the same job or activation group.

• Because only one open data path is allowed for a shared file, only one record position is maintained for all the programs in the job or activation group that is sharing the file. If a program establishes a position for a record using a read or a read-for-update operation, and then calls another program that also uses the shared file, the record position might have moved or a record lock been released when the called program returns to the calling program. This can cause errors in the calling program because of an unexpected record position or lock condition. When sharing files, it is your responsibility to manage the record position and record locking considerations by re-establishing position and locks.

• If a shared file is first opened for update operation, this does not necessarily cause every subsequent program that shares the file to request a record lock. The system determines the type of record lock needed for each program using the file. The system tries to keep lock contention to a minimum, while still ensuring data integrity.

  For example, PGMA is the first program in the job or activation group to open a shared file. PGMA intends to update records in the file; therefore, when the program reads a record for update operation, it locks the record. PGMA then calls PGMB. PGMB also uses the shared file, but it does not update any records in the file; PGMB just reads records. Even though PGMA originally opened the shared file as update-capable, PGMB does not lock the records it reads, because of the processing specifications in PGMB. Thus, the system ensures data integrity, while minimizing record lock contention.

 

Parent topic:

Sharing database files in the same job or activation group