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 thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.