<record id X control statements>
<record id Y control statements>
<record id Z control statements>
The record definition file consists of control statements.
Each statement has two fields: the "command field" that contains the
record definition command that identifies the remainder of the data
and the "specification field" that contains all of the
parameters and arguments required by a particular control command.
The specification field may span multiple lines. The terminator of a
specification field is another command. Commands must
be the first character of a line with no preceding white space (i.e., they
must start at column 1). Comments can be embedded within the
specifications field by using braces { }.
_________________________________________________
| | |
Command Field Specification Field
The following example should clarify these concepts:
COMMENT The "COMMENT" is a record definition command.
The body of the comment is called the specification
field (that is what you are reading now). Notice that
this field can span as many lines as desired.
A new control command ends the specification field.
RECORD`ID 23 {This is a comment too}
COMMENT The above line has "RECORD`ID" as the Command
and "23" as the specification field.
On MPE/iX, the record definition file can be created with any editor, but
must be kept as a Fixed ASCII 80-Byte Unnumbered file.
Syntax:
COMMENT <anything may follow>
Example:
COMMENT This is a comment.
It spans several lines.
Syntax:
RECORD`ID <record id #>
Notes:
RECORD`ID numbers must be between 0 and 255.
Examples:
RECORD`ID 1
RECORD`ID 123
TYPE my_record = RECORD
field1 : integer;
CASE select : boolean OF
true : (true_case : some_other_type);
false : (false_case : yet_another_type);
END;
It has a tag field called "select" and two possible variant parts.
Each of the two variant parts would need a TAG`ID entry (with additional
record definition commands) to define the variant part. The
specifications field indicates which RECORD`ID this TAG`ID is to be
used with. For more details, see the section called
Tag Usage Example.
Syntax:
TAG`ID <record id # this definition is used with>
Examples:
TAG`ID 100
RECORD`LENGTH
N`FIELDS
RECORD`LABEL
FIELD`FORMATS
The RECORD`LENGTH and N`FIELDS commands must be provided
before any of the other commands. For a TAG`ID definition, the
VARIANT command is required.
Syntax:
RECORD`LENGTH <# of bits>
Notes:
The maximum number of bytes is 2028.
Example:
RECORD`LENGTH 220
Syntax:
N`FIELDS <# of fields>
Example:
N`FIELDS 5
Syntax:
RECORD`LABEL "<name>"
Example:
RECORD`LABEL "I/O"
RECORD`LABEL
| JUNK | Typically a reserved field and is not formatted. (Don't include VALUE`LABEL or VAR`LABEL entries for this type). |
| INTEGER | Numeric data. It may be displayed in any of the popular bases (2,8,10,16). Currently a maximum of 64 bits is allowed. |
| ASCII | ASCII<\esc> data. The full specified bit count will be displayed. |
| STRING | A PASCAL string. [Length information in the front]. Only the valid characters in the string will be printed. |
For the present, assume PASCAL/MODCAL strings are of the following format:
[current length] [ASCII data] [String trailer]
|__________________|___________________|__________________|
| | |
String Overhead String Data String Overhead
The current length field requires 32 bits.
String trailer requires 32 bits.
| |
| ARRAY | An array of data. The specified number of
bits (rounded up to the nearest byte count) will be displayed in HEX AND
ASCII (if the character is valid) - something like the following:
XX XX XX XX XX XX XX XX ..hello.. XX XX XX XX XX XX XX XX ..w....4. |
| MPEXLSTAT | Specifies this field to be interpreted as an MPE/iX Operating System status. LOGTOOL will display a text message from the system message catalog corresponding to the value obtained. If a message cannot be found in the catalog, the value will be displayed in the report. This type requires that the <#bits> parameter given is 32. |
| LLIOSTAT | Specifies this field is to be interpreted as an MPE/iX Low Level I/O status. LOGTOOL will display a text message from the system message catalog corresponding to the value obtained. If a message cannot be found in the catalog, the value will be displayed in the report. This type requires that the <#bits> parameter given is 32. |
| TIME | Specifies this field is to be interpreted as a timestamp produced from the CLOCK intrinsic. The time obtained will be obtained in a native Language format. This type requires that the <#bits> parameter given is 32. |
| DATE | Specifies this field is to be interpreted as a datestamp produced from the CALENDAR intrinsic. The date will be displayed in a native Language format. This type requires that the <#bits> parameter given is 16. |
| HARDSTAT | This specifies that this field is to be interpreted as device hardware status. The hardware status bytes found in this field will be translated into text form. This type can only be successfully used for the I/O ERROR (111) record type. Use of this type for any other record id will produce unpredictable results. |
| DIAGSTACK | This specifies that this field is to be interpreted as a diagnostic error stack. The diagnostic error stack found in this field will be translated into text form. This type can only be successfully used for the DIAGNOSTICS (150) record type. Use of this type for any other record id will produce unpredictable results. |
Syntax:
FIELD`FORMAT <field list>
<field list> ::= <repeat factor> (<field def>) |
<repeat factor> (<field def>) <field list>
<repeat factor> ::= an integer | <nil>
<field def> ::= <#bits>, JUNK |
<#bits>, STRING |
<#bits>, ARRAY |
<#bits>, ASCII |
<#bits>, LLIOSTAT |
<#bits>, MPEXLSTAT |
<#bits>, TIME |
<#bits>, DATE |
<#bits>, INTEGER, <base> |
<#bits>, INTEGER, <base>, TAG, <#bits>
<#bits> ::= 0 .. 16256
<base> ::= 2 | 8 | 10 | 16
Notes:
FIELD`FORMAT 2(32,INTEGER,16) (160,ASCII)(3,INT,8)(13,JUNK)
(64,STRING) (64,ARRAY) (12,INTEGER,10,TAG,20)
- TWO (2) 32 bit integer fields printed in HEX
- 160 bits (32 chars) of printed in ascii.
- A 3 bit integer printed in octal
- 13 bits of junk which it not printed
- A 64 bit (8 char max) string - only valid chars printed.
- A 64 bit (8 bytes) array printed as HEX/ASCII
- A 12 bit integer tag field printed in decimal
20 additional bits [identified by the tag] follow.
A TAG`ID must be used to describe the data.
Syntax:
VAR`LABELS <label def>
<label def> ::= <label index> "<label>" <label def> |
<label index> "<label>" | <nil>
<label index> ::= [ <field#> ]
<label> ::= ASCII<\esc> text (up to 20 chars)
<field#> ::= an integer
Notes:
VAR`LABELS [ 1 ] "Name for field 1 : "
[ 2 ] "field 2 name : "
[ 4 ] "field 3 is unlabeled"
Syntax:
VALUE`LABELS <label def>
<label def> ::= <label index> (<label list>) <label def> | <nil>
<label index> ::= [ <field#> ]
<label list> ::= <value range>, "<label>" |
<value range>, "<label>" ; <label list> | <nil>
<value range> ::= <value> | <value>/<value>
<value> ::= an integer
<label> ::= ASCII<\esc> text (up to 20 chars)
<field#> ::= an integer
Notes:
VALUE`LABELS [ 2 ] (1, "one"; 2, "two"; 3, "three")
[ 3 ] (-1, "Unlimited"; 1/14 "Half power")
[ 8 ] (-32768/-1, "Negative";
0/32767, "Positive")
FIELD`FORMAT (8,INT,10,TAG,64)
In this example, we have an 8-bit tag field (to be printed in decimal)
followed by 64 bits of variant data. The VARIANT command will
identify the RECORD`ID that the current TAG`ID is to be used with
by a field number and value range. The VARIANT command will identify
the TAG`ID containing a tag data type by a list of field number and
value range pairs, which will specify the path to the current TAG`ID.
Error checking is performed to ensure that only TAG data types have variants. The value associated with a tag is not limited to a single value, but a range of values may be specified for a tag. All ranges must be unique and may not overlap with any other value or range.
Syntax:
VARIANT <variant def>
<variant def> ::= <label index> ( <variant list> ) <variant def> | <nil>
<label index> ::= [ <field#> ]
<variant list> ::= <value range>
<value range> ::= <value> | <value>/<value>
<value> ::= an integer
<field#> ::= an integer
Examples:
VARIANT [ 1 ] (1/100)
[ 3 ] (-5 ) {This example is for a TAG`ID which
has a variant field}
TYPE
some_other_type = integer; { 32 bits }
yet_another_type = RECORD
count : integer; { 32 bits }
name : string[4]; { (4 " 8 bits) + 64 bit overhead }
CASE stuff : integer OF { 32 bits }
0 : ( f1 : integer ); { 32 bits }
1 : ( f2 : bit8 ); { 8 bits }
END; { SIZEOF = 192 bits }
YET_ANOTHER_TYPE MAX RECORD SIZE = x18 BYTES
COUNT x0.0 @ 4.0
NAME x4.0 @ C.0 <- Note compiler added
32 bits for string
header and 32 bits
for string trailer.
STUFF x10.0 @ 4.0
F1 x14.0 @ 4.0
F2 x14.0 @ 1.0
my_record = RECORD
field1 : integer; { 32 bits }
CASE select : boolean OF { 8 bits + 12 bits pad}
true : (true_case : some_other_type); { 32 bits }
false : (false_case : yet_another_type);{ 192 bits (max) }
END; { SIZEOF = 256 bits }
MY_RECORD MAX RECORD SIZE = x20 BYTES
FIELD1 x0.0 @ 4.0
SELECT x4.0 @ 1.0 <- Note: compiler padded
to next word.
TRUE_CASE x8.0 @ 4.0
FALSE_CASE x8.0 @ 18.0
The following would define the above structures:
COMMENT This defines MY_RECORD "
RECORD`ID 1
RECORD`LENGTH 256
RECORD`LABEL "MY_REC"
N`FIELDS 2
FIELD`FORMAT {field1} (32,INT,10)
{select} (8,INT,10,TAG,216)
VAR`LABELS [ 1 ] "field 1 :"
[ 2 ] "select code : "
VALUE`LABELS [ 2 ] (0,"False"; 1, "True" )
COMMENT " This defines the case variant "TRUE"
(SOME_OTHER_TYPE) from the above record
TAG`ID 1 {This tag is to be used with RECORD`ID 1}
RECORD`LENGTH 216 {Must match length given in FIELD`FORMAT}
RECORD`LABEL
VARIANT [ 2 ] (1)
N`FIELDS 3
FIELD`FORMAT {compiler filler} (24,junk)
{some_other_type} (32,INT,10)
(160, junk) {Total # bits must match RECORD`LENGTH}
VAR`LABELS [ 1 ] "True Case"
COMMENT " This defines the case variant "FALSE"
(YET_ANOTHER_TYPE) from the above record "
TAG`ID 1 {This tag is to be used with RECORD`ID 1}
RECORD`LENGTH 216 {Must match length given in FIELD`FORMAT}
RECORD`LABEL
VARIANT [ 2 ] (0) {Use this TAG`ID for RECORD`ID 1, when}
{the second field has a value of zero}
N`FIELDS 4
FIELD`FORMAT (24,junk) (32,INT,10) (96,STRING) (32,INT,16,TAG,32)
VAR`LABELS [ 1 ] "Count :"
[ 2 ] "Name : "
[ 3 ] "Stuff tag : "
COMMENT " This defines the case variant "0" of
(YET_ANOTHER_TYPE) from the above record "
TAG`ID 1 {This tag is to be used with RECORD`ID 1}
RECORD`LENGTH 32 {Must match length given in FIELD`FORMAT}
RECORD`LABEL
VARIANT [ 2 ] (0)
[ 4 ] (0) {Use this TAG`ID when field 3 of}
{previous TAG`ID has a value of zero}
N`FIELDS 1
FIELD`FORMAT (32,INT,10)
VAR`LABELS [ 1 ] "F1:"
COMMENT " This defines the case variant "1" of
(YET_ANOTHER_TYPE) from the above record "
TAG`ID 1 {This tag is to be used with RECORD`ID 1}
RECORD`LENGTH 32 {Must match length given in FIELD`FORMAT}
RECORD`LABEL
VARIANT [ 2 ] (0)
[ 4 ] (1) {Use this TAG`ID when field 3 of}
{previous TAG`ID has a value of zero}
N`FIELDS 2
FIELD`FORMAT (8,INT,10) (24,junk)
VAR`LABELS [ 1 ] "F2:"
As in the above example, TAG`IDs may be nested.
Variants without tags are not supported. Consider the following:
TYPE
some_record = RECORD
case integer of
0 : (f1 : type1);
1 : (f2 : type2);
2 : (f3 : type3);
END;
LOGTOOL does not know which of the variants to print, since it has no idea
which variant the data matches.
For the following example, the log entry will be that of the MPE/iX low-level I/O (LLIO) system which consists of many software modules called "I/O managers." This log entry has the unique attribute that the record definition is written in parts. The log entry itself is written in two parts. A main header which displays information common to all "I/O managers" and a LLIO software dependent portion, which contains information specific to one software module.
The PASCAL declaration for the log entry header information is as follows:
type
io_fixed_rec_type = record
product_name : dac_prodnum_type; { Name: i.e. "HP7933" }
pdev : pdev_str; { Physical path i.e. "1.1.3" }
ldev : ldev_str; { Logical device name }
dev_class_code : shortint; {`ID for DISC, TAPE, etc }
diag_msg_class : bit8; { Indicates HW/SW/OTHER I/O err }
llio_stat : integer; { HPE status }
log_all_retries : boolean; { TRUE if retries not summarized }
retry_again : boolean; { TRUE if log_all_entries&will retry }
io_worked : boolean; { Did I/O finally work ? }
run_autodiag : boolean; { Were Auto diagnostics run? }
retry_count : shortint; { N'th retry OR Total retries }
mgr_port_num : integer; { port number of manager }
tran_num : integer; { transaction number }
hdwr_len : shortint; { # of valid bytes in the HDWR_STAT}
hdwr_stat : hdwr_stat_type; { Hardware status bytes }
end; {io_fixed_rec_type}
io_event_array = packed array [ 1..max_buff_bytes ] of char;
io_var_rec_type = record
data_len : shortint; { # of valid bytes in DATA }
mgr_code : shortint; { Uniquely IDs the mgr }
case boolean of
true : (data : packed array [1..max_event_count] of io_event_array);
false : (buff : packed array [1..io_var_len-4] of char);
end; {io_var_rec_type}
The previous record structure is used when logging information to the
system log file. This record must be translated into a LOGTOOL
record definition file which will be processed by LOGTOOL and
incorporated into its data base. The following is a listing of a
file named LAYLLIO, which contains the record definition for the above
PASCAL record.
RECORD`ID 111
RECORD`LENGTH 16224
N`FIELDS 25
RECORD`LABEL "I/O ERROR"
FIELD`FORMAT {1 product_name} (320,string)
{2 pdev} (320,string)
{3 ldev} (320,string)
{4 dev_class_code} (16,int,10)
{5 diag_msg_class} (8,int,10) (8,junk)
{7 llio_stat} (0,int, 10 ) (32,lliostat)
{9 log_all_retries} (7,junk) (1,int,10)
{11 retry_again} (7,junk) (1,int,10)
{13 io_worked} (7,junk) (1,int,10)
{15 run_autodiag} (7,junk) (1,int,10)
{17 retry_count} (16,int,10)
{18 mgr_port_num } (16,junk) (32,int,16)
{20 tran_num} (32,int,16)
{21 hdwr_len} (16,int,10)
{22 reserved} (16,junk)
{23 hdwr } (320,hardstat)
{24 datalen} (16,int,10)
{25 mgrcode} (16,int,10,tag,14688)
{---IO_VAR portion }
VAR`LABELS [ 1 ] "PRODUCT NAME:"
[ 2 ] "PDEV:"
[ 3 ] "LDEV:"
[ 4 ] "DEVICE CLASS:"
[ 5 ] "I/O EVENT CLASS:"
[ 8 ] "LLIO STATUS:"
[ 10 ] "RETRY SCHEME:"
[ 12 ] "WILL RETRY:"
[ 14 ] "I/O RESULT:"
[ 16 ] "RUN AUTODIAG:"
[ 17 ] "RETRY COUNT:"
[ 19 ] "MGR PORT NUM.:"
[ 20 ] "TRANS. NUM. :"
[ 21 ] "# HDWR BYTES:"
[ 23 ] "HARDWARE STATUS:"
[ 24 ] "DATA LEN:"
[ 25 ] "MGR CODE:"
VALUE`LABELS
[ 5 ] (0,"Hardware"; 1,"Software"; 2,"Other")
[ 4 ] (0,"Hard Disc"; 1,"Mag Tape"; 2,"Terminal";
4,"Plotter"; 7,"Bus Converter" 13,"Crd Rdr";
16,"DTC"; 19,"Term. Mux."; 21,"Printer";
22,"CA"; 23,"DA")
[ 10 ] (1,"Log Each Retry"; 0,"Summarized Retries")
[ 12 ] (1,"YES"; 0,"NO" )
[ 14 ] (1,"I/O Successful"; 0,"I/O Failed")
[ 16 ] (1,"YES"; 0,"NO" )
Now that the record definition file for the header is complete,
it can be installed using LOGTOOL. The user must enter the Diagnostic
User Interface (DUI) to access LOGTOOL. The following LOGTOOL session
will perform this task:
:logtool
************************************************************
***** *****
***** LOGTOOL *****
***** *****
***** (C) Copyright Hewlett Packard Co. 1987 *****
***** All Rights Reserved. *****
***** Version A.00.00 *****
***** *****
************************************************************
Welcome, Today is MON, August 10, 1987 at 12:30 PM
LOGTOOL>list log=23;type=111 {Display the log entry
without a record definition}
SYSTEM ERROR LOG REPORT
=======================
Report Date/Time: TUE, JAN 1, 1987 - 2:25 AM
===============================================================================
TUE, JAN 1, 1987 2:22 AM LOG0023.PUB.SYS SYSTEM (PIN 27)
RECORD TYPE 111
1 2 3 4 5 6 7 8 9 10 11 12
== == == == == == == == == == == ==
1: 00 00 00 07 48 50 49 42 44 41 4D 00 . . . . H P I B D A M .
13: 00 00 00 00 00 00 00 00 00 00 00 00 . . . . . . . . . . . .
25: 00 00 00 00 00 00 00 00 00 00 00 00 . . . . . . . . . . . .
37: 00 00 00 00 00 00 00 03 38 2E 32 00 . . . . . . . . 8 . 2 .
49: 00 00 00 00 00 00 00 00 00 00 00 00 . . . . . . . . . . . .
61: 00 00 00 00 00 00 00 00 00 00 00 00 . . . . . . . . . . . .
73: 00 00 00 00 00 00 00 00 00 00 00 00 . . . . . . . . . . . .
85: 00 00 00 00 00 00 00 00 00 00 00 00 . . . . . . . . . . . .
97: 00 00 00 00 00 00 00 00 00 00 00 00 . . . . . . . . . . . .
109: 00 00 00 00 00 00 00 00 00 00 00 00 . . . . . . . . . . . .
121: 00 06 00 00 5A 00 00 74 00 00 00 00 . . . . Z . . t . . . .
133: 00 00 00 00 FF FF FF AE 00 00 00 00 . . . . . . . . . . . .
145: 00 01 00 00 01 02 00 00 00 00 00 00 . . . . . . . . . . . .
157: 00 00 00 00 00 00 00 00 00 00 00 00 . . . . . . . . . . . .
169: 00 00 00 00 00 00 00 00 00 00 00 00 . . . . . . . . . . . .
181: 00 00 00 00 00 00 00 00 00 18 00 74 . . . . . . . . . . . t
193: 02 00 00 00 00 00 00 0C 00 45 45 45 . . . . . . . . . E E E
205: 00 00 00 0C 00 67 46 94 00 00 00 09 . . . . . g F . . . . .
DEVICE HARDWARE STATUS:
1 2 3 4 5 6 7 8 9 10 11 12
== == == == == == == == == == == ==
1: FF .
===============================================================================
TYPE DESCRIPTION COUNT
====== ==================== ==========
111 1
====== ==================== ==========
LOGTOOL>layout file=layllio; append {Update data base file}
Processing ID 111 ...
================================================
End processing of layout file LAYLLIO.DIAG.SYS
0 Errors encountered
1 out of 1 record ID's were accepted.
0 out of 0 tag ID's were accepted.
Number of messages in LAYMSG = 287
Header records in LAYOUTF = 25
Total record in LAYOUTF = 799
LOGTOOL> list log=23; type=111 {Display log entry with header}
SYSTEM ERROR LOG REPORT
=======================
Report Date/Time: TUE, JAN 1, 1987 - 2:26 AM
==============================================================================
TUE, JAN 1, 1987 2:22 AM LOG0023.PUB.SYS SYSTEM (PIN 27)
I/O ERROR
PRODUCT NAME: HPIBDAM PDEV: 8.2
LDEV: DEVICE CLASS: 6
I/O EVENT CLASS: Hardware LLIO STATUS: $5A000074
MPE/XL I/O Status: Proc. Num. = 0, Error Num. = 90, Subsystem = 116
RETRY SCHEME: Summarized Retries WILL RETRY: NO
I/O RESULT: I/O Failed RUN AUTODIAG: NO
RETRY COUNT: 0 MGR PORT NUM.: -82
TRANS. NUM. : 0 # HDWR BYTES: 1
HARDWARE STATUS:
1 2 3 4 5 6 7 8 9 10 11 12
== == == == == == == == == == == ==
1: FF .
DATA LEN: 24 MGR CODE: 116
TAG DEFINITION NOT GIVEN - FIELD WILL BE DISPLAYED IN HEX:
1 2 3 4 5 6 7 8 9 10 11 12
== == == == == == == == == == == ==
1: 02 00 00 00 00 00 00 0C 00 45 45 45 . . . . . . . . . E E E
13: 00 00 00 0C 00 67 46 94 00 00 00 09 . . . . . g F . . . . .
===============================================================================
TYPE DESCRIPTION COUNT ====== ==================== ========== 111 I/O ERROR 1 ====== ==================== ========== LOGTOOL>Because the record definition file only contains declarations for the header, the "I/O manager" dependent portion of the log entry is displayed as a hex dump. The "I/O manager" dependent portion of the record definition will be given in the format of TAG`ID declarations. As an example, the following PASCAL record defines an "I/O manager" dependent portion of the log entry:
TYPE
dam_log_info_type = PACKED RECORD
hw_status : bit8;
dam_mgr_ptr : srv_ptr_type;
dam_msg_ptr : msg_ptr_type;
dam_uid_num : integer;
END;
DAM_LOG_INFO_TYPE MAX_RECORD_SIZE = x18 BYTES
HW_TSTATUS x0.0 @ 1.0
DAM_MGR_PTR x4.0 @ 8.0
DAM_MSG_PTR xC.0 @ 8.0
DAM_UID_NUM x14.0 @ 4.0
The TAG`ID definition for the above declaration is the following,
which will be stored in the file LAYPORT:
TAG`ID 111 {HP-IB device adapter manager}
RECORD`LENGTH 192
N`FIELD 7
RECORD`LABEL
VARIANT [25] (116)
FIELD`FORMAT (8,int,16) {Hardware status}
(24,junk) {Compiler filler}
(32,int,16) {Port data area address}
(32,int,16)
(32,int,16) {Message pointer}
(32,int,16)
(32,int,10) {UID}
VAR`LABEL [ 1 ] "HDWR STATUS:"
[ 3 ] "PDA SPACE`ID:"
[ 4 ] "PDA OFFSET:"
[ 5 ] "MSG SPACE`ID:"
[ 6 ] "MSG OFFSET:"
[ 7 ] "UID:"
Now, the TAG`ID can be installed through LOGTOOL:
:logtool
************************************************************
***** *****
***** LOGTOOL *****
***** *****
***** (C) Copyright Hewlett Packard Co. *****
***** All Rights Reserved. *****
***** Version A.00.00 *****
***** *****
************************************************************
Welcome, Today is MON, August 10, 1987 at 12:30 PM
LOGTOOL>layout file=layport;append
Processing TAG`ID 111 ...
==============================================
End processing of layout file LAYPORT.DIAG.SYS
0 Errors encountered
0 out of 0 record`IDs were accepted.
1 out of 1 tag`IDs were accepted.
Number of messages in LAYMSG = 292
Header records in LAYOUTF=26
Total records in LAYOUTF = 819
LOGTOOL>list log=14;type=111 {Display log entry}
SYSTEM ERROR LOG REPORT
=======================
Report Date/Time: TUE, JAN 1, 1987 - 2:27 AM
===============================================================================
TUE, JAN 1, 1987 2:22 AM LOG0023.PUB.SYS SYSTEM (PIN 27)
I/O ERROR
PRODUCT NAME: HPIBDAM PDEV: 8.2
LDEV: DEVICE CLASS: 6
I/O EVENT CLASS: Hardware LLIO STATUS: $5A000074
MPE/XL I/O Status: Proc. Num. = 0, Error Num. = 90, Subsystem = 116
RETRY SCHEME: Summarized Retries WILL RETRY: NO
I/O RESULT: I/O Failed RUN AUTODIAG: NO
RETRY COUNT: 0 MGR PORT NUM.: -82
TRANS. NUM. : 0 # HDWR BYTES: 1
HARDWARE STATUS:
1 2 3 4 5 6 7 8 9 10 11 12
== == == == == == == == == == == ==
1: FF .
DATA LEN: 24 MGR CODE: 116
HDWR STATUS: $2 PDA SPACE ID: $C
PDA OFFSET: $454545 MSG SPACE ID: $C
MSG OFFSET: $674694 UID: 9
===============================================================================
TYPE DESCRIPTION COUNT
====== ==================== ==========
111 I/O ERROR 1
====== ==================== ==========
LOGTOOL>
LOGTOOL is not able to display all the information for the log entry.
Since the append option was used in the LAYOUT command, all
subsequent users have access to the definition given. To shorten
this process, the LAYLLIO and LAYPORT record definition files can
be merged together. Then LOGTOOL will process the RECORD`ID, followed
by the TAG`ID.
|
Summary
Commmands |
Records
Err Msgs |
All the files
Diagnostics HOME |