To be able to run this INIT now , shutdown all Multi-Users and plan to rename the data sets in each Multi-User environment later on to avoid this problem in the future . It is not allowed to use the same data set names in a SYSPLEX environment .
This is documented in the CA Datacom/DB System and Administration Guide under
Data Set Protection in a Datacom environment as follows :
Data set protection ensures that a data set currently in use by a MUF or DBUTLTY cannot be used in a contrary way by another DBUTLTY or MUF. This protection also ensures that a data set being created by DBUTLTY cannot be used by a MUF or other DBUTLTY until the creation process completes.
Data set protection is provided in two layers. The specific data sets and functions that require complete protection are described in the Layer 1 and Layer 2 discussions that follow.
ENQ is provided to protect data sets within CA Datacom processing for Version 14.0 and later releases. ENQ protection uses the z/OS Global Resource Serialization (GRS) facility to ENQ across the systems to ensure a data set can be used for the intended purpose. With this layer of protection, any protection of the CXX, LXX, or FXX lasts for the entire job step. Any protection for database data sets for the index or data areas lasts only for the specific DBUTLTY function having the requirement.
Layer 1 is implemented using the ENQ ability of z/OS to lock a resource by name using GRS. The value for the ENQ has a major name of CADTCM02 and a minor name of the characters DSN, a dash, and the data set name.
Functions that need full protection of a data set cause an exclusive ENQ to ensure they are running alone. All other opens of data sets cause a share ENQ to allow multiple users but not a single exclusive user. If a conflict occurs, it produces the DB01408E message, is recognized as a CA Datacom return code of 76(012), and the execution terminates. This return code is accompanied by a DB01408E console message.
For more information about messages and codes, see the CA Datacom/DB Message Reference Guide.
DISPOLD is provided to protect data sets within CA Datacom processing for all releases and also outside CA Datacom processing. It provides similar protection to Layer 1.
With Layer 2 protection, any protection of the CXX, LXX, or FXX, lasts for the entire job step. Any protection for database data sets for the index or data areas lasts only for the specific DBUTLTY function having the requirement. An exception exists if the specific data set name protected is referenced in a subsequent step of the job. The protection is extended by the operating system to include the remainder of the step where acquired through all the succeeding steps and through the step where it is last specified.
Layer 2 is implemented using the operating system DD statement protection, based on the DISP keyword with the setting of OLD. If the DBUTLTY JCL for the data set is provided with a DISP other than SHR, the JCL has provided all the protection it can. If the JCL has SHR, this feature escalates the protection to exclusive control, equivalent to coding DISP=OLD in the JCL.
Layer 2 protection works using the z/OS dynamic allocation ability to have an additional DD statement added with the same data set name as the data set needing protection and having DISP=OLD set. The effective result is the DISP=SHR protection is changed to DISP=OLD without any change to existing DBUTLTY JCL streams. The DDNAME selected is DISPOLD, picked as unlikely to exist in a DBUTLTY JCL stream and being descriptive of its functionality. This protection is for a data set currently open elsewhere and of little value if the data set is currently not open.
This escalation of the data set protection exists for the entire life of the DBUTLTY step, and if the same data set name exists in a later step in the job stream, the protection lasts for all the steps. This could possibly cause JCL change requirements to exist in DBUTLTY JCL.
Note: Dynamic allocation of database index and area data sets is always done with DISP=SHR. This protection is low overhead. It does not protect from all mistakes. For example, one such common mistake is to initialize or load a data set that is currently open and in use.