1) $INSTALL CREATE
2) $LINK (shared images).
3) $CRMPSC and $CRMPSC_GPFILE_64
The reason I am looking for information in these areas is complicated and I will try to go into details later on in this post. Checking out $INSTALL, $CRMPSC and $CRMPSCGPFILE_64 is pretty easy. I can get the doc's from VSI about them and compare it to the old HPe I64 doc's and look for anything that's different. Takes a bit of time, but essentially just a matter or reading/comparing the documentation. The Linker is totally different. The Linker documentation is essentially a book, not a couple of pages. Trying to figure out what might have changed is a bit more of a challenge, hence the whole reason to ask folks that may have had to change to compile/link share images on X86 vs I64.
Now for why I am looking to see if anyone has any pointers in these areas (the messy details).
When we started porting our system from HPe I64 to VSI x86 we came across 2 interesting issues.
The first was the system will crash. The actual error on OPAO: was/is "** Bugcheck code = 0000000DC: DELCONPFN, Fatal error in delete contents of PFN". We eventually traced this back to the use of $INSTALL CREATE <shared image> /share /open /header /resid. We create a shared image as part of our normal build process. Essentially we noticed the $INSTALL CREATE was throwing an error about needing the /shared command to be /shared=address_data. While playing with the $INSTALL command we finally figured out, all we have to do is issue the $INSTALL CREATE <image> /shared / open /header /resid and the /shared can be with or without =address_data and the system will crash the next time you log out. Simple and easy to reproduce, $INSTALL followed by $LOGOUT and watch the system crash on OPAO:. This system crash and all the messy details has been reported to VSI (SP-1285). As a follow up on our side, I just need to do the research to see if anything has changed on what we need to be doing in terms of compiling and linking our shared image. After looking at the $INSTALL command and it says we need to use /shared=address_data, does this imply any changes required in the link command or just the $INSTALL command which leads into what if any thing has changed into the $LINK party. Essentially, I need to verify/insure we are actually building/linking the shared image correctly. Once VSI resolves the $install issue, we want to be good to go on our end.
Now the second issue is when we start our system we create a couple (ok a lot) of global sections that we use to share data back and forth. Some of these global sections might be considered large (embarrassing large). We have noticed that from time to time while creating these sections, we experience a mount-verify-timeout on either the system disk DKA0: or DKA100:. We place all of our exes on DKA100: and the system resides on DKA0:. We do not specify a backing file for the global sections hence they are backed by the system page file (again an embarrassing large file). This could explain why DKA0: goes off line, but why DK100: goes off line is beyond me. As part of research into this situation, we have decided to move the page file from DKA0: to DKA100: and see if dka0: continues to go off line or its just dka100: now. The other part of this investigation is to go thru the grunt work and check to see if anything might have changed in $CRMPSC & $CRMPSC_GPFILE_64, hence question 3.
More messy details
HPe I64 - OpenVMS8.4, VMS84I-Update V11.0
VSI x86 - OpenVMS 9.2-1 with VMS921XUpdate V2.0. We saw both these issues with update V1.0 if it matter
First couple lines on the x86 OPA0: crash (again already reported)
Code: Select all
**** OpenVMS x86_64 Operating System V9.2-1 - BUGCHECK ****
** Bugcheck code = 000000DC: DELCONPFN, Fatal error in delete contents of PFN
** Crash Time: 24-OCT-2023 10:44:59.92
** Crash CPU: 00000000 Primary CPU: 00000000 Node Name: BBIRCH
** Highest CPU number: 00000001
** Active CPUs: 00000000.00000003
** Current Process: <No process name>
** Current PSB ID: 00000000
** Dumping error logs to the system disk (BBIRCH$DKA0:)
** Error logs dumped to BBIRCH$DKA0:[SYS0.SYSEXE]SYS$ERRLOG.DMP
** (used 52 out of 64 available blocks)
** Dumping memory to the system disk (BBIRCH$DKA0:)
Thank you
Rod
Also does anyone know of a way to recover from a mount-verify-timeout condition with out having to reboot the system?