The CREATE-SYSTEM-MANAGED-PUBSET statement can be used by the privileged user to transfer up to 255 SF pubsets to an SM pubset, each SF pubset becoming a volume set of the SM pubset. Here the user data and the associated management and protection information is, with a few exceptions (see "Restrictions"), retained.
When new SM pubsets are created from existing SF pubsets the following steps are performed within the system:
Syntactic check of the statement and preview of the result
If the task in running in interactive mode, the structure of the SM pubset to be created is listed in screen mask 12 and again in screen mask 13 after successful import of the pubset, following the syntactic check of the CREATE-SYSTEM-MANAGED-PUBSET statement; in both masks, the user can also abort the function.
Implicit consistency check
Before the disks are modified, implicitly a consistency check is run over the pubsets involved, see also section “Check function (consistency check)”. If inconsistencies are detected, the function is aborted with an error; detailed error information is output (see also the outputs of the check function in section “Outputs”).
If guard conditions cannot be adapted (item 2, "What is checked?") messages are output during the consistency check. The consistency check is deemed terminated without error (but with warnings).
The possible consequences of an abort following a consistency check are discussed in section “Error behavior”.Exclusive reservation of the disks by SMPGEN
Both during the consistency check and during subsequent processing, SMPGEN accesses public disks exclusively. A flag is set in the MRSCAT entries of the pubset to indicate that they are currently being processed by SMPGEN.
The pubsets cannot be imported during the entire procedure and their MRSCAT entries can neither be deleted nor modified.
An MRSCAT entry is also created for the new SM pubset; this entry cannot be deleted or modified during the procedure and the pubset is marked in the entry as “being created”.
Conversion of the pubsets
The disk SVLs are modified in the course of conversion so that the old SF pubsets can no longer be imported as such. Their association with the SM pubset and the control volume set is permanently anchored in the SVL.
BS2000/OSD-BC V6.0 is stored in the SVL as the lowest operating system version that supports the pubset.
Deletion of all MRSCAT entries of the converted pubsets
Following successful conversion to an SM pubset, the MRSCAT entries of the pubsets that are to be converted to volume sets are deleted.
The MRSCAT entry of the new SM pubset to be created is retained.
The values to be set in the MRSCAT entry of the pubset, e.g. Cache-SIZE-TOLERANCE, are set to the default values.
Simulation mode
If the OPERATIONAL-MODE=*SIMULATION operand is specified, the function is not actually performed. Only a syntax check is carried out and the specified volume sets are listed. For more details, refer to the operand descriptions.
Check mode
If the OPERATIONAL-MODE=*CHECK-NAME-CONSISTENCY operand is specified, only the check function is performed. For more information please see "Check function (consistency check)".
Notes
The files that reside on the pubsets remain in their original physical locations.
The contents of the associated catalog entries remain unchanged, except for the file on a pubset that becomes the volume set with the attribute AVAILABLITY=*HIGH (where the file is not a temporary file):
In this case, the file attribute in the catalog entry is set to AVAILABILITY=*HIGH, which means that the file cannot be migrated to a volume set with a lower availability.
The catalog entries of files that have no disk assignment to the SF pubsets (e.g. migrated files, private disk or volume disks) retain their original contents, just like the job variables.
Whenever possible, BS2000 OSD/BC from V11.0 onwards only supports the EXTRA LARGE catalog format, see the “Introduction to System Administration” [5 (Related publications)]. The NORMAL and LARGE catalog formats are now obsolete. The following aspects must be taken into consideration:
Catalogs of a preceding version in the NORMAL or LARGE format are automatically converted into the EXTRA LARGE format as soon as the pubset is imported exclusively or as master. At the same time, the special catalogs are renamed as well. These converted catalogs can be used in a preceding version as well.
The SM is created with the catalog format EXTRA LARGE. However, the conversion of the catalogs does not take place during the SMPGEN run, but during the first import after the run, see previous point. It is thus recommended that you import the SM pubset immediately after the SMPGEN run.
When a new SM pubset is generated, only one special catalog of the types TSOSCAT.#M00, TSOSCAT.#J00 and TSOSCAT.#P00 each is created. If these catalogs are not large enough to contain all special catalog entries, it is advisable first to generate an SM pubset comprising the future control volume set and then to import this pubset. Additional special catalogs can subsequently be created with
/ADD-CATALOG-FILEand the SM pubset can be extended by the remaining SF pubsets in a second SMPGEN run.
If GUARDS is used, the message PRO6009 ERROR WHEN CLOSING GUARDS CATALOG is output for each affected volume set when the volume sets are exported after successful pubset conversion; this message can be ignored.
The contents of the guards also remain unchanged. For guards that reference a program that is cataloged in the pubsets to be converted, the catalog ID in the path name is replaced by the new pubset ID (this applies only to guard entries within the new SM pubset, however; guard entries in other pubsets are not adapted; further, it is not possible to have automatically adaptable guards, see section “Restrictions”).
The user entries are transferred in the valid format for SM pubset, whereby group structures could be lost (see section “Restrictions”).
If there is a user ID on the pubset but not on the pubset that is to be used for the logon information, the user ID is marked “locked” in the SM pubset (USER-LOCKED=*YES), since no accounting information is available. This is not relevant for using the SM pubset as a data pubset.
If there is a user ID on more than one of the pubsets that are to be combined to form an SM pubset, this ID is treated as though it were the same user.
SMPGEN requires a correct SYSFILE environment. If the function is to be executed in a new batch task that is to be created, the default pubset of the runtime user ID (or in ACS defined Spool-Pubset) must be imported. If SYSOUT or SYSLST outputs fails repeatedly, the SMPGEN function is terminated with an error.
The (physical) format of the control volume set is entered as DEFAULT FILE FORMAT.
If several pubsets with different formats are combined, the DEFAULT FILE FORMAT created by SMPGEN may have to be modified.
Example
The format of the control volume set is K; all other volume sets are keyless (NK); in this case, the files are created on the control volume set per default and this becomes too full.
CREATE-SYSTEM-MANAGED-PUBSET OPERATIONAL-MODE= *OPERATION should never be called without a previous FDDRL backup of the pubset to be converted, since an abort due to an error would destroy all the pubsets and render them inaccessible.
A logical backup using HSMS is also recommended. Here, a new backup archive can be created which can be used for the creation of the HSMS environment for the SM pubset. For details of how to adapt the HSMS environment, refer to the description of SMS migration in the “System-Managed Storage” manual [8 (Related publications)].
SPOOL jobs for files that are cataloged in the pubsets to be converted should no longer be present, since they can no longer be carried out after renaming the catalog ID.
When the operating system is operated without SECOS at the time of pubset conversion, SECOS-specific user information (e.g. group information, privileges) is completely lost even if KEEP-USER-ATTRIBUTES=*ALL is specified.