Thanks, Chuck. Your comments mirror the understanding, however cloudy, that I've come to over the years. Given that RCVMSG is a very old command for a fairly complex API, I think there was a lot done there for "someday" that never came. It's good to remember that I can use QMHRCVPM if I need the more comprehensive features, but I was just trying to dust out the cobwebs and figure out the minimum configuration for retrieving message ID and message data. I think just specifying those two variables should suffice. I'm running that way now and haven't wiped out anything yet.

I may try messing around with a few combinations in my Copious Free Time. I'll report back if I do.

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.

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.