Re: Best way to access QHST programatically

cobol400-l-request@xxxxxxxxxxxx wrote:

  1. Re:  Best way to access QHST programatically (Adrienne McConnon)

date: Mon, 19 Jun 2006 13:11:04 -0500

I am relatively new to the iSeries and I appreciate your assstance.

Adrienne:

That's what these lists are for, so you're welcome.

Thanks so much for your response.  I noticed the documentation you
directed me to was for V5R4 - we are still on V5R2 - does this make a
difference?

There hasn't been much change to the basics of QHST* processing since... 
hmmm... actually, I don't know if there have been _significant_ changes since 
version 1 of OS/400. But V5R4 should be nearly exact at least within version 5. 
But, you ought to be able to find the corresponding V5R2 pages by going to the 
same areas of the navigation pane on the left. For this (QHST), I'd probably 
check V5R2 only if I ran into some error that didn't seem to have any other 
possibility.

Also, all of our systems are batch-oriented, which is why I want to use
the QHST log file - not the QHST queue.  I want to simply start out
accessing the QHST files and then selectively filtering messages based
up[on job name, or rather partial job name.  I am assuming I will need
to first list and mergelog files to include logs for a few days.  I want
to retrieve and report all of the jobs that rean for client xxx (part of
the job name) for the last 2 days and report the status of the job and
maybe who submitted the job.  I do not need to know the specifics of
what the job entailed - more specifically whether it ran to completion
successfully or not.

The mention of the messaging API got me thinking that you'd be expecting to 
process the QHST message queue. Just wanted to ensure that you were on the 
right track.

It looks like you're getting plenty of good info from others; all of it seems 
accurate. No reason for me to cover any of that, but maybe an alternative 
suggestion -- the Job Notification exit point.

Perhaps you could register against the job notification exit point and process 
the data queue messages rather than processing QHST. You'd look at each message 
to determine if it fit whatever criteria you set, discarding ones you don't 
care about. You could run as an NEP or on a regular schedule. Process DQ 
messages directly or write entry info to a database for later processing; 
however you choose.

Since you're on V5R2, you probably would want PTF SI05200 (or a supersede of 
it) in order to get more info in the data queue messages. The PTF can be 
reviewed at:

http://www-912.ibm.com/a_dir/as4ptf.nsf/b20b09ddbe42a96a86256c1b004b10d4/be032e65b20b324a86256c410047fe96?OpenDocument&Highlight=2,SI05200
  or
http://makeashorterlink.com/?U40A21E4D

V5R2 general documentation of the Job Notify exit point is at:

http://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm?info/apis/xjobntfy.htm
  or
http://makeashorterlink.com/?G53A12E4D

That's all just a possible alternative approach. QHST* might be your best 
choice, even if you process it through a spooled file as Simon suggests.

Tom Liotta