Except for PDSEs, the system does not protect data integrity when multiple DCBs are open for output and the DCBs access a data set within the same job step. The system ensures that only one program in the sysplex can open a PDS with the OUTPUT option, even if you specify DISP=SHR. If a second program issues OPEN with the OUTPUT option, for the PDS with DISP=SHR, while a DCB is still open with the OUTPUT option, the second program gets a 213-30 ABEND. This does not apply to two programs in one address space with DISP=OLD or MOD, which would cause overlaid data. This 213-30 enforcement mechanism does not apply when you issue OPEN with the UPDAT option. Therefore programs that issue OPEN with UPDAT and DISP=SHR can corrupt the PDS directory. Use DISP=OLD to avoid the possibility of an abend during the processing of a PDS for output or of corrupting the directory when it is open for update. If a program writes in a PDS while protected with DISP=NEW, DISP=OLD, or DISP=MOD, a program reading from outside of the GRS complex might see unpredictable results such as members that are temporarily missing or overlaid.

The DCBE must not be shared by multiple DCBs that are open. After the DCB is successfully closed, you may open a different DCB pointing to the same DCBE.

The operating system provides job control language (JCL) statements and macros that help you ensure the integrity of the data sets you want to share among the tasks that process them. Figure 1 and Figure 2 show which JCL and macros you should use, depending on the access method your task is using and the mode of access (input, output, or update). Figure 1 describes the processing procedures you should use if more than one DCB has been opened to the shared data set. The DCBs can be used by tasks in the same or different job steps.

The purpose of the RLSE value for the space keyword in the DD statement is to cause CLOSE to free unused space when the data set becomes closed. The system does not perform this function if the DD has DISP=SHR or more than one DCB is open to the data set.

Figure 1. JCL, Macros, and Procedures Required to Share a Data Set Using Multiple DCBs

DISP=SHR. Each job step sharing an existing data set must code SHR as the subparameter of the DISP parameter on the DD statement for the shared data set to let the steps run concurrently. For more information about ensuring data set integrity see z/OS MVS JCL User's Guide.

Related reading: For more information about sharing PDSEs see Sharing PDSEs. If the tasks are in the same job step, DISP=SHR is not required. For more information about detecting sharing violations with sequential data sets, see Enhanced Data Integrity for Shared Sequential Data Sets.

No facility. There are no facilities in the operating system for sharing a data set under these conditions.

ENQ on data set. Besides coding DISP=SHR on the DD statement for the data set that is to be shared, each task must issue ENQ and DEQ macros naming the data set or block as the resource for which exclusive control is required. The ENQ must be issued before the GET (READ); the DEQ macro should be issued after the PUTX or CHECK macro that ends the operation.

Related reading: For more information about using the ENQ and DEQ macros see z/OS MVS Programming: Assembler Services Reference ABE-HSP.

Guarantee discrete blocks. When you are using the access method that provides blocking and unblocking of records (QSAM), it is necessary that every task updating the data set ensure that it is not updating a block that contains a record being updated by any other task. There are no facilities in the operating system for ensuring that discrete blocks are being processed by different tasks.

ENQ on block. If you are updating a shared data set (specified by coding DISP=SHR on the DD statement) using BSAM or BPAM, your task and all other tasks must serialize processing of each block of records by issuing an ENQ macro before the READ macro and a DEQ macro after the CHECK macro that follows the WRITE macro you issued to update the record. If you are using BDAM, it provides for enqueuing on a block using the READ exclusive option that is requested by coding MACRF=X in the DCB and an X in the type operand of the READ and WRITE macros. For an example of the use of the BDAM macros see Exclusive Control for Updating.

Figure 2 describes the macros you can use to serialize processing of a shared data set when a single DCB is being shared by several tasks in a job step.

Figure 2. Macros and Procedures Required to Share a Data Set Using a Single DCB

ENQ. When a data set is being shared by two or more tasks in the same job step (all that use the same DCB), each task processing the data set must issue an ENQ macro on a predefined resource name before issuing the macro or macros that begin the I/O operation. Each task must also release exclusive control by issuing the DEQ macro at the next sequential instruction following the I/O operation. Note also that if two tasks are writing different members of a PDS, each task should issue the ENQ macro before the FIND macro and issue the DEQ macro after the STOW macro that completes processing of the member. See z/OS MVS Programming: Assembler Services Reference ABE-HSP for more information about the ENQ and DEQ macros.

No action required. See Sharing DCBs.

ENQ on block. When updating a shared direct data set, every task must use the BDAM exclusive control option that is requested by coding MACRF=X in the DCB macro and an X in the type operand of the READ and WRITE macros. See Exclusive Control for Updating for an example of the use of BDAM macros. Note that all tasks sharing a data set must share subpool 0. See the ATTACH macro description in z/OS MVS Programming: Assembler Services Reference ABE-HSP.

Key sequence. The DISP=SHR specification on the DD statement is not required.

Data sets can also be shared both ways at the same time. More than one DCB can be opened for a shared data set, while more than one task can be sharing one of the DCBs. Under this condition, the serialization techniques specified for direct data sets in Figure 1 satisfy the requirement. For sequential and PDSs, the techniques specified in Figure 1 and Figure 2 must be used.

Shared Direct Access Storage Devices. At some installations, DASDs are shared by two or more independent computing systems. Tasks run on these systems can share data sets stored on the device. Accessing a shared data set or the same storage area on shared DASD by multiple independent systems requires careful planning. Without proper intersystem communication, data integrity could be endangered.

To ensure data integrity in a shared DASD environment, your system must have global resource serialization (GRS) active or a functionally equivalent global serialization method.

Related reading: For information on data integrity for shared DASD, see z/OS MVS Programming: Authorized Assembler Services Guide. For details on GRS, see z/OS MVS Planning: Global Resource Serialization.