Reconstruction of the user catalog can be initiated at startup (in the case of the home pubset) or with the IMPORT-PUBSET command. Provided that a user catalog was successfully restored in the .BACKUP file before the last shutdown or export.
If a new pubset is created, the SYSSRPM file can also be reconstructed using SIR.
System parameter RECONUC
The reconstruction is controlled by the system parameter RECONUC. The system parameter RECONUC can be set and modified via the startup parameter service. A DIALOG startup allows an additional option of modifying RECONUC: the default value for RECONUC is output via message NSI6010 and you are asked if you wish to modify it.
Note that the system parameters RECONUC and STUPTYPE are connected. If STUPTYPE=J or T is selected, first the first startup is executed (with or without resetting of the user catalog), then the value for RECONUC is evaluated. Message NSI6220 informs you if the value for RECONUC or STUPTYPE is invalid and that it has been set to a default value, which is specified in the message.
The values N, B, T, A and R can be specified for RECONUC. N means no reconstruction.
Example
A: Set of all users existing in the .BACKUP file but not in TSOSCAT
B: Set of all users existing in both the .BACKUP file and TSOSCAT
C: Set of all users existing in TSOSCAT but not in the .BACKUP file
Ideally, sets A and C should be empty, otherwise either user attributes or files could go missing during the reconstruction.
The list below shows which value must be specified for which reconstruction request and how this may possibly affect the sample sets A, B and C. The relevant value is contained in parentheses in the IMPORT-PUBSET command.
Reconstruction by means of BACKUP: RECONUC=B (SCOPE BACKUP)
Based on sets A, B and C, this means:
A: Recreated with the saved attributes.
B: Existing user attributes are updated to the saved ones.
C: Their files and job variables are deleted.
This mode is recommended in the case of regular saving.
Reconstruction via TSOSCAT: RECONUC=T (SCOPE TSOSCAT)
Based on sets A, B and C, this means:
A: no transfer to the reconstructed user structure. This can disrupt the distribution of privileges or the group structure on the pubset concerned such that, for example, a user who in the .BACKUP file exclusively possessed a particular privilege is not transferred to the new user catalog or no group administrator is transferred.
B: Existing user attributes are updated to the saved ones.
C: Set up with default attributes and the preservation of the files, job variables and guards.
This mode is recommended when the preservation of files is paramount and user IDs, if these already exist at the time of the save, are to be reconstructed.
Restoration via BACKUP and TSOSCAT: RECONUC=A (SCOPE ALL)
As with SCOPE BACKUP, the user structure at the time of the save is restored.
As with SCOPE TSOSCAT, files of user IDs which were set up after the save are retained through recreation of the user IDs with default attributes. In the case of two large, disjunctive user structures, this may exceed the capacity of TSOSCAT - a maximum of 8189 user IDs. If so, the import is aborted as soon as this is detected, and can be repeated in one of the modes BACKUP or TSOSCAT.
Resetting the user catalog to the status of TSOSCAT: RECONUC=R (RESET)
This function allows systems support to restore the format of the user catalog while preserving the files. The contents (i.e. the user attributes) must be restored in a second stage with the help of the reconstruction function.
The only alternative in the event of an error is the first startup, in which all IDs, except for those of system administration, and all files which do not belong to the TSOS ID, are lost.
If the SYSSRPM is destroyed by a system error, you should opt for complete pubset reconstruction, as this system error could also have destroyed or damaged other files.
The operator can follow the reconstruction by means of two messages, where the first documents the reconstruction basis at the beginning via the catalog ID and the time of the save (SRM2017 for reconstruction with the .BACKUP file (*BY-BACKUP) or SRM2018 for reconstruction without (*RESET)), and the second specifies at the end the number of reconstructed user IDs (SRM2019 for reconstruction with the .BACKUP file (*BY-BACKUP) or SRM2020 for restoration without (*RESET)).
A logging file is also made available to systems support, see "Logging file".
Reconstruction of a defective user catalog
If the purpose of the reconstruction is to restore a defective user catalog but this catalog cannot be imported due to a defect, an initial rudimentary correction must be made via the RESET function, in which a new user catalog is created on the basis of the user IDs contained in TSOSCAT. The individual user IDs are given default attributes and are all locked except for TSOS and SERVICE. With this method, unlike with a first startup, all files can be retained and the complete rebuilding of the pubset can be avoided.
Unless a zip import is requested, the defective user catalog is not deleted but is stored under the name :catid:$TSOS.SYS.SRPM.RECON.DIAG.<date.time> for later diagnosis of the problem that led to the reset.
CAUTION!
Please bear in mind that when a defective user catalog is passed on to a third party, an unauthorized reconstruction of the user data cannot be ruled out.
As well as the specification of the reconstruction type (see above), the RESET function can also be requested as a response to message SRM2012. This message is only displayed in the event of errors in user administration; errors in other components, such as group administration, lead to abortion of IMPORT-PUBSET processing.
Repercussion on the attributes
Default Pubset
The DEFAULT PUBSET attribute of all user IDs is set to the catalog ID of the reconstructed pubset. The DEFAULT-PUBSET attribute of the remaining user IDs is retained. If the backup of an incompatible pubset configuration was reconstructed, the systems support has the responsibility of assigning the locally valid default pubsets.
Logon passwords
If the user catalog of a system is saved without password encryption (system parameter ENCRYPT) and is reconstructed on a system with password encryption, all logon passwords are encrypted. The corresponding measure in the reverse case is not possible!
Through the reconstruction, all user IDs are given back their logon passwords at the time of the save. It is up to each individual user to remember this password. This applies especially for TSOS or any other ID with the USER-ADMINISTRATION privilege.
SECOS attributes
If the user catalog of a system which has installed SECOS is saved and is then reconstructed on a system without SECOS, the settings of the logon parameters and the privileges of all user IDs are set to their defaults settings. This prevents settings that were made with SECOS from hindering operation without SECOS, even though it is not possible to change these settings.
If, in a reconstruction in a system on which the SECOS subsystem is not available, a .BACKUP file is used (i.e. RECONUC=B, T or A) which was saved on a system which had SECOS available, all privileges are set to their default values as in a first startup. If in this case the .BACKUP file contains a privilege allocation which is only known in a higher BS2000 version (this is possible after changing versions), the unknown privileges in the current version are also reset.
If SECOS is in use on the systems of both the saved user catalog and the reconstructed user catalog, password expiry dates may be reached in the time that elapses between save and reconstruction. The impending locking of the user ID is prevented by reconstruction of the runtime remaining at the time of the save.
SM pubset attributes
If the user catalog of an SF or SM pubset is saved and is then reconstructed on an SM or SF pubset respectively, the SM-pubset-specific attributes are set to their default values (during conversion from SF to SM pubset) or deleted (during conversion from SM to SF pubset).