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 [http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_71/apis/QMHRCVPM.htm]
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.