Re: RCVMSG loop to get *DIAG messages.

On 19-Mar-2012 11:40 , Gqcy wrote:

I am struggling with getting a string of CL going to retrieve ALL
the *DIAG messages from my job log at signoff time.

I have tried all kinds of variations of parms (PGMQ, MSGQ, MSGTYPE,
MSGKEY,) but I haven't found the right combination...

I am going to output the *DIAG messages to a log.

Program messages are associated with, or in effect are scoped to, the
programs or procedures on the stack [call stack entries], not to the job.
_Message Handling Terms and Concepts_
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/term.htm

While possible to receive those messages, generally "receive message"
would be limited to getting messages from a previous invocation within
the program.
_Receiving a message from a program or procedure that has ended_
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rbam6/rcvmsgpgm.htm

"Occasionally, there is a need to receive messages from the job log that
are sent to a call message queue that is no longer active. ..."

There are some APIs to get [a list of] the "joblog" messages and the
capability to DSPJOBLOG to an output file, or control the logging, each
which might be better suited for the requirement, as compared to trying
to "receive message" of the messages for which the program to which the
messages were sent are no longer on the stack.

_Control Job Log Output (QMHCTLJL) API_
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/QMHCTLJL.htm

"
The Control Job Log Output (QMHCTLJL) API controls the production of a
job log when the related job ends or when the job message queue becomes
full and the print-wrap option is in effect for the job. The API can
only influence the job log for the job in which it is used. The API can
be used to control:

* The destination of the job log.
* The amount of message information written to the job log.
* The occurrence of messages in the job log.

To have an effect on the job log, the API must be called before the job
ends. It can be called in an initial program for the job.

This API does not produce a job log; rather, the API captures the
control information specified on the parameters and retains the
information until job log production. The API also prepares the output
files for job log production. When job log production occurs, such as at
end of job, the control information and the prepared output files direct
the job log to the output file. ...
"

http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/QGYOLJBL.htm

_Open List of Job Log Messages (QGYOLJBL) API_
"...
The Open List of Job Log Messages (QGYOLJBL) API lists messages from a
job log. The returned messages are sorted by their sending date and time
unless ...

_Differences between QMHLJOBL and QGYOLJBL_

The differences between the QGYOLJBL API and the List Job Log Messages
(QMHLJOBL) API follow: ...
"

_List Job Log Messages (QMHLJOBL) API_
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/QMHLJOBL.htm

"...
The List Job Log Messages (QMHLJOBL) API lists messages sent to the job
message queue of a job. This API gets the requested message information
and returns it in a user space in the format specified in the parameter
list. The following discusses how the list is sorted for nonbatch jobs
and for batch jobs.
"

_Display Job Log (DSPJOBLOG)_
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/cl/dspjoblog.htm

"...
_Output (OUTPUT)_
...

*OUTFILE
The output is directed to the database file specified in the OUTFILE
parameter. This option can only be used if the JOB parameter specifies
the special value asterisk (*). Using this option only allows a primary
output file to be produced.

*APIDFN
The output is directed to the database files which were previously
prepared by running the QMHCTLJL API. *APIDFN can only be specified if
JOB(*) was also specified. The OUTFILE and OUTMBR parameters are not used.

When this value is used, both a primary and secondary output file can be
produced. Any message filtering specified on the API is applied to the
messages before they are written to the database. The database format
(QMHPFT) of the output file is the same as that used in the IBM-supplied
database file QAMHJLPR.
"

Regards, Chuck