Requirements for operation of SMPGEN

Requirements of the operating system and the job task

• If a guard catalog exists in at least one SF pubset (i.e. the file $TSOS.SYSCAT.GUARDS), the GUARDS subsystem must be loaded.

• Output to an S variable is supported only by the product SDF-P, which must be purchased separately. The VAS subsystem must also be loaded.

In addition to these requirements, the following conditions must also be observed for the MODIFY- and CREATE-SYSTEM-MANAGED-PUBSET statements, depending on the function called:

• The $TSOS.SYSACL.FILE file may not be present on any of the pubsets as the SRPMFACL (FACS) subsystem has not been avaialble since BS2000/OSD-BC V5.0.

• An MRSCAT entry must be present for each pubset.

• The pubsets must not be imported in the local system nor in another system. There must be no import of export (/IMPORT-PUBSET or /EXPORT-PUBSET) running for them.

• No files on Net-Storage volumes may be listed in the pubset’s catalog. These catalog entries must be deleted before a SMPGEN run (/EXPORT-FILE or, see next paragraph, /REMOVE-NET-STORAGE-VOLUME, operand FILES-ON-VOLUME=*EXPORT).

• All Net-Storage volumes must be removed from the pubsets (/REMOVE-NET-STORAGE-VOLUME). On the other hand, Net-Storage volumes may be assigned to the existing SM pubset.

• When the function is called by a nonprivileged user (for which the value CHECK-NAME-CONSISTENCY(PUBSET-STATE=*IMPORTED) is assumed implicitly), the SF pubsets must have the state “local accessible”, i.e. imported locally. If USER-ID=*ALL is specified, either the pubsets must be imported as system-exclusive or the local system must be the pubset master.

Requirements for the original pubsets (SF pubsets)

The following conditions apply to SF pubsets to be converted to an SM pubset:

• They must be capable of being imported into the current version of the operating system with ACTUAL-JOIN=*STD, i.e. without regeneration of the user catalog. This means that they have must already have been imported at least once.

• There may be no more that 8190 different user IDs in the SF pubset (= maximal number of users in an SM pubset).

• No more than 255 SF pubsets can be converted to an SM pubset.

• The paging files on the SF pubsets may not be active (i.e. they may need to be deactivated beforehand).

• No snapsets may exist for the SF pubsets (i.e. system administration may need to delete these beforehand). Empty snapset catalogs are deleted by SMPGEN if necessary.

• If the caller does not specify the operand S1-MIGRATED-FILES=*ALLOWED, the following also applies: there must be no migrated files cataloged on the S1 level. (i.e. any present must be migrated to S2 beforehand).

The first three conditions stated also apply to the check function.

Furthermore, it must be possible to set up new system files without encountering any name conflicts. The precise requirements are listed in the description of the statements.

Notes for Large-Objects pubsets

• If one of the original pubsets is a Large-Objects pubset, the SM pubset created will also be a Large-Objects pubset. The displays for this are located in both the MRSCAT of the SM pubset created and in the DMS entry of the control volume set.

• For security reasons, the displays are also stored in the DMS entry of the other volume sets.

Starting SMPGEN

The SMPGEN functionality is made available by the nonprivileged subsystem SMPGEN-U. SMPGEN-U should be loaded beforehand for performance reasons by systems support with /START-SUBSYSTEM SUBSYSTEM-NAME=SMPGEN-U.

SMPGEN is started during the session with /START-SMPGEN. The SMPGEN-S subsystem is called internally by SMPGEN-U. Both subsystems cannot be replaced by means of DSSM. Parallel product versions are not supported.