SMPGEN creates several WORK files when processing statements; these normally exist only during the SMPGEN session.
In the event of a system failure or recovery errors, such files can of course exist beyond the SMPGEN session. They can be recognized by the prefix SYSWRK.SMPGEN or S.SMPGE. SYSWRK.SMPGEN... files must be deleted by systems support before starting a new SMPGEN session.
Special points when creating or extending SM pubsets
SMPGEN attempts to rule out situations that prevent formation of an SM pubset as early as possible by performing a consistency check. Even after a successful check, the pubset structures are not changed initially, only the new management files are created.
In the event of an extension the SM pubset’s management data is saved by copying it. During conversion, the old administration files are also retained in the main, so that SMPGEN can restore the old environment in the event that conversion fails or that the task is aborted. The pubsets involved are then returned to their old states.
Only the SYSPBN and EAM files could be deleted.
Only in the last phase (after all checks have been completed successfully and disk space requirements are satisfied) is it no longer possible to return to the old state of the SF pubsets. A fatal error in this phase (just like a system crash in the middle phase of conversion) would mean that the pubsets could no longer be imported; they have to be reconstructed from the previous FDDRL backup.
During the critical phase of conversion, the pubsets and volume sets are marked as not importable.
If an import is not possible following a system crash, either as an SF or an SM pubset, it can be assumed that all relevant information is retained and a consistent disk status achieved.
If the system halts while an SM pubset is being imported but the pubset can still be imported as an SM pubset, it can be assumed that a consistent disk status has been achieved. However, depending on when the system halted the SM pubset has either its initial status or the correct status which has been extended by SF pubsets.
If, in the event of a conversion failure, the pubsets were converted back to SF pubset and it was not possible to restore the old GUARDS environment, the pubsets are still marked as importable. Following import as SF pubsets, the objects that are protected by guards cannot be addressed. The old GUARDS environment can be restored by systems support, however, by using /CHANGE-GUARD-FILE to assign the guards catalogs renamed by SMPGEN.
The catalogs reside under the name SYSWRK.SMPGEN.SYSCAT.GUARDS.<pubsetid>.
The new or extended CMS management files are deleted during reconversion to SF pubsets or placed in the initial status.
If they cannot be deleted during reconversion for whatever reason, this does not prevent a new SMPGEN run.
If the same volume set is to become the control volume set, any new CMS administration files still present on it are used again. If another pubset is to become the control volume set, the CMS implicitly deletes the CMS administration files that still reside on the “simple” volume set as leftovers from the previous SMPGEN run.
When exporting the pubsets, the following message may be output for each pubset involved, if guards are used:
PRO6009 ERROR WHEN CLOSING GUARDS CATALOG
This message can be ignored.
Special aspects regarding SMPGEN statements with which all the pubsets involved are imported by SMPGEN itself
(e.g. CREATE-SYSTEM-MANAGED-PUBSET mit OPERATIONAL-MODE=*OPERATION or with OPERATIONAL-MODE=*CHECK-NAME-CONSISTENCY(PUBSET-STATE= *NOT-IMPORTED))
In the event of termination due to an error, or abnormal program/task termination, the MRSCAT entries are cleaned up. Only if the recovery routine aborts do the MRSCAT entries retain the status “inaccessible/SMPGEN processing in progress/cannot be deleted”. The MRSCAT entries can then not be deleted. This means that the pubset can no longer be imported in this session and that the SMPGEN session cannot be started a second time.
STEP termination
If a syntactically or semantically incorrect SMPGEN statement is input, or if the statement cannot be fully processed, the program moves to the next STEP statement, if the error occurs within the program and not in the asynchronously generated task.
If an error occurs that poses problems for the overall program execution (e.g. no information output possible, end of file on SYSDTA), the program ends with STEP termination, i.e. all statements up to the next SET-JOB-STEP or EXIT-JOB are skipped within a procedure.