Help: SCRATCH reinstall of AS/400 after CISC to RISC migration because of QGPL and QUSRSYS???
Jay Ringhal
are *BACKLEVEL and are shown to be at V3R2 on this V4R1 AS/400.
IBM says we have to back up our AS/400 (100+ GB) and restore it in
steps, beginning with a 'scratch' install using a 16 step checklist
they faxed us.
We estimate that it will take us 40+ hours to accomplish this, and
with no small amount of risk. We will also lose our spool files, etc.
- objects that are not backed up by IBM's commands.
Does anyone have an alternative, or an experience that can help us
avoid a full backup and reinstall?
We feel that this 'death sentence' is much too severe for having
missed one step in a complex migration process. It's also hard to
believe that such a sophisticated system has such an exposed Achilles
heel.
Thanks to all who respond.
Jay
Tim
off the phone.
Don't take it!!! Get right back on the phone and raise the roof until they
give you the right answers.
And don't quit until the restraining order shows up at your door.
Jay Ringhal wrote in message <35a40cbb...@news.newsguy.com>...
Richard Phillips
them alone. the next release upgrade will take care of them. If not,
reinstall only the qusrsys and qgpl from your backup tapes and then
select only the qusrsys and qgpl for upgrade.
this should work. be sure to apply ptf's to these after reloading.
we did the same thing by upgrading an empty box from v3r7 to v4r1 and
then restoring qusrsys and qgpl to that box from the V3r7 backup.
Ovbiously it was the wrong way to go.
But everything is working just fine so we are leaving it until V4r2
install next week.
hope it helps.
Dick Daniels
>
> We did this upgrade and did not follow the roadmap. QGPL and QUSRSYS
> are *BACKLEVEL and are shown to be at V3R2 on this V4R1 AS/400.
Your post does not indicate that anything is *happening* that you believe
is a problem.
Are there programs in QGPL or QUSRSYS that do not run? Are there objects
in these libs that cause other programs to 'blow up?'
What if you simply rename the existing libs, create new ones with their
names, and copy or move or recreate the objects in them?
Now, if QSYS had the problem you describe... Never mind. ;-)
Good Luck!
Dick Daniels
http://www.wynth.com/
J Kasselman
selecting them on the Install Licensed Programs. Usually this causes no
problem, but I would definitely make sure that I had a good backup before
trying this, at least of the lic and OS.
Jay Ringhal wrote in message <35a40cbb...@news.newsguy.com>...
>We did this upgrade and did not follow the roadmap. QGPL and QUSRSYS
>are *BACKLEVEL and are shown to be at V3R2 on this V4R1 AS/400.
>
Jay Ringhal
putting on the latest CUM and HIPERS, and we are aware of the
Registration Facility where the OS keeps exit points being kept in
QUSRSYS.
There was supposed to be a conversion in the middle of the upgrade
that did NOT take place, and IBM says this is the only way we can get
it to take place.
Dick Daniels <rlda...@wynth.com> wrote:
>Jay Ringhal wrote:
>>
>> We did this upgrade and did not follow the roadmap. QGPL and QUSRSYS
>> are *BACKLEVEL and are shown to be at V3R2 on this V4R1 AS/400.
>
Jay Ringhal
said 'No'...
rph...@seabiscuit.com (Richard Phillips) wrote:
>IF your system runs with the "backlevel" on qusrsys and qgpl, leave
>them alone. the next release upgrade will take care of them. If not,
>reinstall only the qusrsys and qgpl from your backup tapes and then
>select only the qusrsys and qgpl for upgrade.
>
>this should work. be sure to apply ptf's to these after reloading.
>
>we did the same thing by upgrading an empty box from v3r7 to v4r1 and
>then restoring qusrsys and qgpl to that box from the V3r7 backup.
>Ovbiously it was the wrong way to go.
>
>But everything is working just fine so we are leaving it until V4r2
>install next week.
>
>hope it helps.
>
>On Thu, 09 Jul 1998 00:35:23 GMT, BUNG...@nospamHOTMAIL.COM (Jay
>Ringhal) wrote:
>
>>We did this upgrade and did not follow the roadmap. QGPL and QUSRSYS
>>are *BACKLEVEL and are shown to be at V3R2 on this V4R1 AS/400.
>>
Charles R. Pence
>
> We DO have some problems (like unstable Anynet), and are planning on
> putting on the latest CUM and HIPERS, and we are aware of the
> Registration Facility where the OS keeps exit points being kept in
> QUSRSYS.
>
> There was supposed to be a conversion in the middle of the upgrade
> that did NOT take place, and IBM says this is the only way we can get
> it to take place.
>
> Dick Daniels <rlda...@wynth.com> wrote:
>
> > <<SNIP>>
> >What if you simply rename the existing libs, create new ones with their
> >names, and copy or move or recreate the objects in them?
> > <<SNIP>>
I would fix your first condition before PTFs etc... I think the missing
conversion was *mabye* just the install of QUSRSYS and QGPL??? Trying
to install PTFs with your QUSRSYS and QGPL not in the correct state will
likely not improve your situation IMO.
In attempt to correct the QUSRSYS and QGPL problem I would definitely
*not* do what Dick suggested... albeit it a nice idea, this is really a
very complicated issue; and the reason "IBM" said you should just
scratch to the new system. Of course I would think they would also be
willing for you to shell out a lot of money for something like
ConsultLine services to fix your system.?.?
Do you know exactly what you did, or did not do which led to this? In
which upgrade scenario? I would guess this was a replace-the-release
from V3R2 to V4R1.?.?
Regards, Chuck
-- Comments provided "as is" with no warranties of any kind whatsoever.
tho...@inorbit.com
The trouble is that this wouldn't be a "re-install". In this case, QGPL and
QUSRSYS have not yet been 'installed'; they're simply left over from what was
previously on the machine.
Because of the nature of many things in QUSRSYS/QGPL, I wish I had advice to
give with any confidence; but I don't. I will certainly, however, keep my eye
on this thread for future developments. I definitely want to hear what
happens to the site going to V4R2 next week _without_ fixing the problem
first.
Tom Liotta
In article <6o2hmi$9p...@news.ruraltel.net>,
"J Kasselman" <ka...@ruraltel.net> wrote:
> It is possible to re install qgpl and qusrsys from the distribution media by
> selecting them on the Install Licensed Programs. Usually this causes no
> problem, but I would definitely make sure that I had a good backup before
> trying this, at least of the lic and OS.
>
> Jay Ringhal wrote in message <35a40cbb...@news.newsguy.com>...
> >We did this upgrade and did not follow the roadmap. QGPL and QUSRSYS
> >are *BACKLEVEL and are shown to be at V3R2 on this V4R1 AS/400.
> >
> >IBM says we have to back up our AS/400 (100+ GB) and restore it in
> >steps, beginning with a 'scratch' install using a 16 step checklist
> >they faxed us.
> >
> >We estimate that it will take us 40+ hours to accomplish this, and
> >with no small amount of risk. We will also lose our spool files, etc.
> >- objects that are not backed up by IBM's commands.
> >
> >Does anyone have an alternative, or an experience that can help us
> >avoid a full backup and reinstall?
> >
> >We feel that this 'death sentence' is much too severe for having
> >missed one step in a complex migration process. It's also hard to
> >believe that such a sophisticated system has such an exposed Achilles
> >heel.
> >
> >Thanks to all who respond.
> >
> >Jay
>
>
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
Jay Ringhal
until just now, some major fiber cut on the East coast affected
internet connectivity for a while.
My boss is waiting for a callback from Consultline, so that already
occurred to us and we are pursuing it. I still think the OS/400
shouldn't be so fragile, but I prefer a service to fix it instead of a
reload.
I'm not really confident on the 'upgrade to V4R2', and 'leave it
alone' solutions either, so I'm with you on that score. SOME sort of
conversion did not take place, but the specifics are not documented
anywhere (maybe in IBM's X Files?)
I don't mind the suggestions, maybe there's a better one on the way.
What did we do to screw it up? I'm not sure, I wasn't there at the
time. I think QGPL and QUSRSYS were just restored on the brand new
RISC system, which already had its OS & LPPs installed.
If you think of anything else, please let me know. Since you're with
IBM, maybe you can mention to someone that they need to make this
process a little sturdier.
Thanks again.
Charles R. Pence
> <<SNIP>>
> What did we do to screw it up? I'm not sure, I wasn't there at the
> time. I think QGPL and QUSRSYS were just restored on the brand new
> RISC system, which already had its OS & LPPs installed.
From that, one should infer the upgrade was not a replace-the-release??
I'd suggest researching what was done; the best information, typically
will lead to the best solution. I would first turn off any CLEANUP
function to avoid loss of information which might otherwise assist
determining what transpired <joblogs, history, etc.>
> If you think of anything else, please let me know. Since you're with
> IBM, maybe you can mention to someone that they need to make this
> process a little sturdier.
But that's what the RoadMap was/is for.?.? A lot of money/time was
spent trying to make it work well; for as many configurations <sfw&hdw>
as possible. As you said, the upgrade was performed having chosen not
to follow the RM.
I do understand however, your concern. But you must realize prevention
of problems and recovery actions are quite difficult, because these
libraries <although prefixed w/ the letter 'Q'> are considered USER
LIBRARIES and as such there is no generic protection nor recovery for
what is in them. Many different functions may use these libraries for
storing data. On my system it was always easy to recover QUSRSYS
because we only had SNA/DS and directory <some of it OV>, so scripts
with the ADDxxxx and CRTxxxx stuff could be run to restore the system
onto a new system. The RISC upgrade code does this for some things <eg.
system reply list>, but I am not entirely sure of what is done for QGPL
& QUSRSYS stuff -- as you might have inferred from the previous post, I
think it maybe just depends on standard install-exit processing to
upgrade from old-to-new; this agrees w/ the idea that given the
Rpl-a-Rls method, and your backlevel was just the previous release
copies of those libs, then recovery would seem <I DO NOT KNOW> to be as
simple as installing that feature <as someone else suggested>.
Chris Holko
>What did we do to screw it up? I'm not sure, I wasn't there at the
>time. I think QGPL and QUSRSYS were just restored on the brand new
>RISC system, which already had its OS & LPPs installed.
You screwed up by restoring a previous release version of QUSRSYS/QGPL
AFTER YOU INSTALLED the new versions.
Up until the point you install the new code QUSRSYS and QGPL are reported as
backlevel. It sounds as if you restored either an *ALLUSR or a SAVCHGOBJ
*ALLUSR on top of your installed RISC code.
The normal process is to start with the *backleveled QUSRSYS, QGPL and then
restore your old system to the new system. You then install the RISC code
(36/37/41/42) over top of this, and it converts the needed files in
QGPL/QUSRSYS and brings them up to the current level. Afterward if you need
to sync your two systems together YOU DO NOT BRING OVER QGPL/QUSRSYS else
you basically waste all the time invested.
The standard response is to tell you to scratch your system, and its the
safest route. Instead of wasting time complaining about it I would start
now. Your spending just as much if not more time waiting for a magic
solution than by acting.
The problems in QGPL/QUSRSYS are possibily related to the following files...
QAPZ*, QAO*, and the release markers. Those are the real pests.
If you back up the two libraries, you may be able to try the following....
delete all your objects from those libraries expect outqueues and message
queues. (really that is all you should have in there), whack all the QAO*
files, and whack the QAPZ (PTF files), and the release markers (which I
forget the names of). Restore your old QUSRSYS and QGPL versions of those
same files and attempt to install the newer versions over top of them.
(Please note : I am not saying this will work, and would prefer to follow
IBM's method first and foremost)
It would have been a whole lot better if you had done a full backup before
starting your restore process (backup of r370 or whatever) as you would have
had an out.
Chris
Eagles may soar, but weasels don't get sucked into jet engines.
Paul Nicolay
QGPL and QUSRSYS are two very special libraries, or should I say licensed
programs ! The only correct place to install them is right after the OS
and before any other licensed program. If this isn't done, I don't think
there's any way to correct it... except an unload, scratch install and
reload as said by IBM.
Unfortunately, all this is well documented... so I don't agree in blaming
IBM for this, neither that it is an Achilles heel. Procedures are there to
follow, so next time "RTFM", sorry :-(
Kind regards,
Paul
__________________
Jay Ringhal <BUNG...@nospamHOTMAIL.COM> wrote in article
<35a40cbb...@news.newsguy.com>...
> We did this upgrade and did not follow the roadmap. QGPL and QUSRSYS
> are *BACKLEVEL and are shown to be at V3R2 on this V4R1 AS/400.
>
> IBM says we have to back up our AS/400 (100+ GB) and restore it in
> steps, beginning with a 'scratch' install using a 16 step checklist
> they faxed us.
>
> We estimate that it will take us 40+ hours to accomplish this, and
> with no small amount of risk. We will also lose our spool files, etc.
> - objects that are not backed up by IBM's commands.
>
> Does anyone have an alternative, or an experience that can help us
> avoid a full backup and reinstall?
>
> We feel that this 'death sentence' is much too severe for having
> missed one step in a complex migration process. It's also hard to
> believe that such a sophisticated system has such an exposed Achilles
> heel.
>
> Thanks to all who respond.
>
> Jay
>
The contents of this message express only the sender's opinion.
This message does not necessarily reflect the policy or views of
my employer, Merck & Co., Inc. All responsibility for the statements
made in this Usenet posting resides solely and completely with the
sender.
Francesco Candia
>We did this upgrade and did not follow the roadmap. QGPL and QUSRSYS
>are *BACKLEVEL and are shown to be at V3R2 on this V4R1 AS/400.
>
>IBM says we have to back up our AS/400 (100+ GB) and restore it in
>steps, beginning with a 'scratch' install using a 16 step checklist
>they faxed us.
>Thanks to all who respond.
>
>Jay
I don't have a solution, but two considerations.
1) I can't understand why you don't follow the road map.
Have you ever seen IBM do something for nothing?
If they spend money, time and resources for the Road Map and the
software involved don't you ask why?
2) I can't understand why IBM consider QUSRSYS a "USER" library.
It contains a lot of critical system objects and, as you know, if you
replace it you probably must reinstall your system.
Francesco Candia
Via Monte Cervino 1/9
10090 Gassino Torinese
Italy
fca...@tin.it
francesc...@bigfoot.com
Jay Ringhal
Where does it say that if I mess up QGPL and QUSRSYS that I have to
scratch and reinstall my whole system?
Thanks
"Paul Nicolay" <removethis....@merck.com> wrote:
>Hi Jay,
>
>QGPL and QUSRSYS are two very special libraries, or should I say licensed
>programs ! The only correct place to install them is right after the OS
>and before any other licensed program. If this isn't done, I don't think
>there's any way to correct it... except an unload, scratch install and
>reload as said by IBM.
>
>Unfortunately, all this is well documented... so I don't agree in blaming
>IBM for this, neither that it is an Achilles heel. Procedures are there to
>follow, so next time "RTFM", sorry :-(
>
>Kind regards,
>Paul
>__________________
>Jay Ringhal <BUNG...@nospamHOTMAIL.COM> wrote in article
><35a40cbb...@news.newsguy.com>...
>> We did this upgrade and did not follow the roadmap. QGPL and QUSRSYS
>> are *BACKLEVEL and are shown to be at V3R2 on this V4R1 AS/400.
>>
>> IBM says we have to back up our AS/400 (100+ GB) and restore it in
>> steps, beginning with a 'scratch' install using a 16 step checklist
>> they faxed us.
>>
>> We estimate that it will take us 40+ hours to accomplish this, and
>> with no small amount of risk. We will also lose our spool files, etc.
>> - objects that are not backed up by IBM's commands.
>>
>> Does anyone have an alternative, or an experience that can help us
>> avoid a full backup and reinstall?
>>
>> We feel that this 'death sentence' is much too severe for having
>> missed one step in a complex migration process. It's also hard to
>> believe that such a sophisticated system has such an exposed Achilles
>> heel.
>>
>> Thanks to all who respond.
>>
>> Jay
>>
>
>