z/OS MVS Programming: JES Common Coupling Services
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


IXZXIXSM - Send a Message

z/OS MVS Programming: JES Common Coupling Services
SA23-1387-00

Use the IXZXIXSM macro to send a message from one JES dispatchable unit (JDU) to another JDU. The JDUs can be running on the same JES member or on different JES members of the XCF group.

You can have more than one multi-segment message active at a time. That is, message segments from more than one multi-segment message can be in the process of being sent. The sending member sends complete multi-segment messages in the order that it receives their last segments.

If you start a multi-segment message, and then send single-segment messages before sending the last segment of the multi-segment message, all of the intervening single-segment messages will be sent before the multi-segment message is sent. A multi-segment message is considered incomplete and is not sent until the last segment (SEGTYPE=LAST or SEGTYPE=ABORT) has been sent.

Refer to Sending a Message (IXZXIXSM Macro) for a description of using IXZXIXSM to send a message.

Environment

The requirements for the caller are:

Table 1. Environment
Variable Value
JES environments:
  • JES2 or JES3 main task
  • JES2 or JES3 subtask
  • JES2 or JES3 FSS
  • User
Minimum authorization: Supervisor state with PSW key 0 or 1
Dispatchable unit mode: Task
Cross memory mode: Any PASN, any HASN, any SASN
AMODE: 31
ASC mode: Primary
Interrupt status: Enabled for I/O and external interrupts
Locks: No locks held
Control parameters: None

Programming Requirements

JES2 programs must include the $MODULE macro so it is invoked before IXZXIXSM is invoked.

JES3 programs must include the ENVIRON= keyword on the IATYMOD macro so it is invoked before IXZXIXSM is invoked.

Restrictions

Do not issue IXZXIXSM until JES initialization processing has established an attachment to the JES XCF group; that is, after IXZXIT03 processing has completed.

If two or more JES members are involved in the "send message" operation, both must belong to the same JES XCF group.

Input Register Information

Before issuing the IXZXIXSM macro, the caller does not have to place any information into any register unless using it in register notation for a particular parameter, or using it as a base register.

Output Register Information

When IXZXIXSM returns control, the general purpose registers (GPRs) contain:
Register
Content
0
Reason code
1
Used as a work register by the system
2-13
Unchanged
14
Used as a work register by the system
15
Return code
When IXZXIXSM returns control, the access registers (ARs) contain:
Register
Content
0,1
Used as work registers by the system
2-13
Unchanged
14,15
Used as work registers by the system

Some callers depend on register contents remaining the same before and after issuing a service. If the system changes the contents of registers on which the caller depends, the caller must save them before issuing the service, and restore them after the system returns control.

Performance Implications

None

Syntax

Read syntax diagramSkip visual syntax diagram
>>-+-------+--IXZXIXSM----MBOXNAME=mboxname--------------------->
   '-label-'                                    

>----,MEMBER=member------,DATA=data  --,DATALEN=datalen--------->

   .-,REQTYPE=COMM----------.  .-,SEGTYPE=SINGLE------.   
>--+------------------------+--+----------------------+--------->
   '-,REQTYPE=-+-ASYNCACK-+-'  '-,SEGTYPE=-+-FIRST--+-'   
               +-ASYNC----+                +-MIDDLE-+     
               '-SYNC-----'                +-LAST---+     
                                           '-ABORT--'     

   .-,CONNECT=NONE----.                               
>--+------------------+----,GROUPTOKEN=grouptoken--------------->
   '-,CONNECT=connect-'                               

>--+-----------------------------------------+------------------>
   +-,REQMBOX=reqmbox---,REQTOKEN=reqtoken---+   
   '-| parameters-1 |------------------------'   

>--+------------------+--+------------------+------------------->
   '-,RTNCODE=rtncode-'  '-,RSNCODE=rsncode-'   

   .-,MF=S-------------------------------.   
>--+-------------------------------------+---------------------><
   |                   .-,0D-----.       |   
   '-,MF=-+-(L-,mfctrl-+---------+-)---+-'   
          |            '-,mfattr-'     |     
          |            .-,COMPLETE-.   |     
          '-(E-,mfctrl-+-----------+-)-'     

 
