|
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.
EnvironmentThe requirements for the caller
are:
Table 1. EnvironmentVariable |
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 RequirementsJES2 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.
RestrictionsDo 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 InformationBefore 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 InformationWhen 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 ImplicationsNone
Syntax
>>-+-------+--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-+-----------+-)-'
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 CodesWhen 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 CodesWhen 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.
|
|