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


Parameter Descriptions

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

The parameter descriptions for REQUEST=READ_MULT are listed in alphabetical order. Default values are underlined:
REQUEST=READ_MULT
Use this input parameter to read multiple entries from within the entire structure.
,ADJAREA=adjarea
Use this output parameter to specify a storage area to contain the adjunct data that was read from the first processed entry. Adjunct data is returned only if ADJDATA is specified on the TYPE parameter.

Specify ADJAREA only for structures that support adjunct data. (Adjunct areas for a structure are established through the IXLCONN macro.)

To Code: Specify the RS-type name or address (using a register from 2 to 12) of a 64-byte area (the adjunct area) to contain the adjunct data.

,ANSAREA=NO_ANSAREA
,ANSAREA=ansarea
Use this output parameter to specify an answer area to contain information returned from the request. The format of the answer area is described by mapping macro IXLYLAA.
On a successful completion of the request, the answer area contains:
  • List entry controls (field LAARLRMLCTLS mapped by IXLYLCTL) from the first processed list entry (if ECONTROLS is specified on the TYPE parameter).
  • The number of processed entries (field LAAREADCNT).
If the request completes prematurely, the answer area contains:
  • A restart token (LAARESTOKEN) or extended restart token (LAAEXTRESTOKEN) that can be specified on a subsequent READ_MULT request. (See the RESTOKEN and EXTRESTOKEN parameter descriptions.)
  • The number of processed entries (LAAREADCNT).

To Code: Specify the RS-type name or address (using a register from 2 to 12) of an area (with a length of ANSLEN) where the information from the request will be put.

,ANSLEN=anslen
Use this input parameter to specify the size of the storage area specified by ANSAREA.

Check the prologue of the IXLYLAA mapping macro for the minimum required size of the answer area, or use the length field (LAA_LEN) in the LAA.

To Code: Specify the RS-type name or address (using a register from 2 to 12) of a 2-byte field that contains the size, in bytes, of the answer area.

,AUTHCOMP=NO_AUTHCOMP
,AUTHCOMP=authcomp
Use this input parameter to specify a value to be compared to the list authority value of the list specified by LISTNUM. You must supply the LISTNUM parameter.

If the comparison does not meet the condition specified by the AUTHCOMPTYPE parameter (EQUAL or LESSOREQUAL), the request fails.

Note: The AUTHCOMP parameter is valid only for list structures allocated in a coupling facility with CFLEVEL=1 or higher.

To Code: Specify the RS-type name or address (using a register from 2 to 12) of the 16-byte field that contains the list authority value.

,AUTHCOMPTYPE=EQUAL
,AUTHCOMPTYPE=LESSOREQUAL
Use this input parameter to specify how the list authority comparison is to be performed.
EQUAL
The list authority for the list specified by LISTNUM must be equal to the value specified for AUTHCOMP.
LESSOREQUAL
The list authority for the list specified by LISTNUM must be less than or equal to the value specified for AUTHCOMP.
Note: The AUTHCOMPTYPE parameter is valid only for list structures allocated in a coupling facility with CFLEVEL=1 or higher.
,BUFADDRTYPE=VIRTUAL
,BUFADDRTYPE=REAL
Use this input parameter to specify whether the buffer addresses specified in the BUFLIST list are virtual storage or real storage addresses.
VIRTUAL
The buffer addresses are virtual storage addresses. The virtual storage can be pageable or nonpageable. See the PAGEABLE parameter for information about managing storage binds when specifying virtual storage addresses.
REAL
The buffer addresses are real storage addresses.

It is the caller's responsibility to manage the binds between the data buffer virtual storage and the real storage addresses provided. The caller must ensure that the data buffer virtual storage remains bound to the real storage addresses provided until the request completes.

,BUFALET=NO_BUFALET
,BUFALET=bufalet
Use this input parameter to specify an access list entry token (ALET) to be used in referencing all of the buffers specified by BUFLIST.

To Code: Specify the RS-type name or address (using a register from 2 to 12) of a 4-byte field that contains the ALET.

,BUFFER=buffer
Use this output parameter to specify a buffer area to hold data that is read from list entries.
You must ensure that the storage area specified by BUFFER:
  • Is a multiple of 4096 bytes
  • Is less than or equal to 65536 bytes
  • Starts on a 4096-byte boundary

    See the BUFSIZE parameter description for specifying the size of the buffer.

The type of data returned to the buffer depends on which types of data you request on the TYPE parameter. See z/OS MVS Programming: Sysplex Services Guide for more detailed information about how data is returned from this request.

