RE: Detemine job completion status

~~~
                The reason I didn't see it in the QHST is because I
endded before it
                even run as a way to create an abnormal ended job.
Hhmmmm.  Looks like
                I might need to implement some rules on this procedure.

                Does anyone know of a api that can access the QHST? 
~~~~~


When I read QHST I use an RPG and program describe the file. The layout
of the file is a little tricky...data can span
several records. Here's a snippet from a document found at the ISeries
information center (and it took WAY too long to track down again I may
add.) This snippet is from the CL Programming section: Chapter 8:
Working with messages. I also have a program that reads it, but it does
a lot of other work and I think the program code would not be very
clear...

~~~
QHST History Log
The history log (QHST) consists of a message queue and a physical file
known as a log-version. Messages sent to the history log message queue
are written by the system to the current log version physical file. 

History log (QHST). Contains a high-level trace of system activities
such as system, subsystem, and job information, device status, and
system operator messages. Its message queue is QHST. 

When a log-version is full, a new version of the log is automatically
created. Each version is a physical file that is named in the following
way: 

Qxxxyydddn

where: 


xxx 
Is a 3-character description of the log type (HST) 

yyddd 
Is the Julian date of the first message in the log version 

n 
Is a sequence number within the Julian date (A through Z and 0 through
9)? 
Note:
The number of records in each version of the history log is specified in
the system value QHSTLOGSIZ. 
The text of the log version file contains the date and time of the first
message and last message in the log version. The date and time of the
first message are in positions 1-13 of the text; the date and time of
the last message are in positions 14-26. The date and time are in the
format cyymmddhhmmss, where: 


c 
Is the century guard digit 

yymmdd 
Is the date the message was sent 

hhmmss 
Is the time the message was sent 
You can create a maximum of 36 log versions with the same Julian date.
If more than 36 log versions are created on the same day, the next
available Julian day is used for subsequent log versions. If some of the
older log versions are then deleted, it is possible to use the names
again. Log versions are out of order when sequenced by name if log
versions are deleted and names used again. 

You can also write a program to process history log records. Because
several versions of each log may be available, you must select the
log-version to be processed. To determine the available log-versions,
use the Display Object Description (DSPOBJD) command. For example, the
following DSPOBJD command displays what versions of the history log are
available: 

DSPOBJD   OBJ(QSYS/QHST*)   OBJTYPE(*FILE)

You can delete logs on your system by using the delete option from the
display that is presented on the Work with Objects (WRKOBJ) command. 

You can display or print the information in a log using the Display Log
(DSPLOG) command. You can select the information you want displayed or
printed by specifying any combination of the following: 

Period of time 
Name of job that sent the log entry 
Message identifiers of entries 
The following DSPLOG command displays all the available entries for the
job OEDAILY in the current day: 

DSPLOG JOB(OEDAILY)

The resulting display is: 

+-----------------------------------------------------------------------
---------+
|                       Display History Log Contents
|
|
|
| Job OEDAILY started
|
| Database file OEMSTR in library OELIB expired
|
| Job OEDAILY abnormally ended
|
| Job OEDAILY started
|
| Job OEDAILY ended
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Bottom |
| Press Enter to continue.
|
|
|
| F3=Exit   F10=Display all   F12=Cancel
|
|
|
+-----------------------------------------------------------------------
---------+
If you reset the system date or time to an earlier setting, or if you
advanced the system date and time by more than 48 hours, a new log
version is started. This ensures that all messages in a single log
version are in chronological order. 

Log versions created on a release prior to V3R6M0 may contain entries
that are not in chronological order if the system date and time was
reset to an earlier setting. Therefore, when you try to display the
log-version, some entries may be missed. For example, if the log-version
contains entries dated 1988 followed by entries dated 1987, and you want
to display those 1987 entries, you specify the 1987 dates on the PERIOD
parameter on the DSPLOG command but the expected entries are not
displayed. You should always use the system date (QDATE) and the system
time (QTIME), or you should specify the PERIOD parameter as follows: 

PERIOD((start-time start-date) (*AVAIL *END))

