|
We have a library that lives -above- QSYS in the system portion of the library list. This library holds all of the IBM commands we have changed, as well as all of the subsystem descriptions we use. IBM doesn't touch this library during an upgrade, so any changes we made are untouched. After an upgrade we do have to re-create our copies of IBM commands. We have a CL program that deletes our our copy, duplicates the command from QSYS, and re-applies our defaults and other changes. This additional library has the added benefit that we can use a qualified command (ie QSYS/SBMJOB) to use the 'plain vanilla' command if we have any problems and want to check to see if it's our version that caused it. --Paul E Musselman PaulMmn@ix.netcom.nospam.com
Jeff the point I was making was that if the users find that QINTER doesn't work, they will simply try another - QCTL being a case in point. I do note that - on our untampered system that is - that the authorities on QCTL/QINTER/QBATCH are the same. Therefore, if changing authorities on job queues, this would also need to be re-applied after an upgrade. Perhaps a removal of *JOBCTL from their profiles might have the desired effect (?) although IIRC, this stops them starting writers. Mike
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.