RE: RNX0356 Document for DATA-INTO does not match RPG Variable

Vern (and Joe),

Thanks you.

In my case, this should work just fine. I just wanted the crux of the message to write in a text log file on the IFS, which is emailed to those who monitor an Order Import process (order data is in XML). I think my service program that does this for me has a character limit of 1024.

Unfortunately, some of our customers have a difficult time producing "well-formed" XML (or JSON) data. I grew tired running the process interactively to see the joblog (and the field occurrence in error). What's scary is that they run applications like SAP, NAV, etc. yet produce this kind of data (missing required data elements).

I may try to stick this in a service pgm so I can use it elsewhere.

Thanks again,
Greg

-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxxxxxxxx] On Behalf Of Vernon Hamberg
Sent: Wednesday, July 31, 2019 11:52 AM
To: RPG programming on IBM i <rpg400-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: RNX0356 Document for DATA-INTO does not match RPG Variable

+1

Since there is no way to know how long the variable data will be that is returned from an API, IBM doesn't include anything in the copy members in QSYSINC for those parts.

Bruce Vining, who was the guy who was involved closely with the process that generated the QSYSINC includes, did exactly as you, Greg, did, in his example of this API - he just made a subfield named Variable of length 10000 - this is in his book, APIs at work. In his example he is retrieving both the message and the second-level help text.

So this is pretty much de rigueur, just the way it goes.

It IS possible to run some APIs twice, the 1st time to determine how much data CAN be available, then allocate and run again - this is not one of those, so far as I can see.

Regards
Vern

On 7/31/2019 7:51 AM, Joe Pluta wrote:

Greg, I haven't worked with this one specifically, but I've worked
with a lot of IBM structures with variable length data.  If this one
follows the normal pattern, it would work something like this:

1. Data starts AFTER the last fixed-length field 2. In this case, the
last fixed-length field is QMHLHAVL 3. The positions are from 173 to
176 4. And so the first variable length field starts at position 177

Since data structure positions are one-based, the offset of the first
field is actually 176.  The rest of the calculations are made using
the returned lengths, QMHLDRTN, QMHLMRTN, and QMHLHRTN.  So if I start
with a pointer pData whose value is %addr(myDS), then I get this:

Replacement data starts at (pData + 176) for QMHLDRTN bytes Message
data starts at (pData + 176 + QMHLDRTN) for QMHLMRTN bytes Help starts
at (pData + 176 + QMHLDRTN + QMHLMRTN) for QMHLHRTN bytes

Is this not what you're seeing?



On 7/30/2019 3:38 PM, Greg Wilburn wrote:

These Data Structures suck...

So I added a message field of my own to the end of the DS:

   /include qsysinc/qrpglesrc,qmhrtvm          // QMHRTVM API data
structures

          dcl-ds Error        qualified;
            rcvm0200          likeds(QMHM020000);
            Message           char(3000);
          end-ds;

The DS field QMHLDRTN00 has a description (in the /include) of "
Length Data Returned"

Through trial and error I discovered that this value is the length of
the first part of the message... The actual Message and Cause from
the job log BEGIN at one position beyond that (QMHLDRTN00 + 1).

Has anyone worked with these enough to confirm this?  It just doesn’t
make sense to me given the IBM field description in the source file
and online.

Greg

--
This is the RPG programming on IBM i (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com