z/OS DFSMS Using Data Sets
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Considerations for CBUF Processing

z/OS DFSMS Using Data Sets
SC23-6855-00

If your program shares a data set defined with SHAREOPTIONS(3 3) or SHAREOPTIONS(4 3), you should note that:
  • In a shared environment, VSAM does not allow you to process the data set in an initial load or reset mode (create). VSAM forces your data set to be processed as though it were defined with SHAREOPTIONS(1 3).
  • A user program cannot share a system data set (for example, the master catalog, page space data sets, SYS1. data sets, duplex data sets, and swap data sets).
  • The user's program must serialize all VSAM requests against the data set, using ENQ/DEQ (or a similar function).
  • The user's program must insure that all VSAM resources are acquired and released within ENQ/DEQ protocol to:
    • Force VSAM to write sequential update and insert requests.
    • Release VSAM's positioning within the data set.
  • VSAM invalidates data and index buffers used with cross-region or cross-system SHAREOPTIONS 4 data sets, but does not invalidate buffers used with SHAREOPTIONS 3 data sets. When a buffer is marked nonvalid, it is identified as a buffer that VSAM must refresh (read in a fresh copy of the control interval from DASD) before your program can use the buffer's contents.
  • Programs that use GSR and LSR can invalidate and force writing of buffers using the MRKBFR and WRTBFR macros.
  • Because programs in many regions can share the same data set, an error that occurs in one region can affect programs in other regions that share the same data set. If a logical error (register 15=8) or physical error (register 15=12) is detected, any control block changes made before the error was detected will be propagated to the shared information in common storage.
  • When a VSAM data set requires additional space, VSAM end-of-volume processing acquires new extents for the data set, updates the VSAM control block structure for the data set with the new extent information, and updates the critical control block data in common storage so that this new space is accessible by all regions that use the data set. If the occurrence of an abend or unexpected error prevents this space allocation from being completed, all regions are prevented from further extending the data set. To obtain additional space, you must close the VSAM data set in all regions, then reopen it.
  • To correct the control blocks of a data set after an abnormal termination (abend), issue the VERIFY macro to update them. VERIFY does not modify the data set. You must determine what recovery action is required, if any. A subsequent CLOSE updates the catalog record. The system bypasses the update to the data set's catalog record after an abnormal termination.
  • Implicit VERIFY is invoked by the open-for-output indicator in the catalog. When a data set is opened and the open-for-output indicator is already on, CLOSE processing resets the indicator only if the data set was just opened for output; otherwise it leaves the bit on.
  • Data sets shared in a cross-region or cross-system environment should either use the access method services VERIFY command or issue the VERIFY macro from within the application program.
  • Because programs in many regions can share the same data set, an error in one region can affect programs in other regions that share the data set. If a logical error (register 15=8) or physical error (register 15=12) occurs, control block changes made before the error was detected propagate to the shared information control block in common storage. When this condition occurs, that data set can place incorrect information in the catalog. Check the affected data set by using the appropriate diagnostic tool (such as EXAMINE) to determine if the data set has been corrupted. If the data set is damaged, use an appropriate utility, such as REPRO, to recover the data set.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014