Conference turris::decc

2201.0. "PROCGONE bugcheck after installing an ECO" by MUCTEC::BECKER (Hartmut B., VMS & Languages, Munich) Mon May 26 1997 05:11

              <<< VAXAXP::NOTES$:[NOTES$LIBRARY]VMSNOTES.NOTE;1 >>>
               -< VAX and Alpha VMS - Digital Internal Use Only >-
================================================================================
Note 641.0          PROCGONE bugcheck after installing an ECO         No replies
MUCTEC::BECKER "Hartmut B., VMS & Languages, Munich" 37 lines  26-MAY-1997 04:08
--------------------------------------------------------------------------------
You may never see this problem but I want to mention it here in case anybody
else sees it. Maybe my quick analysis is wrong or incomplete but it fits to
what I saw. 

If your system disk is badly fragmented applying an ECO may leave your system
unbootable.

I installed ALPACRT02_071, made a shutdown with re-boot check and got a PROCGONE
bugcheck during the boot.

All my attempts to boot the system failed. The system crashed before I could
set the time (forced via sysboot settime set to 1). I booted from another disk
and checked what changed since the last successful boot. I removed or renamed
two UCX images which were in sys$loadable_images and which were replaced since
then. I disabled loading system images, I renamed all images mentioned in
VMS$SYSTEM_IMAGES.DATA, nothing helped. At last I renamed DECC$SHR.EXE which
was installed with that ECO. The system booted.

This surprised me because the same image was installed on a AS255, which was
successfully re-booted. I thought of dropping this ECO with the supplied
command procedure. A quick look into that COM-file showed it requires an old
version of DECC$SHR.EXE, hence I copied the old working one and re-booted:
The system crashed with PROCGONE at the same time during boot. This forced me
to have a closer look at that file, the file id, the header. I found that the
new DECC$SHR.EXE and the copied one had more than one header and more than 100
retrieval pointers. I concluded that at that stage during the boot such
fragmented files couldn't be mapped. I deleted some files and converted the new
DECC$SHR.EXE to a file with one header and only 30 retrival pointers: the
system booted without any complaint.

Maybe installation procedures can be made smarter to create less fragmented
new critical files. Maybe the re-boot check should check critical files for
fragmentation.

Hartmut

Crossposted to the DECC notes conference.

    This discussion is likely best left in VMSNOTES, as it is unlikely
    the DEC C RTL is directly involved here -- this appears more likely
    a case where C is an "innocent bystander" to the actual problem.
    (We hit a recent similar problem with the 10K ECO -- the primitive
    file system was unable to map the file, and the bootstrap failed.)

    And if you'd like your suggestion considered (by the right folks),
    it's likely best to use a QAR or IPMT...  (This sounds reasonable;
    the resulting fragmentation checks would likely need to be added to
    both VMSINSTAL and to PCSI.)