A task uses a multiple-part naming convention on an ENQ or RESERVE request to identify a resource that it needs and to indicate the extent to which access should be serialized for that resource.
The following are the parts of the name used on ENQ and RESERVE requests:
Indicates what class contains the resource. For example, if a task allocates a data set, then it specifies SYSDSN as the QNAME.
Indicates the name of the resource needed by the task. For example, when a task needs to allocate a data set, the task usually uses the dsname of the data set as the RNAME.
Indicates how z/OS serializes access to the resource:
Serializes access only in the address space of the task
Serializes access in the current processor or image; that is, in the local system only
Serializes access among all of the systems in the complex
To serialize access to a resource, tasks must issue ENQ requests that match all three: QNAME, RNAME, and scope. All three parts of the name are used to identify the resource. ENQ/RESERVE requests for resources that do not match all three parts are considered by z/OS to be requests for different resources. GDIF and ECMF work with the same QNAMEs, RNAMEs, and scopes to identify resources.
RESERVE requests are always treated as having SCOPE SYSTEMS. Usually, a program makes a RESERVE request by using the RESERVE macro of z/OS. Sometimes, a program makes a RESERVE request by using the ENQ macro but also using the UCB keyword of the ENQ macro. To reduce confusion, assume that programs always use the RESERVE macro to make RESERVE requests and always use the ENQ macro to make ENQ requests; that is, assume that programs never use the UCB keyword of the ENQ macro.
CA MII has no effect on ENQ requests that specify STEP as the request scope.
|
Copyright © 2014 CA.
All rights reserved.
|
|