We used to get a fair number of these back in the days of V5.n Have not seen it in ages though. Here's what I wrote up at the time, I think it covers all of the bases. Try the workaround I've laid out for you here and report back on the results please. /jeff
"RMS-F-RSZ" Error When ERRFMT Fails At Startup
COMPONENT: ANALYZE/ERROR Utility
SOURCE: Customer Support Center / USA
SYMPTOM:
During VMS startup after a reboot, the error formatter process ERRFMT
fails to start. VMS displays the following error messages on the
console:
%%%%%%%%%%% OPCOM %%%%%%%%%%%
Message from user SYSTEM on XXXXXX
ERRFMT - ERROR ACCESSING ERROR LOG FILE
%RMS-F-RSZ, invalid record size
%%%%%%%%%%% OPCOM %%%%%%%%%%%
Message from user SYSTEM on XXXXXX
ERRFMT - DELETING ERRFMT PROCESS
ERROR LOG FILE UNWRITEABLE
TO RESTART ERRFMT PROCESS, USE "@SYS$SYSTEM:STARTUP ERRFMT"
GENERAL ANALYSIS:
When a VMS system is shut down or crashes, VMS copies the error log
buffers from memory to disk. The buffers are copied to the system
dumpfile, SYS$SYSTEM:SYSDUMP.DMP, if the file exists. If it doesn't,
VMS writes the buffers to the primary pagefile on the system disk,
SYS$SYSTEM:PAGEFILE.SYS, if that file exists.
On reboot, the SYSINIT process looks for the SYSDUMP.DMP and the
PAGEFILE.SYS file on the system disk, and copies these error log
buffers from the first file it finds into the new error log buffers in
memory. Later, when STARTUP starts the ERRFMT process, the error log
buffers are copied from memory to the error log file,
SYS$ERRORLOG:ERRLOG.SYS.
If SYSINIT reads invalid data, either because the data is corrupt or
the file is new and has never had valid error log information written
to it, then the ERRFMT process aborts with the RSZ error when it tries
to read the data and copy it to the ERRLOG.SYS file.
The data can be invalid for either of these reasons:
ANALYSIS #1:
The data is corrupt; it may have been corrupt when copied or have been
corrupted later. This can occur if the disk has hardware errors.
SOLUTION #1:
Create a new version of the file, either SYSDUMP.DMP or PAGEFILE.SYS,
and reboot. When you create a new file, you no longer use the same
disk blocks, which may have become corrupt.
Create a file of the same size as the old one, but with the next
higher revision number. This example shows how to create a new
dumpfile; to create a new pagefile, substitute the filename
PAGEFILE.SYS.
$ DIR SYS$SYSTEM:SYSDUMP.DMP/SIZE=ALL ! get size/version number
SYSDUMP.DMP;n x blocks
$ RUN SYS$SYSTEM:SYSGEN
SYSGEN> CREATE SYS$SYSTEM:SYSDUMP.DMP;n+1 /SIZE = x
SYSGEN> EXIT
Reboot, so that VMS can identify the new file as the dump file. Then
purge the older version of the file.
CAUTION: Do not remove the old version until AFTER you reboot.
Otherwise further data corruption may occur.
If NO errors are reported for the disk, and if you already had a valid
dumpfile or pagefile, reboot the system again.
ANALYSIS #2:
VMS had not identified the file as a dumpfile before the previous
system boot. For example, if you create a new dumpfile, you must
shutdown and reboot for VMS to recognize it as a dumpfile. When you
shut down, VMS does not yet recognize the new dumpfile and so cannot
write the buffers to it. When you reboot, VMS does map the dumpfile
and so tries to read the buffers from it. Because the buffers are not
in the file, VMS just reads whatever random bit patterns are at the
buffer location. The random data often triggers the RSZ error.
SOLUTION #2:
If you created a new file, either SYSDUMP.DMP or PAGEFILE.SYS, and
rebooted so that VMS could map it as a dumpfile, then reboot again.
During this next shutdown, VMS writes valid data to the file.
ANALYSIS #3:
The dumpfile is restored from a backup, either as an individual file
or as part of restoring an image backup. The dumpfile is usually
marked "Backups disabled", as seen in a DIRECTORY/FULL of the file.
BACKUP does not save the file contents of such a file, but it does
save the file header information. During a restore operation, BACKUP
re-creates this file based on the information in the file header,
allocating enough disk space so the file is the same size as before.
The allocated disk blocks do not contain dumpfile information, so the
error formatter may not be able to read them, and it fails with the
RSZ error.
SOLUTION $3:
Reboot twice after restoring the dumpfile. During the first reboot,
VMS maps the file as a dumpfile. During the second shutdown VMS
writes valid data to the file, so the error formatter can read it
during the second reboot.
ANALYSIS #4:
The disk might have hardware errors.
SOLUTION #4:
If the error persists, examine the disk for hardware errors:
$ SHOW ERROR
Call your Field Service Representative to further investigate any
reported errors.
le plus ca change...
