I agree - I can see where this would happen on a migration (especially one
of the migrations that jump a release).
Scott Klement
<midrange-l@scott
klement.com> To
Sent by: Midrange Systems Technical
midrange-l-bounce Discussion
s@xxxxxxxxxxxx <midrange-l@xxxxxxxxxxxx>
cc
08/08/2007 06:40 Subject
PM Re: non-IBM objects in QGPL removed
during OS upgrade
Please respond to
Midrange Systems
Technical
Discussion
<midrange-l@midra
nge.com>
Hi Aaron,
I was talking with a customer today that said they have experienced
non-IBM
objects being removed/replaced in QGPL during an OS upgrade.
I haven't encountered this during an OS upgrade. But I've seen it for a
data migration. (the distinction being that an OS upgrade just installs a
new OS on the same machine, whereas a migration involves moving all of
your data from one CPU to another.)
There are basically two ways to perform a migration:
a) You can install only the base components of the OS, then restore all of
your libraries from the previous machine, then finish installing the OS.
(This is the method currently blessed by IBM).
With this method, your QGPL & QUSRSYS libraries are restored from the
previous system, then the OS components that are in them are updated to
the new release.
b) You can install the OS (completely) ahead of time, and just restore
the user libraries. This is often done when the upgrade window is shorter
because you can do all of the OS installation and PTF stuff ahead of time
while the previous server is still in production.
The problem with this method is that you can't restore the QGPL or QUSRSYS
libraries because you'll mess up the OS installation. So you skip those
two libraries. You can restore the user profiles, etc that were in them,
but if you had any ordinary data files or programs in these libraries,
you'd have problems. (Of course, you could restore them one by one if
you knew all the names, etc, but that'd be a tedious and time
consuming process.)
My company DOES put junk in QGPL, and we've been doing so since (at least)
V1R3. As long as we use approach A, above, we haven't had any problems.
However, despite that we use QGPL this way, I still think it's the wrong
thing to do. A better idea is to create your own "general purpose
library" (maybe name it GENERAL or GLOBAL) and insert it into the library
lists of all of the jobd's and QUSRLIBL sysval. Use that library
instead. There's really no disadvantage to using your own library in this
manner, and it eliminates the dangers of using QGPL.
That's just my opinion/experience, of course.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/midrange-l.
midrange.com
