× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



+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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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

This mailing list archive is Copyright 1997-2024 by midrange.com 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.