Patching v7.3-2 process "hangs" ...

[Art Wiens]

I am playing with my test system, trying to prove one way or the other that our current v7.2-2 environment can be made to run on v7.3-2 with little effort.

I applied VMS732_UPDATE-V0500, rebooted and then applied the remaining 8 patches to bring it current. I had all the updates in one directory and chose the "All products listed above" option. It's at 90% done and now doing nothing:

Execution phase starting ...

The following products will be installed to destinations:
DEC AXPVMS DWMOTIF_ECO02 V1.3-1 DISK$ALPHASYS:[VMS$COMMON.]
DEC AXPVMS VMS732_ACRTL V2.0 DISK$ALPHASYS:[VMS$COMMON.]
DEC AXPVMS VMS732_DCL V4.0 DISK$ALPHASYS:[VMS$COMMON.]
DEC AXPVMS VMS732_DDTM V1.0 DISK$ALPHASYS:[VMS$COMMON.]
DEC AXPVMS VMS732_LAT V1.0 DISK$ALPHASYS:[VMS$COMMON.]
DEC AXPVMS VMS732_MANAGE V5.0 DISK$ALPHASYS:[VMS$COMMON.]
DEC AXPVMS VMS732_RTPAD V1.0 DISK$ALPHASYS:[VMS$COMMON.]
DEC AXPVMS VMS732_UAF V1.0 DISK$ALPHASYS:[VMS$COMMON.]
%PCSI-I-RETAIN, file [SYSHLP]VMS732_MANAGE-V0100.RELEASE_NOTES was not replaced because file from kit has lower generation number

Portion done: 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%

Hitting ctl-t shows no io:

xxxxxx::SYSTEM 16:46:21 PCSI$MAIN CPU=00:00:23.71 PF=3214 IO=25653 MEM=878
xxxxxx::SYSTEM 16:46:22 PCSI$MAIN CPU=00:00:23.71 PF=3214 IO=25654 MEM=878
xxxxxx::SYSTEM 16:46:24 PCSI$MAIN CPU=00:00:23.72 PF=3214 IO=25655 MEM=878

Show process shows:

Process SYSTEM 17:18:00



State LEF Working set 878

Cur/base priority 9/4 Virtual pages 11200

Current PC 80146984 CPU time 0 00:00:23.88

Current PSL 0000001B Direct I/O 12231

Current user SP 7AE83420 Buffered I/O 13431

PID 00000235 Page faults 3214

UIC [SYSTEM] Event flags C0000002
80000000


xxxxxx$DKB100:[SYS0.SYSCOMMON.][SYSEXE]PCSI$MAIN.EXE;1

SHOW DEVICE/FILES shows:

SYSTEM 00000235 [VMS$COMMON.SYSEXE]PCSI$MAIN.EXE;1
SYSTEM 00000235 [VMS$COMMON.SYSLIB]PCSI$SHR.EXE;1
SYSTEM 00000235 [SYSTEM_SOFTWARE.VMS732_PATCHES]DEC-AXPVMS-VMS732_UAF-V0100--4.PCSI;1

Read through UAF patch release notes, no special mention of anything to heed before installing the patch.

Anyone have an idea what's going on here?

Hopefully someone can answer in the next two hours before I ctl-y it and shut my laptop off to go home.

Cheers,
Art

[Art Wiens]

BTW, no outstanding opcom requests, nothing in operator.log, no device errors, I'm able to login with another session (obviously!) nothing going on on the system ... it's idle.

Art

[Jan van den Ende]

Art,

just to make sure: is that a typo?
You are updating your >> 7.2-2 << environment with >> 7.3-2 << patches?

It would surprise me if that would work!

Proost.

Have one on me.

jpe

[Art Wiens]

No no ... I had a test system already at v7.3-2 from about a year ago ... just wanted to freshen it up and start testing the apps again.

Give me a bit of credit!! ;-)

Anything I can glean from ANALYZE/SYSTEM while it's "hung"?

Cheers,
Art

[Thomas Ritter · Accepted solution]

Art, when we do our bulk patching it is usually always using a batch job. We workout all the dependancies and code accordingly. Selecting "ALL" using PCSI sounds risky. How is the order of product installations determined ?

Here is an example of some our our work. the procedure is modified over and over. We run a 4 node cluster with 4 independant system disks. This way we get reproducibility.

