topic Re: OpenVMS v7.3-2 Bugcheck: PROCGONE, Process not in system in Operating System - OpenVMS

OpenVMS v7.3-2 Bugcheck: PROCGONE, Process not in system

Matthew Booth — Tue, 20 Feb 2007 00:26:02 GMT

OpenVMS Alpha v7.3-2 Bugcheck: PROCGONE, Process not in system This happened after AXPVMS-VMS732_UPDATE-V0900 and AXPVMS-VMS732_TZ-V0300 was applied to my system disk in cluster. I need to back these products out to get my cluster back on it's feet. What's the proper procedure?

Please Help,
Thanks, Matt (VMS)

Re: OpenVMS v7.3-2 Bugcheck: PROCGONE, Process not in system

Karl Rohwedder — Tue, 20 Feb 2007 00:43:58 GMT

Matt,

if your system is up and running, PRODUCT UNDO PATCH would undo the latest patch (PROD SHO RECOV displays a list of applied patches).
But it seems, as if your system is crashing during boot, so you could:
- either boot a CD and restore the latest backup
- or boot a CD and try a PRODUCT UNDO PATCH/REMOTE (but read the help before, I never tried this myself)

regards Kalle

Re: OpenVMS v7.3-2 Bugcheck: PROCGONE, Process not in system

Matthew Booth — Tue, 20 Feb 2007 00:55:44 GMT

Hi Karl, Thanks for the quick response! Apparently giving each of my servers a time to rest has allowed them to boot back up?.. I suspect that some sort of lock was still hanging around on the patched system disk. I will investigate further later today.

Thanks,
Matt

Re: OpenVMS v7.3-2 Bugcheck: PROCGONE, Process not in system

Matthew Booth — Tue, 20 Feb 2007 00:57:20 GMT

The v7.3-2 Alpha server are now booting not sure why this is happening but for know I'm back up and running.

Matt

Re: OpenVMS v7.3-2 Bugcheck: PROCGONE, Process not in system

Hoff — Tue, 20 Feb 2007 12:24:24 GMT

It looks almost like something bumped into a VAX or I64 image somewhere, or something that caused the bootstrap to think it bumped into a VAX or I64 image.

R0 is an interesting value for a PROCGONE.

$ x=f$mess(%x04D8CFC)
$ sho sym x
X = "%IMGACT-F-NOTNATIVE, image is not an OpenVMS Alpha image"

From that value and from some digging in the OpenVMS source listings, you can sometimes find additional details left in R1 or other registers, or from pieces left around in the carcass; in the dumpfile.

There seems to be an image header buffer referenced in the carcass, and a look at that in the carcass might help determine what image was involved when the bootstrap tipped over.

Another option is to enable a "gonzo" R5 boot, with diagnostics enabled. There are a couple of bitflags in the middle of the APB R5 list of flags that turn on some serious boot-time diagnostic displays. b fl=0,3xxxxx or some such, would turns on both of the boot diagnostic flags. (Not sure about the number of zeros on that, but the FAQ has the defined bits. I'll queue an example for the next edition of the FAQ, since that particular bitflag combo is a go-to boot command.)

Stephen Hoffman
HoffmanLabs