z/OS MVS Programming: Sysplex Services Reference
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


REQUEST=OBTAIN

z/OS MVS Programming: Sysplex Services Reference
SA38-0658-00

The parameter descriptions for REQUEST=OBTAIN are listed in alphabetical order. Default values are underlined.
,CONID=NO_CONID
,CONID=conid
Use this input parameter to specify the connection identifier that indicates the connection from which the record data entry is being reacquired. If the record data entry designated by ENTRYID is not associated with the connection specified by CONID, the IXLLOCK request will fail. When a record data entry is successfully reacquired, it will become associated with the reacquiring connected user.

To Code: Specify the RS-type name or address (using a register from 2 to 12) of a one-byte input field that contains the connection identifier associated with the record data entry to be reacquired.

,CRITICALREQUEST=0
,CRITICALREQUEST=criticalrequest
Use this input parameter to indicate whether monitoring of storage is to be honored for this request. Valid values are 0 (or IxllockCriticalRequestNo) and 1 (or IxllockCriticalRequestYes). The CRITICALREQUEST option only has meaning when MONITORSTORAGE=1 (IxlconnMonitorStorageYes) is also specified on the IXLCONN request.

A value of 0 (IxllockCriticalRequestNo) specifies to monitor storage usage whenever MONITORSTORAGE=1 (IxlconnMonitorStorageYes) is also specified on the IXLCONN request. When the amount of inuse storage reaches a preestablished threshold, the request will be rejected with a return code of IXLRETCODEENVERROR and a reason code of IXLRSNCODERESOURCESCONSTRAINED.

A value of 1 (IxllockCriticalRequestYes) specifies not to monitor storage usage. Preestablished thresholds for the amount of inuse storage will be ignored for this request. Only when dataspace storage for this request becomes exhausted will an abend X'026' be issued by the XES storage manager.

Any other specified value will have the same behavior as specifying a value of 0 (IxllockCriticalRequestNo).

To Code: Specify the RS-type name or address (using a register from 2 to 12) of a one-byte input field that contains the value indicating whether monitoring of storage is to be honored.

,ENTRYCOUNT=entrycount
Use this output parameter to contain the number of record data entries in the structure that are currently in-use upon successful, synchronous completion of the request. This value is analogous to the IXLYAMDSTRL_LSEC field that is returned by the XES Accounting and Measurement service, IXLMG. The value returned in the ENTRYCOUNT field can be used in conjunction with the value indicating the maximum number of record data entries supported by the allocated lock structure to monitor structure capacity and anticipate “structure full” conditions. The maximum number of record data entries allowed is returned in the CONALOCKMAXRECORDELEMENTS field of the Connect answer area. You can also use the IXLMG macro to retrieve the value, which will be returned in the IXLYAMDSTRL_LSEC field of the IXLMG answer area.

