Inline JCLIN

If a SYSMOD that had inline JCLIN is restored, SMP/E attempts to restore the target zone entries affected by the JCLIN to the state they were in before the SYSMOD was applied. This is done by accessing the BACKUP entry for such SYSMODs. For each BACKUP entry, SMP/E checks the corresponding target zone entry to ensure that the last modification (LASTUPD subentry) to the target zone entry was for the SYSMOD being restored. If it was, the entry is replaced from the BACKUP entry. If it was not, SMP/E issues messages to indicate that the SYSMOD was not restored, and RESTORE processing stops for that SYSMOD. This condition can occur if you used UCLIN or JCLIN to update an entry after you applied the SYSMOD being restored, or if a subsequent SYSMOD was applied that updated the entry but did not have a dependency relationship with the SYSMOD being restored. The latter should occur only for LMOD entries.

Note: RESTORE processing is limited for a SYSMOD using the CHANGE statement in inline JCLIN. When that SYSMOD is restored, the backup copy of the LMOD entry (which does not have the updates from the CHANGE statement) replaces the target zone LMOD entry, and the information from the CHANGE statement is lost. Module names that were changed by the inline JCLIN remain in the load module under their changed names.

As each entry is completed, SMP/E deletes the BACKUP entry. When all BACKUP entries have been processed, SMP/E deletes the related SYSMOD entry. This processing is done before the target system libraries are updated.

JCLIN processing occurs in the reverse order of application; that is, the latest update is restored first, the earliest one last. The order is determined by the dependency relationships of the SYSMODs being restored.