Note: You cannot code BUFFER with MODE=ASYNCNORESPONSE.

To Code: Specify the RS-type name or address (using a register from 2 to 12) of an area (with a length of BUFSIZE) where the data read from list entries will be put.

,BUFLIST=buflist
Use this output parameter to specify a list of buffers to hold data that is read from list entries. BUFLIST specifies a 128-byte storage area that consists of a list of 0 to 16 buffer addresses.
The 128-byte storage area must:
  • Consist of 0 to 16 elements.
  • Each element must consist of an 8-byte field in which:
    • The left (high-order) four bytes are reserved and
    • The right (low-order) four bytes contain the address of a buffer.
The BUFLIST buffers must:
  • Reside in the same address space or same data space.
  • Be 4096 bytes.
  • Start on a 4096-byte boundary.
    Note: The buffers do not have to be contiguous in storage. List services treats BUFLIST buffers as a single buffer, even if the buffers are not contiguous.

    See the BUFNUM parameter description to specify the number of buffers in the buffer list.

The type of data returned to the buffers depends on which types of data you request on the TYPE parameter. See z/OS MVS Programming: Sysplex Services Guide for more detailed information about how data is returned from this request.

Note: You cannot code BUFLIST with MODE=ASYNCNORESPONSE.

To Code: Specify the RS-type name or address (using a register from 2 to 12) of a 128-byte area that contains a list of buffer addresses.

,BUFNUM=bufnum
Use this input parameter to specify the number of buffers in the BUFLIST list. Valid BUFNUM values are from 0 to 16. A value of zero indicates that no data is to be read into the buffers.

To Code: Specify the RS-type name or address (using a register from 2 to 12) of a 1-byte field that contains the number of buffers (0 to 16) in the list (BUFLIST).

,BUFSIZE=bufsize
Use this input parameter to specify the size of the BUFFER area. See the BUFFER parameter description for valid buffer sizes.

To Code: Specify the RS-type name or address (using a register from 2 to 12) of a fullword field that contains the size of the buffer (BUFFER) in bytes.

,BUFSTGKEY=CALLERS_KEY
,BUFSTGKEY=bufstgkey
Use this input parameter to specify a storage key that you define and use when referencing the buffers specified by BUFLIST or the buffer specified by BUFFER.

If you do not specify BUFSTGKEY, or if you specify BUFSTGKEY=CALLERS_KEY, all references to the buffer(s) are performed using the caller's PSW key.

To Code: Specify the RS-type name or address (using a register from 2 to 12) of an 8-bit field that contains the storage key in the format B'kkkkxxxx', where kkkk is the key and xxxx is ignored.

,CONTOKEN=contoken
Use this input parameter to specify the connect token that was returned by the IXLCONN service. The connect token uniquely identifies your connection to the list structure, and must be specified on each IXLLIST invocation.

The connect token is available in the IXLCONN answer area mapped by IXLYCONA.

To Code: Specify the RS-type name or address (using a register from 2 to 12) of a 16-byte field that contains the connect token.

,EXTRESTOKEN=NO_EXTRESTOKEN
,EXTRESTOKEN=extrestoken
Use this input parameter to specify an extended restart token that can be used to resume processing of a READ_MULT request that completed prematurely. The extended restart token is returned in the answer area (field LAAEXTRESTOKEN), and should be specified on the next READ_MULT request to resume processing.
If the request does not complete prematurely, the extended restart token will not be provided.
Note:
  1. Specifying an extended restart token of all zeros causes list services to treat all of the entries as unprocessed.
  2. Do not specify an extended restart token other than the one returned in the answer area or one set to all zeros, because results will be unpredictable.

Requestors that specify IXLCONN ALLOWAUTO=YES must use the extended restart token. Requestors that specify or default to IXLCONN ALLOWAUTO=NO must use the standard restart token (RESTOKEN).

To Code: Specify the RS-type name or address (using a register from 2 to 12) of a 16-byte field that contains the extended restart token.

,KEYCOMP=NO_KEYCOMP
,KEYCOMP=keycomp
Use this input parameter to specify a value to be compared to the entry key of each list entry in the designated list.

If the list entry that is to be processed does not have an entry key value that is equal to the specified KEYCOMP value, the entry is not processed. Processing continues with the next entry.

Note: The KEYCOMP parameter is valid only for list structures allocated in a coupling facility with CFLEVEL=1 or higher.

