Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
14 <strong>File</strong> <strong>Management</strong> V4R5<br />
For example, PGMA is the first program to open FILE1 in the job and PGMA<br />
only needs to read the file. However, PGMA calls PGMB which will delete<br />
records from the same shared file. Because PGMB will delete records from the<br />
shared file, PGMA will have to open the file as if it, PGMA, is also going to<br />
delete records. You can accomplish this by using the correct specifications in the<br />
high-level language. (In order to accomplish this in some high-level languages,<br />
you may have to use file operation statements that are never run. See your<br />
appropriate language information for more details.)<br />
v Sometimes sharing a file within a job is not possible. For example, one program<br />
may need records from a file in arrival sequence, and another program may<br />
need the records in keyed sequence. Or, you may use the same file for printing<br />
output, but want to produce the output from each program separately. In these<br />
situations, you should not share the open data path. You would specify<br />
SHARE(*NO) on the override command to ensure that programs do not share<br />
the file within the job.<br />
v If debug mode is entered with UPDPROD(*NO) after the first open of a shared<br />
file in a production library, subsequent shared opens of the file share the original<br />
open data path and allow the file to be changed. To prevent this, specify<br />
SHARE(*NO) on the OVERRIDE command before opening files while debugging<br />
your program.<br />
v The use of commitment control for the first open of a shared file, requires that<br />
all subsequent shared opens also use commitment control.<br />
v If you did not specify a library name in the program or the OVERRIDE<br />
command (*LIBL is used), the system assumes that the library list has not<br />
changed since the last open of the same shared file with *LIBL specified. If the<br />
library list has changed, you should specify the library name on the OVERRIDE<br />
command to ensure that you opened the correct file.<br />
v The system processes overrides and program specifications that are specified on<br />
the first open of the shared file. Overrides and program specifications specified<br />
on subsequent opens, other than those that change the file name or the value<br />
specified on the SHARE or LVLCHK parameters on the OVERRIDE command,<br />
are ignored.<br />
I/O considerations for files shared in a job<br />
The system uses the same input/output area for all programs sharing the file, so<br />
the order of the operations is sequential regardless of which program does the<br />
operation. For example, if Program A is reading records sequentially from a<br />
database file and it reads record 1 just before calling Program B, and Program B<br />
also reads the file sequentially, Program B reads record 2 with the first read<br />
operation. If Program B then ends and Program A reads the next record, it receives<br />
record 3. If the programs were not sharing the file, Program A would read record 1<br />
and record 2, and Program B would read record 1.<br />
For device files, the device remains in the same state as the last I/O operation.<br />
For display and ICF files, programs other than the first program that opens the file<br />
may acquire more display or program devices or release display or program<br />
devices already acquired to the open data path. All programs sharing the file have<br />
access to the newly acquired devices, and do not have access to any released<br />
devices.
Change language