On 21-Dec-2011 14:57 , Sam_L wrote:
I have a bunch of year end jobs where I'd like to route the joblog
to somewhere other than QEZJOBLOG. Preferably without changing the
jobs.
Are they all started by SBMJOB from a controlling program, or might
some jobs be started from other EOY jobs? And are all jobs submitted
with the same routing data and job queue?
From my research, job logs go to the OUTQ specified in the the
QPJOBLOG printer file. The spooling system finds the first QPJOBLOG
in the library list and uses that, and the first QPJOBLOG is in
QSYS, which is at the top of the library list. Thus it seems very
hard to reroute job logs.
Or... for those using secondary language libraries, the printer file
would probably come from QSYS29##. That same concept can be taken
advantage of; see next comment.
If I create a temporary library, copy QPJOBLOG there, change it, and
put that library at the top of the library list, I can make it work.
Code like this:
PGM
CHGSYSLIBL LIB(SAM_TEMP)
dsplibl
ENDPGM
But that means I would have to change every job.
The same effect could be had using the SYSLIBLE on the subsystem that
will be used for the batch jobs; according to the job queue. According
to CHGSBSD, that system library list setting is established for all new
jobs entering since that change, not merely since Start Subsystem
[STRSBS] time.
Subsystem library (SYSLIBLE) - Help:
"Specifies a library that is added ahead of other libraries in the
system portion of the library list of jobs started in the subsystem.
This parameter allows you to use a secondary language library."
Alternatively the above program source example, with a TFRCTL QCMD
replacing the "dsplibl", can be instituted as a routing program; though
the addition of RTGDTA specifications requirements may require source
changes. And if source changes are acceptable, then the jobs might best
effect their own desired joblog spooling [or output to database file];
having preceded DSPJOBLOG with the desired CHGJOB LOG() to set the
logging\filtering and OVRPRTF QPJOBLOG to specify the OUTQ() and
whatever other parameters like SPLFACN(), HOLD(), SAVE(), etc. And if
other spooled data should also go to some specific location, perhaps
OVRPRTF *PRTF included as well.
I suppose I could permanently move QPJOBLOG to somewhere in the
user portion of the library list and control it by manipulating
the library list through JOBDs.
The OS joblog spooling for end of job will use the *LIBL to find
QPJOBLOG. To get the "user portion of the library list" to affect that
spooling would require moving the QPJOBLOG *FILE object out of the
system portion of the library list, which means out of QSYS, which is a
very poor idea IMO. Or was that supposition of what could be done meant
to imply something other than "MOVOBJ QSYS/QPJOBLOG *FILE SomeUsrLib"?
Has anyone else come up with a solution? How have you done it?
I was similarly frustrated by the implementation of the OA
"Operational Assist" to force the use of the QEZJOBLOG output queue.
Although seemingly "nice" to have to enable CLEANUP, I too experienced
the desire for some jobs to have default logging use a different OUTQ.
My solution was to undo the OA effects for printer files. That is, I
just changed the affected printer files [CHGPRTF] to have OUTQ(*JOB)
DEV(*JOB) so the end-of-job [and service\dump\debug] spooling would
default to whatever the job had established.... just like how things
worked before the invention of the OA. That of course opens the issue
for controlling QPJOBLOG spool files, however the OS has stepped up to
provide more\alternate means to minimize the impact; spool file action
control and IIRC both some retention attributes and more robust
delete-by-age or retention.
I had long wished the Work Management and Data Management could have
allowed the [printer filee] overrides to persist until the true end of
job; i.e. until after the EOJ joblog spooling, at least until the open
of QPJOBLOG though perhaps until after completed spooling the joblog. I
seem to recall the overrides are honored during *PRTWRAP "print wrap"
conditions for JOBLOGFULL processing, so why not EOJ as well? If that
had been the case, an override [even if necessitating OVRSCOPE(*JOB)]
could have allowed any job to easily circumvent the OUTQ(QEZJOBLOG) as
defined in the printer file for both DSPJOBLOG and EOJ joblogging.
As I recall there was an API for EOJ job logging, which could
alternatively enable the outfile. I recall coding something to take
advantage once, but only for testing rather than actually implementing,
so my recollection is dim. That is the Control Job Log Output
(QMHCTLJL) API which can override the EOJ joblog processing, and the
OUTPUT(*APIDFN) for DSPJOBLOG requests in the job. From a very quick
review of the doc I infer the API allows only *OUTFILE support, with no
ability to name an alternate [library name as the] location for the
QPJOBLOG printer file to be used :-( Seems like the input value of
*PRINT possibly could be extended to do that.
I do not recall if there is a program which spools a JobLog from the
database file(s) previously used as output for *APIDFN, but if there is,
that might make that option more palatable. The API call could be put
in a routing program or in source of the EOY programs. But a routing
program could probably just as easily establish request message(s) to
effect OVRPRTF and DSPJOBLOG as the last CL requests.?
Regards, Chuck
midrange.com