The system writes the messages sent to a log message queue to the
current version physical file when the message queue is full or when the
DSPLOG command was used. If you want to ensure the current version is
up-to-date, specify a fictitious message identifier, such as ###0000, on
the DSPLOG command. No messages are displayed, but the log-version
physical file is made current. 

If you print the information in a log using the Display Log command and
output parameter *PRINT, (DSPLOG OUTPUT(*PRINT), only one line from each
message is printed, using the first 105 characters of each message. 

If you print the information in a log using the Display Log command and
output parameter *PRTWRAP, (DSPLOG OUTPUT(*PRTWRAP), messages longer
than 105 characters are wrapped to include additional lines to a limit
of 2000 characters. 

If you print the information in a log using the Display Log command and
output parameter *PRTSECLVL, messages longer than 105 characters are
wrapped to include additional lines to a limit of 2000 characters. The
second-level message text is also printed if available, up to a maximum
of 6000 characters. 

If you display the information in a log using the Display Log (DSPLOG)
command, only 105 characters of message text are shown. Any characters
after 105 characters are truncated at the right. 


Format of the History Log
A database file is used to store the messages sent to a log on the
system. Because all records in a physical file have the same length and
messages sent to a log have different lengths, the messages can span
more than one record. Each record for a message has three fields: 

System date and time (a character field of length 8). This is an
internal field. The converted date and time also are in the message. 
Record number (a 2-byte field). For example, the field contains hex 0001
for the first record, hex 0002 for the second record, and so on. 
Data (a character field of length 132). 
The third field (data) of the first record has the following format: 
Contents  Type  Length  Positions in Record  
Job name  Character  26  11-36  
Converted date and time1  Character  13  37-49  
Message ID  Character  7  50-56  
Message file name  Character  10  57-66  
Library name  Character  10  67-76  
Message type2  Character  2  77-78  
Severity code  Character  2  79-80  
Sending program name3  Character  12  81-92  
Sending program instruction number4  Character  4  93-96  
Receiving program name3  Character  10  97-106  
Receiving program instruction number4  Character  4  107-110  
Message text length  Binary  2  111-112  
Message data length  Binary  2  113-114  
Coded character set identifier (CCSID) for text or data5  Binary  4
115-118  
Reserved  Character  24  119-142  

1 
The format is: cyymmddhhmmss 
where: 


c 
Is the century digit (c=0 if yy >= 40, c = 1 if yy < 40) 

yymmdd 
Is the year, month, and day that the message is sent 

hhmmss 
Is the hour, minute, and second that the message is sent 

2 
This has the same value as the RTNTYPE parameter on the Receive Message
(RCVMSG) command. 

3 
If the sender or receiver is an ILE procedure, the entry in the history
log contains only the ILE program name. The module name and procedure
name are not included in the history log. 

4 
If the sender or receiver is an ILE procedure, the sending or receiving
instruction number is 0. 

5 
This CCSID applies only to the message data that is defined as *CCHAR
data if the message is a stored message. The rest of the message data
can be considered 65 535. Otherwise, this is the CCSID of the immediate
message.  


The third field (data) of the remaining records has the following
format: 
Contents  Type  Length  
Message  Character  Variable1  
Message data  Character  Variable2  

1 
This length is specified in the first record (positions 111 and 112) and
cannot exceed 132. 

2 
This length is specified in the first record (positions 113 and 114).  


A message is never split when a new version of a log is started. The
first and last records of a message are always in the same QHST version.


For a description of the message data for a message, see Defining
Substitution Variables. 


Processing the QHST File
If you use an HLL program to process the QHST file, keep in mind that
the length of the message can vary with each occurrence of a message.
Because the message includes replaceable variables, the actual length of
the message varies; therefore, the message data begins at a variable
location for each use of the same message. 


QHST Job Start and Completion Messages
The system performs special formatting of the job start and job
completion messages. For message CPF1124 (job start) and message CPF1164
(job completion), the message data always begins in position 11 of the
third record. 

Job accounting provides more information than CPF1124 and CPF1164. For
simple job accounting functions, use the CPF1164 message. 

Performance information is not displayed as text on message CPF1164.
Because the message is in the QHST log, users can write application
programs to retrieve this data. The format of this performance
information is as follows. 

The performance information is passed as a variable length replacement
text value. This means that the data is in a structure with the first
entry being the length of the data. The size of the length field is not
included in the length. The first data fields in the structure are the
times and dates that the job entered the system and when the first
routing step for the job was started. The times are in the format
'hh:mm:ss'. The separators are always colons. The dates are in the
format defined in the system value QDATFMT and the separators are in the
system value QDATSEP. The time and date the job entered the system
precede the job start time and date in the structure. 

The time and date the job entered the system are when the system becomes
aware of a job to be initiated (a job structure is set aside for the
job). For an interactive job, the job entry time is the time the
password is recognized by the system. For a batch job, it is the time
the BCHJOB or SBMJOB command is processed. For a monitor job, reader or
writer, it is the time the corresponding start command is processed, and
for autostart jobs it is during the start of the subsystem. 

Following the times and dates are the total response time and the number
of transactions. The total response time is in seconds and contains the
accumulated value of all the intervals the job was processing between
pressing the Enter key at the work station and when the next display is
shown. This information is similar to that shown on the WRKACTJOB
display. This field is only meaningful for interactive jobs. 

It is also possible in the case of a system failure or abnormal job end
that the last transaction will not be included in the total. The job end
code in this case would be a 40 or greater. The transaction count is
also only meaningful for interactive jobs other than the console job and
is the number of response time intervals counted by the system during
the job. 

The number of synchronous auxiliary I/O operations follows the number of
transactions. This is the same as the AUXIO field that appears on the
WRKACTJOB display except that this value is the total for the job. If
the job ends with a end code of 70, this value may not contain the count
for the final routing step. Additionally, if a job exists across an IPL
(using a TFRBCHJOB command) it is ended before becoming active following
an IPL, the value is 0. 

The final field in the performance statistics is the job type. Values
for this field are: 


A 
Automatically started job 

B 
Batch job 

I 
Interactive job 

M 
Subsystem monitor 

R 
Spooling reader 

S 
System job 

W 
Spooling writer 

X 
Start job 
For messages in which the message data begins in a variable position,
you can access the message data by doing the following: 

Determine the length of the variables in the message. For example,
assume that a message uses the following five variables: 
Job name    *CHAR 10
User name   *CHAR 10
Job number  *CHAR 6
Time        *CHAR 8
Date        *CHAR 8

These variables are fixed in the first 42 positions of the message data.


To find the location of the message data, consider that: 
The message always begins in position 11 of the second record. 
The length of the message is stored in a 2-position field beginning at
position 111 of the first record. This length is stored in a binary
value so if the message length is 60, the field contains hex 003C. 
Then, by using the length of the message and the start position of the
message, you can determine the location of the message data. 


Deleting QHST Files
Log-version physical files accumulate on a system and you should
periodically delete old logs that are not needed. A log-version is
created such that only the security officer is authorized to delete it. 

The Operational Assistant* provides a cleanup function which includes
the deletion of old QHST files. Another alternative is: 

As the security officer, specify: 
WRKOBJ  OBJ(QSYS/QHST*)  OBJTYPE(*FILE)

Use option 4 to delete old unneeded files. 
~~~~~

Hope it helps.


Jim Wiant


                                                                  




If you don't have time to do it right you must have time to do it over. 

Unknown, Source


This message has been sent from Foodstuffs (Auckland) Limited ("Foodstuffs").

The information contained in this message and or attachments 
is intended only for the person or entity to which it is 
addressed and may contain confidential and/or privileged 
material. Any review, retransmission, dissemination or other 
use of, or taking of any action in reliance upon, this 
information by persons or entities other than the intended 
recipient is prohibited. If you received this in error, 
please contact the sender and delete the material from any 
system and destroy any copies.

The views and opinions expressed in this message may be those
of the individual and not necessarily those of Foodstuffs, 
and are not given or endorsed by it.

Please note that this communication does not designate an 
information system for the purposes of the Electronic 
Transactions Act 2002.