To Code: Specify the RS-type name or address (using a register from 2 to 12) of the 16-byte field that contains the value to be compared to the entry key of the designated list entry.

,LISTNUM=NO_LISTNUM
,LISTNUM=listnum
Use this input parameter to specify the number of the list on which the entries to be read must reside.

To Code: Specify the RS-type name or address (using a register from 2 to 12) of a 4-byte field that contains the number of the list.

,LOCKCOMP=NO_LOCKCOMP
,LOCKCOMP=lockcomp
This parameter has slightly different meanings based on the value specified for the LOCKOPER parameter. Generally, this input parameter specifies a connection identifier to be verified as the owner of the lock specified by LOCKINDEX. This verification is a prerequisite to the successful completion of the request.

When LOCKCOMP is specified, the completion of the request is conditional on there being no contention for the lock. If contention exists, the request will fail.

The connection identifier is available from the IXLCONN answer area, mapped by IXLYCONA, in field CONACONID.

The effect of LOCKCOMP is based on the LOCKOPER value specified. See the description under LOCKOPER to see how each request is affected by this parameter.

To Code: Specify the RS-type name or address (using a register from 2 to 12) of a 1-byte field that contains the connection identifier.

,LOCKINDEX=NO_LOCKINDEX
,LOCKINDEX=lockindex
Use this input parameter to specify the index of the lock to be operated on as specified by LOCKOPER. The lock indexes begin with zero.
Note: You cannot code LOCKINDEX with MODE=ASYNCNORESPONSE.

To Code: Specify the RS-type name or address (using a register from 2 to 12) of a 4-byte field that contains the lock index.

,LOCKMODE=COND
Use this input parameter to specify that the lock operation for the lock specified by LOCKINDEX be performed conditionally; that is, only if there is no contention for the lock. If the specified lock is held by another user, the request will be terminated with no change to the structure, and return and reason codes describing the termination are returned to the caller.
,LOCKOPER=NOTHELD
,LOCKOPER=HELDBY
Use this input parameter to specify the type of operation to be performed on the lock specified by LOCKINDEX.
LOCKOPER=NOTHELD
The request is performed only if the lock is not held by any connection. This option also ensures that the lock remains free for the duration of the request. If another connection holds the lock, your task is suspended until the lock is released, or your request fails depending on the LOCKMODE value you specify. See the LOCKMODE description for how to handle possible lock contention.
LOCKOPER=HELDBY
  • When LOCKCOMP is not specified, the request is performed only if your connection holds the lock.
  • When LOCKCOMP is specified, the request is performed only if the lock is held by the connection specified by LOCKCOMP.
,MF=S
,MF=(L,mfctrl)
,MF=(L,mfctrl,mfattr)
,MF=(L,mfctrl,0D)
,MF=(E,mfctrl)
,MF=(E,mfctrl,COMPLETE)
Use MF=S to specify the standard form of the macro, which builds an inline parameter list and generates the macro invocation to transfer control to the service.

Use MF=L to specify the list form of the macro. Use the list form together with the execute form of the macro for applications that require reentrant code. The list form defines an area of storage that the execute form uses to store the parameters. Only the PLISTVER parameter can be coded with the list form of the macro.

Use MF=E to specify the execute form of the macro. Use the execute form together with the list form of the macro for applications that require reentrant code. The execute form stores the parameters into the storage area defined by the list form, and generates the macro invocation to transfer control to the service.
,mfctrl
Use this output parameter to specify a storage area to contain the parameters.

To Code: Specify the RS-type name or address (using a register from 2 to 12) of the parameter list.

,mfattr
Use this input parameter to specify the name of a 1- to 60-character string that can contain any value that is valid on an assembler DS pseudo-op. You can use this parameter to force boundary alignment of the parameter list. If you do not code mfattr, the system provides a value of 0D, which forces the parameter list to a doubleword boundary.
,COMPLETE
Use this input parameter to require that the system check for required parameters and supply defaults for omitted optional parameters.
Note: In the macro expansion you might see some defaults for optional parameters that are not documented here. The ones that are not documented do not have any effect on the macro. For example, if SMILE=var were an optional parameter and the default is SMILE=NO_SMILE then it would not be documented. However, if the default was SMILE=:-), then it would be documented because a value would be the default.
,MODE=SYNCSUSPEND
,MODE=SYNCECB
,MODE=SYNCEXIT
,MODE=SYNCTOKEN
,MODE=ASYNCECB
,MODE=ASYNCEXIT
,MODE=ASYNCTOKEN
,MODE=ASYNCNORESPONSE
Use this input parameter to specify:
  • Whether the request is to be performed synchronously or asynchronously
  • How you wish to be notified of request completion
