The parameters are explained as follows:

,#MSGDESC=#msgdesc

,#MSGDESC=1

When MSGDESC=msgdesc is specified, use this optional input parameter to indicate the number of data descriptors in the message descriptor table. The default is 1.

To code: Specify the RS-type name or address in register (2)-(12), of a fullword field, or specify a literal decimal value.

,#SYSTEMS=#systems

,#SYSTEMS=1

When SYSTEMS=NAME, SERVER=server, and SENDTO=SERVER are specified, use this optional input parameter to contain the number of system names specified by the SYSNAME keyword. The default is 1.

When SYSTEMS=SYSID, SERVER=server, and SENDTO=SERVER are specified, use this optional input parameter to contain the number of system IDs specified by the SYSID keyword. The default is 1.

To code: Specify the RS-type name or address in register (2)-(12), of a fullword field, or specify a literal decimal value.

,CLIENTLEVEL=clientlevel

,CLIENTLEVEL=0

When SENDTO=SERVER is specified, use this optional input parameter to contain a number that identifies the level of the client. When the request arrives on one or more of the target systems, XCF presents the request only to those server instances that support the indicated client level. If no server supports the indicated level, the request is canceled because the target server does not have any instances that are suitable for processing a request from a client of CLIENTLEVEL.

The client and server mutually determine the content and interpretation of the client level. The intended purpose is to provide a protocol that helps clients and servers function compatibly with mixed release levels. When it invokes the IXCSRVR macro to define itself to XCF, a server specifies the range of client levels (MINCLIENT and MAXCLIENT) whose server level requests it is willing to accept (MINLEVEL, MAXLEVEL). An uplevel server can in effect refuse to process requests from a downlevel client.

The default is 0.

To code: Specify the RS-type name or address in register (2)-(12), of a fullword field, or specify a literal decimal value.

,CRITERIA=criteria

,CRITERIA=SC_MINSERVERLEVEL,

When SENDTO=SERVER is specified, use this optional input parameter mapped by ixcysrvr_tCriteria to define the range of server levels and set of features that the server must support and that are suitable to the client to process the request. When a server is started, it specifies the range of server levels it supports (MINLEVEL, MAXLEVEL), the range of client levels whose requests it is willing to process (MINCLIENT, MAXCLIENT), and the features that it supports (FEATURES) when it invokes the IXCSRVR macro to define itself to XCF.

• Specifying server levels

  The meaning of "server level" is defined by the server. The intended purpose is to provide a protocol that helps clients and servers function compatibly with mixed release levels. An uplevel client can specify a minimum Server Level (sc_MinSeverLevel) to ensure that XCF does not route the request to a downlevel server. An uplevel server can in effect refuse to accept requests intended for a downlevel server instance.

  The sc_MinServerLevel field of the ixcysrvr_tCriteria mapping contains a number that identifies the minimum server level required to process the request.

  The sc_MaxServerLevel field of the ixcysrvr_tCriteria mapping contains a number that identifies the maximum server level that is suitable for processing the request.

  If non-zero, sc_MaxServerLevel must be greater than or equal to sc_MinServerLevel. If sc_MaxServerLevel is zero (0), it defaults to the value used for sc_MinServerLevel.

  The combination of minimum server level (sc_MinServerLevel) and maximum server level (sc_MaxServerLevel) defines the range of server levels that are acceptable to the client. When the request arrives on one or more of the target systems,, XCF presents the request only to those server instances that support a server level within the range requested by the client. If no server supports such a level, the request is cancelled with a "no receiver" response code.

• Specifying server features

  The sc_features feature string indicates the set of features that the server must support in order to process the request. XCF uses the indicated specification to determine whether a particular server instance is capable of processing the request. If no server supports the required features, the request is cancelled with a "no receiver" response code.

  The feature string and how it is used by XCF to select a server instance is defined in the IXCYSRVR macro. (See the declare for ixcysrvr_tFeatures.) However, the content and interpretation of the "feature level" and the "feature flags" within the feature string is defined by the server.

The default for SC_MINSERVERLEVEL, sc_MaxServerLevel and sc_Features. are all zeroes (0).

