Error with VMS732_Update v14 Install

[Rick Dyson]

I installed this newest update on a system I have that is otherwise caught up and got this error:

Portion done: 0%...10%...20%...30%...40%...50%...60%...70%...80%
%PCSI-I-PRCOUTPUT, output from subprocess follows ...
%LIBRAR-W-HISTERR, error accessing library update history in DISK$SIPLE_73:[SYS0.SYSCOMMON.][SYSLIB]STARLET.OLB;5
-RMS-E-EOF, end of file detected

%PCSI-E-MODREPLERR, error replacing module C$$MAIN in library DISK$SIPLE_73:[SYS0.SYSCOMMON.][SYSLIB]STARLET.OLB
%PCSI-E-OPFAILED, operation failed
Terminating is strongly recommended. Do you want to terminate? [YES]

I did terminate on this node, however on another one that was not critical, I experimented and let it continue. At this time, that node seems OK but I am not sure if I want to blindly override the recomendation on more production critical nodes until I know where and why I am getting the error.

Does anyone have any insight?

Rick

[Volker Halle]

Rick,

this sounds like the module update history in STARLET.OLB is corrupt. There was a recent problem on OpenVMS I64 regarding similar symptoms (see VMS83I_LIBRAR-V0100), but it seems to have been Itanium-only.

Is STARLET.OLB;5 your current library ? Did you try $LIBRARY/LIST/HISTORY/FULL SYS$LIBRARY:STARLET.OLB;5 ?

This error has apparently not been reported before. You will not directly 'see' this type of corruption, unless you try to delete or replace that (or any other) module, which would typically only happen during upgrades or patch installations.

Volker.

[Bart Zorn_1]

Hello Rick,

At the first attempt to install UPDATE V14 on our test system, I encountered the same error.

I just tried to reinstall the update on the same system, and the error did not happen again!

Because I had planned to install ECO's on our production systems last weekend, and UPDATE V14 does not contain anything new which I had not verified before, I installed UPDATE V14 on production. No error here!

YMMV!

Bart Zorn

[Rick Dyson]

Bart: Thank you for the info! I have not tried a 2nd time, but will now to see. I too had everything up to date so it was theoretically just a formality!

Volker: I did not sniff around with library commands, but may just to see what I get. I have never done anything manually to that library outside of running ECOs or Installs, etc.

Thanks!
rick

[Volker Halle]

Rick,

I've just installed VMS732_UPDATE-V1400 on an OpenVMS Alpha V7.3-2 SSB system with just VMS732_PCSI-V0300 installed previously. No problem.

So the STARLET.OLB update history corruption must have happened during installation of a previous patch.

After installing VMS732_UPDATE-V1400, the following command lists lots of module deletions and replacements in the Library Update History section:

$ libr/lis/full/hist sys$share:starlet.olb

This kind of problem may be very hard to diagnose. You would have to collect all patch installation history information from all sites seeing this problem and try to figure out, under which circumstances this problem would show up. Collecting such information would only make sense at HP, but as V7.3-2 is out of support...

Until then, I would suggest to check STARLET.OLB prior to installation of VMS732_UPDATE-V1400 with to above LIBR/LIS command.

Volker.

[Duncan Morris]

Rick,

I have also experienced this error - but on only 1 system.

The update went in with no issues on 2 DS20e systems with 4GB, but failed on a DS10 with only 256MB of memory.

From the lis/his/fu listings, the process appears to have completed OK - even though I did an explicit continue following the "error". The C$$MAIN module appeared to have been correctly inserted when compared with the DS20e systems.

I would suspect that it might be related to quotas in some way (although the DS10 account appeared to have ample).

The failing LIBRARIAN phase is certainly a heavy consumer of virtual memory.

Repeating the install on the DS10 came up with no problems, second time around.

Regards,

Duncan

[Volker Halle]

Duncan,

did you also get RMS-E-EOF as the system service failure code for the %LIBRAR-W-HISTERR error ? I've seen EXQUOTA errors being reported on a situation like this, but EOF due to quota problems would not be VMS-like.

Volker.

[Duncan Morris]

Volker,

it was exactly the same error as reported by Rick.

I was also suprised by the EOF error!

Duncan

[Duncan Morris]

Hi,

the DS10's small memory was probably a red herring, as I also have the issue on another larger system.

The problem is repeatable provided I abort the update at the prompt, so I will look at it in more detail later today.

Duncan

[Volker Halle]

Duncan,

for further tests, please always check STARLET.OLB with LIBR/LIS/FULL/HIST before installing the update kit. If STARLET.OLB is o.k. before the update and you get the error during the update, it must be an error in the update procedure.

Maybe the 'replace' worked and the new module has been correctly replaced, but accessing and/or writing the record in the update history failed.

After a successful installation, I see the following entries (from a LIBR/LIS=x.x/FULL/HIST SYS$SHARE:STARLET.OLB):

...
Max. Number history records: 50 Library history records: 50
...

C$$MAIN Ident V4.5-108 Inserted 10-DEC-2007 12:21:02 14 symbols
C$$MAIN_COND_HAND Ident V4.5-28 Inserted 10-DEC-2007 12:21:03 6 symbols
...
SYSTEM deleted 1 module on 10-DEC-2007 12:17:43
C$$MAIN_COND_HAND

SYSTEM deleted 1 module on 10-DEC-2007 12:17:46
C$$MAIN
...

SYSTEM inserted 182 modules on 10-DEC-2007 12:23:48
C$$MAIN
C$$MAIN_COND_HAND
C$$MEMFUNC
...


Volker.