Standalone Logtool for MPE/iX: Records
Record Definition Files
Each entry found in the system error log has an associated
record ID number, which is the first 16 bits of every log entry.
Since these record ID numbers identify unique log entries,
LOGTOOL will use these record ID numbers to match data from the log
files with a record ID declaration. The record ID declarations
specify the exact format of each log record and will be used during
the translation of a log file. Therefore, the record definition file
contains a series of RECORD ID DECLARATIONS. To support PASCAL record
variants, a second type of record ID may also appear in the file.
These are referred to as TAG IDs, since they describe a variant record
tag field. Therefore, the record definition file
would look as follows:
<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.
Record Definition Commands
The following section describes the various commands that
can be used in a record definition file.
All commands are terminated by finding a new command (remember, all
commands must start at column one). Command names may be abbreviated to
the shortest unambiguous number of characters.
For example, the FIELD`FORMAT command could be abbreviated
to F since no other commands begin with the letter F.
COMMENT
The COMMENT command allows one to separate record definitions and
supply useful information to the maintainer of the file.
Comments are ignored.
Syntax:
COMMENT <anything may follow>
Example:
COMMENT This is a comment.
It spans several lines.
RECORD`ID
This command must precede all commands which specify an
attribute of a RECORD`ID. It identifies the numeric RECORD`ID that
can be used to distinguish log entries in the system log file. All
commands following (until the next RECORD`ID or TAG`ID) are assumed to
belong to the current RECORD`ID.
Syntax:
RECORD`ID <record id #>
Notes:
RECORD`ID numbers must be between 0 and 255.
Examples:
RECORD`ID 1
RECORD`ID 123
TAG`ID
This command defines the variant tag portion of a previously defined
RECORD`ID or TAG`ID. For example, refer to the following PASCAL record
definition:
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 Description Commands
The following set of commands are used to define the attributes of an
individual log record (RECORD`ID) or tag variant of some record (TAG`ID).
(From here on RECORD and TAG`IDs will not be differentiated unless
required). If the LOGTOOL LAYOUT command sees any of the commands
without a RECORD or TAG`ID command, it will generate an error.
Additionally, only one of the possible definition commands may be
provided for any one record. The following commands must be
provided when defining a RECORD or TAG`ID:
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.
RECORD`LENGTH
This command specifies the total length in bits for the maximum
size of the current RECORD`ID. This value should not include the size
of any data added by the system (i.e., the actual RECORD`ID, time stamp,
etc.). This value and the number of bits specified in the
FIELD`FORMAT must agree.
Syntax:
RECORD`LENGTH <# of bits>
Notes:
The maximum number of bytes is 2028.
Example:
RECORD`LENGTH 220
N`FIELDS
This command specifies the number of fields (pieces of data) in the current
RECORD`ID. Variant tags are considered as 1 field. The subfields are
defined with subsequent TAG`ID commands. This value must be equal
to the number of entries on the FIELD`FORMAT command.
Syntax:
N`FIELDS <# of fields>
Example:
N`FIELDS 5
RECORD`LABEL
This command assigns a label to the log record. The label is restricted
to 20 characters and must be enclosed by either double or single quotes.
Syntax:
RECORD`LABEL "<name>"
Example:
RECORD`LABEL "I/O"
RECORD`LABEL
FIELD`FORMAT
This command defines (bit for bit) what the record contains and the
data types of each field. Several "types" are known, as follows:
| 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:
- The total # of bits must match the record length specification.
- The number of fields must match the N`FIELDS specifications.
- ARRAY, ASCII, & STRING data must start on byte boundaries.
- ARRAY, ASCII, & STRING data must be multiples of 8 bits in length.
- ARRAY, ASCII, & STRING data can have a maximum of 132 bytes.
- ARRAY data will always print out in whole bytes.
- Integer data is at most 64 bits long.
- The length given for string data should include the overhead bytes value.
Examples:
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.
VAR`LABELS
This command provides the ability to give each field a label. The
string provided will be what is used to label the field when LOGTOOL
decodes the log record. If the label is longer than the maximum number
of allowable characters, the user is warned that the label is truncated.
Error checking is performed to prevent duplicate labels within the
current record. If a field is not given a VAR`LABEL, a null string
will be used.
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:
- Single or double quotes may be used to bracket the label.
- The maximum # of characters is 20.
Examples:
VAR`LABELS [ 1 ] "Name for field 1 : "
[ 2 ] "field 2 name : "
[ 4 ] "field 3 is unlabeled"
VALUE`LABELS
This command allows the binding of values in a field with ASCII
descriptions of those values. Error checking is performed to ensure that
only numeric (INTEGER) data has VALUE`LABELS. The value is not limited to
a single value, but a range of values may be specified for a particular label.
All ranges must be unique and may not overlap with any other value or range.
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:
- Single or double quotes may be used to bracket the label.
- The maximum number of characters is 20.
- If a value label is given and data in the log file does not match
one of the indicated values, it will simply be printed as numeric
data as indicated in the FIELD`FORMAT command.
Examples:
VALUE`LABELS [ 2 ] (1, "one"; 2, "two"; 3, "three")
[ 3 ] (-1, "Unlimited"; 1/14 "Half power")
[ 8 ] (-32768/-1, "Negative";
0/32767, "Positive")
VARIANT
This command must be provided for a TAG`ID definition. This
command indicates which field of the RECORD`ID or TAG`ID the current
TAG`ID definition is to be used. The RECORD`ID definition must
contain a field declared as a tag. For example, a RECORD`ID must
have a field similar to the following:
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}
Tag Usage Example
The system log file is expected to contain data structures
as defined in PASCAL. In order to handle Pascal case variant records,
the notion of TAGs has been provided. In the following example, a
record definition file will be written for the PASCAL record "MY_RECORD."
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.
RECORD`ID Installation Example
This section describes in detail the process required for LOGTOOL to
decode a log entry. Normally, when LOGTOOL is instructed to display the
contents of a system log file, it searches through the LOGTOOL data
structures for a RECORD`ID definition. If a RECORD`ID definition cannot be
found, the log entry is displayed based on the definition located.
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.
|