upgrade VMS 7.3-2 to 8.2 and abs 4.1

[Rob Hussey]

After performing the upgrade to 8.2 the system aborted when trying to bring up abs or mdms.
I am going to try an upgrade ABS 4.1 to 4.4 but the install instructiions or kind of nebulous. Because I am already running ABS version 4.n is there any thing I have to do after installing 4.4 or should I be ready to go without any reconfiguring?

[Hoff]

System "aborted" as in a system crash?

That shouldn't happen. If your OpenVMS Alpha V8.2 system encountered a bugcheck of some sort, confirm that your ECOs are current for OpenVMS Alpha V8.2 (and apply the mandatory ECOs and then load the optional ECOs as needed), then ring up HP support. HP will probably want you to load current ABS and MDMS, too, and might want the CLUE CRASH output from ANALYZE/SYSTEM.)

Per HP, ABS V4.4A requires MDMS V4.4A.

And if the instructions are nebulous -- which is never a good sign -- make a restorable BACKUP /IMAGE of your system disk before you commit to the upgrade. (As I expect you and anyone else will usually do, of course.)

And regardless of the leading digit, V8.2 was arguably not a major upgrade for OpenVMS Alpha; the kernel didn't see major changes. (Though something here did perturb ABS/MDMS.)

[Rob Hussey]

I only have between 5:00 and 6:00 on Thursday to make changes and 5:00 to 9:00 on the 2nd Saturday of the month. Any problems I pretty much have to back out and figure out the problem off line.

I had installed 8.2 on 2 systems that did not run ABS and they seem to be OK. I installed 8.2 with these patches
DEC-AXPVMS-TCPIP-V0505-11ECO2-1
DEC-AXPVMS-VMS82A_BACKUP-V0200--4
DEC-AXPVMS-VMS82A_DRIVER-V0200--4
DEC-AXPVMS-VMS82A_LAN-V0200--4
DEC-AXPVMS-VMS82A_PCSI-V0100--4
DEC-AXPVMS-VMS82A_SYS-V0700--4
DEC-AXPVMS-VMS82A_UPDATE-V0700--4
DEC-AXPVMS-VMS82A_XFC-V0300--4

and it got a bugcheck when I rebooted.
With the system backup and firmware updates I didn't have time to make a call but had to back out and turn it back over to operations.

I tried to install ABS4.4 this morning under vms7.3-2, but I got the system late and by the time I did my backups I didn't have time to try the install. Still need to know after the update can I just run or are there any reconfigurations I have to do.

[Volker Halle]

Douglas,

if you could provide the CLUE file from the crash (to be found in CLUE$COLLECT:CLUE$node_ddmmyy_hhmm.LIS) as a .TXT attachment to this thread, I may be able to tell more about the crash and what may be needed to resolve the underlying problem.

Volker.

[Rob Hussey]

I would get a bugcheck everytime I booted and didn't have time to do a limited boot. I had to restore the system pack and bring the system back online.

[Volker Halle]

Douglas,

apparently you don't seem to have a test system for pre-testing the upgrade. In a situation like this, some old Alpha or even a PersonalAlpha emulator could be used to test the upgrade and isolate the problem without disturbing your production system.

Volker.

[EdgarZamora_1]

I used ABS heavily in the past, and my experience with ABS is that it needs to be reinstalled after an OS upgrade. Just reinstall the ABS (even if you want to stay on the same version of ABS) after the VMS upgrade.

[Rob Hussey]

Looking back at the console logs there were many things that happened. We have a 2 cluster system sharing the system pack so we cannot do a rolling update. We have a production system with ABS. The test system is for redundancy and does not have any tape drives on it.

I updated the test system and applied all the patches and it seemed to be ok. I went to upgrade the production system and it said it was already running 8.2 so I just applied the patches and it aborted with a debug. Then I tried to reinstall 8.2 and applied the patches and it still got a debug.

The next opportunity I get to upgrade I think I will just do the production system 1st and see what happens. If that works then I will update tes test system.

If both of these work I will then try to upgrade abs 4.1 to abs 4.4 as it is pretty old.

If any problems I wil try to get collector files and things pulled off before restoring files.

[Guenther Froehlin]

If I remember right there is one routine in ABS to change the user context in P1 space and one to change ownership of tape drives in the UCB. Both execute in kernel mode. That's why ABS images are linked against the EXEC and are OS version dependent. Should have been replaced with system service calls by now.

And ABS is supposed to be just a user mode utility...&#$^#^$%&.

/Guenther

[Hoff]

If in your situation, I'd be requesting a test system here of the responsible managers. This is easily the sort of case that can become business-visible and business-critical upon failure. If you can't get the system(s) needed here, make sure the risks are known to the management chain.

Doing this live on a production server given your window and your time constraints can (will?) lead to pain and suffering; you're invariably and inevitably going to be rushed, which doesn't work when you're dealing with a production system. And getting rushed can mean bad things for running regression tests, and can be contrary to the requisite degree of care involved in any production upgrade.

System crashes and application stackdumps are a pleasant and comfortable outcome here, relatively speaking. They're obvious.

Less obvious cases -- including creeping corruptions -- can nail you here. These are the ones that concern me when I have a production server environment. "How do I avoid these", "how do I seek and detect any latent cases of these", and "how do I recover from these" are the sorts of questions I ask.

What's your downtime cost per unit time? That's the usual justification for funding a testing configuration.

For something like this case, I'd tend to replicate the system disk on the test system or test cluster, and pound on it over there. I'm guessing you already replicate the system disk, and use this as part of your recovery processing should your upgrade fail; that's one of the few ways you can buy yourself time within the windows you specify.