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