Operands

APARS

indicates that all eligible APARs should be applied.

Note:

APARS can also be specified as APAR.
If APARS is specified along with SELECT, all eligible APARs are included in addition to the SYSMODs specified on SELECT.
If APARS is specified along with SOURCEID, all APARs associated with the specified source IDs are included.

ASSEM

indicates that if any SYSMOD contains both source code and object code for the same module, the source code should be assembled and should replace the object code.

BYPASS

You can specify any of these options:

HOLDCLASS
HOLDERROR
HOLDFIXCAT
HOLDSYSTEM
HOLDUSER
ID
IFREQ
PRE
REQ
XZIFREQ
XZIFREQ(list)

Note: If you specify both BYPASS and GROUPEXTEND, SMP/E does not include superseding SYSMODs needed to take the place of requisites or error reason IDs that have been bypassed.

During CHECK processing, if you want to see whether any superseding SYSMODs are available for requisites that have been bypassed, specify GROUPEXTEND without BYPASS.

BYPASS(HOLDCLASS(value,…))

indicates that exception SYSMODs associated with the specified class names should not be held. The list of class names is required.

These are the hold classes you can specify:

Class: Explanation
ERREL: The SYSMOD is held for an error reason ID but should be installed anyway. IBM® has determined that the problem the SYSMOD resolves is significantly more critical than the error reflected by the holding APAR.
HIPER: The SYSMOD is held with a hold class of HIPER (High Impact)
PE: The SYSMOD is held with a hold class of "PTF in Error".
UCLREL: UCLIN needed for the SYSMOD has been handled by IBM and no longer requires your attention.
YR2000: Identifies PTFs that provide Year 2000 function, or fix a Year 2000-related problem.

BYPASS(HOLDERROR)

indicates that exception SYSMODs associated with the specified error reason IDs should not be held. The list of reason IDs is optional.

If you include a list of reason IDs, only the ones you specify are bypassed. If you do not include a list, all error reason IDs are bypassed.

Note: HOLDERROR can also be specified as HOLDERR.

BYPASS(HOLDFIXCAT)

indicates that held SYSMODs associated with the specified fix category reason IDs should not be held. The list of reason IDs is optional. If a list of reason IDs is included, only the ones specified are bypassed. If a list is not included, all fix category reason IDs are bypassed.

BYPASS(HOLDSYSTEM)

indicates that exception SYSMODs associated with the specified system reason IDs should not be held. The list of reason IDs is optional, as is the list of SYSMOD IDs for a particular reason ID. Generally, you should specify BYPASS(HOLDSYSTEM) on all APPLY CHECK commands, and BYPASS(HOLDSYSTEM(reason_id,…)) on all APPLY commands for all system reason IDs for which appropriate action has been (or will be) taken.

How you specify the reason IDs determines which system reason IDs are bypassed. Make sure the appropriate action has been taken for all SYSMODs whose reason IDs are to be bypassed.

If you do not include a list of reason IDs, all system reason IDs are bypassed.
If you include a list of reason IDs without a list of SYSMOD IDs, all the SYSMODs with the specified reason IDs are bypassed.
If you include a list of SYSMOD IDs for a particular reason ID, that reason ID is bypassed only for the specified SYSMODs. Other SYSMODs held for that reason remain held, unless the hold is released by some other BYPASS operand (such as CLASS).

Note: HOLDSYSTEM can also be specified as HOLDSYS.

These are the system reason IDs currently used by IBM:

ID

Explanation

ACTION

The SYSMOD needs special handling before or during APPLY processing, ACCEPT processing, or both.

AO

The SYSMOD may require action to change automated operations procedures and associated data sets and user exits in products or in customer applications. The PTF cover letter describes any changes (such as to operator message text, operator command syntax, or expected actions for operator messages and commands) that can affect automation routines.

DB2BIND

A DB2® application REBIND is required for the SYSMOD to become effective.

