Open considerations for files shared in a job or an activation group

 

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

• Make sure that when the shared file is opened for the first time in a job or activation group, all the open options 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 or to the Open Database File (OPNDBF) or Open Query File (OPNQRYF) command parameters, to remove any incompatible options.)

  For example, PGMA is the first program to open FILE1 in the job or activation group 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 will have to 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. (To accomplish this in some high-level languages, you might have to use file operation statements that are never run. See your high-level language topic collection for more details.) You can also specify the file processing option on the OPTION parameter on the OPNDBF and OPNQRYF commands.

• Sometimes sharing a file within a job or activation group is not desirable. For example, one program needs records from a file in arrival sequence and another program needs records in keyed sequence. In this situation, you should not share the open data path (ODP). Specify SHARE(*NO) on the Override with Database File (OVRDBF) command to ensure that the file is not shared within the job or activation group.

• 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 ODP and allow the file to be changed. To prevent this, specify SHARE(*NO) on the OVRDBF command before opening files being debugged.

• The use of commitment control for the first open of a shared file requires that all subsequent shared opens also use commitment control.

• Key feedback, insert key feedback, or duplicate key feedback must be specified on the full open if any of these feedback types are desired on the subsequent shared opens of the file.

• If you did not specify a library name in the program or on the OVRDBF command (*LIBL is used), the system 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 OVRDBF command to ensure that the correct file is opened.

• The record length that is specified on the full open is the record length that is used on subsequent shared opens even if a larger record length value is specified on the shared opens of the file.

• Overrides and program specifications specified on the first open of the shared file are processed. 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 parameter of the OVRDBF command, are ignored.

• Overrides specified for a first open using the OPNQRYF command can be used to change the names of the files, libraries, and members that should be processed by the OPNQRYF command. Any parameter values specified on the OVRDBF command other than TOFILE, MBR, LVLCHK, and SEQONLY are ignored by the OPNQRYF command.

• The OPNDBF and OPNQRYF commands scope the ODP to the level specified on the Open Scope (OPNSCOPE) parameter according to the following rules:

  • The system searches for shared opens in the activation group first, and then in the job.

  • Shared opens that are scoped to an activation group might not be shared between activation groups.

  • Shared opens that are scoped to the job can be shared throughout the job, by any number of activation groups at a time.

The CPF4123 diagnostic message lists the mismatches that can be encountered between the full open and the subsequent shared opens. These mismatches do not cause the shared open to fail.

The OPNQRYF command never shares an existing shared ODP in the job or activation group. If a shared ODP already exists in the job or activation group with the same file, library, and member name as the one specified on the OPNQRYF command, the system sends an error message and the query file is not opened.

 

Parent topic:

Sharing database files in the same job or activation group