MODE=SYNCSUSPEND
The request is suspended until it can complete synchronously. To use this option, your program must be enabled for I/O and external interrupts.
MODE=SYNCECB
The request processes synchronously if possible. If the request processes asynchronously, the ECB specified by REQECB is posted when the request completes.
MODE=SYNCEXIT
The request processes synchronously if possible. If the request processes asynchronously, your complete exit is given control when the request completes.
MODE=SYNCTOKEN
The request processes synchronously if possible. If the request processes asynchronously, an asynchronous request token is returned in the area specified by REQTOKEN on invocation of the request. Use the returned request token on the IXLFCOMP macro to determine whether your request has completed.
Note: ANSAREA is a required parameter when MODE=SYNCTOKEN is specified.
MODE=ASYNCECB
The request processes asynchronously. The ECB specified by REQECB is posted when the request completes.
MODE=ASYNCEXIT
The request processes asynchronously. Your complete exit is given control when the request completes.
MODE=ASYNCTOKEN
The request processes asynchronously. An asynchronous request token is returned in the area specified by REQTOKEN upon invocation of the request. Use the returned request token on the IXLFCOMP macro to determine whether your request has completed.
Note: ANSAREA is a required parameter when MODE=ASYNCTOKEN is specified.
MODE=ASYNCNORESPONSE
The request processes asynchronously. No notification of request completion is provided. The answer area (ANSAREA) fields will not contain valid information when this mode is specified.
Note: You cannot code MODE=ASYNCNORESPONSE with LOCKINDEX, BUFFER, or BUFLIST.
,PAGEABLE=YES
,PAGEABLE=NO
Use this input parameter to identify whether the storage areas specified by BUFFER or BUFLIST are in pageable or potentially pageable storage.
YES
Specify this option to indicate that the BUFFER or BUFLIST buffers reside in pageable virtual storage. XES performs the required page fixing to fix the buffers in real storage while the cache or list request transfers data to or from the coupling facility.

This includes storage obtained from pageable subpools, disabled reference (DREF) storage, and may include storage that has the potential to become pageable during the processing of a request. (An example is address space storage owned by any swappable address space, for which a PGSER FIX has been successfully processed, but for which the owning address space gets swapped during processing of a cache or list request.) This does not include implicitly non-pageable storage (for example, storage obtained from non-pageable subpools).

The system takes responsibility for managing binds to central storage for the duration of the cache or list request, regardless of what address space owns the storage or whether the storage-owning address space is swappable or nonswappable. The storage can be owned by any address space.

High shared virtual storage areas (above 2GB) may not be used.

NO
Specify this option to indicate that the BUFFER or BUFLIST buffers reside in non-pageable virtual storage. XES does not page fix the buffers in real storage.

This includes implicitly non-pageable storage areas (for example, storage obtained from non-pageable subpools), and may include storage that has the potential to become pageable during the processing of a request (An example is address space storage owned by any swappable address space, for which a PGSER FIX has been successfully processed, but for which the owning address space gets swapped-out during processing of a cache or list request.)

The system takes responsibility for managing binds to central storage for the duration of the cache or list request, if and only if the non-pageable storage is owned by either the requestor's address space or the connector's address space. If the storage is owned by any other address space, then the invoker is responsible for ensuring that the virtual storage remains non-pageable for the duration of the request (including the case in which the storage is owned by a swappable address space that is swapped during processing of an IXLCACHE or IXLLIST request). Subject to this consideration, the storage can be owned by any address space. See z/OS MVS Programming: Sysplex Services Guide.

,PLISTVER=IMPLIED_VERSION
,PLISTVER=MAX
,PLISTVER=plistver
Use this input parameter to specify the version of the macro. See Understanding IXLLIST Version Support for a description of the options available with PLISTVER.
,REQDATA=NO_REQDATA
,REQDATA=reqdata
Use this input parameter with MODE=SYNCEXIT or MODE=ASYNCEXIT to pass any data you choose to the complete exit. The exit will get control only if the request is processed asynchronously.

To Code: Specify the RS-type name or address (using a register from 2 to 12) of an 8-byte field that contains the data to be passed to the complete exit.

