Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

Extending an existing SM pubset

&pagelevel(3)&pagelevel

The MODIFY-SYSTEM-MANAGED-PUBSET statement is used by the privileged user to extend an existing SM pubset by the addition of SF pubsets, each SF pubset becoming a volume set of the SM pubset. When the statement is executed a check is made to see that a maximum of 255 volume sets are contained in the extended SM pubset.

The user data and the associated management and protection information of the SF pubsets to be added and of the existing SM pubset are, with a few exceptions (see section “Restrictions”), retained.

When new SM pubsets are extended the following steps are performed within the system:

  1. 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 extended is listed in screen mask 12 and again in screen mask 13 after successful import of the pubset, following the syntactic check of the MODIFY-SYSTEM-MANAGED-PUBSET statement; in both masks, the user can also abort the function.

    With MODIFY-SYSTEM-MANAGED-PUBSET only the newly added volume sets are listed in screen masks 12 and 13. The existing volume sets of the SM pubset are not displayed in the list.

  2. 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”ff.

  3. 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. The MRSCAT entry of the SM pubset to be extended is marked as “being generated”.

  4. Conversion of the pubsets

    The disk SVLs of the SF pubsets 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.

  5. Deletion of all MRSCAT entries of the converted pubsets

    Following successful conversion to an SM pubset, the MRSCAT entries of the SF pubsets that are to be converted to volume sets are deleted.

  6. Reworking

    After the SMPGEN statement for extending an SM pubset has been executed this does not mean that extension of the SM pubset has been completed. Nor is a renewed extension of the SM pubset possible immediately after the SMPGEN statement for extending an SM pubset has been executed. Extension of an SM pubset can be completed only after the SM pubset has been successfully imported and the next extension of the SM pubset with SMPGEN is permitted after this.

    When the next import - which must be initiated by the user - takes place the CMS catalogs of the SM pubset are cleared of superfluous job variable entries.

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

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.

Whenever possible, BS2000 from OSD/BC 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. When SM pubsets are extended in conjunction with SF pubsets, the following special aspects must be taken into consideration:

  1. 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.

  2. While an SM pubset is being extended, only the special catalogs are available that already exist. However, if necessary, these will be extended to their maximum size during the SMPGEN run (32008 4K blocks).

 

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 the SPOOL pubset defined in ACS) must be imported. If SYSOUT or SYSLST outputs fails repeatedly, the SMPGEN function is terminated with an error.

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.

WARNING!
  • MODIFY-SYSTEM-MANAGED-PUBSET OPERATIONAL-MODE= *OPERATION should never be called without a previous FDDRL backup of the SF pubsets to be converted, since an abort due to an error would destroy all the SF 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 extended 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 SF pubsets to be converted should no longer be present, since they can no longer be carried out after renaming the catid.