|
> This and the journaling idea are good ideas, assuming that I have
> control over the system. I was hoping that this info would be part
> of the *JOBQ attributes, retrievable by an API.
>
> A commercial utility or even a full blown application would be hard
> pressed to assume that they could install a VCP on an OS command or
> to set up auditing for the command.
One approach (which may be as much taboo as altering the OS command, but is
actually much less risky) is to put commands named RLSJOBQ, HLDJOBQ and
whatever else floats your boat into a separate library. These commands
would be attached to your own programs that do the logging, then execute
QSYS/RLSJOBQ (etc.). Actually, there's good reason to do the QSYS thing
before your logging. In any case, then put this library ahead of QSYS in
the system library list. The only things that would have to reside in that
library would be the *CMD objects. This works very well. In fact, I would
avoid any alteration to IBM-supplied objects even if the system is under my
control.
Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"We can't all be heroes, because somebody has to sit on the curb and clap as
they go by."
-- Will Rogers
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.