Bugcheck code = 0000036C: PROCGONE, Process not in system

[Heinz W Genhart]

Hi FernandoML

does this cluster have multiple Systemdisks?
Are all cluster nodes booting from same systemdisk?

If you have more than one Systemdisk, be sure that they have different labels otherwise you have this problem with procgone

Regards

Geni

[FernandoML]

Hi all,
The systems we have doing clustring are an Alpha server 4000 and an Alpha server 8400 (we have another 800 sorry for the mistake)

Disks are on the storageworks (2 disks on raid 1 for booting system and the rest for data)

Storage controller console give warnings concerning "cache battery is now sufficiently charged" and "Previous controller operation terminated by removal of program card" ???!


Register dump shows R0 as 00000000.004D8CFC
(see pic attached)

We are trying to repair autochanger TZ887 and try to recover from last system backup of the cliente done in 1999!!!! My god!

Before booting last time we made a system backup on the disks of storage.

[Duncan Morris]

Fernando,

that translates to

exit %x004D8CFC
%IMGACT-F-NOTNATIVE, image is not an OpenVMS Alpha image

You definitely want to use -flags 0,30000 during the boot to identify the invalid image.

[Hoff]

[[[The systems we have doing clustring are an Alpha server 4000 and an Alpha server 8400 (we have another 800 sorry for the mistake)]]]

Ok. So which specific model of AlphaServer box are we working with here? Some AlphaServer boxes will not bootstrap as far back as OpenVMS V7.1. With the Alpha SRM console, some combination of SHOW CONFIG and SHOW DEVICE or such (at the >>> prompt) will provide platform and configuration details on the box. You should see a specific system name and specific system model.

Verify the hardware path out to the disk is correct, and correctly configured. Here, you can use the installation directions that are available for the various widgets to confirm that your particular combination is correctly configured.

Verify that the ECOs are current for V7.1 or whatever release is involved here. V7.1 had a *gazillion* ECO kits; so many that this release effectively begat the V7.1-2 release and its roll-up of ECOs and of a whole new and massively improved way of dealing with and of installing ECO kits on OpenVMS.

Verify version support for whichever hardware is involved here: http://h71000.www7.hp.com/openvms/hw_supportchart.html

You can use the QuickSpecs or such to verify controller-level support.

Enable boot-time diagnostics with a conversational bootstrap and setting STARTUP_P2 to P might help, and enable boot-time diagnostics with >>> boot -fl root,30000 or such.

Call HP to help decode register R0, if it's not the bad image header message nor something else involved here.

Here, if the disks are functional, I would not overwrite the contents. I'd use a known scratch disk (and preferably a local disk; not a FC SAN disk), install OpenVMS Alpha V8.3 on it, and see if I could sort out the configuration and boot issues from there.

Alternatively, you can call in some more formal and more experienced assistance for a direct look at the configuration and at the particular AlphaServer box. This could be HP support, or one of the various HP partners that specialize in OpenVMS.

[FernandoML]

Ok. HP is already working on it. Changing autoloaders will help us to backup disk 0 before any action.

We shall boot -fl 0,30000 to identify invalid image and probably try to install OpenVMS in local disk.

Tomorrow I will give you more information.
I really thank your support, it's incredible how this forum works.

[Volker Halle]

Fernando,

the %IMGACT-F-NOTNATIVE reason code in R0 indicates, that SYSINIT or one of it's shareable images is not an OpenVMS Alpha image. You can boot from CD and check those images...

This type of crash has also been seen when such an image is 'too fragmented' for the early boot phase (e.g. DECC$SHR.EXE after installing ALPACRT03_071).

Volker.

[FernandoML]

Hi all,
When booting -fl 0,30000 images not valid are these ones:
SYS$FILES_64.EXE
SYS$XFS_CLIENT.EXE
SYS$XFS_SERVER.EXE
SYS$LFS.EXE

We are now backing up one of the disks in order to install on that disk a new VMS to get those images and copy to the 0 disk.

[FernandoML]

Bad news, those images files are not on the new installation nor in the backup copies cartridges.

HP came and couldn`t do anything except helping to repair the autochanger.

[Duncan Morris]

Fernando,

you can ignore the errors with those files.

See

http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&cc=us&taskId=110&prodSeriesId=416077&prodTypeId=18964&prodSeriesId=416077&objectID=c00625969

Did you see any other problems?

Hoff's "Ask the Wizard" articles and Volker have both pointed to excessive fragmentation as possible issues.

Now that your autochanger is fixed, maybe you should try doing a full image backup and restore of the system disk.

Duncan

[FernandoML]

Ok. We'll stop looking for those files and ignore messages. No other errors appear to flow.

Recover on one of the disk from tape of 1999 resulted in no success as OS was of a former version. We have installed from CD in another disk (not in DCK0) a new OpenVMS 7.2 and works fine but we need to recover lots of configuration and procedures files as lots of products.

Before shuting down the system we made a system backup on one of the disk of the SW500 as the changer was offline.

Tomorrow we'll try to recover system from that copy on DCK105.

Last chance is to reinstall OpenVMS again and start from the begining looking for products and licenses but we are afraid to lose some of those products installed later.

Fernando.