On 01-Sep-2015 12:30 -0600, Joe Pluta wrote:
I'm having a brain cramp and for some reason nothing I find online
fixes it. When I'm doing a RCVMSG, is the variable I specify in
MSGDTALEN an input or an output?
I believe the original intent may have been for that parameter to
serve as both input and output. However in my experience, the value is
only functional as output; corresponding to the "Length of replacement
data [or impromptu message text] available" documented in the RCVM0100
Format of the Receive Program Message (QMHRCVPM) API
Does it tell the API how long my buffer is, or does it tell me how
much data it put in there?
As input, I believe the intention would have been to specify\limit
how much of the message data should be received; per the above however,
noting that I believe the value on input is ignored, the value for
Message Data Length (MSGDTALEN) is apparently always output designating
how much data was available with the message data, irrespective the size
of the receiver variable for the Message Data (MSGDTA) parameter.
If I specify MSGDTA but don't specify MSGDTALEN can I overrun my
As I understand, there should be no overwriting of storage. That is
because the RCVMSG feature should know how big is the CL [or REXX]
variable that was provided on the command invocation, and therefore
should only write as much as that size [i.e. limit how much is copied
into the receiver] if the receiving variable is smaller than the amount
of message data available. Ignored as input, there is no means to
reduce the amount written, except to reduce the size of the variable for
the MSGDTA() parameter. The size determination by the CPP [QMHRCVMS]
for the Receive Message (RCVMSG), I believe, is made per the value for
the Varying Length (VARY) attribute of the MSGDTA Parameter (PARM);
RtvCmdSrc [not an IBM command] issued against RCVMSG should enable
verification of that setting.
Thanks. Just one of those days.
Better docs would go a long way to ameliorate, on such days. I can
easily find code where I had provided a value for input, despite
/knowing/ that the value seems always to be ignored; apparently coded in
futility, likely hoping to minimize data movement for messages with
potentially large *VARY Message Data Fields Formats (FMT) elements or
messages whereby the generic\accurate reflection of the declarative
match the FMT() but for which only the first few fields are of interest.