Read syntax diagramSkip visual syntax diagram
parameters-1

>>-,RESPDATA=respdata----,RESPDLEN=respdlen--------------------->

>----,MSGTOKEN=msgtoken----+----------------+------------------><
                           '-,USERRC=userrc-'   

Parameters

label
Specifies an optional symbol, starting in column 1, to be used as the name on the IXZXIXSM macro invocation.

Default: no name

MBOXNAME=mboxname
Specifies the name (RS-type) or address (in GPR2-GPR12) of a required 16-character input field that contains the name of the mailbox where messages are placed for processing by another JDU. Valid characters are A-Z, 0-9, $, #, @, and embedded and trailing blanks.

Default: none

MEMBER=member
Specifies the name (RS-type) or address (in GPR2-GPR12) of a required 16-character input field that contains the name of the XCF member to which a message is to be sent. This name must respect the following naming standards for XCF groups: characters A-Z, 0-9, and $, #, @; and must be left justified, and padded on the right with blanks. Avoid names beginning with A-I, the character string SYS, or the reserved name UNDESIG. These are reserved for IBM use only.

Default: none

DATA=data
Specifies the name (RS-type) or address (in GPR2-GPR12) of a required fullword input field that contains the address of the message data to be sent.

Default: none

DATALEN=datalen
Specifies the name (RS-type) or address (in GPR2-GPR12) of a required fullword input field that contains the length (up to 60 kilobytes in decimal) of the message data to be sent.

Default: none

REQTYPE=COMM | ASYNCACK | ASYNC | SYNC
Optionally specifies how you prefer acknowledgements to be handled.
COMM
Process the message asynchronously. There is no recovery processing if either the sending or receiving system fail before the message is processed. This option is used for most typical communication, such as WTO message processing, between members of the XCF group.
ASYNCACK
Process the message asynchronously. The sender receives an acknowledgement message from the receiver, thus providing the sender with potential recovery situation information.
Note: You must also specify REQTOKEN= and REQMBOX= for REQTYPE=ASYNCACK messages.
ASYNC
Process the message asynchronously. No acknowledgement message is returned to the sender. JES XCF provides recovery processing.
SYNC
Process the message synchronously. The sender waits until the receiver returns an acknowledgement before continuing further processing. If you specify SYNC, and this is a multi-segment message of SEGTYPE=LAST or SEGTYPE=ABORT, you must also specify MSGTOKEN=.

Default: COMM

REQMBOX=reqmbox
Specifies the name (RS-type) or address (in GPR2-GPR12) of an optional 16-character input field that contains the name of the mailbox into which the acknowledgement message is returned. Valid characters are A-Z, 0-9, $, #, @, and embedded and trailing blanks. If you specify REQTYPE=ASYNCACK, you must also specify REQMBOX.

Default: none

REQTOKEN=reqtoken
Specifies the name (RS-type) or address (in GPR2-GPR12) of an optional 64-bit output field that contains a token used to associate the message acknowledgement with an issued message.
Note: If you specify REQTYPE=ASYNCACK, you must also specify REQTOKEN; all other REQTYPE specifications receive a binary 0 if you specify REQTOKEN.

Default: none

SEGTYPE=SINGLE | FIRST | MIDDLE | LAST | ABORT
Optionally specifies the type of message that is being sent.
SINGLE
The message being sent is a single-segment message.
FIRST
The message is the first segment of a multi-segment message. Use the CONNECT= keyword to receive a token to associate all following segments of the message.
MIDDLE
The message is a segment other than the first or last of a multi-segment message.
LAST
The message is the last segment of a multi-segment message.
ABORT
The multi-segment message is terminated, and all held resources are freed.

Default: SINGLE

CONNECT=connect | NONE
Specifies the name (RS-type) or address (in GPR2-GPR12) of an optional 64-bit input/output field used to associate the segments of a multi-segment message. This token is returned for SEGTYPE=FIRST and must be passed as input for SEGTYPE=MIDDLE | LAST | ABORT. CONNECT= has no meaning for SEGTYPE=SINGLE.

Default: NONE

