RE: QMHLJOBL woes

Thanks a ton Scott!

I have taken what you created and made it into something that's callable by
other programs.  Check it out at http://mowyourlawn.com/files/JLIFS_v1.zip
(Job Log IFS)

I added a command that works like the following: 

JLIFS IFSLOC('/home/myjob.txt') JOBNAM(*)

I added a test program to show how to call from another program:

     D JLIFSR          pr                  extpgm('JLIFSR')
     D  ppIFSLoc                    256a
     D  ppJobNam                     10a
     D  ppJobUsr                     10a
     D  ppJobNbr                      6a

     D IFSLoc          s            256a
     D JobNam          s             10a
     D JobUsr          s             10a
     D JobNbr          s              6a
      /free

       // Go after a specifc job
       IFSLoc = '/home/JLIFS_specificjob.txt';
       JobNam = 'MYRXS';
       JobUsr = 'QTMHHTTP';
       JobNbr = '002235';
       JLIFSR(IFSLoc: JobNam: JobUsr: JobNbr);

       // Go after this job
       IFSLoc = '/home/JLIFS_thisjob.txt';
       JobNam = '*';
       JobUsr = '';
       JobNbr = '';
       JLIFSR(IFSLoc: JobNam: JobUsr: JobNbr);

       *inlr = *on;

      /end-free 

I have some more ideas to make this into a cool little utility that is very
configurable.  I will have to see if I get to it anytime in the near future.

Aaron Bartell
http://mowyourlawn.com

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

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 ;-)

Hmmm.. the last conference we were both at would've been RPG And Beyond. 
If only there was a way to drink beer over the Internet... :)  (Sorry, the
headline "Drunk Driving on the Information Superhighway" just came to
mind.)

... 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?

Yes, you have the right idea.  Though, it's the dOfsFrtn field, not 
dOfsNext, that you should use.   Basically "dOfsFrtn" is the distance from 
the start of the user space to the dOfsNFldR field.  So, if dOfsFrtn is 64,
then you start reading with position 65 to get dOfsNFldR.

An offset is a "distance" from point A to point B. APIs usually refer to
offsets as being the distance from the start of the user space to a
particular field.  So, if the API says "offset 64" then you start at
position 1 of the user space, and count forward 64 bytes.  1+64 = 65.

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?).

Absolutely right.

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.

I wrote a quick n dirty free format example. Here's what it does differently
than the example you posted.

a) It keeps the API prototypes in a /COPY member.
b) It uses pointer logic (which is faster and easier, IMHO) to access the
data in the user space.
c) It uses the offsets correctly :)
d) It writes the result to an IFS stream file in ASCII text format to a
stream file in the IFS, and displays it with the DSPF command.

It's extremely quick & dirty -- but perhaps it'll be easier to read than the
one you posted.  (It's easier for me -- but I'm a bit biased!)

The code can be found here:
http://www.scottklement.com/rpg/listlog.zip