> "Hello Everyone!"
Hi.
> "IT is my first message in that forum. I wuld like t thank you first because it is a usefull forum."
You are welcome. Please post more.
> "While the node boot we saw the following message"
> "sys$system:sys$dump.dmp status= 910 (cannot find file)"
>
> "But the file is there but the date is old"
> "dir SYSDUMP.DMP;1 /date /size"
>
> Directory SYS$SYSROOT:[SYSEXE]
>
> SYSDUMP.DMP;1 490518 29-NOV-2002 14:42:31.86
>
> Total of 1 file, 490518 blocks.
> "1/ how this file is create? "
When you install the system, autogen creates this dump file. But it almost always sizes it wrong. You only need to size sysdump.dmp once unless you add memory (sizing is a short topic unto itself.) Subsequent use of autogen, may alter the size further so I put a line such as "dumpfile=0" in modparams.dat to avoid this behavior.
> "1/ IS there any process who manage it(like for exemple the ERRFMT process manage the errorlog.sys)?"
As mentioned above, you can run autogen and unexpectedly change the size and create multiple versions of sysdump.dmp.
The answer to this question is that there is no detached process like errfmt. You are the one that manages sysdump.dmp.
> "2/ is the date okay? because we are now in may 2004 and the system rebooted"
It is fine. The size of the file is the important thing and where the dump file lives is too (yet, another topic).
> "3/How can we exalin the error during the reboot (my friend google didn't help ;0) and also all documentation on the web site)"
> Directory SYS$SYSROOT:[SYSEXE]
>
> SYSDUMP.DMP;1 490518 29-NOV-2002 14:42:31.86
Your post indicates a 9 node cluster. Your boot time error message indicates that the dumpfile is missing for one of the nodes.
From your directory display, notice that sysdump.dmp is in sys$sysroot. This is a unqiue directory for each node in the cluster.
Suggestion: You'll need to do the directory command from the same node that is giving the error message.
Better yet, you can display *all* the sysdump.dmp files by using the following directory commnand:
$ dire/date/size=all sys$sysdevice:[sys*.sysexe]sysdump.dmp
This should be enough information to solve the problem. If it isnt' . . .
To be absolutely complete, you'll need to get what are called dump_dev, bootdef_dev, and boot_osflags from each Alpha's console (the console being the >>> prompt when you shutdown/powerup a system). They are referred to as environment variables; these are just three environment variables and many more exist. In addition, you'll need to get the sysgen parameter dumpstyle from each node. Do the following for each node in the cluster preferably on OPA0 using the system account:
You can retrieve dump_style, bootdef_def, and boot_osflags by using the following commands (it should work on V7.2-1).
$ a=f$getenv("dump_dev")
$ sho sym a
$ a=f$getenv("bootdef_dev")
$ sho sym a
$ a=f$getenv("boot_osflags")
$ sho sym a
You can get the dumpstyle parameter by using the following commands:
$ mcr sysgen
use current
sho dumpstyle
exit
It is better to STQ then LDQ