GROUPTOKEN=grouptoken
Specifies the name (RS-type) or address (in GPR2-GPR12) of a required fullword input field that contains the group token. Refer to Retrieving the JES XCF Group Token for the procedure for retrieving the JES XCF group token.

Default: none

RESPDATA=respdata
Specifies the name (RS-type) or address (in GPR2-GPR12) of an optional fullword output field that contains the address of a message buffer that contains the response message returned by the acknowledger of the message; that is, the response message specified by the DATA= keyword on the IXZXIXAC macro.

Default: none

RESPDLEN=respdlen
Specifies the name (RS-type) or address (in GPR2-GPR12) of an optional fullword output field that contains the length of the response message returned by the acknowledger of the message; that is, the response message length specified by the DATALEN= keyword on the IXZXIXAC macro.

Default: none

MSGTOKEN=msgtoken
Specifies the name (RS-type) or address (in GPR2-GPR12) of an optional 64-bit output field that contains the token that must be used when acknowledging that the response data has been received. This token will be used as input to the MSGTOKEN= keyword on the IXZXIXAC macro.

Default: none

USERRC=userrc
Specifies the name (RS-type) or address (in GPR2-GPR12) of an optional fullword output field that returns the processing results as specified by the message receiver (through the USERRC= parameter on the IXZXIXAC macro). USERRC only has meaning for REQTYPE=SYNC because only synchronous messages receive a direct response from the receiver. All asynchronous messages receive a binary 0, and receive the user return code in the message envelope (mapped by IXZYIXEN).

Default: none

RTNCODE=rtncode
Specifies the name (RS-type) of an optional fullword output field or register (GPR2-GPR12) into which the return code is copied from GPR 15.

Default: none

RSNCODE=rsncode
Specifies the name (RS-type) of an optional fullword output field or register (GPR2-GPR12) into which the reason code is copied from GPR 0.

Default: none

MF=S | L | E
Specifies the form of the macro as standard (S), list (L), or execute (E). This keyword is optional.
MF=S
Specifies the standard form of the macro; that is, to build the in-line parameter list and invoke the desired service. Processing also includes checking for all required keywords and supplying defaults, if any, for omitted optional parameters.
MF=(L,mfctrl{,mfattr | 0D})
Specifies the list form of the macro; that is, defining an area to be used for the parameter list. If you code MF=L, do not code anything else except a label, the macro name, and the following values:
mfctrl
Specifies the name of a storage area to contain the parameters.
mfattr | 0D
Specifies an optional 1- to 60-character input string, which 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.

Default: 0D

MF=(E,mfctrl,COMPLETE)
Specifies the execute form of the macro; that is, builds the parameter list specified by mfctrl. Processing also includes checking for all required keywords and supplying defaults, if any, for omitted optional parameters.
mfctrl
Specifies the name (RS-type) or address (in GPR1-GPR12) of a storage area for the parameter list.
COMPLETE
Specifies the desired degree of macro parameter syntax checking. Syntax checking includes checking for all required keywords and supplying default values, if any, for all omitted optional parameters.

Default: COMPLETE

Default: S

ABEND Codes

When control returns from your program, if you receive a return code of X'C', it indicates that processing failed because the IXZXIXSM service ended abnormally, and you will also receive an associated ABEND code. Refer to z/OS MVS System Codes for a description of the following possible ABEND codes:
DC5
JES XCF detected an unrecoverable error during attach or detach processing.
EC5
JES XCF detected an unrecoverable error while attempting recovery from a previous abend.

Return and Reason Codes

When the IXZXIXSM macro returns control to your program, GPR 15 (and rtncode if you coded RTNCODE) contains the return code and GPR 0 (and rsncode if you coded RSNCODE) contains the reason code.

Return Code (hex) Reason Code (hex) Meaning and Action
0 0 Meaning: Processing was successful. If the call was asynchronous, the message was queued to be sent. If the call was synchronous, the message was delivered to the receiver and acknowledged.

Action: None

4 4 Meaning: Processing failed because the parameter list passed to the IXZXIXSM service contains an eyecatcher that is not valid.

Action: Check the parameter list to be certain it was not overlaid with other data.

4 8 Meaning: Processing failed because the parameter list passed to the IXZXIXSM service does not have a valid version indicator.

