Open considerations for files shared in a job

There are certain points to consider when you open a shared file in the same job by specifying SHARE(*YES).

• You must make sure that when the shared file is opened for the first time in a job, all the open options that are needed for subsequent opens of the file are specified. If the open options specified for subsequent opens of a shared file do not match those specified for the first open of a shared file, an error message is sent to the program. (You can correct this by making changes to your program to remove any incompatible options.)

  For example, PGMA is the first program to open FILE1 in the job and PGMA only needs to read the file. However, PGMA calls PGMB which will delete records from the same shared file. Because PGMB will delete records from the shared file, PGMA must open the file as if it, PGMA, is also going to delete records. You can accomplish this by using the correct specifications in the high-level language. (In order to accomplish this in some high-level languages, you might need to use file operation statements that are never run. See your appropriate language information for more details.)

• Sometimes sharing a file within a job is not possible. For example, one program might need records from a file in arrival sequence, and another program might need the records in keyed sequence. Or, you might use the same file for printing output, but want to produce the output from each program separately. In these situations, you should not share the open data path. You would specify SHARE(*NO) on the override command to ensure that programs do not share the file within the job.
• If debug mode is entered with UPDPROD(*NO) after the first open of a shared file in a production library, subsequent shared opens of the file share the original open data path and allow the file to be changed. To prevent this, specify SHARE(*NO) on the OVERRIDE command before opening files while debugging your program.
• The use of commitment control for the first open of a shared file, requires that all subsequent shared opens also use commitment control.
• If you did not specify a library name in the program or the OVERRIDE command (*LIBL is used), the server assumes that the library list has not changed since the last open of the same shared file with *LIBL specified. If the library list has changed, you should specify the library name on the OVERRIDE command to ensure that you opened the correct file.
• The server processes overrides and program specifications that are specified on the first open of the shared file. Overrides and program specifications specified on subsequent opens, other than those that change the file name or the value specified on the SHARE or LVLCHK parameters on the OVERRIDE command, are ignored.