Parameter Descriptions

The parameter descriptions for REQUEST=READ_LCONTROLS are listed in alphabetical order. Default values are underlined:

REQUEST=READ_LCONTROLS

Use this input parameter to specify that control information for the list specified by LISTNUM be returned.

,ANSAREA=NO_ANSAREA

,ANSAREA=ansarea

Use this output parameter to specify an answer area to contain list control information about the LISTNUM list that is returned from the request. The format of the answer area is described by mapping macro IXLYLAA.

When the request successfully completes, the following information is returned to the answer area:

The total number of entries or elements currently on the list (field LAALISTCNT).
The maximum number of entries or elements allowed to reside on the list (field LAALISTLIMIT).
The approximate number of list transitions from the empty to the non-empty state (field LAALISTTRAN).
The user-defined list description (field LAALISTDESC) and list authority (field LAALISTAUTH).
The number of list monitoring information elements returned in the BUFFER area or BUFLIST buffers (field LAALMICNT).
The list entry identifier of the entry to which the list cursor points (field LAALISTCURSOR).
The current value of the list cursor direction indicator (field LAACURSORDIR). Returned only for a structure allocated in a CFLEVEL=1 or higher coupling facility.
The list controls key value (field LAALISTKEY). Returned only for a structure allocated in a CFLEVEL=1 or higher coupling facility.
The list controls maximum list key value (field LAAMAXLISTKEY). Returned only for a structure allocated in a CFLEVEL=1 or higher coupling facility.

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

,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 the returned list monitoring data for the LISTNUM list.

You must define the buffer to be 4096 bytes on a 4096-byte boundary.

Once the request completes, the buffer contains, starting at offset zero, an array of list monitoring information. The relative position of an element in the array associates that element with a connection identifier. The first array element is associated with a connection identifier of zero, and is reserved. The format of each array element is described by mapping macro IXLYLMI. The array elements are numbered from 0 to LAALMICNT-1.

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 a 4096-byte area to contain the data returned by the request.

,BUFLIST=buflist

Use this input parameter to specify a buffer to hold the returned list monitoring information for the LISTNUM list.

BUFLIST specifies a 128-byte storage area that contains the address of a single buffer. (Unlike any other IXLLIST request, for a READ_LCONTROLS request, only one buffer can be passed.) The address of the buffer should be placed in the second four bytes of the 128-byte area, beginning at offset zero. The rest of the area is ignored.

You must define the buffer to be 4096 bytes on a 4096-byte boundary.

Once the request completes, the buffer contains, starting at offset zero, an array of list monitoring information. The relative position of an element in the array associates that element with a connection identifier. The first element is associated with a connection identifier of zero, and is reserved. The format of each array element is described by mapping macro IXLYLMI.

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 the address of the buffer.

,BUFSTGKEY=bufstgkey

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

If you do not specify BUFSTGKEY, all references to the buffer are assumed to be in your PSW key.

To Code: Specify the RS-type name or address (using a register from 2 to 12) of a 1-byte field that contains the storage key in the format kkkkxxxx in which only the left four bits are used. (The right four bits are 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.

,LISTNUM=listnum

Use this input parameter to specify the number of the list for which list control and monitoring information will be returned.

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.

,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

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 if the request is processed asynchronously.

See z/OS MVS Programming: Sysplex Services Guide for more information on understanding synchronous and asynchronous cache operations.

SYNCSUSPEND: The request processes synchronously. If necessary, the request is suspended until it can complete synchronously. To use this option, your program must be enabled for I/O and external interrupts.
SYNCECB: The request processes synchronously if possible. If the request processes asynchronously, the ECB specified by REQECB is posted when the request completes.
SYNCEXIT: The request processes synchronously if possible. If the request processes asynchronously, your complete exit is given control when the request completes.
SYNCTOKEN: The request processes synchronously if possible. If the request processes asynchronously, an asynchronous request token is returned to the area specified by REQTOKEN. 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.
ASYNCECB: The request processes asynchronously. The ECB specified by REQECB is posted when the request completes.
ASYNCEXIT: The request processes asynchronously. Your complete exit is given control when the request completes.
ASYNCTOKEN: The request processes asynchronously. An asynchronous request token is returned to the area specified by REQTOKEN. 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.

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

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