,REQECB=reqecb
Use this output parameter with either MODE=SYNCECB or MODE=ASYNCECB to specify the address of an ECB, which is to be posted when the request completes if the request was processed asynchronously.
Before coding REQECB, you must ensure that:
  • You initialize the ECB before you issue the request.
  • The ECB resides in either common storage or the home address space where IXLCONN was issued.
  • Any tasks that wait for the ECB to be posted reside in the home address space where IXLCONN was issued.

To Code: Specify the RS-type name or address (using a register from 2 to 12) of a 4-byte field that contains the address of the ECB to be posted when the request completes. The ECB must be aligned on a fullword boundary.

,REQID=NO_REQID
,REQID=reqid
Use this input parameter to specify a user-defined request identifier to be associated with the request. You can specify this request identifier on the IXLPURGE macro to cancel a request that has not yet been processed.

To Code: Specify the RS-type name or address (using a register from 2 to 12) of an 8-byte field that contains the user-defined request identifier.

,REQTOKEN=reqtoken
Use this output parameter with either MODE=SYNCTOKEN or MODE=ASYNCTOKEN to specify the address of a storage area to receive the request token that is returned when the request will be processed asynchronously. This token, which uniquely identifies the request, must be used as input to the IXLFCOMP macro, which you use to determine if the request has completed.

To Code: Specify the RS-type name or address (using a register from 2 to 12) of a 16-byte field where the system will put the request token.

,RESTOKEN=NO_RESTOKEN
,RESTOKEN=restoken
Use this input parameter to specify a restart token that can be used to resume processing of a READ_MULT request that completed prematurely because it exceeded the coupling facility model-dependent time-out criteria. The restart token is returned in the answer area (field LAARESTOKEN), and should be specified on the next READ_MULT request to resume processing with the next entry to be read.
If the request does not exceed the model-dependent time-out criteria, the returned token will not be provided.
Note:
  1. Specifying an extended restart token of all zeros causes list services to treat all of the entries as unprocessed.
  2. Do not specify an extended restart token other than the one returned in the answer area or one set to all zeros, because results will be unpredictable.

Requestors that specify or default to IXLCONN ALLOWAUTO=NO must use the standard restart token. Requestors that specify IXLCONN ALLOWAUTO=YES must use the extended restart token (EXTRESTOKEN).

To Code: Specify the RS-type name or address (using a register from 2 to 12) of an 8-byte field that contains the restart token.

,RETCODE=retcode
Use this output parameter to specify a field to contain the return code. (The return code is also returned in register 15.)

To Code: Specify the RS-type name or address (using a register from 2 to 12) of a 4-byte field that will contain the return code when the request has completed.

,RSNCODE=rsncode
Use this output parameter to specify a field to contain the reason code returned, if applicable. (The reason code is also returned in register 0.)

To Code: Specify the RS-type name or address (using a register from 2 to 12) of a 4-byte field that will contain the reason code (if any) when the request has completed.

,TYPE=ENTDATA
,TYPE=ADJDATA
,TYPE=ECONTROLS
Use this input parameter to specify the type of data to be read from each processed entry.
ENTDATA
Entry data is read.
ADJDATA
Adjunct data is read.
ECONTROLS
List entry control data is read.

You can specify one, two, or all three of these data types, and you can code them in any order on the TYPE parameter. When more than one data type is specified, the format of the parameter would be: TYPE=(ENTDATA,ADJDATA,ECONTROLS). The order in which you code the values does not affect the order in which the system returns the data in the BUFFER area or BUFLIST buffers. See z/OS MVS Programming: Sysplex Services Guide for more information about how the data is arranged in the buffer(s).

,VERSCOMP=NO_VERSCOMP
,VERSCOMP=verscomp
Use this input parameter to specify a version number to be compared to the version number of each entry to be read. Only those entries with a version that meets the condition specified by the VERSCOMPTYPE parameter are read.

To Code: Specify the RS-type name or address (using a register from 2 to 12) of an 8-byte field that contains the version number.

,VERSCOMPTYPE=EQUAL
,VERSCOMPTYPE=LESSOREQUAL
Use this input parameter to specify how a list entry version number comparison as specified by VERSCOMP is to be performed.
Note: The VERSCOMPTYPE parameter is valid only for list structures allocated in a coupling facility with CFLEVEL=1 or higher.
VERSCOMPTYPE=EQUAL
The version number for the list entry must be equal to the value specified for VERSCOMP.
VERSCOMPTYPE=LESSOREQUAL
The version number for the list entry must be less than or equal to the value specified for VERSCOMP.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014