DDDEF

Data set changes or additions as required.

DELETE

The SYSMOD contains a ++DELETE MCS, which deletes a load module from the system.

DEP

The SYSMOD has a software dependency.

DOC

The SYSMOD has a documentation change that should be read before the SYSMOD is installed.

DOWNLD

Code that is shipped with maintenance that needs to be downloaded.

DYNACT

The changes supplied by the SYSMOD may be activated dynamically without requiring an IPL. The HOLD statement describes the instructions required for dynamic activation. If those instructions are not followed, then an IPL is required for the SYSMOD to take effect.

EC

The SYSMOD needs a related engineering change.

ENH

The SYSMOD contains an enhancement, new option or function. The HOLD statement provides information to the user regarding the implementation and use of the enhancement.

EXIT

The SYSMOD contains changes that may affect a user exit. For example, the interface for an exit may be changed, an exit may need to be reassembled, or a sample exit may be changed.

EXRF

The SYSMOD must be installed in both the active and the alternative Extended Recovery Facility (XRF) systems at the same time to maintain system compatibility. (If you are not running XRF, you should bypass this reason ID.)

FULLGEN

The SYSMOD needs a complete system or subsystem generation to take effect.

IOGEN

The SYSMOD needs a system or subsystem I/O generation to take effect.

IPL

The SYSMOD requires an IPL to become effective. For example, the SYSMOD may contain changes to LPA or NUCLEUS, the changes may require a CLPA, or a failure to perform an IPL might lead to catastrophic results, such as could be caused by activation of a partial fix.

Note: If you plan to perform an IPL with CLPA after the SYSMOD has been applied, then no further investigation of the HOLD is required; simply bypass the IPL reason ID. However, if you are not planning to perform an IPL with CLPA, then the details of the HOLD statement must be investigated to determine what kind of actions are required to activate the SYSMOD.

MSGSKEL

This SYSMOD contains message changes that must be compiled for translated versions of the message changes to become operational on extended TSO consoles.

If you want to use translated versions of the messages, you must run the message compiler once for the library containing the English message outlines, and once for each additional language you want to be available on your system. For details, see z/OS MVS Planning: Operations.

If you want to use only the English version of the messages, you do not need to run the message compiler. You should bypass this reason ID.

MULTSYS

Identifies fixes that need to be applied to multiple systems, in one of three cases: preconditioning, coexistence, or exploitation.

RESTART

To become effective, the SYSMOD requires a special subsystem restart operation. The HOLD statement contains information regarding the required restart actions.

BYPASS(HOLDUSER)

indicates that exception SYSMODs associated with the specified user reason IDs should not be held. The list of reason IDs is optional.

If you include a list of reason IDs, only the ones you specify are bypassed. If you do not include a list, all user reason IDs are bypassed.

BYPASS(ID)

indicates that SMP/E should ignore any errors it detects when checking the SYSMOD's RMID and UMIDs.

BYPASS(IFREQ)

indicates that SMP/E should ignore any conditional requisites that are missing.

BYPASS(PRE)

indicates that SMP/E should ignore any missing prerequisites.

BYPASS(REQ)

indicates that SMP/E should ignore any requisites that are missing.

BYPASS(XZIFREQ)

indicates that SMP/E is to continue APPLY processing for a SYSMOD, even if SMP/E detects a missing cross-zone requisite. SMP/E will identify such missing cross-zone requisites with a warning message, instead of terminating the APPLY processing.

BYPASS(XZIFREQ(list))

indicates that SMP/E is to continue APPLY processing for a SYSMOD, even if SMP/E detects a missing cross-zone requisite, provided that the missing requisite SYSMOD is included in the list provided with the XZIFREQ option. For SYSMODs identified in the list, SMP/E will identify with a warning message any that are missing cross-zone requisites. For missing requisite SYSMODs that are not included in the list, SMP/E will terminate APPLY processing.