$v='f$verify(0,0)
$!+
$!
$!-
$ if f$mode() .eqs. "INTERACTIVE" THEN EXIT 2
$ username = f$edit(f$getjpi("","USERNAME"),"COLLAPSE")
$ if username .nes. "SYSTEM"
$ then
$ write sys$output "Use the SYSTEM account."
$ exit 1 !Modify to suit
$ endif
$ saved_directory = f$environment("DEFAULT")
$ set default common:[KITS732.ECOS]
$ DEFINE/SYS NO_ASK$BACKUP TRUE
$ DEFINE/SYS NO_ASK$REBOOT TRUE
$ DEFINE/JOB ARCHIVE_OLD NO
$!
$!---------------------------------------------------
$!
$ PROD INSTALL VMS732_PCSI/PRODUCER=DEC/BASE=AXPVMS /VER=V1.0/SAVE_RECOVERY_DATA
$!
$ DEASSIGN/SYS NO_ASK$BACKUP
$ DEASSIGN/SYS NO_ASK$REBOOT
$ EXIT
$!
$!----------------- rating 1 ----------------------------------
$!
$ PROD INSTALL VMS732_UPDATE/PRODUCER=DEC/BASE=AXPVMS/VER=V3.0/SAVE_RECOVERY_DATA
$!
$ PROD INSTALL VMS732_SYS/PRODUCER=DEC/BASE=AXPVMS/VER=V7.0/SAVE_RECOVERY_DATA
$!
$ PROD INSTALL VMS732_DRIVER/PRODUCER=DEC/BASE=AXPVMS/VER=V1.0/SAVE_RECOVERY_DATA
$!
$!---------------- rating 3-----------------------------------
$!
$ PROD INSTALL VMS732_SYSINI/PRODUCER=DEC/BASE=AXPVMS/VER=V1.0/SAVE_RECOVERY_DATA
$!
$ PROD INSTALL VMS732_RMS/PRODUCER=DEC/BASE=AXPVMS/VER=2.0/SAVE_RECOVERY_DATA
$!
$ PROD INSTALL VMS732_PTHREAD/PRODUCER=DEC/BASE=AXPVMS/VER=V2.0/SAVE_RECOVERY_DATA
$!
$ PROD INSTALL VMS732_FIBRE_SCSI/PRODUCER=DEC/BASE=AXPVMS/VER=V4.0/SAVE_RECOVERY_DATA
$!
$ PROD INSTALL VMS732_BACKUP/PRODUCER=DEC/BASE=AXPVMS /VER=V3.0/SAVE_RECOVERY_DATA
$!
$ PROD INSTALL TCPIP_ECO /PRODUCER=DEC/BASE=AXPVMS/VER=V5.4-154/SAVE_RECOVER_DATA
$!
$!---------------- Software -----------------------------------
$!
$ set default common:[KITS732.PRODUCTS.COBOL028]
$!
$ PROD INSTALL VMS732_COBRTL PRODUCER=DEC/BASE=AXPVMS /VER=V2.8-670B /SAVE_RECOVERY_DATA
$!
$!
$!
$ DEASSIGN/SYS NO_ASK$BACKUP
$ DEASSIGN/SYS NO_ASK$REBOOT
$!
$ set def 'saved_directory'
$ prod show history
$ exit 1 + 0 * f$verify(v)

[Art Wiens]

That's a nice, organized way of doing things! I often wonder about the order of patches, but if the release notes don't mention prerequisites or strongly suggest a reboot, there really _shouldn't_ be an issue.

Thanks,
Art

[Art Wiens]

Well, I ctl-y'd it, it gave me the longwinded "are you sure you want to cancel" text, first I answered NO to see if that would magically bump it along, no diff. Then I answered YES and it did the same ... nothing!

I rebooted and checked - the AUTHORIZE.EXE that VMS732_UAF was to replace had been done. PRODUCT SHOW HISTORY shows all 8 patches were installed.

Very strange. What might it have been waiting on?

Cheers,
Art

[Robert_Boyd]

Art,

Did you get into ANALYZE/SYSTEM and do a

SHOW PROC/in=/CHAN on it?

You might have found something there

Robert

[David B Sneddon]

Art,

Although the "main" process is doing nothing, some
of the work is done in a subprocess... the ACRTL
patch (which I have installed recently on 15 systems)
gets to 90% then sits there for a while.
If you find the subprocess you will find it is using
LIBRARIAN to update stuff -- the time taken to do
the job varies depending on process quotas.
There was a recent thread, don't recall if it was
here or on c.o.v. regarding this matter.

Dave

[David B Sneddon]

Found it...

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=983493

Dave

[Art Wiens]

I'm going to reattempt this. I made a "standalone" backup before I started with the v0500 update yesterday. Restoring it as I write.

Robert, thanks, hopefully it fails the same way and this command might show something.

David, thanks as well, I had read that thread when it first came about, and I searched/found it again yesterday before posting. It did not match my situation, the system was completely idle, the process was in an LEF state waiting for something ... perhaps New Year's ;-)

Let you know in a few hours.

Cheers,
Art

[Art Wiens]

Recreated my steps and "unfortunately" it all worked as it should. Blew through 90% to 100%, told me about some of things it did for me and finished successfully.

Oh well, I won't let it spoil my weekend ... doesn't affect the temperature of the beer in my fridge ;-)

Happy New Year to all!!!

Cheers,
Art

[Lawrence Czlapinski]

Art: The DEC AXPVMS VMS732_ACRTL V2.0 DISK$ALPHASYS:[VMS$COMMON.] is the culprit. It takes a very long time to run. I was running the patches one at a time over the net and had the same thing happen. I was wondering if it had hung. I was about ready to give up on it when it completed.
Lawrence

[Art Wiens]

I don't think so. The system was dead idle ... not doing anything when it said 90% done. The post about the ACRTL said the cpu was 100% busy ... again, not my case.

It seems that PRODUCT processes the "select all above" in the order it shows them (alphabetically) and seems to be confirmed by the fact that it still had the last pcsi (the UAF patch) open when it was idling at the 90% mark. The ACRTL was second on the list.

Anyways, again, have a Happy New Year,
Art

[Bradford Hamilton]

Just adding my $0.02 here...

I performed one patch update a few years ago by selecting "all" under similar circumstances to the one you describe above. The patches did seem to be installed in the "correct" order, and all worked fine after a reboot.

However...I prefer to have as much control as possible over the patching process, so subsequent to this "experiment", I returned to my usual method of patching - patch infrequently, only absolutely-necessary patches, done in the "correct" order, after backing up my system disk.

[Art Wiens]

Let's turn the thread in that direction then...perhaps there are some PCSI experts out there.

Is there anything "special" about the "All of the above" choice when installing multiple patches? Any downfall for choosing All.

It might be a nice feature for PCSI to have the smarts to parse the list of patches to do and sort out the correct order of installation.

Cheers,
Art

[Ian Miller.]

I am told PCSI does the right thing if you install all. PCSI will look at the generation numbers if the same file appears in multiple kits. However there will be only one set of undo information created so you can then not undo one of the patches.