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.