Operands

APARS

indicates that all eligible APARs should be accepted.

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 SYSMODs contain 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:

APPLYCHECK
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(APPLYCHECK)

indicates that SYSMODs should be accepted even if they have not been applied. For example, if you are preparing the distribution libraries before doing a system generation, you want to accept SYSMODs that have not been applied.

Note: APPLYCHECK can also be specified as APPCHK.

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 one, only the reason IDs specified on it 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 the 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 ACCEPT CHECK commands, and BYPASS(HOLDSYSTEM(reason_id,…)) on all ACCEPT 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 one, only the reason IDs specified on it 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 prerequisites that are missing.

BYPASS(REQ)

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

BYPASS(XZIFREQ)

indicates that SMP/E is to continue ACCEPT 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 ACCEPT processing.

BYPASS(XZIFREQ(list))

indicates that SMP/E is to continue ACCEPT 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.

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

sysmod_id
(sysmod_id,zonename)

sysmod_id

Indicates that SMP/E is to continue ACCEPT processing, even if the requisite sysmod_id is missing in any zone.

(sysmod_id,zonename)

Indicates that SMP/E is to continue ACCEPT processing, even if the requisite sysmod_id is missing from either:

the set-to zone. In this case, SYSMODs in zone zonename require that sysmod_id be installed in the set-to zone.
the zone identified by the zonename parameter. In this case, SYSMODs in the set-to zone require that sysmod_id be installed in zone zonename.

Note: A cross-zone requisite relationship necessarily involves two zones (the set-to zone and another zone) and two SYSMODs (the SYSMOD making the requirement and the requisite SYSMOD), with the requiring SYSMOD being in one zone and the requisite SYSMOD in the other zone. The zone specified in the (sysmod_id,zonename) pair must never be the set-to zone. It must always be a zone that has a requisite relationship with the set-to zone.

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. Rather, it should just take these actions:

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

COMPRESS

indicates which distribution libraries should be compressed.

If you specify ALL, any libraries in which elements will be installed by this ACCEPT 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 accepted.

Note:

EXCLUDE can also be specified as E.
If a SYSMOD is specified on the EXCLUDE operand, SMP/E does not include this SYSMOD, even though it might be specified on the GROUP or GROUPEXTEND operand.

EXSRCID

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

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 ID.
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 SOURCEID operands.
If a source ID is specified implicitly or explicitly on the EXSRCID operand and is also specified either implicitly or explicitly on the SOURCEID operand, all SYSMODs with that source ID are excluded from processing.
If a given SYSMOD has multiple source IDs and at least one of those source IDs is specified either implicitly or explicitly on the SOURCEID operand, the SYSMOD is excluded from processing if another one of its source IDs is specified either explicitly or implicitly on the EXSRCID operand.
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 that would have been included by the GROUP or GROUPEXTEND operand is excluded by the EXSRCID operand, SMP/E does not include it.
If no SYSMOD types are specified, 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.

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 accepted.

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 accepted 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 accepted until the APAR is resolved. If a fix category specified on a FIXCAT HOLD for a SYSMOD being accepted 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() can 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 accepted.

Note:

Functions containing a ++VER DELETE statement are not automatically included by the FORFMID operand. You must specify them on the SELECT operand.
If no SYSMOD types are specified, only PTFs are processed. To process other types of SYSMODs, you must specify the desired SYSMOD types.

FUNCTIONS

indicates that all eligible functions should be accepted.

Note:

FUNCTIONS can also be specified as FUNCTION.
If FUNCTIONS is specified along with SELECT, all eligible functions are included in addition to the SYSMODs specified on SELECT.
If FUNCTIONS is specified along with SOURCEID, all functions associated with the specified source IDs are included.
Functions that contain 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 accepted, SMP/E should automatically include them.

Note:

GROUP can also be specified as G.
GROUP is mutually exclusive with GROUPEXTEND.
GROUP might include SYSMODs at a higher service level than the level specified by the SOURCEID operand.
If you specify GROUP without any 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 reaccepted; 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 that would have been included by the GROUP operand 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 accepted and cannot be processed for one of the reasons shown in Table 1, SMP/E should automatically include a superseding SYSMOD. Table 1 shows what GROUPEXTEND includes, depending on why the requisite cannot be processed.

Table 1. What GROUPEXTEND includes (ACCEPT 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 reasons: Held for a system reason ID Held for a user reason ID Accepted in error Not available	A SYSMOD that supersedes the requisite

You can specify NOAPARS or NOUSERMODS (or both) 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 any 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 might include SYSMODs at a service level higher than that specified by the SELECT or SOURCEID operand.
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 specified by the GROUPEXTEND operand. For example, if REDO is specified, only SYSMODs specified on the SELECT operand are reaccepted; SYSMODs included by the GROUPEXTEND operand are not.
If a SYSMOD that would have been included by the GROUPEXTEND operand 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 ACCEPT 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 when inline JCLIN is processed at ACCEPT time (ACCJCLIN is set in the DLIBZONE entry).

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 reaccepting SYSMODs, you may not want to process inline JCLIN that would change distribution 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.

Note: If inline JCLIN is not being processed at ACCEPT time (ACCJCLIN is not set in the DLIBZONE entry), you do not need to specify NOJCLIN.

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 accepted.

Note:

PTFS can also be specified as PTF.
PTFS is the default SYSMOD type for mass-mode processing. If no other SYSMOD types are specified, only PTFs are processed, even if PTFS was not specified.
If PTFS is specified along with SELECT, all eligible PTFs are included in addition to the SYSMODs specified on SELECT.
If PTFS is specified 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 ACCEPT command.

Before SMP/E processes the ACCEPT 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 ACCEPT command. Otherwise, the ACCEPT 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 ACCEPT 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 accepted, it should be reaccepted.

Note:

If you specify REDO, you must also specify SELECT.
If GROUP or GROUPEXTEND is also specified, REDO does not reaccept SYSMODs included by the GROUP or GROUPEXTEND operand. It only processes SYSMODs specified on the SELECT operand.
When reaccepting a function SYSMOD, be sure to also reaccept all PTFs, APARs, and USERMODs for the same FMID that have already been accepted 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 should 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 YES is specified.

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 ACCEPT command and before the ACCEPT REUSE command, SMP/E may use the wrong level of object modules.

SELECT

Specifies one or more SYSMODs that should be accepted.

You may specify any combination of individual SYSMOD IDs and FMIDSET names, provided that there are no duplicate values. 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 reaccept 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 is 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 accepted.

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 example, 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 SOURCEID operands.
If a source ID is specified implicitly or explicitly on both the SOURCEID operand and the EXSRCID operand, all SYSMODs with that source ID are excluded from processing.
If a given SYSMOD has multiple source IDs and at least one of those source IDs is specified either explicitly or implicitly on the SOURCEID operand, and another one is specified either explicitly or implicitly 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.
Functions containing a ++VER DELETE statement are not automatically included by the SOURCEID operand. You must specify them on the SELECT operand.
If no SYSMOD types are specified, 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.

USERMODS

indicates that all eligible USERMODs should be accepted.

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 was specified on the ACCEPT 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 ACCEPT command.
After the initial zone group is established, it is culled by removing all target zones for ACCEPT 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 FORFMID is specified, only cross-zone requisites for the specified FMIDs become primary candidates for installation.
When the XZREQ operand is specified without EXSRCID operand, FORFMID operand, the SELECT operand, or the SOURCEID operand, only unsatisfied cross-zone requisites become primary candidates.
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 the XZREQ operand is specified, the XZGROUP operand may not be specified as a null list.