Each entry in the list must be in one of the following formats:

sysmod_id
(sysmod_id,zone)

sysmod_id: specifies that SMP/E is to continue APPLY processing, even if requisite SYSMOD sysmod_id in any zone (other than the set-to zone) is missing.
(sysmod_id,zone): specifies that SMP/E is to continue APPLY processing, even if requisite SYSMOD sysmod_id in zone zone is missing.

Each entry in the list must be unique. Also, a SYSMOD ID must not appear both by itself and as part of a SYSMOD/zone pair. However, a SYSMOD ID may appear in multiple SYSMOD/zone pairs, provided each of the pairs is unique.

The list provided must not be a null list; that is, BYPASS(XZIFREQ()) is not allowed.

CHECK

indicates that SMP/E should not actually update any libraries. Instead, it should just take these actions:

Test for errors other than those that occur when the libraries are actually updated.
Report on which libraries are affected.
Report on any SYSMOD that would be regressed.

COMPRESS

indicates which target libraries should be compressed. SMP/E does not compress any libraries that are actually paths in a UNIX file system.

If you specify ALL, any libraries in which elements will be installed by this APPLY command are compressed.
If you specify particular ddnames, those libraries are compressed regardless of whether they will be updated.

Note:

COMPRESS can also be specified as C.
If you specify both COMPRESS and CHECK, COMPRESS is ignored. This is because SMP/E does not update any data sets for CHECK.

EXCLUDE

specifies one or more SYSMODs that should not be applied.

Note:

EXCLUDE can also be specified as E.
SMP/E does not include a SYSMOD that would be included by the GROUP or GROUPEXTEND operand if that SYSMOD is specified on the EXCLUDE operand.

EXSRCID

indicates that SYSMODs associated with the specified source IDs should not be applied.

Note:

There are two ways to specify source IDs:
- Explicitly, by fully specifying a particular source ID (for example, RSU0711). In this case, all SYSMODs that contain the identified source ID are excluded.
- Implicitly, by partially specifying a source ID value using asterisks (*) as global characters and percent signs (%) as placeholders.
  - A single asterisk indicates that zero or more characters can occupy that position. Here are some examples:
    - For RSU*, all SYSMODs that contain a source ID that begins with the character string RSU* are excluded.
    - For *0711, all SYSMODs that contain a source ID that ends with the character string 0711 are excluded.
    - For RSU*1, all SYSMODs that contain a source ID that begins with the character string RSU and ends with the character string 1 are excluded.
  - A single percent sign indicates that any one single character can occupy that position. For RSU0%11, for example, SYSMODs that contain any of these source IDs are excluded: RSU0711, RSU0211, and RSU0311. SYSMODs that contain source ID RSU00711 are not excluded.
Any number of asterisks and percent signs can be used within a single partially specified source IDs.
The following examples are valid source ID specifications:
```
RSU0709
RSU*
IBM.Device.20%4
IBM.Device.*.zAAP
```
A given source ID can be explicitly specified only once on the EXSRCID operand.
The same source ID cannot be explicitly specified on both the EXSRCID and source ID operands.
If a source ID is implicitly or explicitly specified on the EXSRCID operand and on the SOURCEID operand, all SYSMODs with that source ID are excluded from processing.
If a given SYSMOD has multiple source IDs, at least one of which is specified either implicitly or explicitly on the SOURCEID operand and another is specified on the EXSRCID operand, the SYSMOD is excluded from processing.
For example, assume PTF UZ12345 has been assigned source IDs SMCREC and PUT0703. If you specify SOURCEID(SMC*) and EXSRCID(PUT0703), the SYSMOD is excluded from processing.
If a SYSMOD would be included by the GROUP or GROUPEXTEND operand, but is excluded by the EXSRCID operand, SMP/E does not include it.
If you do not specify any SYSMOD types, SMP/E processes only PTFs. To process other types of SYSMODs, you must specify the desired SYSMOD types.
A source ID value might contain mixed case alphabetic characters. However, SMP/E ignores the case when identifying matches for a specified source ID value. For example, a specified source ID value of ABCDEF matches a value of abcdef.

