Updated: 24-SEP-2003 (Use your browsers' Reload button to ensure you're viewing the most recent version)
VAXRMS04_061 VAX V6.1 RMS/CONVERT ECO Summary
Copyright (c) Digital Equipment Corporation 1996. All rights reserved.
OP/SYS: OpenVMS VAX
COMPONENT: RMS.EXE
CONVERT.EXE
CONVSHR.EXE
RECLAIM.EXE
RECOVER.EXE
RMSREC$SERVER.EXE
SOURCE: Digital Equipment Corporation
ECO INFORMATION:
ECO Kit Name: VAXRMS04_061
ECO Kits Superseded by This ECO Kit: VAXRMS03_061
VAXRMS02_061
VAXRMS01_061 (CSCPAT_1181)
ECO Kit Approximate Size: 774 Blocks
Kit Applies To: OpenVMS VAX V6.1
System/Cluster Reboot Necessary: Yes
NOTE: It is strongly recommended that this kit be applied immediately
after any system is upgraded to OpenVMS VAX V6.1 before
production activity begins on the system.
ECO KIT SUMMARY:
An ECO kit exists for RMS/CONVERT on OpenVMS VAX V6.1. This kit
addresses the following problems:
Problems addressed in VAXRMS04_061 kit:
o Fix for compressed primary key problem that occurs in the
context of record deletes being done using sequential access
rather than keyed access.
Sequentially walking through (accessing) the primary data records
in an indexed file (primary key is a string key with key
compression enabled), a delete is done of one of the records.
The following error may be returned when an attempt is made to
sequentially access the next record:
RMS-F-BUG, fatal RMS condition, process deleted.
The file is not left corrupted. A convert of the file will
leave the file in a consistent state.
This problem is fixed in OpenVMS VAX V7.1.
o Make last chance handler more robust when a process that has file
opened with global buffers enabled is terminated with STOP/ID.
STOP/ID invokes the RMS abort last chance handler (RM$LAST_CHANCE).
Problems addressed include:
o A potential deadlock in the RMS last-chance handler if the
same file is open more than once within a process or
subprocess and it has global buffers set on it.
o A potential fatal KRNLSTAKNV system crash due to nonfatal
RMS bugchecks from failing $GETLKI calls which cause error
rundown recursion until the stack fills up.
These problems are fixed in the OpenVMS VAX V7.1.
NOTE: Until the system can be upgraded to OpenVMS Alpha V7.1
or this remedial kit can be installed, these symptoms may be
avoided by refraining from the use of the 'STOP/ID' DCL command.
Instead, if a process needs to be terminated, (which should be
a rare event), use a program that does a $FORCEX, waits a few
seconds, and then does a $DELPRC.
o Fix for RMS bugcheck NOTLOCKED (R2=FFFFFFEF) on shared sequential file.
Process is delivered blocking AST to release file lock. Before
releasing file lock, it has to release the lock it holds on EOF buffer.
NOTLOCKED bugcheck is returned if process is holding PW (protected
write) rather than EX (exclusive) lock on EOF buffer. The check
should be for either EX or PW lock.
This problem is fixed in OpenVMS VAX V7.1.
o Fix for loop when deleting network logical links. Loop occurs
at EXEC-MODE AST level and the process cannot be deleted. Process
in loop will be an application that does network operations.
RMS maintains a process cache of recent logical links for a
period of time in an attempt to reuse them and save on image
and process activations. When a link becomes inactive and is
added to the cache, RMS deletes any links in surplus of three.
In walking the link cache queue to delete these links, there is
a potential race condition that could result in a stale pointer
being used after a stall, which leads to the loop.
This problem is fixed in OpenVMS VAX V7.1.
o Autoextend fix for shared block I/O write which requires use of
UPI option -- which disables any locking (file or EOF bucket).
For this particular case with no locking synchronization, it is
possible if two or more processes or two or more asynchronous
streams are writing to a file, that two or more autoextends may
occur concurrently. Though the file system will do the extends
synchronously, the processing of the extend result may complete
out of sequence and result in RMS bugcheck FTL$_BADEBKHBK
(R2=FFFFFFDC).
This problem is fixed in OpenVMS VAX V7.1.
o Fix for possible client/server hang in detached RU recovery
server. Given the right series of coincidences, both a client
RMS process and the detached RU recovery server process can
hang when the client accesses a file on which there is an open
RU transaction.
This problem is fixed in OpenVMS VAX V7.1.
o Non-indexed file opened with an indexed file XAB may ACCVIO.
If a non-indexed file (sequential or relative) is opened with
one or more XABs specific to indexed files (XABKEY, XABSUM, or
XABALL) chained to the FAB, the process may either:
o Terminate (SYSGEN parameter BUGCHECKFATAL not enabled) with
an access violation (ACCVIO); or
o Crash the system (BUGCHECKFATAL enabled) with a SSRVEXCEPT
ACCVIO.
A necessary condition for this to occur is that the virtual
address space used for the program region (P0) must be more
than half a gigabyte. In other words, it requires both a very
large application and one that has indexed XABs chained to the
FAB for a non-indexed file. We are aware of only one
application that this problem has occurred with to date:
ALL-IN-1.
This problem is fixed in OpenVMS VAX V7.1.
o Fix to detect outlier XAB area on indexed file open. RMS-F-AID
error (invalid area ID) was not reported on the open of an
indexed file with an XABALL declaration that has an area ID
that is exactly one greater than the maximum number of areas in
that indexed file. A check has been added for record I/O
access. Block I/O access is excluded from this check.
This problem is fixed in OpenVMS VAX V7.1.
o Fix for SDA-W-FAOERR when displaying RMS FWA (File Work Area).
The contents of a buffer (LOGNAM) are being displayed after the
space have been returned and reallocated for some other use.
This problem is fixed in OpenVMS VAX V7.1.
o Statistics setting on a file is lost from the FDL produced by
ANALYZE/RMS/FDL. File monitoring is always set to 'no' whether
it is enabled or not. The problem is not with ANALYZE[/RMS],
but with RMS's processing of an XABITM list.
This problem is fixed in OpenVMS VAX V7.1.
Problems addressed in the VAXRMS03_061 kit:
o Make last chance handler more robust to re-entry to avoid
potential system crash when process that has file opened with
global buffers enabled is terminated with STOP/ID.
STOP/ID invokes the RMS last chance handler (RM$LAST_CHANCE).
The last chance handler was written with the assumption that it
will be called exactly once during any process rundown. An
example of this assumption is the dequeuing of the global
buffer header (GBH) lock, though the pointer to it is not
cleared.
Evidence from several recent crash dumps suggests that it may
be possible for a STOP/ID to result in the last chance handler
being entered more than once. If this happens and the process
being stopped has global buffers enabled on one or more files,
a fatal KRNLSTAKNV system crash may result due to nonfatal RMS
bugchecks from failing $GETLKI calls which cause error rundown
"recursion" until the stack fills up.
This problem is corrected in OpenVMS VAX V7.0.
o If one of the files being closed by the RMS abort rundown
procedure has global buffers set on it and there is an
end-of-file (EOF) sublock associated with the system-owned
global buffer header (GBH) parent lock, then the EOF sublock
should be dequeued as part of rundown. Without the fix an
incorrect branch instruction results in a $DEQ being done if
the lock-id is zero (SS$_INVLOCKID returned) rather than
nonzero.
This problem is corrected in OpenVMS VAX V6.2.
o Quota borrowing implemented for RMS internal AST to avoid an
RMS bugcheck. An RMS process that's operating at ASTLM may
bugcheck on an AST generated internally by RMS for rescheduling
execution. This extra AST is currently charged against the
user's ASTLM.
This problem is corrected in OpenVMS VAX V6.2.
o This fix addresses several synchronization problems with $WAIT
on a FAB:
o Status is currently cleared on the initial entry to $WAIT
checking.
o $WAIT on a $CLOSE does not wait.
These problems are corrected in OpenVMS VAX V6.2.
o An update to the end-of-file for a sequential file with an
undefined (UDF) record format inappropriately rounds the first
free byte (FFB) up to an even number. This results in the last
record, if an odd size, containing one more byte than it
should.
This problem is corrected in OpenVMS VAX V6.2.
o Add check of extend values returned in FIB by file system.
A check has been added to the RMS code to test the assumption
that if the file system (XQP) returns no error for an
autoextend, the values returned in the FIB (FIB$L_EXSZ and
FIB$L_EXVBN) result in an increase in the size of the HBK. If
FIB$L_EXVBN) result in an increase in the size of the HBK. If
there is an increase (as expected), then the HBK in the IFAB is
updated. If there is no increase, an RMS bugcheck
(FTL$_BADEBKHBK) is returned and the process is terminated.
This check was added to guard against the possibility of an
infinite loop that might occur under the remote circumstance of
the XQP failing to update the FIB values for a successful
extend operation in the context of a process in an overdrawn
quota state.
This problem is corrected in OpenVMS VAX V6.2.
o Fix added to change dangling SIDR error status from RMS$_BUG to
RMS$_RNF.
This fix changes the handling of a dangling SIDR pointing to a
nonexistent record from an RMS$_BUG status to a status of
RMS$_RNF. Also a cleanup of the SIDR element is done if the
process doing the $GET (or $FIND) has WRITE access to the file.
If a process has any modified buckets whose writeback to disk
has been deferred (deferred-write option) when a power failure,
system crash or a STOP/ID occurs, the indexed file may be left
with a secondary index data record (SIDR) pointing to a
nonexistent primary data record. This can happen when some
other process has requested through the lock manager access to
a modified SIDR data bucket but not the primary data bucket.
This request triggers a blocking AST to writeback the SIDR
bucket to disk. If the process with the modified buckets
closes the file or exits normally thereafter, then any
remaining modified buckets are written back to disk and now the
SIDR points to a primary data record that exists in the "disk"
file. It is the combination of both deferred-write and the
rare event of a power failure, system crash or a STOP/ID that
may leave an indexed file with this inconsistency. (Note that
enabling RMS RU journaling automatically enables
deferred-write.)
If a subsequent $GET or $FIND via a secondary key attempts to
retrieve a nonexistent primary data record pointed to by a
dangling SIDR, then without this fix an RMS$_BUG status (with
an associated RAB$L_STV of RMS$_RNF) will be returned.
Although the text of the message associated with RMS$_BUG
indicates the process has been terminated, in the case of a
dangling SIDR, this is not true. Even though the process is
not terminated, a side-effect of handling this condition as a
bugcheck is that the internal context for the record operation
(IRAB) is not updated. The result of this is that it is
impossible for a process to recover from this error.
RMS$_BUG is a status returned for a broad spectrum of
conditions that RMS views as suggesting some risk in continuin
any further processing. In its regular use of RMS$_BUG, it
identifies the specific condition associated with the bugcheck
in R2 and does in fact terminate the process. In the case of a
dangling SIDR pointing to a nonexistent record there is no risk
in continuing.
The handling of the error status varies depending on whether
the dangling SIDR is encountered as part of an exact match
keyed access rather than either a sequential access or a
NXTEQ/NXT keyed access:
o Exact match keyed retrieval
Status (RMS$L_STS) of RMS$_RNF is returned. RNF is a
status routinely checked for by existing applications so
this change will not require modification of existing
applications. In addition a nonzero status value is
returned in the status value (RAB$L_STV) to indicate the
special case of a dangling SIDR pointing to a record-id
that is inconsistent with the information in the primary
data bucket header. Except for this condition, a status of
RMS$_RNF will continue to have a status value of zero
associated with it.
This has the advantage of conveying the information to the
user that this special case of a dangling SIDR has occurred
while allowing the application to continue. Applications
can build into the design of any exact keyed retrievals via
a secondary key, checking the associated status value and
signaling it when it is nonzero, if they so choose, or
simply displaying an informational text message and
continuing.
o sequential access or NXTEQ/NXT (KGE/KGT) keyed retrieval
No explicit status will be returned to the user. When this
condition is detected, RMS silently advances to the next
SIDR element or array attempting to find the next
"non-deleted" primary data record via the secondary key.
This problem is corrected in OpenVMS VAX V6.2.
o Fix for relative file fixed record format file.
This problem is restricted to a relative file with a fixed
length record format that has global buffers enabled on it. An
improper move instruction (MOVW that has been corrected to
MOVZWL) was used to move maximum record size (word in length)
into a register for relative file with fixed length record
format. This register has always been clear so to date it
causes no problem on a VAX system. To ensure that it never
becomes a future problem, it was corrected in OpenVMS VAX V6.2.
o A key-greater-than $get or $find to a newly created indexed
file that has not had a single record added to it (primary
index is uninitialized) returns a RNF (record not found) error
to user.
A key-less-than $get or $find to a newly created indexed file
that has not had a single record added to it (primary index is
uninitialized) returns an IDX (index not initialized) error to
user.
While strictly speaking the errors could be different for the
two cases, this requires different handling by the user. The
error reported to the user for a key-less-than $get or $find in
the case of a newly created file that has never had any records
added to it (index is uninitialized) has been changed to be
consistent with the error reported under the same circumstances
for a key-greater-than $get or $find. Specifically, the error
that will now be reported for both cases will be RNF (record
not found).
This change was made in OpenVMS VAX V6.2.
o RMS-F-AID error (invalid area ID) is not reported on the open
of an indexed file with an XABALL declaration that has an area
ID that is exactly one greater than the maximum number of areas
in that indexed file.
If FDL$GENERATE is used to generate an FDL from this file open,
a bad area definition in the FDL will be created.
This problem is corrected in OpenVMS VAX V7.0.
o An ISAM RMS nonfatal bugcheck is returned by RM$EXPAND_KEY
(module RM3PCKUNP). This bugcheck is forced if key expansion
for the deletion of a secondary index data record (SIDR) would
overflow a SIDR data bucket.
The current problem occurs in the context of an $UPDATE that
changes a secondary key value (with key compression enabled) if
both the SIDR data bucket freespace is exactly equal to the
bucket size minus one and the key expansion of the next SIDR
record (if any) results in a gain in bytes exactly equal to the
number of bytes to be deleted. For both conditions to be
satisfied makes the probability of this problem's occurrence
extremely rare.
The update to the primary record will have been completed; the
problem occurs during the delete operation to remove the old
secondary key value after the new updated secondary key value
has been added. The file is not left corrupted. A convert of
the file will rebuild the secondary indexes and leave the file
in a consistent state.
This problem is corrected in OpenVMS VAX V7.0.
o Fix for a SIDR (secondary index data record) compressed key
expansion problem that could result in a corrupted SIDR bucket.
The conditions that are required make the probability of its
occurrence extremely rare.
For this problem to occur requires both (1) the presence of
many duplicate records for a secondary key, (2) a secondary key
of string type that is 9 bytes or more in length, and (3) a
very particular key pattern which results in a number of bytes
at the front of the key being compressed. The problem occurs
in the context of a bucket split when the current design moves
an entire SIDR array into a new bucket. It is possible that
when the compressed secondary key for that SIDR array is
expanded in its position as the first record in the new bucket,
it may grow larger than the bucket.
ANALYZE/RMS_FILE will most likely report the following error:
"Invalid first free byte offset in bucket header." Since the
problem is with a secondary key bucket, a convert will recover
all the data records in the corrupted file.
This problem is corrected in OpenVMS VAX V7.0.
o Fix to $TRUNCATE for zero-byte record problem for STREAM_LF
sequential file.
The RMS service $TRUNCATE does not properly handle a zero-byte
record in a STREAM_LF file. Truncating a STREAM_LF file after
reading a zero-byte record will fail with an RMS-F-CUR (no
current record) error. This problem is restricted to a
sequential file with a STREAM_LF record format.
This problem is corrected in OpenVMS VAX V6.2.
o Running APL (which creates a system logical name that points to
the terminal) and then stopping (STOP/ID) the process results
in the terminal being unavailable. Subsequent attempts to
login to this terminal fail. This is due to the channel not
being properly deassigned.
This problem is corrected in OpenVMS VAX V6.2.
Problems addressed in the VAXRMS02_061 kit:
o Under DECnet/OSI, an RMS process issuing $WRITEs to a remote node
which encounters a non-continuable error (such as, device-full)
may hang along with the remote FAL. An example is using BACKUP
on a Phase V node to write a saveset to another node (which may be
Phase IV or Phase V) when the remote device becomes full.
NOTE: This problem only occurs when the $WRITEs are issued on a
Phase V node.
This problem is corrected in OpenVMS VAX V6.2.
o Fix added to transparently recover a global buffer descriptor
(GBD) if it becomes lost to the GBD queue associated with an RMS
global buffer section. A prerequisite of a GBD becoming lost
is not only that a STOP/ID is done of a process that is "actively"
doing something to a file that has global buffers set on it but
also that the kernel-mode STOP/ID interrupts a very specific
activity (between the removal and reinsert of a GBD into a queue),
which occurs within a very small window.
This problem is corrected in OpenVMS VAX V6.2.
o If the data bucket pointed to by the level 1 "high key" index value
for a duplicate key (primary or secondary) has one or more
continuation buckets chained to it and the last bucket is full,
under rare conditions a race condition may occur when two processes
are concurrently adding (putting) records to a duplicate key, each
with a key value higher than the highest key value currently stored
in the file.
Symptoms of this problem are:
+ If the index is compressed, an infinite loop will occur due to
an attempt to add a duplicate entry to the level 1 index
bucket.
+ If the index is not compressed, a duplicate entry will
successfully be added to the level 1 index bucket.
NOTE: An index bucket should never have a duplicate entry for
any index value.
This can result in:
+ Records in the level 0 data chain being out of sorted order.
+ Records being hidden from a keyed lookup though visible
with a sequential scan.
This problem is corrected in OpenVMS VAX V6.2.
o Heavy concurrent INSTALL and F$FILE_ATTRIBUTE usage may cause
locking conflicts accessing the KFE (Known File Entry) list
which can result in a bad KFE pointer being handed to RMS leading
to an Access Violation (ACCVIO).
This problem will be corrected in a future release of OpenVMS VAX.
o Incomplete security success audit information may be generated upon
image activation of installed /OPEN images.
This problem will be corrected in a future release of OpenVMS VAX.
o When converting a VFC-format file to a fixed-format file using the
/PAD qualifier, the following error may occur:
%LIB-F-BADBLOADR, bad block address
The problem is restricted to a convert job that involves an input
file with a VFC record format that is being converted to an output
o When trying to convert an input file with an "undefined" record
format, the following error may occur:
%LIB-F-BADBLOADR, bad block address or %FDL-E-INVBLK, invalid
RMS control block at virtual address nnnnnn
This problem is corrected in OpenVMS VAX V6.2
o If callable convert (CONV$CONVERT preceded by CONV$PASS_FILES and
file with a fixed record format using the /PAD qualifier.
This problem will be corrected in a future release of OpenVMS VAX.
o When trying to convert an input file with an "undefined" record
format, the following error may occur:
%LIB-F-BADBLOADR, bad block address or %FDL-E-INVBLK, invalid
RMS control block at virtual address nnnnnn
This problem is corrected in OpenVMS VAX V6.2
o If callable convert (CONV$CONVERT preceded by CONV$PASS_FILES and
CONV$PASS_OPTIONS) is called multiple times with the FDL option
enabled in an earlier call and disabled in a later call, the call
may fail with the following error:
%CONV-F-OPENOUT, error opening <file-name> as output
-RMS-F-MBC, invalid multi-block count
This problem is corrected in OpenVMS VAX V6.2
Problems addressed in the VAXRMS01_061 kit:
o Sometime after upgrading to OpenVMS V6.1, a user tries to
access their mail file (named MAIL.MAI by default) and finds
that it is corrupted. Any of the following errors may be
returned when the corruption is encountered:
- RMS-F-IRC, illegal record encountered; VBN or record number = nn
- MAIL-W-WRITERR, error writing 'file-spec'
- MAIL-F-CODERR, internal coding error. Please submit an SPR.
An ANALYZE/RMS of the mail file returns the following errors:
*** VBN nn: Data record spills over into free space of bucket.
Unrecoverable error encountered in structure of file.
Prior to noticing the corruption a CONVERT/RECLAIM has been
performed on the mail file via one of the following methods:
+ If AUTO_PURGE is enabled or a PURGE command issued and more
than 32767 bytes of deleted messages have accumulated, Mail
will automatically perform a CONVERT/RECLAIM on the user's
behalf.
+ The user issues a PURGE/RECLAIM in Mail.
+ A CONVERT/RECLAIM MAIL.MAI command is issued at DCL.
Any new mail messages received after the corruption occurs may
be orphaned. This occurs because the external mail file
(MAIL$xxx.MAI) is created before the entry into the mail file
(MAIL.MAI) fails.
This problem is corrected in OpenVMS VAX V6.2
o The CONVERT/RECLAIM Utility 1 may cause a secondary index data
(SIDR) bucket to be left in a state which may subsequently
cause the file to become corrupted. This occurs only under
certain circumstances.
An attempt to read or add another record to an indexed
sequential (ISAM) file returns the following error:
RMS-F-IRC, illegal record encountered; VBN or record number = nn
An ANALYZE/RMS of the above file or another ISAM file reports
the following errors:
*** VBN nn: Data record spills over into free space of bucket.
Unrecoverable error encountered in structure of file.
The file has multiple keys with at least one of the secondary
keys allowing duplicates. Prior to these errors, a
CONVERT/RECLAIM has been performed on the file.
This problem is corrected in OpenVMS VAX V6.2
o When converting a record from any record format without FORTRAN
carriage control (in any type of file organization) to a
fixed-length record format with FORTRAN carriage control, the
last character from the input record may be overwritten by the
pad character if the record is short and requires padding.
This problem is corrected in OpenVMS VAX V6.2
RELATED ARTICLES:
Detailed articles describing the problems listed above may exist in
the OPENVMS databases. To view these articles, open the appropriate
product database and perform a query using either of the following
search strings: 'VAXRMS04_061' or 'VAXRMS'.
ECO KIT ORDERING INSTRUCTIONS:
If after an evaluation you wish to obtain this kit, request it
electronically using the appropriate Advanced Electronic Services
(AES) Service Tool. If you are not familiar with how to request
kits electronically, open the DIA, WIS or DSNLINK database and
review the article entitled:
[AES] How To Electronically Request ECO Kits Using Service Tools
INSTALLATION NOTES:
In order for the corrections in this kit to take effect, the system
must be rebooted. If the system is a member of a VAXcluster,
the entire cluster should be rebooted.
It is strongly recommended that this kit be applied immediately
after any system is upgraded to OpenVMS V6.1 before production
activity begins on the system. Once the kit is applied, no data
files thereafter using Convert/Reclaim will be left with unreclaimed
buckets with a freespace of hex '0E'; therefore, the Convert/Reclaim
problem listed above will not occur.
If this kit is applied after there has been some production activity on
a V6.1 system, the remedial images in this ECO will not correct any
files that already contain any buckets with a freespace of hex '0E'. A
full convert (CONVERT infile outfile) is needed to take care of this.
In other words, once this kit is applied, a file can experience the same
corruption thereafter if Convert/Reclaim was used on it prior to
applying this kit and it was not converted after the kit was applied.
Users should not rely on an ANALYZE/RMS revealing an error since the
right conditions leading to the corruption may not have occurred yet.
For those who are already using OpenVMS V6.1, once the remedial kit
has been applied, they should recommend to all their users that
performing a full convert at a convenient time is advisable on any
MAIL.MAI files or any other data files with which Convert/Reclaim
may have been directly used since upgrading to OpenVMS V6.1. A
precautionary convert will preclude the possibility of an untimely
occurrence at some future time.
NOTE: If the previous version of this ECO, VAXRMS01_061 (CSCPAT_1181),
was applied and if necessary, the recommendation listed about
was followed, it should not be necessary to follow this
recommendation again after this ECO is installed. The issue
with CONVERT/RECLAIM was initially addressed with
the VAXRMS01_061 ECO.
==========================================================================
| Table of Kit Image Information |
+----------------------------+----------+-----------------+--------------+
| | Overall | Image File | Image Link |
| Image Name | Checksum | Identification | Date/Time |
+----------------------------+----------+-----------------+--------------+
| CONVERT.EXE |%XF570BDAA| X-3 | 29-AUG-1995 |
| | | 16:57:33.20 |
+----------------------------+----------+-----------------+--------------+
| CONVSHR.EXE |%XECA230D3| X-1 | 29-AUG-1995 |
| | | 16:55:22.81 |
+----------------------------+----------+-----------------+--------------+
| RECLAIM.EXE |%XD82CED0E| X-3 | 29-AUG-1995 |
| | | 16:57:40.08 |
+----------------------------+----------+-----------------+--------------+
| RECOVER.EXE |%X9A02F0C0| X-3 | 13-JAN-1997 |
| | | 07:39:32.81 |
+----------------------------+----------+-----------------+--------------+
| RMS.EXE |%XABECEA53| RMS | 19-DEC-1996 |
| | | 15:48:04.10 |
+----------------------------+----------+-----------------+--------------+
| RMSREC$SERVER.EXE |%X45054338| X-3 | 13-JAN-1997 |
| | | 07:39:36.41 |
+----------------------------+----------+-----------------+--------------+
|
