RE: Upgrading your OS release level

<snip>
What do you think?
If going from V4R3 to V5R2 would it be better to:
1.  Go incrementally to V4R5 and then jump to V5R2?
2.  Do a double savsys and then do a scratch/reload of V5R2 and restore
user
data on V5R2.
</snip>

Jerry,

New box:
My preference, V4R5 then V5R2, but If:
   There are very few/no programs that use outfile support on commands
   Triggers are not being used
   There are not any "user" objects in QGPL/QUSRSYS that were not put there
   by IBM processes, (meaning a user created system library to hold the
   system level objects )
you could get away with "reimplementing" the software from a V4R3 machine
to a V5R2 machine.  I have done this several times, however I do not call
it an upgrade.  In order to avoid trouble, I usually will recreate all of
the user profiles, work management objects,  printers and queues, etc from
the source release on to the target release.  That avoids nasty problems
with most of the objects.  Then restore the applications and test like mad.
While I have not found any real problems, there have been some tweaks to
make with outfile support etc.

On a single system, over a weekend, definitely V4R5 first, run a week, then
V5R2

BTW:  I have done this procedure to get into Independent Disk Pools with
several applications and have been very successful.  I know that Al Barsa
complains that the TAATOOLS have massive changes and get broken by IBMs
changes, but I have not had the types of trouble he reports.  The only
areas I have had any trouble with is changing the recovery plan/save plan
to accommodate for the IDP, and changing the job descriptions to point to
the correct ASP group.    Al is correct that there are some commands that
need to be checked, but a scan of the source files will fix those fairly
easily.  The manual on Independent Disk Pools does a reasonable job of
discussing them

One more note:  I had a session at COMMON that talked about the IDP and how
to implement them, (We will actually do it live if I have a VPN connection)
but the session was not scheduled in Orlando due to schedule constraints.
If there is sufficient desire, Larry Bolhuis and I will set up a BOF and/or
try and get a session booked over a cancelation.  Please let Larry and/or
me know if you're interested.

Jim Oberholtzer
Senior Solutions Architect
Computech Resources, Inc.