FIXCAT

identifies the list of fix categories of interest for command processing. This list determines which fix category APARs must be resolved for the SYSMODs being applied.

A fix category APAR provides a fix for a held SYSMOD and the APAR is associated with one or more fix categories. Fix category APARs are identified by FIXCAT HOLD entries. If a fix category specified on a FIXCAT HOLD for a SYSMOD being applied matches any of those specified on the FIXCAT operand of the command, then the SYSMOD is held for the APAR reason ID from the FIXCAT HOLD and will not be applied until the APAR is resolved. If a fix category specified on a FIXCAT HOLD for a SYSMOD being applied does not match any of those specified on the FIXCAT operand of the command, or if the list of fix categories is null, the SYSMOD is not held for the APAR reason ID from the FIXCAT HOLD.

The values specified on the FIXCAT operand will override the list of values, if any, defined by the FIXCAT subentry in the active OPTIONS entry. FIXCAT() may be used to specify a null list, which means no fix category APARs must be resolved during current accept processing.

Fix category values can be 1 to 64 characters in length and can contain any nonblank character in the range X'41' - X'FE' except the single quotation mark, comma, left parenthesis, and right parenthesis. They can be specified in two ways:

Explicitly, by fully specifying a particular fix category value. For example, IBM.Device.zIIP. In this case, all HOLDDATA associated with this fix category is applicable to command processing.
Implicitly, by partially specifying a fix category value using any number of asterisks (*) as global characters and percent signs (%) as placeholders.
- A single asterisk indicates that zero or more characters can occupy that position. For example, IBM.Device*, *z/OS or IBM*z/OS. In the first case, all HOLDDATA associated with a fix category that begins with the character string IBM.Device is applicable. In the second case, all HOLDDATA associated with a fix category that ends with the character string z/OS® is applicable. In the third case, all HOLDDATA associated with a fix category that begins with the character string IBM and ends with the character string z/OS is applicable.
- A single percent sign indicates that any one single character can occupy that position. For example, IBM.Device.20%4. In this case, HOLDDATA associated with any of the following fix categories is applicable: IBM.Device.2084, IBM.Device.2094, and IBM.Device.20t4. HOLDDATA associated with fix category IBM.Device.20914, however, is not applicable.

Fix category values can contain mixed case alphabetic characters. However, SMP/E ignores the case when identifying matches for a specified Fix category value. For example, a specified value of IBM.FUNCTION.HEALTHCHECKER matches the value of IBM.Function.HealthChecker.

Fix category values are defined by FIXCAT HOLD entries. The following examples of acceptable fix categories are based on the fix category values that are used by IBM in FIXCAT HOLD entries:

IBM.Device.2094.zAAP
*
IBM.Function*
IBM.Device.20%4.*
*.HealthChecker

FORFMID

indicates that only SYSMODs for the specified FMIDs or FMIDSETs should be applied.

Note:

Functions containing a ++VER DELETE statement are not automatically included by the FORFMID operand. You must specify them on the SELECT operand.
If you do not specify any SYSMOD types, SMP/E processes only PTFs. To process other types of SYSMODs, you must specify the desired SYSMOD types.

FUNCTIONS

indicates that all eligible functions should be applied.

Note:

FUNCTIONS can also be specified as FUNCTION.
If you specify FUNCTIONS along with SELECT, all eligible functions are included in addition to the SYSMODs specified on SELECT.
If you specify FUNCTIONS along with SOURCEID, all functions associated with the specified source IDs are included.
Functions containing a ++VER DELETE statement are not automatically included by the FUNCTIONS operand. You must specify them on the SELECT operand.

GROUP

indicates that if any SYSMODs specifically defined as requisites for eligible SYSMODs have not yet been applied, SMP/E should automatically include them.

