Re: QSYSOPR message queue security

On 12 Mar 2013 12:36, Voris, John wrote:

On 12 Mar 2013 09:34, CRPence wrote:

On 12 Mar 2013 08:02, Voris, John wrote:

And in your CL, you could also DSPMSGQ QSYSOPR *PRINT.
I like to do that as part of the Shift Change / Daily Startup.
It is nice to have the report around for about a week,
because it sure beats looking at DSPLOG.

Just curious... Is the output from DSPLOG really that much
different than DSPMSG OUTPUT(*PRINT)? The DSPLOG also has an
OUTPUT(*PRINT), if the comparison was being made between spooled
DSPMSG and an interactive display for presentation of DSPLOG
output. But even better IMO, the DSPLOG has OUTPUT(*PRTSECLVL) to
include the second level message details, which AFaIK, the DSPMSG
command still does not have.

I am not sure, but I think there is more system stuff in DSPLOG
than in QSYSOPR. At least, that been my experience.

True, there may be. While everything that goes to QSYSOPR also goes to QHST, some messages will be sent only\directly to QHST.

And QSYSOPR can be cleaned up / individual lines deleted by using
F11. <<SNIP>>

OK. But that would seem to be a reason to avoid DSPMSG QSYSOPR with regard to the Opening Post; i.e. the original issue was about data gone missing from QSYSOPR. No matter what was deleted from QSYSOPR in the DSPMSG interface, those deleted messages would still be copied to the QHST message queue by the OS, and thus should appear for DSPLOG of QHST.

Also, programmers can have their programs send INQUIRY messages
using SNDPGMMSG and other types to QSYSOPR.

Yes, and QHST is not a message queue for such activity; its purpose is only a logging facility. However the effects of any inquiries sent to QSYSOPR would appear in the output from DSPLOG for the QHST, just as they appear in DSPMSG QSYSOPR OUTPUT(*PRINT).

However one notable difference that I see [on v5r3], and an important distinction, is that DSPMSG output includes the sending program [and something else; a four-digit field of ¿I am not sure what?] in its spooled output. The same output positions in DSPLOG spooled output appear /always/ to be empty. I suppose that is at least consistent, because using DSPLOG for non-spooled output, using the F1=Help and F9=Additional, there are no from-program details there either, only the from-job information.