Typical scenario

When converting SF pubsets to SM pubsets, it is generally not sufficient just to call the SMPGEN function CREATE- or MODIFY-SM-PUBSET. Rather, systems support has the task of making sure that the conversion is as easy as possible for the user. After the SMPGEN run, various work must be performed before the SM pubset can be operated as required.
In particular, the pubsets generated by SMPGEN are not yet supported by HSMS. in order to be able to process migrated files, it is first necessary to set up an HSMS environment. Depending on the complexity of the existing HSMS environments, there are several ways of modifying the HSMS environment; these require special preparation; for details please refer to the “System-Managed Storage” manual [8 (Related publications)].

The actions which can be necessary and useful when converting to SM pubsets are described below:

• If several SF pubsets are to be combined, it is useful to perform a consistency check first. This determines whether or not conversion is possible.

• If conversion is possible, the users are informed that references to the old pubset IDs in all BS2000 procedures must be replaced by references to the new pubset ID.

  Normally, the users are not really affected greatly by this, since the files are addressed via the standard catalog ID in the user catalog.
  Data inventory systems are not really affected either, since they use a specific addressing logic to hide the location of the file from the user.
  If applications that have to work with particular pubsets are present, they must in future specify, along with the pubset ID of the SM pubset, the relevant volume set ID or a storage class that references the desired volume set when storing the files. However, it is not possible to specify this ID unless the relevant user ID possesses the physical allocation right in the pubset. This right must be assigned explicitly following conversion.

  If only one SF pubset is to be converted, it is useful to first rename this pubset with PVSREN and to specify the old pubset ID as the pubset ID of the SM pubset. This ensures that the catalog ID in the file name is not changed and that the JCL of the user does not need to be adapted. Similarly, the catalog ID may be retained as the standard catalog ID in the user catalog.

  The procedure is analogous when several SF pubsets are to be combined, but one of them has to play a special role in the system; it can be expedient to rename this pubset and specify its old pubset ID as the pubset ID of the SM pubset.

  The control volume set should be as reliable as possible and should therefore also not be too large. It must, however, provide enough space for the new catalogs to be created (see section “Creating new SM pubsets”).

• If a consistency check has already been carried out and conflicts have been detected in the file names or in the guards, systems support must request the user to resolve these conflicts.

• Systems support is responsible for resolving name conflicts in system files. System files anchored in the SVL (IPL, SLEDSAVE etc.) should not be deleted; they should either be renamed or be deleted by using the SIR statement DELTE-IPL-FACILITY.
  To resolve name conflicts in (HSMS) migration directories, rename the directories and adapt the associated archive definitions to match the new directory names.

• If necessary, paging files must be deactivated using /REDUCE-PAGING-AREA.

• Systems support checks whether snapsets exist for the SF pubsets. If this is the case, they delete the snapsets.

• Systems support prepares the inputs for the SMPGEN run and possibly a procedure for importing the SM pubset.

• If the SM pubset is to be operated with HSMS support (always necessary if several migrated files are present), systems support prepares the conversion or adaption of the HSMS environment.
  (The catalog entries of the migrated files are retained after conversion; however, it is not possible to recall these files, until HSMS support has been established. Similarly, there is no backup environment. Direct access to previous backups is not possible.)

• It may be useful to perform a further consistency check in offline mode. The users should, if necessary, be informed of any inconsistencies that have to be resolved.

• When all inconsistencies have been resolved, conversion to the SM pubset may be started at a time agreed with the users, at which the SF pubsets are not being used.

  Some final preparatory work may be required for conversion of the HSMS environment, e.g. relocation of the migrated files on the S1 level to S2 to ensure that the conversion will be successful.
  First, a full logical backup and an FDDRL backup of the pubsets is made. Then the pubsets are converted using the SMPGEN statement CREATE- or MODIFY-SYSTEM-MANAGED-PUBSET.

  If there are still inconsistencies at this point, or if new one are encountered, they are listed; conversion is not performed, and the pubsets can still be imported as SF pubsets.

• Following successful conversion, the standard catalog IDs that correspond to the volume set IDs should be replaced by the pubset ID of the SM pubset in the user catalogs of all systems in which the pubset is to be imported.

• The program name must be modified in the guards of other pubsets which reference a program in the new SM pubset. Systems support can provide the users with a corresponding SDF-P procedure.

• Now the new SM pubset can be imported normally, for which ACTUAL-JOIN=*STD must apply.
  An extended SM pubset must be reimported in order to perform outstanding recovery measures after the SMPGEN run. Here, too, ACTUAL-JOIN=*STD (default) must be specified. SIZE-TOLERANCE=*YES must, if required, be entered previously in the MRSCAT entry of the SM pubset (with /MODIFY-PUBSET-CACHE-ATTRIBUTES); it then applies to all volume sets.

• If the SM pubset is to contain volume sets with USAGE=*WORK, these must be added to the imported pubset using /MODIFY-PUBSET-DEFINITION-FILE and put into operation with /MODIFY-PUBSET-PROCESSING.

• Now, if desired, HSMS support and the HSMS environment can be set up or adapted.

• The quotas and pubset-wide authorizations can be adapted to the special conditions, e.g. by restricting the work quotas.
  Groups can be generated or the group constellation completed. If desired, the groupspecific quotas may be changed.

• If desired, the standard file format (FILE FORMAT) may be modified.

• If guard condition faults are notified, the guard owners must check the relevant guard entries and adapt the new pubset ID as required.

• If software was installed on one of the converted SF pubset using IMON, and the catalog ID of the installed files has changed, the software configuration inventory (SCI) must be modified with /MODIFY-IMON-SCI. The name of the SF pubset prior to conversion must be specified for OLD-NAME, and the name of the SM pubset specified for NEW-NAME.

• After successful conversion of the pubset, systems support should inform the user.