Note:

GROUP can also be specified as G.
GROUP is mutually exclusive with GROUPEXTEND.
GROUP may include SYSMODs at a service level higher than that specified by the SOURCEID operand.
If you specify GROUP with no other SYSMOD selection operands (such as a SYSMOD type, SOURCEID, FORFMID, or SELECT), GROUP is ignored.
Processing done for SYSMODs specified on the SELECT operand is not necessarily done for SYSMODs included by the GROUP operand. For example, if REDO is specified, only SYSMODs specified on the SELECT operand can be reapplied; SYSMODs included by the GROUP operand are not.
Functions containing a ++VER DELETE statement are not automatically included by the GROUP operand. You must specify them on the SELECT operand.
If a SYSMOD would be included by the GROUP operand, but is excluded by the EXCLUDE or EXSRCID operand, SMP/E does not include it.

GROUPEXTEND

indicates that if a SYSMOD specifically defined as a requisite for an eligible SYSMOD has not been applied and cannot be processed for one of the reasons shown in Table 1, SMP/E should automatically include a superseding SYSMOD. As the table shows, what GROUPEXTEND includes depends on why the requisite cannot be processed.

Table 1. What GROUPEXTEND includes (APPLY processing)
For a requisite that is:	GROUPEXTEND includes:
Held for an error reason ID	A SYSMOD that supersedes the requisite OR A SYSMOD that matches or supersedes the error reason ID
One of these situations: Held for a system reason ID Held for a user reason ID Applied in error Not available	A SYSMOD that supersedes the requisite

You can specify NOAPARS or NOUSERMODS (or both NOAPARS and NOUSERMODS) to limit the types of SYSMODS that are included by GROUPEXTEND to resolve error reason IDs. The default is to include all eligible SYSMODs, regardless of SYSMOD type.

NOAPARS: indicates that SMP/E should exclude APARs that resolve error reason IDs.
NOUSERMODS: indicates that SMP/E should exclude USERMODs that resolve error reason IDs.

Note:

GROUPEXTEND can also be specified as GEXT.
GROUPEXTEND is mutually exclusive with GROUP.
If you specify both BYPASS and GROUPEXTEND, SMP/E does not include superseding SYSMODs needed to take the place of requisites or error reason IDs that have been bypassed.
During CHECK processing, if you want to see whether any superseding SYSMODs are available for requisites that have been bypassed, specify GROUPEXTEND without BYPASS.
GROUPEXTEND may include SYSMODs at a service level higher than what is specified by the SELECT or SOURCEID operands.
Functions and excluded SYSMODs are not automatically included by GROUPEXTEND.
Processing done for SYSMODs specified on the SELECT operand is not necessarily done for SYSMODs included by the GROUPEXTEND operand. For example, if REDO is specified, only SYSMODs specified on the SELECT operand can be reapplied; SYSMODs included by the GROUPEXTEND operand cannot.
If a SYSMOD would be included by the GROUPEXTEND operand, but is excluded by the EXCLUDE or EXSRCID operand, SMP/E does not include it.
When GROUPEXTEND is specified, SMP/E examines more SYSMODs than it does if GROUP were specified. Because of this additional processing, the APPLY command runs longer than if GROUP was specified, and a larger region size might be needed.
On the other hand, GROUPEXTEND reduces the amount of time you would otherwise spend searching for missing requisites.

JCLINREPORT

indicates that SMP/E is to write the JCLIN reports after processing inline JCLIN. This is the default.

Note: JCLINREPORT can also be specified as JCLR.

NOJCLIN

indicates that SMP/E should not process inline JCLIN for the specified SYSMODs. For example, if you are reapplying SYSMODs, you may not want to process inline JCLIN that would change target zone entries that should not be changed.