To code: Specify the RS-type name or address in register (2)-(12), of a character field mapped by ixcysrvr_tCriteria.

,DESCRIPTION=description

When SENDTO=SERVER is specified, use this required input parameter to contain a description of the request. The description might indicate the function, service, purpose, or role of the client. Or it might indicate the application with which the client is associated. Or it might describe the request or the reason the request is being issued. The string can contain any alphanumeric (a-z, A-Z, 0-9), national (@,#,$), or special (underscore or blank) character. Leading blanks and all blank descriptors are not permitted. Descriptions are case sensitive. XCF presents the client description to the server as part of the request. The description also appears in various XCF messages and diagnostic data reports. The intended purpose is to help installations and service personnel understand how the system (or sysplex) might be impacted if there are problems with this request.

To code: Specify the RS-type name or address in register (2)-(12), of a 32-character field.

,EXPECTREPLY=NO

,EXPECTREPLY=YES

Use this optional parameter to indicate whether the sender is expecting the target to send a reply in response to this message. The default is EXPECTREPLY=NO.

,EXPECTREPLY=NO

The target is not expected to reply to this message.

For a SENDTO=SERVER request with a nonzero HOLDTIME, an XCF acknowledgment will be sent to confirm whether or not the message was delivered to the target. If an XCF acknowledgment is received before RESPTIME expires, the information returned by IXCRECV will provide the status of the delivery. (See field td_RespCode in macro IXCYSRVR.) If instead HOLDTIME is zero, no XCF acknowledgments are sent.

,EXPECTREPLY=YES

The sender expects the target to reply to this message. EXPECTREPLY=YES can only be specified for a SENDTO=SERVER request.

Note that an XCF acknowledgment might be sent as well. Thus the status information returned by IXCRECV could indicate that the message was delivered to the target even though a response was not received from the target before the RESPTIME expired.

,FUNCTION=function

When SENDTO=SERVER is specified, use this required input parameter to indicate the request or function that the server is to perform. The content and interpretation of FUNCTION is defined by the server.

To code: Specify the RS-type name or address in register (2)-(12), of an 8-character field.

,HOLDTIME=holdtime

,HOLDTIME=NONE

Use this optional input parameter to indicate the maximum number of seconds that XCF preserves message results for retrieval using the IXCRECV service after the message completes. When the HOLDTIME expires, the message and its results are eligible for discard. Once discarded, any attempt to inspect the responses fails. If specified, the HOLDTIME value must be between 0 and 3600, inclusive. If not specified, XCF discards the

When a non-zero HOLDTIME value is specified, a RETMSGTOKEN is required in order to retrieve IXCSEND results using IXCRECV. You must specify RETMSGTOKEN on the IXCSEND invocation when a non-zero HOLDTIME is specified. The default is NONE.

To code: Specify the RS-type name or address in register (2)-(12), of a fullword containing the HOLDTIME in seconds that XCF preserves message results.

,LENMDENTRY=lenmdentry

,LENMDENTRY=16

When MSGDESC=msgdesc is specified, use this optional input parameter to indicate the length in bytes of each entry in the message descriptor table. As XCF iterates through the table, it locates the next descriptor by adding LENMDENTRY to the location of the current descriptor.

LENMDENTRY must be greater than or equal to the length of one data descriptor, which is the default value of 16. The length must be a decimal value greater than or equal to 16. If not specified, LENMDENTRY defaults to the length of one message descriptor (16). The default is 16.

To code: Specify the RS-type name or address in register (2)-(12), of a fullword field, or specify a literal decimal value.

,LENSYSENTRY=lensysentry

,LENSYSENTRY=8|4

When SYSTEMS=NAME or SYSTEM=SYSID are specified, use this optional input parameter to contain the length of the array entries that contain a sysname or system ID. XCF locates successive array entries by adding this length to the address of the current array entry.

LENSYSENTRY defaults to 8 if SYSTEMS=NAME is specified. LENSYSENTRY defaults to 4 if SYSTEMS=SYSID is specified.

To code: Specify the RS-type name or address in register (2)-(12), of a fullword field, or specify a literal decimal value.

,MF=S

,MF=(L,list addr)

,MF=(L,list addr,attr)

,MF=(L,list addr,0D)

,MF=(E,list addr)

,MF=(E,list addr,COMPLETE)

Use this optional input parameter to specify the macro form.

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. MF=S is the default.

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 might 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 of the macro stores the parameters into the storage area defined by the list form, and generates the macro invocation to transfer control to the service.

,list addr

The name of a storage area to contain the parameters. For MF=S and MF=E, this can be an RS-type address or an address in register (1)-(12).

,attr

An optional 1- to 60-character input string that you use to force boundary alignment of the parameter list. Use a value of 0F to force the parameter list to a word boundary, or 0D to force the parameter list to a doubleword boundary. If you do not code attr, the system provides a value of 0D.

,COMPLETE

Specifies that the system is to check for required parameters and supply defaults for omitted optional parameters.

,MSGCNTL=msgcntl

,MSGCNTL=0

Use this optional input parameter to contain "message control data". This information is to be presented to the receiver as part of the metadata associated with the message. The content and interpretation of the message controls is up to the sender. The intended purpose is to allow the sender to provide control data to influence the processing performed by the receiver. Depending on the protocols employed by the sender and receiver, the message control data could in fact be the message (as opposed to information about the message). The default is 0.

To code: Specify the RS-type name or address in register (2)-(12), of a 64-character field.

MSGID=msgid

MSGID=0

Use this optional input parameter to contain a message ID that identifies this particular message. The content and interpretation of MSGID is defined by the sender. It is intended that MSGID be a value that uniquely identifies the message from the sender perspective. The message ID is preserved in the XCF control structures for the message. It is also presented to the recipient. If problems arise, the message ID can aid diagnosis by helping service personnel correlate XCF control blocks and traces with the control blocks and traces of the sender. The default is 0.

To code: Specify the RS-type name or address in register (2)-(12), of a 16-character field.

,MSGLEN=msglen

When MSGDATA=msgdata is specified, use this required input parameter to contain the length in bytes of the message. The length must be a decimal value in the range 0 to 104,857,600 bytes (100MB), inclusive.

To code: Specify the RS-type name or address in register (2)-(12), of a fullword field, or specify a literal decimal value.

,MSGSTGKEY=msgstgkey

,MSGSTGKEY=ANY

Use this optional input parameter to contain the storage key to be used when fetching the message data. The message data is fetched from either the storage area indicated by the MSGDATA keyword, or the storage area identified by a data descriptor in the message data descriptor table indicated by the MSGDESC keyword. The high order nibble contains the storage key, the low order nibble is ignored. For example, set 'kkkk' in the binary bit string 'kkkkxxxx'B to correspond to the desired storage key.

If MSGSTGKEY is not specified, the message data can reside in any storage key.

Note that key-controlled protection will permit the message data to be moved successfully if either the access key specified by MSGSTGKEY matches the storage protect key of the indicated storage areas, or if the indicated storage areas are not fetch protected.

The default is ANY - message data can reside in any storage key.

To code: Specify the RS-type name or address in register (2)-(12), of an 8 bit field.

,NODATA

,MSGDATA=msgdata

,MSGDESC=msgdesc

Use one of these mutually exclusive required input parameters to indicate information about the message data.

,NODATA

A parameter that indicates that the message does not have any data. Only the metadata for the message is presented to the receiver.

,MSGDATA=msgdata

A parameter that identifies a single contiguous buffer variable which contains the message data to be delivered to the receiver.

The message data buffer can reside in the primary address space of the caller, or in a space addressable through a public entry on the dispatchable unit access list (DU-AL), or in a common area data space. The storage key of the storage area containing the message data must match the storage protect key indicated by the MSGSTGKEY keyword.

To code: Specify the RS-type name or address in register (2)-(12), of the storage area containing the message data .

,MSGDESC=msgdesc

A parameter that contains a table of one or more data descriptors. The message descriptor table is used when the message data resides in discontiguous storage areas. A data descriptor identifies a storage location from which XCF is to obtain a portion of the message data. Data descriptors are mapped by ixcysrvr_tDataDescriptor which is defined in the IXCYSRVR macro. A data descriptor specifies the ALET, address, and length of a contiguous virtual storage area where the message data resides.

XCF concatentates each component of the message end to end and presents a copy of the result to the receiver. So for example, if the table had two entries whose descriptors identified storage containing the five byte strings 'PART1' and 'PART2' respectively, the message data presented to the receiver would be the ten byte string 'PART1PART2'.

The storage area defined by each data descriptor must reside in the primary address space of the caller, or in a space addressable through a public entry on the dispatchable unit access list (DU-AL), or in a common area data space. The storage key of the storage area containing the message data indicated by each data descriptor must match the storage protect key indicated by the MSGSTGKEY keyword.

The storage area containing the data descriptors must reside in the primary address space of the caller, or in a space addressable through a public entry on the dispatchable unit access list (DU-AL), or in a common area data space.

To code: Specify the RS-type name or address in register (2)-(12) of a character input variable containing a table of one or more data descriptors.

,PLISTVER=IMPLIED_VERSION

,PLISTVER=MAX

,PLISTVER=0

Use this input parameter to specify the version of the macro. See Understanding IXCSEND Version Support for a description of the options available with PLISTVER.

,PRIMARY

,HOME

,STOKEN=stoken

When RECVBIND=ADDRSPACE is specified, use this required input parameter to indicate the responsibility of the invoker of the IXCRECV request.

,PRIMARY

A parameter keyword that that belongs to a set of mutually exclusive keys used with RECVBIND=ADDRSPACE. PRIMARYindicates that responsibility for invoking IXCRECV is to be assigned to the primary address space of the sender.

,HOME

A parameter keyword that belongs to a set of mutually exclusive keys used with RECVBIND=ADDRSPACE. HOME indicates that responsibility for invoking IXCRECV is to be assigned to the home address space of the sender.

,STOKEN=stoken

A parameter keyword that belongs to a set of mutually exclusive keys used with RECVBIND=ADDRSPACE. STOKEN contains the space token of the address space to which responsibility for invoking IXCRECV is to be assigned.

To code: Specify the RS-type name or address (using a register from 2 to 12) of the 8-byte storage area containing a space token.

,RECVBIND=TASK

,RECVBIND=ADDRSPACE

,RECVBIND=SYSTEM

Use this optional parameter to indicate the entity that is responsible for issuing an IXCRECV to inspect the results of the IXCSEND request.

RECVBIND is required to be specified when HOLDTIME is non-zero for SRB mode callers.

The RECVBIND specification helps XCF ensure that system resources are recovered in a timely manner if the intended invoker of IXCRECV fails before it can process the message results. The default is RECVBIND=TASK.

,RECVBIND=TASK

Responsibility for issuing the IXCRECV is to be assigned to the indicated task. SRB mode callers must explicitly specify a TTOKEN other than CURRENT or 0 when assigning responsibility for issuing the IXCRECV to a task (RECVBIND=TASK).

,RECVBIND=ADDRSPACE

Responsibility for invoking IXCRECV is to be assigned to the indicated address space.

,RECVBIND=SYSTEM

The IXCRECV will be issued from the local system. XCF is not to establish a receive bind to any particular address space or task. If the sender fails such that IXCRECV is never invoked, the message persists until its hold time expires (HOLDTIME).

,RESPONSELEVEL=responselevel

,RESPONSELEVEL=0

When EXPECTREPLY=YES is specified, use this optional input parameter to specify the level of the response data that the sender wants the recipient to return. The content and interpretation of the response level is defined by the receiver. The response level is made available when the message is presented to the target server. For example, when presenting a client request to a server exit, the server exit parameter list contains the level of response data that the sender wants the recipient to send.

The sender and receiver can use response level in any way they choose. The intended purpose is to provide a protocol that helps clients and servers function compatibly with mixed release levels. For example, the sender might specify the level of response data that it would like to receive, and the receiver might send a reply with data at a level no greater than what the sender requested. Thus an uplevel target would not provide results containing data that a downlevel sender is not prepared to handle. A downlevel receiver asked to provide data at a response level it does not understand might choose to reject the request of the uplevel sender outright, or it might choose to provide a response at the highest level it can. The default is 0.

To code: Specify the RS-type name or address in register (2)-(12), of a fullword field, or specify a literal decimal value.

,RESPRETCODE=respretcode

,RESPRETCODE=0

When SENDTO=ORIGINATOR is specified, use this optional input parameter to contain the return code to be provided to the target along with the response. This return code will be placed in the rd_RespRetCode field of the ANSAREA returned by the IXCRECV macro when the target gathers the response. The content and interpretation of the return code is defined by the sender. The default is 0.

To code: Specify the RS-type name or address in register (2)-(12), of a fullword field, or specify a literal decimal value.

,RESPRSNCODE=resprsncode

,RESPRSNCODE=0

When RESPRETCODE=respretcode and SENDTO=ORIGINATOR are specified, use this optional input parameter to contain the reason code to be provided to the target along with the response. This reason code will be placed in the rd_RespRsnCode field of the ANSAREA returned by the IXCRECV macro when the target gathers the response. The content and interpretation of the reason code is defined by the server. The default is 0.

To code: Specify the RS-type name or address in register (2)-(12), of a fullword field, or specify a literal decimal value.

,RESPTIME=resptime

,RESPTIME=60

Use this optional input parameter to indicate the amount of time the sender is willing to wait for the expected responses to arrive. For EXPECTREPLY=YES, the expected response is a reply sent by the target server. For EXPECTREPLY=NO with a nonzero HOLDTIME, the expected response is an acknowledgment sent by XCF. If the expected responses do not arrive within the specified RESPTIME, XCF deems the request to have completed and starts the HOLDTIME timer.

RESPTIME also determines the amount of time XCF attempts to send messages that are pending due to system conditions. If the RESPTIME expires before the pending messages can be sent to the targets, the pending messages are cancelled and XCF deems the request to have completed.

The timeout value must be between 1 and 3600, inclusive. The default is 60.

To code: Specify the RS-type name or address in register (2)-(12), of a fullword field, or specify a literal decimal value.

,RESPTOKEN=resptoken

When SENDTO=ORIGINATOR is specified, use this required input parameter to contain the token that identifies the originating message to which this response is being sent. The response token was made available when the originating message was presented to the receiver. For example, the SXPLRQ_RespToken field in the server exit parameter list (macro IXCYSRVR) contains the response token to be used when sending results back to the requesting client.

To code: Specify the RS-type name or address in register (2)-(12), of a 64-character field.

,RETCODE=retcode

Use this optional output parameter into which the return code is to be copied from GPR 15. If you specify 15, GPR15, REG15, or R15 (within or without parentheses), the value will be left in GPR 15.

To code: Specify the RS-type name of a fullword field, or register (2)-(12) or (15), (GPR15), (REG15), or (R15).

,RETMSGTOKEN=retmsgtoken

,RETMSGTOKEN=NONE

Use this output parameter to specify a storage area to contain a token that identifies the message. For recovery purposes, the sender should initialize the storage to hexadecimal zero before invoking IXCSEND to send a message. The token is required for use with other XCF client/server interfaces and the XCF message control service (IXCMSGC). For example it is used with the IXCRECV macro to identify the message whose results are to be received.

When a non-zero HOLDTIME is specified, a RETMSGTOKEN is required in order to retrieve IXCSEND results using IXCRECV. You must specify RETMSGTOKEN on the IXCSEND invocation when a non-zero HOLDTIME is specified.

The storage for the message token can reside in the primary address space of the caller, or in a space addressable through a public entry on the dispatchable unit access list (DU-AL), or in a common area data space.

XCF stores the message token before the IXCSEND service returns to the caller. Non-zero RetMsgToken storage indicates that the message token is available for use.

In cases where the calling work unit must be suspended, the token is stored before the work unit is actually suspended. If it should become necessary for the sender to break out of the suspend before the service routine resumes and returns of its own accord, some other work unit can use this token to cancel the request by invoking the XCF message control service (IXCMSGC). Note that cancelling the send likely implies that the message will not be delivered to all of the intended targets. The default is NONE.

To code: Specify the RS-type name or address in register (2)-(12), of a 32-byte character output field to contain the message token

,RSNCODE=rsncode

Use this optional output parameter into which the reason code is to be copied from GPR 0. If you specify 0, 00, GPR0, GPR00, REG0, REG00, or R0 (within or without parentheses), the value will be left in GPR 0.

To code: Specify the RS-type name of a fullword field, or register (0) or (2)-(12), (00), (GPR0), (GPR00), REG0), (REG00), or (R0).

