RE: QMHLJOBL woes -- RPG400-L

Sigh... would you like a better example?   It'd be easier for me to write

the code from scratch than it would be to fix this one.

Lol!  Well, a "free" example is always nice, though I could take you out for
a hotdog and a beer next time we are at the same conference to pay off my
debt.  I will make sure they have Klements on the grill ;-)

Actually, I would rather gain an understanding of how to work through that
variable reserved area so I don't get bitten next time.  Let me take a stab
at it now that I know the code I downloaded was wrong....

... Instead of "reading" as much out of the user space as I am, should I
instead read up to dMicroSecSnt, and then use the value in dOfsNext to
determine where I should find the beginning of dOfsNFldR - essentially
skipping over the dReserve1 variable?  In that case it seems having a second
DS with dOfsNFldR through dData would be the way to go as I would be reading
into that structure multiple times based on the offsets (correct?).

Guess I should be reading your Intro To API articles more closely eh? ;-)
Doesn't seem like I come across API's that return multiple sets of data as
much though.

Aaron Bartell

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Scott Klement
Sent: Tuesday, November 21, 2006 3:55 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: QMHLJOBL woes


Hi Aaron

The code referenced an older version of the QMHLJOBL API so I had to 
modify the code slightly (i.e. add dMicroSecSnt to dJLMsg data
structure) - I am compiling to V5R3.


The reason you had to modify it is because the code was written improperly.
Here's the data structure you posted:

    d dJLMsg          ds
    d  dOfsNext                     10i 0
    d  dOfsFrtn                     10i 0
    d  dNumRtn                      10i 0
    d  dMsgSvty                     10i 0
    d  dMsgId                        7
    d  dMsgType                      2
    d  dMsgKey                       4
    d  dMsgFile                     10
    d  dMsgLib                      10
    d  dDateSnt                      7
    d  dTimeSnt                      6
    d  dMicroSecSnt                  6


-- up to this point, it's correct --

    d  dReserve1                     2
    d  dOfsNFldR                    10i 0
    d  dLngFldRt                    10i 0
    d  dIdnFld                      10i 0
    d  dDataType                     1
    d  dDataSts                      1
    d  dReserve2                    14
    d  dDataLng                     10i 0
    D  dData                      1024


Bzzt... this part is wrong.  The length of "dReserve1" can vary.  It can 
change at any time without notice.  You can't hard-code it to be 2 
characters long and expect your code to always work!

You can call it one day and the API will tell you it's 2 this time around. 
Then you can say to yourself "hey, it's two! I'll hard-code that in my 
program."  But then what happens if it's 10 the next time you call it?  Or 
14? Or any other number you can think of?

The length of the field varies.  Because it varies, the starting position 
of all of the fields that come after it will also vary.

The only reason this program broke when you ran it on V5R3 is because the 
original programmer (Vadim Rozen, apparently) ignored the field (dOfsFrtn) 
that tells him where the dOfsNFldR field should start.  If you used that 
field, the code would still work today on the latest release of i5/OS 
without changes.

Sigh... would you like a better example?   It'd be easier for me to write 
the code from scratch than it would be to fix this one.