The user data and the associated administration and protection information are retained except for the following restrictions:
If one or more of the SF pubsets transferred to the volume set was usable as the home pubset, this option no longer possible; an SM pubset can no longer be used as the home pubset.
Only the contents of the guard entries in the pubsets specified for conversion are adapted and remain valid (if they can be adapted; if not, the warnings mentioned on "Outputs" and following are output; the relevant guard entries must be adapted by the guard owner.)
Guard entries in other pubsets can be rendered invalid by conversion. This happens when the access condition contains the name of a program that was cataloged in the SF pubset. Since the path name of the program has changed during the conversion, the program that has the access right is no longer found. The owner of the guard must therefore modify the guard.
The SYSEAM files are lost.
The privileges and authorizations relevant only to the home pubset are either lost or taken over by exactly one of the SF pubsets, depending on the setting of the KEEP-USER-ATTRIBUTES parameter.
The logon password are either lost or taken over by exactly one of the SF pubsets, depending on the setting of the KEEP-USER-ATTRIBUTES parameter.
(In the latter case, the logon passwords are lost for users who do not have a user entry on the specified SF pubset. However, as the system does not check passwords which are stored on SM pubsets, this is not important.)The group structures are either lost or taken over by exactly one of the SF pubsets, depending on the setting of the KEEP-USER-ATTRIBUTES parameter.
The user IDs for which no group structure is adopted are assigned to the group *UNIVERSAL.
(This is in the one case all user IDs, and in the other the user IDs that are not entered on the specified pubset or have not been assigned to a group there).The SYSSRPM.BACKUP file is lost. This means that the pubset conversion and switchover to another user catalog cannot be carried out simultaneously.
SPOOL jobs are lost if they refer to files that have the catalog ID of a converted SF pubset, since the catalog ID is not adapted in the SPOOL job queue. Any print jobs from an earlier session that it still contains must therefore be restarted and the associated temporary files must then be deleted explicitly by systems support.
The HSMS-EXCEPT-FILE files loses its effect. To restore the protection against unwanted file displacement, systems support can create a pubset-specific EXCEPT-FILE on the SM pubset and assign it to the pubset when setting up the HSMS environment, or assign the attribute MIGRATE=*FORBIDDEN to the files affected.
Pubset configuration files that do not originate from an aborted reconfiguration job or from an aborted cache mode change are deleted implicitly, and a warning is issued. It is recommended not to carry out pubset conversion if the reconfiguration is incomplete, or if the cache mode has been changed; instead, clean up the pubset beforehand using
/RESUME-PUBSET-RECONFIGURATION.