If you include a list of SYSMOD IDs, SMP/E skips JCLIN processing only for the specified SYSMODs. If you do not include a list of SYSMOD IDs, SMP/E skips JCLIN processing for all SYSMODs.

NOJCLINREPORT

indicates that SMP/E should not write any JCLIN reports after processing inline JCLIN.

Note: NOJCLINREPORT can also be specified as NOJCLR.

PTFS

indicates that all eligible PTFs should be applied.

Note:

PTFS can also be specified as PTF.
PTFS is the default SYSMOD type for mass-mode processing. If you do not specify any other SYSMOD types, only PTFs are processed, even if PTFS was not specified.
If you specify PTFS along with SELECT, all eligible PTFs are included in addition to the SYSMODs specified on SELECT.
If you specify PTFS along with SOURCEID, all PTFs associated with the specified source IDs are included.

RC

changes the maximum return codes allowed for the specified commands. These return codes determine whether SMP/E can process the APPLY command.

Before SMP/E processes the APPLY command, it checks whether the return codes for the specified commands are less than or equal to the values specified on the RC operand. If so, SMP/E can process the APPLY command. Otherwise, the APPLY command fails. For more information about the RC operand, see Processing the SMP/E RC operand.

Note:

The RC operand must be the last operand specified on the command.
If you do specify the RC operand, return codes for commands not specified do not affect processing for the APPLY command. Therefore, if you use the RC operand, you must specify every command whose return code you want SMP/E to check.

REDO

indicates that if any SYSMOD specified on SELECT has already been successfully applied, it should be reapplied.

Note:

If you specify REDO, you must also specify SELECT.
If GROUP or GROUPEXTEND is also specified, REDO does not reapply SYSMODs included by the GROUP or GROUPEXTEND operand. It processes only SYSMODs specified on the SELECT operand.
If you use REDO to reapply a SYSMOD with inline JCLIN, you may not be able to restore that SYSMOD. This is the case if the target zone entries were updated the first time the SYSMOD was applied. When the SYSMOD is reapplied by use of the REDO operand, the target zone entries are first copied to the SMPSCDS as BACKUP entries, and then updated again for the SYSMOD. As a result, the BACKUP entries and the target zone entries are at the same level, and SMP/E has no record of the target zone entries before the SYSMOD was installed.
When reapplying a function SYSMOD, be sure to also reapply all PTFs, APARs, and USERMODs for the same FMID that have already been applied to prevent intersecting elements from being regressed. Otherwise, the correct service level of the intersecting elements may not be installed.

RETRY

indicates whether SMP/E should try to recover from out-of-space errors for utilities it calls.

YES

indicates that SMP/E should try to recover and retry the utility if a RETRYDDN list is available in the OPTIONS entry that is in effect. RETRY(YES) is the default.

If retry processing does not reclaim sufficient space and input to the utility was batched (copy or link-edit utility only), SMP/E debatches the input and retries the utility for each member separately. If this final attempt fails, the resulting x37 abend is treated as an unacceptable utility return code. In this case, processing continues for SYSMODs containing eligible updates to other libraries, but processing fails for SYSMODs containing unprocessed elements for the out-of-space library (and it fails for any SYSMODs that are dependent on the failed SYSMODs). For guidance on setting up the desired retry processing, see SMP/E for z/OS User's Guide. For more information about OPTIONS entries, see SMP/E for z/OS Reference.

If there is no RETRYDDN list, SMP/E does not try to recover from out-of-space errors, even if you specify YES.

NO

indicates that SMP/E should not try to recover from the error.

REUSE

indicates that if a module was successfully assembled during previous SMP/E processing, it should not be reassembled. Instead, the existing object module from SMPWRK3 should be reused.

Note: The REUSE operand must be used with great care. SMP/E does not ensure that the same set of SYSMODs are being processed after a failure. If new maintenance is received after the initial APPLY command and before the APPLY REUSE command, SMP/E may use the wrong level of object modules.

SELECT

specifies one or more SYSMODs that should be applied.

