On 21-Dec-2011 15:31 , Scott Klement wrote:
It's been an awfully long time since I did this, but I _think_ when
I did it years ago, I just changed the QPJOBLOG in QSYS.
CHGPRTF FILE(QPJOBLOG) DEV(PRT01)
Granted, you'll probably have to re-do this every time you upgrade
the OS... But, IMHO that's a lesser evil vs. making your own copy of
an IBM object.
On 12/21/2011 4:57 PM, 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.
The change to the printer file as I recall would have been to the
OUTQ() parameter which takes precedence over the DEV() parameter. And
the OUTQ() should be what defines the QEZJOBLOG, as an *OUTQ object
type? So probably instead:
CHGPRTF FILE(QSYS/QPJOBLOG) OUTQ(*JOB /* i.e. ^QEZJOBLOG */)
Note: For those using alternate language libraries, perhaps best,
that same request repeated for each library name QSYS29## for consistency.?
Consider however, that such a change defeats the OA CleanUp feature.
If there is dependence on that feature [for which an alternative has
not been or will not be implemented], then consider the consequences as
possibly more evil than the making a duplicate and adjusting the system
library list for just the jobs which need that change implemented.
I believe to avoid the whole QEZJOBLOG entirely, just do not
implement the Operational Assist CLEANUP; i.e. never issue CHGCLNUP
after an upgrade, since the SYSPRT() parameter has no option to "leave
my printer files alone!". That assumes the printer files ship with the
OS with OUTQ(*JOB); I think they do. I do not recall how customizable
the OA Cleanup is, but possibly the undesirable CHGPRTF activity that
feature might institute could be removed; is that part of QEZUSRCLNP
which can be retrieved as CL source? Note that several other printer
files are similarly affected, but with different OUTQ() specifications;
QEZDEBUG.
Note: The CHGPRTF FILE() parameter supports a generic, so for
post-install customization [and to undo OA cleanup changes] as part of
system change management, I had coded the following request [though
lazily ignoring "not all changed" as a presumed occasional\rare issue
reoccurring for "in-use"]:
CHGPRTF QSYS/Q* OUTQ(*JOB) DEV(*JOB)
FWiW: Making the copy of the OS object [e.g. QPJOBLOG printer file]
may not be even a little more evil than a change :-) Somewhat less
desirable perhaps, for the additional storage taken and perhaps having
to manipulate with overrides or library lists. However in either case,
the change and the copy\customize scenarios, the proper system change
management requires that either the change or the delete\copy\customize
activity be repeated on each new release of the OS [and although very
unlikely, but still possibly, after applying PTF maintenance]. Negative
effects are most likely only encountered when at the next release the
System CM has failed to delete the down-level object; i.e. when the
object created by the CRTDUPOBJ on the prior release is not deleted,
then the error on the duplicate is ignored, possibly the down-level
object is changed with success or any errors ignored, but the object
which the OS wants to utilize [expected to be from this newer release]
is no longer compatible with the new release. I actually recall
customers having down-level QPJOBLOG printer files which caused
End-of-job joblog spooling to "function check" and produce no QPJOBLOG
spooled output; though leaving a message in sysopr\qhst about the
inability to produce the output. So regardless of the implementation,
either should be safe, when done properly.
Regards, Chuck
midrange.com