Action: The caller might need to be recompiled. Check the parameter list to be certain it was not overlaid with other data.

4 C Meaning: Processing failed because the group token passed to the IXZXIXSM service was not valid.

Action: Verify that the correct group token is being passed to IXZXIXSM.

4 10 Meaning: Processing failed because the member name passed to the IXZXIXSM service contains characters that are not valid.

Action: Be certain you specified MEMBER= correctly. Only A-Z, 0-9, $, #, and @ are valid.

4 14 Meaning: Processing failed because the mailbox name passed to the IXZXIXSM service contains characters that are not valid.

Action: Be certain you specified MBOXNAME= correctly. Only A-Z, 0-9, $, #, @ and embedded and trailing blanks are valid.

4 18 Meaning: Processing failed because the mailbox name specified on the REQMBOX= parameter contains characters that are not valid.

Action: Be certain you specified REQMBOX= correctly. Only A-Z, 0-9, $, #, @, and embedded and trailing blanks are valid.

4 20 Meaning: Processing failed because the IXZXIXSM service was called on a member that is detaching.

Action: Check to be certain this is not a symptom of a serialization problem within your JES XCF group.

4 24 Meaning: Processing failed because CONNECT= was not specified.

Action: Be certain that for SEGTYPE=FIRST | LAST | ABORT send message calls, you also include the CONNECT= parameter. If it is missing, add it and rerun the program that issues the IXZXIXSM macro.

4 28 Meaning: Processing failed because MSGTOKEN= was not specified. service.

Action: Be certain that for this REQTYPE=SYNC message send call, you also include the MSGTOKEN= parameter. If it is missing, add it and rerun the program that issues the IXZXIXSM macro.

4 2C Meaning: Processing failed because you did not also specify REQMBOX= on this IXZXIXSM call. REQMBOX= is required for ASYNCACK call to identify the mailbox into which the acknowledgement message is returned.

Action: Add REQMBOX= to the IXZXIXSM macro and rerun the program that issues the send message call.

4 34 Meaning: Processing failed because the CONNECT= specification is not valid. A SEGTYPE=MIDDLE | LAST | ABORT was specified, but the first segment was not found or the last segment was already sent.

Action: Be certain the CONNECT= parameter was specified on all but SEGTYPE=SINGLE messages. Resend the message and its segments using the CONNECT= token returned on a SEGTYPE=FIRST call as input to all successive SEGTYPE=MIDDLE | LAST | ABORT calls.

4 38 Meaning: Processing failed because the DATALEN= value is not valid.

Action: DATALEN= must be a positive decimal integer of 0 to 60 kilobytes. Validate the size of the data packet and rerun the program that issues the IXZXIXSM macro.

4 3C Meaning: Processing failed because the message was cleared (by a IXZXIXMC call) from the target mailbox before the message was processed.

Action: You must be aware of message processing unique to REQTYPE=SYNC messages. To prevent this error, consider and provide necessary code in your routine to handle potential situations in which a mailbox could be cleared or deleted during synchronous message processing.

4 48 Meaning: Processing failed because the message was deleted (by a IXZXIXMD call) from the target mailbox before the message was processed.

Action: You must be aware of message processing unique to REQTYPE=SYNC messages. To prevent this error, consider and provide necessary code in your routine to handle potential situations in which a mailbox could be cleared or deleted during synchronous message processing.

4 4C Meaning: Processing failed because, although the message was delivered, it was not received by the intended recipient. Likely the recipient previously deleted the mailbox using the IXZXIXMD service.

Action: You must be aware of message processing unique to REQTYPE=SYNC messages. To prevent this error, consider providing necessary code in your routine to handle situations in which a mailbox could potentially be deleted prematurely during synchronous message processing.

8 0 Meaning: IXZXIT01 failed. The message being processed at the time IXZXIT01 failed is lost.

Action: Review your IXZXIT01 code for coding errors, correct the error, and rerun the program that issues the IXZXIXSM macro.

C 0 Meaning: Processing failed because the IXZXIXSM service abended.

Action: Refer to z/OS MVS System Codes for a description of the abend code and its associated reason codes.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014