You may specify any combination of individual SYSMOD IDs and FMIDSET names, provided that there are no duplicate SYSMOD IDs nor any duplicate FMIDSET names. For each FMIDSET specified, all FMIDs defined in the FMIDSET are processed as if they were explicitly specified in the SELECT list.

Note:

SELECT can also be specified as S.
To reapply a SYSMOD, it is not enough to specify that SYSMOD on the SELECT operand. You must also specify REDO.
To process functions containing a ++VER DELETE statement, you must specify them on the SELECT operand.
When using FMIDSETs on the SELECT operand, remember that:
- A value specified in the SELECT list is processed as an FMIDSET if the GLOBAL zone contains an FMIDSET entry by that name.
- A value specified in the SELECT list is processed as a SYSMOD ID if it is not defined as an FMIDSET in the GLOBAL zone and it is a valid SYSMOD ID.
- If the value in the SELECT list is valid both as a SYSMOD ID and as an FMIDSET name, it is processed (for SELECT) as an FMIDSET. If you want to select a SYSMOD that has the same name as an FMIDSET, you must define that SYSMOD in an FMIDSET and then include that FMIDSET name in the SELECT list.
  If this same value is specified on the EXCLUDE operand, it will be processed as a SYSMOD ID (because only SYSMOD IDs are valid on EXCLUDE) and will not be rejected as a duplication of the identical FMIDSET name in the SELECT list.
- Any given value (whether it represents a SYSMOD ID, an FMIDSET, or both) may not appear more than once in the SELECT list.
- Any given SYSMOD ID may not simultaneously appear in both the SELECT and EXCLUDE lists, unless it is also a valid FMIDSET name.
- A SYSMOD ID may be explicitly specified in the SELECT list and also included in an FMIDSET that is also specified in the SELECT list, provided the SYSMOD ID does not have the same name as the FMIDSET. The duplicate SYSMOD ID is ignored.

SOURCEID

indicates that SYSMODs associated with the specified source IDs should be applied.

Note:

There are two ways to specify source IDs:
- Explicitly, by fully specifying a particular source ID (for example, RSU0711). In this case, all SYSMODs that contain the identified source ID are selected.
- Implicitly, by partially specifying a source ID value using asterisks (*) as global characters and percent signs (%) as placeholders.
  - A single asterisk indicates that zero or more characters can occupy that position. Here are some examples:
    - For RSU*, all SYSMODs that contain a source ID that begins with the character string RSU are selected.
    - For *0711, all SYSMODs that contain a source ID that ends with the character string 0711 are selected.
    - For RSU*1, all SYSMODs that contain a source ID that begins with the character string RSU and ends with the character string 1 are selected.
  - A single percent sign indicates that any one single character can occupy that position. For RSU0%11, for instance, SYSMODs that contain any of these source IDs are selected: RSU0711, RSU0211, and RSU0311. SYSMODs that contain source ID RSU00711 are not selected.
Any number of asterisks and percent signs can be used within a single partially specified source ID.
The following examples are valid source IDs:
```
RSU0709
RSU*
IBM.Device.20%4
IBM.Device.*.zAAP
```
A given source ID can be explicitly specified only once on the SOURCEID operand.
The same source ID cannot be explicitly specified on both the EXSRCID and the SOURCEID operands.
If a source ID is implicitly or explicitly specified both on the SOURCEID operand and on the EXSRCID operand, all SYSMODs with that source ID are excluded from processing.
If a given SYSMOD has multiple source IDs, at least one of which is specified either implicitly or explicitly on the SOURCEID operand and another on the EXSRCID operand, the SYSMOD will be excluded from processing.
For example, assume that PTF UZ12345 has been assigned source IDs SMCREC and PUT0703. If you specify SOURCEID(SMC*) and EXSRCID(PUT0703), the SYSMOD is excluded from processing.
Functions containing a ++VER DELETE statement are not automatically included by the SOURCEID operand. You must specify them on the SELECT operand.
If you do not specify any SYSMOD types, only PTFs are processed. To process other types of SYSMODs, you must specify the desired SYSMOD types.
A source ID value might contain mixed case alphabetic characters. However, SMP/E ignores the case when identifying matches for a specified source ID value. For example, a specified source ID value of ABCDEF matches a value of abcdef.
SOURCEIDs for fix category values are assigned to the resolving (fixing) PTFs named on the FIXCAT ++HOLDs, during the RECEIVE of those ++HOLDs. The SOURCEIDs can only be assigned to a PTF, if that PTF has been received before the HOLDDATA is received. This requirement is met if the PTF was received during a previous RECEIVE command, or during the same RECEIVE with SYSMODS HOLDDATA, since the SYSMODs are received first then the HOLDDATA.

