Jim Sloan, the father of CL, wrote a very useful book (CL Tips &
Techniques). The first three chapters cover messages. If you search for
it, there are dozens of places that have used copies; a few have new
editions. It was written before the recent updates to CL (subroutines,
etc.), but still very valuable.

Jerry C. Adams
IBM i Programmer/Analyst
Never go to bed with anyone crazier than yourself.
--
A&K Wholesale
Murfreesboro, TN
615-867-5070


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Monday, March 19, 2012 2:13 PM
To: midrange-l@xxxxxxxxxxxx
Subject: 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.ht
m
"
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.ht
m
_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.ht
m
"...
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
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.


This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].