I'm sure there was an option somewhere along the way regarding refreshing
QGPL during an upgrade...but I might be dating myself with a System/38
flashback.
Options:
1. Reach out to the retired admin and ask if he remembers what he
changed.
2. Do a SAVOBJ on the current Q* QGPL objects before any upgrade; you
can restore them over the old objects if necessary and if you're careful.
If you're lucky, only QPRINT has been changed.
3. Do DSPOBJD to a file and run a query showing the last changed
date/time; this might help you find changed objects.
4. Find an outfit already on 7.4 and get a SAVF with their Q* objects
from QGPL (they'll have to save to your current release, of course).
Restore them to a stand-alone library and do a side-by-side
comparison against your current objects. Check the create/last changed
dates.
5. Reach out to the retired admin and ask if he remembers what he
changed (if he didn't respond the first time, try again!).
Unless you are highly disciplined and love documenting every change, don't
change IBM-supplied objects. Having thusly pontificated, my solution is a
post-upgrade script that changes a few QPRINT* parameters, adds a few
entries to the system reply list, adjusts storage pool assignments, and
changes the unprintable character replacement in IBM's print files--in
other words, my documentation is CLLE setup programs with the source
*obviously* not in QGPL and printed out for the upgrade planning meeting.
I have a strict policy that all configuration activity, including work
management changes, compiling externally-defined printer files, and
changing command defaults, is scripted in CLLE. We can redo things in a
flash, we have documentation, and we have one less item on the risk
register when it's time to upgrade. My customers don't depend upon, or
even need me, when they do an upgrade; they just upgrade, run a couple of
CL's, and get back on the air. Greedy vendors--especially those outfits in
bed with private equity--will sneer at this philosophy without realizing
these scripts have other uses, like configuring a hot-site
system/development partition. I don't know if IBM distributes QGPL-type
objects in PTF's; that could be another case where a quick reconfiguration
is necessary.
My application has its own set of work management objects (subsystems, job
queues, job descriptions, classes) for batch and daemon activity; this
means I never touch my customers' configurations. I don't put anything
into QGPL but you could create work management objects not starting with Q
and put them there; a lot depends upon how you manage your library lists.
On Wed, Jul 21, 2021 at 5:52 PM Michael Quigley <MichaelQuigley@xxxxxxxxxx>
wrote:
I'm really a developer not a systems admin. However, our long-time system
admin retired and his replacement moved away to handle some family affairs.
As a result, I'm the only one with a decent understanding of the IBM i.
We're starting to look at upgrading to 7.4 and I recall many years ago
someone shared with me that custom and customized objects QGPL can be lost
or overwritten during an upgrade. Is this true? If so, I think I can script
the changes and additions. But I'm puzzled why it would be called the
"General Purpose Library" if this was really the case.
Also, it would be great if anyone could point me to where IBM documents
the real answer-assuming they do.
Thanks in advance for any clarification and/or advice.
Michael Quigley
Computer Services
The Way international
www.TheWay.org<http://www.theway.org/>
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com
midrange.com
