RE: Re: Analysing DSPLOG to CFG -- MIDRANGE-L

Tom

I must be missing something. As I understand it, you can't DSPMSGQHST - the only way to show the "contents" of QHST is to use DSPLOG.Am I on the same page with you there?

I also thought that all messages are written to the current QHST*file very soon after being written to the *MSGQ. And running DSPLOGforces the dump to the file. So it seems to me you SHOULD see thesame thing in both. I remember working this a couple years ago andfinding occasional, rare instances where messages did not get to themost current QHST* - might depend on level of activity of your system.

The key for me was using a message ID on the DSPLOG command thatwould never be found. This was because I was doing programmatic stuffhere. I did not want to see the messages, I didn't want a hugereport, I just wanted to work with all I could get in the files. SoDSPLOG OUTPUT(*PRINT) MSGID(@@@0000) results in a report with nodata, but it forces the system to dump the *MSGQ. At least, that'swhat the books say.

I don't think the actual *MSGQ (which we cannot display directly) hasall that much in it. The stuff is all in the files, even the stuffyou see that looks like messages in the DSPLOG display. The stuff inthe files has the message IDs and message data, all that is needed touse RTVMSG in order to make it displayable in what looks like anormal DSPMSG display - but it's only an illusion, AFAIK.

And the message data that is useful in the CPF1164 is never displayedthrough DSPLOG - it has some very nice performance info. And youdon't even need the matching CPF1124 to get the start time - it is ina message data field that is not displayed in the message text.

But all these words probably don't matter much - I did not findanything missing if I did the DSPLOG as described first.

There's also the matter of the cleanup settings. And QHST* files thatare not always in the correct order by the name. The name, as youprobably know but for benefit of others, is the letters QHST followedby a Julian date (IIRC - 5 digits, anyway) followed by a finalsequence character that is A-Z and 0-9, again, IIRC. So there is alimit of 36 for a given date - so the system will use older namesthat might be available - or something like that. There's a way toget the right order, but if I told everyone, I'd have to be arrestedfor mass homicide.


;-)

Vern

At 08:27 PM 12/12/2005, you wrote:

Vern:
What has me wondering is that I didn't find entries in QHST thatweren't also in the QHST* files when I ran a couple trivial teststoday. DSPLOG made no difference. I have a minor nagging memory thatI ran across a mention that something was done about this a fewyears ago, but nothing remotely solid.
And maybe I just didn't have sufficient time for testing.
As much as I regularly rely on the manuals for documentation, I canalso point to numerous errors that have been in some of them atleast back to V4R3. (And yes, I do point them out to IBM support,but...) Sometimes there just aren't people in IBM who know aboutsome of the older parts of OS/400. E.g., try tracking down how toconnect alerts (e.g., ADDMSGD ALROPT()) into SNMP nowadays. Thereused to be people who knew how/when the journal was created andother details. They're retired or moved on.
QHST has been around and fairly unchanged for a long time. About thelast change I clearly remember was when DSPLOG no longer allowed anyvalue for LOG() other than QHST. Maybe nobody knows.
Tom

midrange-l-request@xxxxxxxxxxxx wrote:

>   7. RE: Re: Analysing DSPLOG to CFG (Vernon Hamberg)
>
>Tom, this is right. The trick is to DSPLOG MSGID(###0000) or other
>bogus message ID - this will bring all messages off the QHST *MSGQ
>that are not yet in the QHST* files.
>
>One other gotcha is that these files are deleted during system
>cleanup, according to the schedule set in GO CLEANUP, I think.
>
>Another problem is that the order is not always that of the names of
>the QHST* files - there is always the possibility of wrapping and
>overrunning days. See the CL Programming manual and, IIRC, the Work
>Management guide for more information. Most of the above is in the
>manuals. Some was painfully learned.
>
>Vern
>
>At 06:35 PM 12/12/2005, you wrote:
>
>>Reading all QHST* files wouldn't reliably give you all available
>>entries somewhere in the past.
>>
>>The problem was something like QHST itself is a form of message
>>queue, not a physical file. Only messages that had been copied to
>>the QHST* files would be available for reading through those files.
>>
>>It's been a while, but IIRC, it was necessary to execute a DSPLOG
>>command first. This somehow caused the *MSGQ to be flushed to the files.

--
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone  253-872-7788 x313
Fax    253-872-7904
http://www.powertech.com


__________________________________________________________________
Switch to Netscape Internet Service.
As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register

Netscape. Just the Net You Need.

New! Netscape Toolbar for Internet Explorer
Search from anywhere on the Web and block those annoying pop-ups.
Download now at http://channels.netscape.com/ns/search/install.jsp
--
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.