USERMODS

indicates that all eligible USERMODs should be applied.

Note:

USERMODS can also be specified as USERMOD.
If USERMODS is specified along with SELECT, all eligible USERMODs are included in addition to the SYSMODs specified on SELECT.
If USERMODS is specified along with SOURCEID, all USERMODs associated with the specified source IDs are included.

XZGROUP(list)

indicates that you wish to override SMP/E's default method for determining the zones to be checked for cross-zone requisites.

You may specify either:

A list of ZONESETs and zones that are to be used to establish the zone group for this command. Each value in the list must be a valid ZONESET or zone name.
XZGROUP() to provide a null list, which means that no cross-zone requisite checking is to be done for this command. A null list is not valid if the XZREQ operand is also specified.

The XZGROUP operand always requires a list or null list. That is, XZGROUP (without parentheses) is not allowed.

Note:

If XZGROUP is specified, whatever ZONESETs the user specifies are used to establish the initial zone group, even if the set-to zone is not in a ZONESET and the XZREQCHK subentry is not set.
If no XZGROUP operand is specified on the APPLY command, SMP/E reads all ZONESET entries. If a ZONESET entry has its XZREQCHK subentry set to YES and it contains the set-to zone, then all the other zones within the ZONESET entry become part of the initial zone group for the APPLY command.
After the initial zone group is established, it is culled by removing all distribution zone for APPLY processing. In other words, only zones having the same type as the set-to zone are left in the final zone group used for cross-zone requisite checking.

XZREQ

indicates that SMP/E should install unsatisfied cross-zone requisites into the set-to zone.

XZREQ causes cross-zone requisites to become primary candidates for installation. To do this, SMP/E checks secondary zones in the currently established zone group for CIFREQ data that is applicable to functions installed or being installed into the set-to zone.

Note:

SYSMODs selected with the XZREQ operand are in addition to any SYSMODs selected with the FORFMID and SOURCEID operands.
If XZREQ is specified along with SELECT, the specifically selected SYSMODs are included along with any unsatisfied cross-zone requisites.
If SOURCEID is specified, only cross-zone requisites with the specified SOURCEID values become primary candidates for installation.
If FORFMID is specified, only cross-zone requisites for the specified FMIDs become primary candidates for installation. Otherwise, all unsatisfied cross-zone requisites become primary candidates for installation.
When the XZREQ operand is specified without the FORFMID operand, the SOURCEID operand, or the SELECT operand, only unsatisfied cross-zone requisites become primary candidates.
PTFS is the default SYSMOD type for mass-mode processing. If no SYSMOD types are specified, only PTFs are processed, even if PTFS was not specified.
If any SYSMOD types are specified, processing is limited to those SYSMOD types, except for those SYSMODs that might be needed to satisfy processing for these operands:
- GROUP
- GROUPEXTEND
- SELECT
- XZREQ
If EXSRCID is specified, any unsatisfied cross-zone requisite with one of the specified source IDs is excluded from processing.
If the XZREQ operand is specified, the XZGROUP operand may not be specified as a null list.