Note that if the request is unsuccessful or being processed asynchronously (in which case the results are presented to the user's complete exit), the contents of ENTRYCOUNT are not valid.

To Code: Specify the RS-type name or address (using a register from 2 to 12) of a fullword output field to contain the number of record data entries in the structure that are currently in-use.

,ENTRYID=entryid
Use this input/output parameter to specify the unique identifier assigned to the record data entry.
  • When RDATA=WRITE, ENTRYID is an output parameter to contain the unique identifier assigned to the record data entry upon successful, synchronous request completion. If the request is unsuccessful or being processed asynchronously (in which case the results are presented to the user's complete exit), the contents of ENTRYID are not valid.
  • When RDATA=REACQUIRE, ENTRYID is an input parameter to contain the unique identifier of the record data entry to be reacquired. The entry with this identifier must already exist.

ENTRYID is a required keyword when RDATA=REACQUIRE or RDATA=WRITE is specified.

To Code: Specify the RS-type name or address (using a register from 2 to 12) of a 12-character input/output field to contain the unique identifier assigned to the record data entry.

,HASHVAL=hashval
Use this input parameter to specify a hash value associated with the resource name. The hash value along with the resource name serves to fully qualify an IXLLOCK resource. The method of producing the hash value is completely at the discretion of the connected user. Typically, the value provided for this keyword is the output of a user-defined hashing algorithm that receives a resource name as input.

To Code: Specify the RS-type name or address (using a register from 2 to 12) of an input fullword field that contains a hash value associated with the resource name.

,LOCKDATA=ALL_ZEROES
,LOCKDATA=lockdata
Use this input parameter to specify user-defined data to be associated with this resource. The contents of LOCKDATA are at the discretion of the user and have no meaning to the system. The associated LOCKDATA is presented to this connected user's complete exit if the OBTAIN request is processed asynchronously. The LOCKDATA is also presented to the complete and notify exits to inform the user of subsequent updates (such as the completion of requests to alter this resource) and status regarding the owned resource.

To Code: Specify the RS-type name or address (using a register from 2 to 12) of an eight-character input field that contains connected user-defined data to be associated with this resource.

,MODE=SYNCSUSPEND
,MODE=SYNCEXIT
,MODE=SYNCFAIL
,MODE=VALUE
Use this input parameter to specify how the request should be processed if it is not able to be serviced immediately. If the request is able to be processed immediately, the MODE keyword is ignored and control is returned to the caller with all information regarding the completed request.
SYNCSUSPEND
Indicates that the OBTAIN request is to be handled synchronously. The caller receives control back only when the request is complete. If necessary, the caller is suspended until the request is complete.
SYNCEXIT
Indicates that the OBTAIN request is to be handled asynchronously. Return and reason codes are returned to the caller indicating that the request will be processed in this manner. Request completion is reported through the connected user's complete exit. The user-specified complete exit might be given control before control returns to the next sequential instruction after the connected user's IXLLOCK request.
SYNCFAIL
Indicates that the OBTAIN request is to be cancelled if it cannot be processed without delay. Return and reason codes are returned to the caller indicating that the request has been cancelled.
SYNCFAILDELAY=0,SYNCFAILDELAY=syncfaildelayvalue
When you specify MODE=SYNCFAIL, use this optional keyword to handle delays for XES latch serialization when the XES normal latch is being held.

0 indicates that the delay is to be cancelled and is the default; the return and reason code provide information.

syncfaildelayvalue specifies the value represented in IXLYCON, to control which delays to tolerate by the MODE=SYNCFAIL request. This option is ignored for all other types of requests.

The valid IXLYCON constants for IXLLOCK requests are:
  • IXLSYNCFAILDELAYFORLATCHNO, which specifies that if the request encounters delays for internal XES serialization, it is cancelled with the IxlRetCodeEnvError return code and IxlRsnCodeNoDelay reason code.
  • IXLSYNCFAILDELAYFORLATCHYES , which specifies that if the request encounters delays for normal internal XES serialization, it is NOT cancelled with the IxlRetCodeEnvError return code and IxlRsnCodeNoDelay reason code. Note that this does not include serialization on behalf of serialized connection recovery processing.

Note that IXLCONN ALLOWAUTO=YES, SUSPEND=YES behavior is not changed as part of the SYNCFAILDELAY specification. If the system receives an IXLLOCK OBTAIN or ALTER SYNCFAIL request while the target structure is delayed because of system-managed rebuild processing, the request is not deferred regardless of SYNCFAILDELAY. The system will fail the request with the IxlRsnCodeNoDelay reason code.

If you specify a value other than one of the valid IXLYCON constants for an IXLLOCK request, the request fails with reason code IxlRsnCodeBadSyncFailDelay

To Code: Specify the RS-type name or address (using a register from 2 to 12) of a one-byte input field that contains a value that indicates the desired SyncFailDelay behavior for the request to be processed.

VALUE
Indicates that the contents of MODEVAL are to be used to specify how the request is to be processed if it cannot be serviced immediately.
,MODEVAL=modeval
Use this input parameter to specify the value, as represented in IXLYCON, of the desired mode in which the request is to be processed.
The valid IXLYCON constants for an OBTAIN request are:
  • IXLMODESYNCSUSPEND
  • IXLMODESYNCEXIT
  • IXLMODESYNCFAIL

If you specify a value other than one of the IXLYCON constants that is valid for an OBTAIN request, the IXLLOCK request fails with reason code IXLRSNCODEBADMODEVAL.

To Code: Specify the RS-type name or address (using a register from 2 to 12) of a one-byte input field that contains a value indicating the desired mode in which the request is to be processed.

SYNCFAILDELAY=0,SYNCFAILDELAY=syncfaildelayvalue
When you specify MODE=VALUE,MODEVAL=modeval, use this optional keyword to handle delays for XES latch serialization when the XES normal latch is being held.

0 indicates that the delay is to be cancelled and is the default; the return and reason code provide information.

syncfaildelayvalue specifies the value represented in IXLYCON, to control which delays to tolerate by the MODE=VALUE,MODEVAL=modevalL request. This option is ignored for all other types of requests.

The valid IXLYCON constants for IXLLOCK requests are:
  • IXLSYNCFAILDELAYFORLATCHNO, which specifies that if the request encounters delays for internal XES serialization, it is cancelled with the IxlRetCodeEnvError return code and IxlRsnCodeNoDelay reason code.
  • IXLSYNCFAILDELAYFORLATCHYES , which specifies that if the request encounters delays for normal internal XES serialization, it is NOT cancelled with the IxlRetCodeEnvError return code and IxlRsnCodeNoDelay reason code. Note that this does not include serialization on behalf of serialized connection recovery processing.

Note that IXLCONN ALLOWAUTO=YES, SUSPEND=YES behavior is not changed as part of the SYNCFAILDELAY specification. If the system receives an IXLLOCK OBTAIN or ALTER SYNCFAIL request while the target structure is delayed because of system-managed rebuild processing, the request is not deferred regardless of SYNCFAILDELAY. The system will fail the request with the IxlRsnCodeNoDelay reason code.

If you specify a value other than one of the valid IXLYCON constants for an IXLLOCK request, the request fails with reason code IxlRsnCodeBadSyncFailDelay

To Code: Specify the RS-type name or address (using a register from 2 to 12) of a one-byte input field that contains a value that indicates the desired SyncFailDelay behavior for the request to be processed.

,RDATA=NORDATA
,RDATA=WRITE
,RDATA=REACQUIRE
Use this input parameter to specify the record data operation, if any, that is to be performed as part of obtaining the specified resource.
NORDATA
Indicates that no record data entry is to be allocated and associated with the specified resource.
WRITE
Indicates that a record data entry is to be allocated and to be associated with the owned resource.
REACQUIRE
Indicates that a record data entry identified by ENTRYID is to be reacquired.
The use of the REACQUIRE option is intended to aid in recovery of resources during recovery scenarios. For example,
  • Upon reconnecting, a previously failed-persistent connected user of locking services can re-obtain resources that were held by its previous instance and reacquire the existing record data entries to be associated with the new instances of ownership. The user could potentially use the UPDATERDATA suboption to update the contents of the reacquired record data entries to reflect updated state information.
  • A connected user of locking services fails such that the related surviving users wish to recover the resources held by the failing user. The survivors may wish to obtain the specified resources while reacquiring the associated record data entries from the failed connector. The surviving connectors could potentially exploit the CONID suboption to coordinate their processing.
,RDATAVAL=rdataval
Use this input/output parameter to specify the user-defined data to be written to the record data entry.

RDATAVAL is a required parameter when RDATA=WRITE is specified. The entry identifier of the record data entry is returned to the connected user in the ENTRYID field.

To Code: Specify the RS-type name or address (using a register from 2 to 12) of a 64-character input/output field that contains user-defined data to be written to the record data entry. The contents of RDATAVAL are at the discretion of the connected user and have no meaning to the system. The contention exit may modify the value that is to be written to the record data entry as part of granting the request.

If completion of the OBTAIN request is presented to the user synchronously, the input variable will contain the resultant record data value.

,RNAME=rname
Use this input parameter to specify the resource name for which the request is to be processed. The resource name and length along with the hash value serve to fully qualify an IXLLOCK request.

To Code: Specify the RS-type name or address (using a register from 2 to 12) of the character input field that contains the resource name for which the request is being processed.

,RNAMELEN=NO_RNAMELEN
,RNAMELEN=rnamelen
Use this input parameter to specify the length of the resource name identified by RNAME. The resource name length attribute is established on the IXLCONN invocation. The resource name and length along with the hash value serve to fully qualify an IXLLOCK request.
RNAMELEN is valid only when variable-length resource names are in effect for the lock structure. The value you specify for RNAMELEN must be between 1 and 300 inclusive.
  • If you specify RNAMELEN for a lock structure that does not have the variable-length name attribute, the system rejects the request with reason code IXLRSNCODENOVARRNAME.
  • If you specify a value for RNAMELEN that is different from the actual length of RNAME, the system uses the RNAMELEN value as the length of RNAME.
  • If you do not specify RNAMELEN, the length of the resource name defaults to 64 bytes.

To Code: Specify the RS-type name or address (using a register from 2 to 12) of a fullword input field that contains the resource name length of the resource identified by RNAME.

,STATE=SHR
,STATE=EXCL
,STATE=VALUE
Use this input parameter to specify the state in which the connected user is requesting to own the resource.
Note that the OBTAIN request may be granted by the contention exit with a STATE different from what was requested. If a user's protocol is exploiting the capability for the contention exit to grant requests with a STATE different than requested, it is recommended that STATE=VALUE be specified for this option to ensure that an output variable will be available to contain the resultant state when request completion is reported synchronously.
SHR
Specifies a shared state.
EXCL
Specifies an exclusive state.
VALUE
Specifies that the contents of STATEVAL are to be used to identify the ownership state.
,STATEVAL=stateval
Use this input/output parameter to specify the value, as represented in IXLYCON, of the desired ownership state.

Note that if a value other than the IXLYCON constants for shared or exclusive is specified, the resource will be requested in the default STATE of share.

Upon successful, synchronous request completion, the input variable will contain the state in which ownership of the resource was granted.

To Code: Specify the RS-type name or address (using a register from 2 to 12) of a one-byte input field that contains a value indicating the desired ownership state.

,UDATAVAL=ALL_ZEROES
,UDATAVAL=udataval
Use this input/output parameter to specify user-defined data to be associated with the resource. The contents of UDATAVAL are at the discretion of the connected user and have no meaning to the system. UDATAVAL is presented to the complete, notify, and contention exits when driven.

Note that the contents of UDATAVAL may be modified by the contention exit as part of granting or denying the request. The contents of UDATAVAL have no meaning to the system.

If request completion is reported to the connected user synchronously, UDATAVAL, if specified, will contain the resultant user data value.

To Code: Specify the RS-type name or address (using a register from 2 to 12) of a 64-character input/output field that contains user-defined data to be associated with the resource.

,UPDATERDATA=NO
,UPDATERDATA=YES
Use this input parameter to specify whether or not to update the contents of the record data entry at the time it is reacquired.
NO
Indicates that the data in the record data entry is not to be updated.
YES
Indicates that the data in the record data entry is to be updated with the data specified by RDATAVAL.

RDATAVAL is a required keyword when UPDATERDATA=YES is specified.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014