,SENDER=sender

Use this required input parameter to contain the name of the sender. When sending a request to a server for processing, the client is the sender. When sending a response containing request results back to the client, the server is the sender. XCF includes the sender name as part of the metadata presented to the receiver of the message. The sender name also appears in various XCF messages and diagnostic data reports.

Sender names consist of four 8-byte sections. Each 8 byte section must be left justified, padded on the right with EBCDIC blanks as needed. Each section string can contain any alphanumeric (a-z,A-Z,0-9), national (@,#,$), or underscore character (_). Any section but the first can be entirely blank. Names are case sensitive. The IXCYSRVR macro defines a mapping for client and server names (ixcysrvr_tName).

To avoid names used by IBM®, do not begin names (section 1) with the letters A through I or the character string SYS.

To code: Specify the RS-type name or address in register (2)-(12), of a 32-character field.

,SENDERID=senderid

,SENDERID=0

Use this optional input parameter to contain the sender ID. The sender ID is presented to the target of the message. The intended purpose is to allow the sender to provide a token to uniquely identify itself. For example, a server might specify its server ID as the SENDERID when sending a response to a client request. The default is 0.

To code: Specify the RS-type name or address in register (2)-(12), of a 16-character field.

,SENDTIME=sendtime

,SENDTIME=5

Use this optional input parameter to indicate the maximum number of seconds XCF might pause the work unit to allow XCF to synchronously complete accessing callers storage areas.

If the SENDTIME expires before the processing that XCF paused for is complete, XCF will cancel incomplete send processing which might result in not all desired targets receiving the send request.

The timeout value must be between 1 and 3600, inclusive. The default is 5.

To code: Specify the RS-type name or address in register (2)-(12), of a fullword field, or specify a literal decimal value.

,SENDTO=SERVER

,SENDTO=ORIGINATOR

Use this required parameter to indicate the target (receiver) of the message.

,SENDTO=SERVER

Send a request to a server on one or more systems for processing.

,SENDTO=ORIGINATOR

Send a response to the indicated message.

,SERVER=server

,SERVERID=serverid

When SENDTO=SERVER is specified, use one of these mutually exclusive required input parameters to specify the name or server id of the server.

,SERVER=server

A parameter variable containing the name of the server that is to process the request. Server names are mapped by ixcysrvr_tName (macro IXCYSRVR). Server names consist of four 8-byte sections. Each 8 byte section must be left justified, padded on the right with EBCDIC blanks as needed. Each section string can contain any alphanumeric (a-z, A-Z, 0-9), national (@,#,$), or underscore character. Any section but the first can be entirely blank. Server names are case sensitive.

To code: Specify the RS-type name or address in register (2)-(12), of a 32-character field.

,SERVERID=serverid

A parameter variable that contains the server ID of the target server. The request is sent to the system on which the indicated server instance resides. When the request arrives on the target system, the request is presented to the indicated server instance for processing. The client request is presented to the specified server instance without comparing client specified server selection criteria. If the server instance no longer exists, the request is not processed and the response code indicates "no receiver."

A client might use the SERVERID if it has a set of requests that must be processed by the same server instance. SERVERID might also be used if the algorithms used by XCF to select a server are not appropriate for the client/server application.

A server instance can choose to communicate its SERVERID to a client in various ways:

• As part of the message content sent in response to a request
• As part of the MSGCNTL
• As the SENDERID when sending a response to a client request.

The IXCREQ REQUEST=SERVERINFO interface can also be used to obtain server ids for server instances that have started on the local system or on any other system in the sysplex.

To code: Specify the RS-type name or address in register (2)-(12), of a 16-character field.

,SUPPLIEDLEVEL=suppliedlevel

,SUPPLIEDLEVEL=0

When SENDTO=ORIGINATOR is specified, use this optional input parameter to indicate the "level" of response data being provided by the sender. The indicated level is placed in the rd_SuppliedLevel field of the ANSAREA returned by the IXCRECV macro when the target gathers the response. The content and interpretation of this data is defined by the sender. The intended purpose is to provide a protocol that helps clients and servers function compatibly with mixed release levels. For example, a client might request "level 2" results (see the RESPONSELEVEL keyword), but the server might provide result data at some other level. Thus the results might include more or less data than requested. The default is 0.

To code: Specify the RS-type name or address in register (2)-(12), of a fullword field, or specify a literal decimal value.

,SUPPORTSLEVEL=supportslevel

,SUPPORTSLEVEL=0

When SENDTO=ORIGINATOR is specified, use this optional parameter to indicate the maximum level of response data that the sender could provide. The indicated level is placed in the rd_SupportsLevel field of the ANSAREA returned by the IXCRECV macro when the target gathers the response. The content and interpretation of this data is defined by the sender. The intended purpose is to provide a protocol that helps clients and servers function compatibly with mixed release levels. For example, a client might request the lowest possible result level knowing that every server can provide that data. The server might then supply the requested "level 0" data, and indicate that it supports data as high as "level 3". The client might then modify the response level requested for future requests. The default is 0.

To code: Specify the RS-type name or address in register (2)-(12), of a fullword field, or specify a literal decimal value.

,SYSID=sysid

When SYSTEMS=SYSID, SERVER=server, and SENDTO=SERVER are specified, use this required input parameter to contain the XCF system ID of the target system.

If #SYSTEMS is greater than 1, SYSID is the first entry in an array of system IDs. XCF iterates through each array entry and includes the indicated system as a target only if the system is known to the sysplex when the request is accepted. Excluded systems will not appear in any further information that XCF provides with respect to the message. At most one instance of the message is sent to any one system.

The XCF query service (IXCQUERY REQINFO=SYSPLEX) can be used to obtain the names of systems in the sysplex. The service returns a record (QUASYS) for each system in the syplex. Within the QUASYS record, the field QUASSID contains the system ID.

To code: Specify the RS-type name or address in register (2)-(12), of a fullword field, or specify a literal decimal value.

,SYSNAME=sysname

When SYSTEMS=NAME, SERVER=server, and SENDTO=SERVER are specified, use this required input parameter to contain a system name. The system name must be 8 characters, left justified, and padded on the right with blanks as needed.

System names must contain characters that are valid for a system name and might also contain valid wildcard characters which can be used for wildcard character matching.

Wildcard characters are defined by the WILDCARDONE and WILDCARDANY keywords.

Since system names are not case sensitive, the system names are folded to upper case for comparison.

If #SYSTEMS is greater than 1, SYSNAME is the first entry in an array of system names. XCF iterates through each 8 byte entry and includes one or more of the indicated systems as a target only if the system is known to the sysplex when the request is accepted. Excluded systems will not appear in any further information that XCF provides with respect to the message. At most one instance of the message is sent to any one system.

The XCF query service (IXCQUERY REQINFO=SYSPLEX) can be used to obtain the names of systems in the sysplex. The service returns a record (QUASYS) for each system in the syplex. Within the QUASYS record, the field QUASNAME contains the system name.

To code: Specify the RS-type name or address in register (2)-(12), of an array of one or more contiguous character fields, each of which is of length LENSYSENTRY.

,SYSTEMS=ALL

,SYSTEMS=OTHER

,SYSTEMS=LOCAL

,SYSTEMS=NAME

,SYSTEMS=SYSID

When SERVER=server and SENDTO=SERVER are specified, use this required parameter to indicate which systems in the sysplex are candidates for processing the request. XCF sends a copy of the message to each of the indicated systems (provided the system supports the XCF client/server interfaces). When the message arrives, XCF presents the message to a suitable instance of the indicated server (if any).

,SYSTEMS=ALL

Send the request to every system in the sysplex.

,SYSTEMS=OTHER

Send the request to all other systems in the sysplex. Do not send the request to the local system.

,SYSTEMS=LOCAL

Send the request to the local system only. Do not send the request to any other system in the sysplex.

,SYSTEMS=NAME

Select the candidates to send the request to by system name using the provided system name array indicated by SYSNAME. XCF processes each candidate system name to determine if the system is active in the sysplex and whether the system supports the XCF client/server protocols. Duplicates of system names are ignored. Only one instance of a system name is to be used as a candidate target. System names not chosen as candidates are not provided to the IXCSEND requester. A target descriptor record for each system to which a request was sent is returned in the answer area provided when issuing the XCF receive service (IXCRECV) to obtain the results of the request.

,SYSTEMS=SYSID

Select the candidates to send the request to XCF by XCF system ID (SYSID).

,TTOKEN=ttoken

,TTOKEN=CURRENT

When RECVBIND=TASK is specified, use this optional input parameter to contain the task token of the task that is responsible for invoking IXCRECV. If the TTOKEN is not specified, responsibility is assigned to the current task under which the caller is running. Note that SRB mode callers must explicitly specify a TTOKEN other than CURRENT or 0 when assigning responsibility for issuing the IXCRECV to a task. The default is CURRENT.

To code: Specify the RS-type name or address in register (2)-(12), of a 16-character field.

,USERDATA=userdata

,USERDATA=0

Use this optional input parameter to contain user data that is to be associated with the message. A copy of the user data is placed in the sd_UserData field of the send descriptor in the ANSAREA returned by the IXCRECV macro when the sender inspects the results of this message. The data is not delivered to the target. The content and interpretation of the user data is defined by the sender. For example, user data might be used to locate control information used by the sender to manage the message. The default is 0.

To code: Specify the RS-type name or address in register (2)-(12), of a 16-character field.

,WILDCARDANY=wildcardany

,WILDCARDANY=*

When SYSTEMS=NAME, SERVER=server, and SENDTO=SERVER are specified, use this optional input parameter to contain a wild card character to be used for pattern matching on the system names. WILDCARDANY indicates the character that matches zero or more characters. By default, an asterisk ('*') within the system name will match any sequence of zero or more characters. For example the pattern 'S*D ' would match any system name that began with 'S' and ended with 'D', including 'SD', 'SYD', and'SYSD' but none of 'S', 'D', 'SD1', or 'SYD1'.

The WILDCARDANY character cannot be:

• Alphabetic characters (A-Z, a-z)
• Numeric characters (0-9)
• National characters (@, #, $)
• ampersand ( & ) or underscore ( _ )
• Blank
• Equal to WILDCARDONE

A value of decimal zero (0) will indicate that the default of asterisk ('*') is to be used as the WILDCARDANY character. The default is *.

To code: Specify the RS-type name or address in register (2)-(12), of a 1-character field.

,WILDCARDONE=wildcardone

,WILDCARDONE=?

When SYSTEMS=NAME, SERVER=server and SENDTO=SERVER are specified, use this optional input parameter to contain a wild card character to be used for pattern matching on the system names. WILDCARDONE indicates the character that matches any one character. By default, a question mark ('?') within the system name will match any one character. For example, the pattern 'S?D ' would match any three character name that began with 'S' and ended with 'D', such as 'SYD' but none of 'SD', 'SD1', 'SYD1', or 'SYSD'.

The WILDCARDONE character cannot be:

• Alphabetic characters (A-Z, a-z)
• Numeric characters (0-9)
• National characters (@, #, $)
• ampersand ( & ) or underscore ( _ )
• Blank
• Equal to WILDCARDANY

A value of decimal zero (0) will indicate that the default of question mark ('?') be used as the WILDCARDONE character. The default is ?.

To code: Specify the RS-type name or address in register (2)-(12), of a 1-character field.