RE: Re: Analysing DSPLOG to CFG

[Vernon Hamberg <vhamberg@xxxxxxxxxxx>]

Tom

I must be missing something. As I understand it, you can't DSPMSG 
QHST - 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 DSPLOG 
forces the dump to the file. So it seems to me you SHOULD see the 
same thing in both. I remember working this a couple years ago and 
finding occasional, rare instances where messages did not get to the 
most current QHST* - might depend on level of activity of your system.
The key for me was using a message ID on the DSPLOG command that 
would never be found. This was because I was doing programmatic stuff 
here. I did not want to see the messages, I didn't want a huge 
report, I just wanted to work with all I could get in the files. So 
DSPLOG OUTPUT(*PRINT) MSGID(@@@0000) results in a report with no 
data, but it forces the system to dump the *MSGQ. At least, that's 
what the books say.
I don't think the actual *MSGQ (which we cannot display directly) has 
all that much in it. The stuff is all in the files, even the stuff 
you see that looks like messages in the DSPLOG display. The stuff in 
the files has the message IDs and message data, all that is needed to 
use RTVMSG in order to make it displayable in what looks like a 
normal DSPMSG display - but it's only an illusion, AFAIK.
And the message data that is useful in the CPF1164 is never displayed 
through DSPLOG - it has some very nice performance info. And you 
don't even need the matching CPF1124 to get the start time - it is in 
a message data field that is not displayed in the message text.
But all these words probably don't matter much - I did not find 
anything missing if I did the DSPLOG as described first.
There's also the matter of the cleanup settings. And QHST* files that 
are not always in the correct order by the name. The name, as you 
probably know but for benefit of others, is the letters QHST followed 
by a Julian date (IIRC - 5 digits, anyway) followed by a final 
sequence character that is A-Z and 0-9, again, IIRC. So there is a 
limit of 36 for a given date - so the system will use older names 
that might be available - or something like that. There's a way to 
get the right order, but if I told everyone, I'd have to be arrested 
for 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 that 
> weren't also in the QHST* files when I ran a couple trivial tests 
> today. DSPLOG made no difference. I have a minor nagging memory that 
> I ran across a mention that something was done about this a few 
> years 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 can 
> also point to numerous errors that have been in some of them at 
> least back to V4R3. (And yes, I do point them out to IBM support, 
> but...) Sometimes there just aren't people in IBM who know about 
> some of the older parts of OS/400. E.g., try tracking down how to 
> connect alerts (e.g., ADDMSGD ALROPT()) into SNMP nowadays. There 
> used to be people who knew how/when the journal was created and 
> other details. They're retired or moved on.
> QHST has been around and fairly unchanged for a long time. About the 
> last change I clearly remember was when DSPLOG no longer allowed any 
> value 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.