Input to APPLY is both the SMPPTS (SMPTLIBS) and the global zone (HOLDDATA information).
HOLDDATA is introduced to SMP/E at RECEIVE time. The information is analyzed during APPLY and
ACCEPT time.
Clearly, SMP/E is a utility manager. Utilities are invoked by SMP. SMP itself does not perform a link
edit or copy.
Target libraries contain primarily executable code, that is, executable load modules. Macros, source
modules, and data elements also reside in the target libraries in case they are needed either during an
assembly (macro and source elements), or system execution (data elements).
APPLY Operands
GROUP tells SMP to check G zone for missing prereqs. If not coded on the APPLY and missing
prerequisites are found, APPLY fails. Always code group on APPLY check.
GROUPEXTEND indicates that if a SYSMOD specifically defined as a requisite for a candidate SYSMOD
has not yet been applied and is in error, is not available, or is being held, SMP/E should automatically
include a SYSMOD that supersedes the requisite, or that supersedes the HOLDERROR REASON-ID. APPLY
GROUPEXTEND causes SMP/E to search the GZONE and PTS for such a SYSMOD. The GROUPEXTEND
operand also provides keywords which cause SMP/E not to process APARS or USERMODs to resolve
HOLD REASON-IDs, for example, GROUPEXTEND (NOAPARS, NOUSERMODS). GROUPEXTEND does all
that the GROUP does and more.
APPLY processing defaults can be overridden using the BYPASS operand. If APPLY encounters a
particular condition that exists for a SYSMOD, default processing ends with a non-zero return code.
When the BYPASS operand is coded, SMP/E ignores the condition and continue processing. Warning
messages are generated when bypass conditions occur.
CHECK simulates the APPLY command in that messages and reports are produced which determine the
outcome of the actual APPLY. By specifying the CHECK operand, SMP/E does not update any libraries,
therefore, any library not having sufficient allocated space or directory blocks is not identified. SMP/E
tests for errors, determines which libraries are updated, and reports on any SYSMODs that regress
currently installed SYSMODs. In order for CHECK processing to test install all valid candidate SYSMODs,
the BYPASS operand should be coded with both the HOLDSYSTEM and ID keywords; however, the
BYPASS of anything should be done with care and generally only when the CHECK operand is coded.
The REDO operand indicates that if a SYSMOD specified in the select list has already been applied, it
should be reapplied.
Two operands exist that attempt to prevent a potential out-of-space condition, RETRY and COMPRESS.
COMPRESS indicates which target libraries should be compressed during the APPLY. Individual libraries
can be specified by ddname. If the ALL option is specified, any library that is updated is compressed.
RETRY(YES|NO) indicates whether SMP/E should attempt to recover from an out-of-space condition
encountered by the utilities that it calls. If YES is specified (it is the default) SMP checks the GZONE
options entry for the RETRYDDN subentry for a list of data sets (by ddname) that are to be retried for
more space. C(ALL) has no effect with CHECK. CHECK does not perform any updates.
SMP/E checks the MCS for applicability. The SREL and FMID information is checked against the SREL list
and SYSMOD status entries of functions for service SYSMODs and dependent functions. Only the SREL
information is checked for base functions.
SMP/E does not APPLY any SYSMODs which have exceptions associated with them. Exception processing
is done using the SYSMOD status entry in the global zone and the HOLDDATA subentry. SMP/E supplies
you with an exception report to inform you of any SYSMODs that could not be applied because of
HOLDDATA.
For system and user holds, you must code the BYPASS operand to tell SMP/E that you know about the
exception. Obviously, you have taken or will take the necessary action or will take it. For example, by
coding BYPASS HOLDSYSTEM (DOC), you can bypass HOLDSYSTEMs for DOC REASONID for all SYSMODs
which are held for that REASONID. To selectively BYPASS a HOLDSYSTEM REASONID you can code the
SYSMODID. BYPASS HOLDSYSTEM(ACTION(UZ118765, UZ12368, UZ91664)).
Example: BYPASS HOLDSYSTEM (DOC(UZ98765))
Error holds are resolved when the APAR fix specified becomes available or the superseding PTF becomes
available. If GEXT is specified, SMP looks for superseding service to resolve the ERROR HOLD condition.
HOLDDATA is deleted from the global zone when the SYSMOD is accepted or by the REJECT command.
The order of APPLY processing is FUNCTIONs, PTFs, APARs, USERMODs. Base functions before
dependent functions. Prerequisite SYSMODs before requisite SYSMODs.
The DELETE operand on the ++VER MCS is used to delete older versions of a function. It not only deletes
SMP/E’s information, but also scratches the elements and LMODS from the libraries (target). The
element and LMOD entries are deleted from Tzone. Dependent SYSMODs are also deleted.
++FUNCTION(HGF1200).
++VER...DELETE(HGF1100).
…
In general, the APPLY process works with module elements to form executable load modules on the
target system. APPLY invokes the linkage editor to link the SYSMOD's elements into load modules. Some
macros and source modules must first be assembled and then linked.
SYSMODs that create or modify executable code must tell SMP/E how to build that code. They provide
SMP/E with structural information that is used to build executable code. The SYSMOD uses ++JCLIN MCS
to tell SMP/E to use the utility JCL and control statements provided in the SYSMOD to build structural
entries in the target zone. JCLIN creates MOD entries in Tzone and adds needed subentries. It also
creates LMOD entries with target LIB and LKED CTL information.
Inline JCLIN is restorable! We save the current MOD and LMOD entries in //SMPSCDS, save control data
set. You can list these using the LIST BACKUP command. SMP/E only saves one level. At ACCEPT time,
the entries in the SMPSCDS are purged.
Structural entries are created in the TZONE using SMP/E's processing of the JCLIN data. SYSMODs which
are installed using RECEIVE, APPLY, and ACCEPT process contain the ++JCLIN MCS followed by (typically)
binder job steps. The JCL which follows the ++JCLIN statement is scanned during APPLY. The appropriate
TZONE entries are built in the TZONE to reflect the structure of the product as it exists in the target
libraries. JCLIN stores this information in the TZONE in the form of entries and subentries. APPLY then
has the information to process the elements represented by the element statements that follow.
Normally, function SYSMODs do not use inline JCLIN but rather put all JCLIN data in a relative file.
When the CALLLIBS operand is coded on the JCLIN MCS, SMP/E places the CALLIBS subentry in the
LMOD entry to identify the library from which the implied module is retrieved for link editing.
APPLY updates the target zone element entry, that is (HFS, MAC, MOD, SRC, and data element), to
record the new service level. ++HFS, ++MAC, ++MOD, ++SRC, and ++element changes cause the RMID
value to be reset and all UMID values to be deleted. ++ZAP, ++MACUPD, and ++SRCUPD changes result
in the addition of UMID identifiers.
HFS elements and data elements (++element) do not have a UMID subentry associated with them.
A SYSMOD status entry is created for every SYSMOD processed. The SYSMOD entry in Gzone is updated
with APPID to identify which target zone the sysmod was applied into.
APPLY processing is recorded in the SMPLOG (or SMPLOGA) data set as well as SMPOUT and SYSPRINT
utility output. The output has the APPLY command that was issued followed by APPLY completion
messages. The JCLIN summary report lists the added, deleted, and changed entries in the CSI. One
report is produced for each SYSMOD processed that contains inline JCLIN.
SMP/E has a special report, the causer SYSMOD summary report, also known as root cause analysis. This
report, which may be produced after APPLY, ACCEPT, and RESTORE processing, attempts to isolate the
SYSMODs that caused other SYSMODs to fail during processing.
The SYSMOD status report summarizes the processing performed for each SYSMOD eligible for
processing. The information in the report is listed by SYSMOD ID, type (PTF, Function, and so forth),
FMID (code owner), pre and corequisite, and if superseded.
Currently, all SMP/E report output is written to the SMPRPT ddname. To simplify finding specific
information at the conclusion of an SMP/E operation, the HOLDDATA reports may be written to a
different (optional) ddname, SMPHRPT.
If SMPHRPT is allocated, then HOLDDATA reports for APPLY, ACCEPT, and RECEIVEare written
to it.
If you do not want to review HOLDDATA reports, use the following statement to define SMPHRPT
as dummy:
//SMPHRPT DD DUMMY
The distribution libraries contain elements only. We do not execute code or IPL from DLIBs. The
distribution zone maps DLIB elements as well as any modifications made to those elements. ACCEPT is
responsible for updating the DLIBs and DZONE.
If GEXT is used, NOAPARS and NOUSERMODS should be specified because we should never accept
APARS or USERMODS.
ACCEPT processing also performs data set cleanup operations. The global zone SYSMOD and the PTS
SYSMOD entries are deleted. This clean-up action occurs if the PURGE subentry is in the options entry
associated with the distribution zone. PURGE is the default. NOPURGE causes ACCEPT to skip this
cleanup as does specifying BYPASS(APPLYCHECK) on the ACCEPT command. In addition, CLEANUP
processing scratches SMPTLIBS (RELFILES), STS, MTS, and SCDS entries from related Tzone.
ACCEPT processing uses the elements from the SYSMODs which have been received (and usually
applied) to update the base system (building blocks). As the result of the ACCEPT process, SMP/E also
updates the distribution zone to reflect which SYSMODs were accepted.
RESTORE may be the most confusing SMP/E command. Its purpose is to remove one or more SYSMODs
from the target system by pulling the most recent good copy of elements from DLIBs. RESTORE can be
done for SYSMODs applied and not accepted.
RESTORE processing replaces the elements on the target libraries with the last accepted version of the
element that exists on the related distribution libraries. SMP/E looks at the related entry in the target
zone definition to determine which distribution zone contains the information about the distribution
libraries. The element is reinstalled from the distribution library into the target system library. A link edit
may also be required, automatically managed by SMP/E. In addition, the RMID and UMID values are
copied from the distribution zone element entry to the target zone element entry. Pointers (DDDEFs and
DD statements) are required during RESTORE processing to identify the distribution libraries involved.
RESTORE will not use the DDDEFs from the distribution zone. SMP/E ZONEMERGE DEFINITION or
UNLOAD DDDEF can be used to obtain copies from the distribution zone.
The LIST command is used to gather information about the entries of one or more zones. It is the batch
mode equivalent of the QUERY function in the SMP/E dialogs.
The REPORT command is used to obtain information about SYSMODs which have been installed on your
system.
Code the LIST command to retrieve specified information from the consolidated software
inventory. It is the batch mode equivalent of the QUERY function in the SMP/E dialogs.
Code the REPORT command to check dependencies between products installed in different non-
global zones
Code the REPORT MISSINGFIX command to identify fixes associated with particular fix categories
that have not yet been installed
The LIST command can be used to extract information from the following data sets: global zone, target
zone, distribution zone, SMPPTS, SMPLOG, and SMPSCDS. ALLZONES parameter may be specified if one
wants the LIST command to look at a global zone along with all the target and distributions zones which
are defined by the zone index in the global zone definition entry.
The LIST command can be used to list the global zone control entries, such as OPTIONS, UTILITYs,
DDDEFs, FMIDSETs, and ZONESETs. MCS specifies that SMP/E should list the MCS entries from the
SMPPTS.
LIST GZONE will list the GZONE entry. You can use mass mode or selective when listing things like
DDDEFs. LIST DDDEF lists ALL DDDEFs in the global zone. LIST DDDEF(SMPLIB,LINKLIB) will selectively list
information only for the specified zones. LIST MCS also lists the PTF cover letters.
REPORT CROSSZONE is used to determine software dependencies between products which are installed
in different target zones. The FORFMID operand can be coded to limit the dependency checking to one
or more FMIDS. The FORZONE operand can be coded to limit the dependency checking to one or more
zones within the ZONESET. If FORZONE is not coded, SMP/E will check all zones within the ZONESET. It
also builds commands to get missing requisites installed (//SMPPUNCH DD).
For each zone checked, the report shows which SYSMODs are required for each FMID and tells whether
or not those requisite SYSMODs have been received yet. It also shows which SYSMOD caused this
dependency.
REPORT ERRSYSMODS is used to determine whether any SYSMODs which have already been installed
are now exception SYSMODs. The ZONES operand is used to identify which zone or zones should be
checked. Global, target, or distribution zones can be specified.
REPORT SOURCEID is used to determine which SOURCEIDs have been assigned to SYSMODs in a zone.
The SYSMODIDS operand can be coded so that SMP/E lists the SYSMODs which have the given
SOURCEID associated with them.
REPORT SYSMODS is used to compare the SYSMODs installed in two zones. The comparisons are done
only between zones which are target or distribution zones, not a global zone. The INZONE operand is
coded to specify which zone you want to compare against another one. The COMPAREDTO operand
specifies the zone it is to be compared to.
The new REPORT MISSINGFIX command does the following:
Identifies fixes associated with particular fix categories that have not yet been installed
Identifies any SYSMODs available to satisfy missing fixes
Identifies FMIDs that are applied or accepted for which FIXCAT HOLDs have been received and whose
reason IDs (APARs) have not yet been resolved
FIXCAT HOLDs analyzed for the report processing are determined by the fix category values you
specify.