E.R.T.E. User Manual

1) introduction
2) script formats
3) parameter files
4) running E.R.T.E.
5) error messages
6) configuring E.R.T.E.
7) data analysis
8) script file utilities
9) other relevant documentation

Issue no. 6.0 (for ERTE MK.3 & ERTE MK.4) 16th March 1979

Section 1: introduction

The EDINBURGH REMOTE TERMINAL EMULATOR is a system
designed to simulate terminal users on a Multi Access System.
It operates by passing commands (held in SCRIPT FILES) to the
receiving system (referred to as the TARGET in the rest of this
document) as if from ordinary terminals. These script files and
the corresponding parameter files may be generated using the
MAVIS [Brebner 1977] suite or merely by editing appropriate text
files using the standard system editor. The versions of ERTE
described have been used extensively on EMAS 4/75, various EMAS
2900'S and DEC VAX VMS. This document describes particular
implementations of ERTE specific to the needs of the original
SRC funded research project ( SRC grants BRG 93968 and BRG
96084 ), a more general discussion of ERTE may be found in ADAMS
et al 1977.

The current supported versions of ERTE are as follows:

ERTE mk.3.0 Simulates a TCP on the RCO net,
talking NSI and ITP protocols down 1 concentrated
synchronous line. Upto 48 simultaneous users on a
32k word PDP 11/40.

ERTE mk.3.1 Simulates a TCP connected directly to
the target FRONT END, talking NSI and ITP
protocols down 1 concentrated asynchronous line (
usually a C.S. dept LINK ). Upto 48 users on a
32k word PDP 11/40.

ERTE mk.3.2 Simulates a TCP on the RCO net,
talking NSI and ITP protocols down 1 concentrated
synchronous line. Upto 128 users have been handled
on a 48k word PDP 11/40, and more may be possible.

ERTE mk.4.0 Outputs characters onto a number of
individual asynchronous lines, no protocol is
usually placed on these and ERTE is connected to
the target as though it were a number of local
terminals. Currently up to only 7 users have been
simulated by this method due to the non existence
of any more multiplexor lines. Capacity of the
PDP 11/40 under this regime is not known, but will
not be as high as under ERTE mk.3 as extra
processing is required to identify system prompt
messages etc.

The entire package is written in the high level language
IMP-77 [Robertson 1977] and the listings are intended to be self
documenting. This document is intended to suplement said listings
and give a quick guide to running the package. ERTE consists of
several co-operating tasks running under the DEIMOS Operating
System on a PDP 11 with memory management and at least 32K
Core Memory. The tasks are as follows:-

INIT Initialise and Control Task ( given the DEIMOS
name of ERTE )

TIME Stimulator Clock Task

DQS1 DQS/11E synchronous line Communications Handler ( mk.3 )

DZAn DZ/11 Multiplexor Handlers ( mk.4 )

PROT Line Protocol Handler ( HDLC ) ( mk.3 )

CSLK C.S. Link Handler and HDLC Protocol Handler ( mk.3.1 )

NSI Network Protocol Handler ( to RCO NSI ) ( mk.3 )

TCP Terminal Protocol Handler ( to RCO ITP ) ( mk.3 )

TSIM Terminal Simulator ( mk.4 )

CPUT Optional CPU Utilisation Module

TSKn n SCRIPT Tasks, each of which can handle up to a
fixed number of scripts for the "virtual terminals"
(currently 16 scripts). ( mk.3 )

TSCn n SCRIPT Tasks ( mk.4 version of TSK )

All the details of the number of scripts, etc. are passed
to ERTE in PARAMETER FILES, one per Script Task. The limit
to the number of script tasks and virtual consoles is determined
by the available core.

All monitoring data from ERTE is output to a fixed file ,
XOT, on a specified disc unit, and there is a set of utilities
for processing this data. (See SECTION 7)

Section 2: script formats

A script file contains the simulated input from a terminal.

It may be of any length and can include any number of user
sessions i.e. loging on and off.

Its format is as follows

command line
check line
delay time

COMMAND LINE:- This is passed on verbatim to the system
(current max. 70 characters). Note that the script must start
with the usual system startup requirements (&, EMAS, USERNAME,
PASSWORD)

CHECK LINE:- May be used to verify the script. In ERTE

mk.3 this is currently not used ( line usually holds a "0") except
that the last check digit in a user session MUST be negative. In
ERTE mk.4 this line is used to hold the expected system prompt
message, or a "0" if the prompt is the same as that of the
previous interaction. All text output from the target will be
checked against this message for a match. On a match being found,
the TSIM task will inform the TSC task and the next user think
time and command will start. The format of this line is "<prompt
text>0". The "prompt text" should not contain a "0" and should be
as short as possible to identify the prompt. N.B. the first
occurence of the "prompt text" appearing in the output from the
target is taken to be the prompt. If the prompt is unchanged then
the CHECK LINE should contain a "0" ( spaces before the "0" are
significant ). N.B. attempting to change the "prompt text" to
the same value will usually cause the TSIM task (which actually
does the checking for the prompts) to send an immediate reply to
the TSC task indicating a prompt has been found. The CHECK
LINE should only contain a change of "prompt text" when
necessary.

DELAY TIME:- The time in seconds between the system
response to the command and the input of the next command in the
script (i.e. the user think time). User think times are normally
calculated from the end of typing of the target's prompt. However
for ERTE mk.3.3 and ERTE mk.4 a "type ahead" option is included.
If a minus sign precedes the user think time then the user think
time is calculated from the last character being input from the
current command and ERTE does not wait for the system's prompt to
appear.

There should be no redundant blank lines in the script file
and no terminator is required. The utility ANALY can be used to
tidy up script files, verify them and provide a summary of delay
times etc. SCRIPT files may exist on any logical disc unit under
any user file system number, but the name MUST be EXACTLY 6
characters in length.

Section 3: parameter files

The parameter files inform the script tasks within ERTE
which script files etc. to use. the parameter files MUST be on
the same unit and file system number as ERTE when it is run and
there is one such file per script task.

Parameter file names must be of the form TKPARn where n
= Script Task Number (1-9) and have the following format

line 1: <number of scripts> <typing rate> <start up delay>

The TYPING RATE is the percentage of line speed to be used
as a typing speed for inputing the command lines of the script.

The START UP DELAY is the time in seconds between sending
the first logon attempt for each sucessive script.

For each script the task has to handle there are four lines
of data:-

1: script file name (exactly 6 characters)
2: file system number for file (0-63 decimal)
3: disc unit for file
4: line speed in characters per second.

No terminator is required.

Section 4: running e.r.t.e.

To set up any TARGET to receive ERTE input the appropriate
experimentors guide should first be consulted [see Section 9].

The following procedure should then be followed:-

1)ipl deimos
2)logon to the appropriate deimos file system

The following tasks are loaded for ERTE mk.3.0 and mk.3.2:

STIMULATOR USER COMMENTS

ERTEnn Loads the current version nn
of ERTE ( nn usually found in
the current edition of the
INSTANT ERTE GUIDE).

ERTE VNN DD/MM/YY Reports the version number and
date of issue. If wrong halt
machine & start again.

TCP UNIT: n Requests the logical output
device for the file ( XOT )
produced by the TCP task. On
the original configuration n=2
or 3 or 0 (if only one disc).

TIME LOADED Timer Module Loaded.

DQSY LOADED DQS/11E Handler.

PROT LOADED Line Protocol Handler.

TCPn LOADED Terminal Protocol Handler.

n='X' - The non NSI version.
n='Z' - The NSI version.

NSIZ LOADED Network Protocol Handler (if
using TCPZ).

CPUT LOADED CPU Utilisation Monitoring
task (see below)

NSIZ: PROT UP Physical line up

NSIZ: ATTACHED as nn Sucessfully attached to RCO
network

NSIZ: CONNECTED to nn Sucessfully connected to
target

TCPZ: BUFF REM nn Sometimes output by ERTE
mk.3.2. Means that one of the
ITP message buffer pool spans
a PDP 11 segment boundary and
has been removed from the free
pool. This usually only
happens in versions with large
buffer pools E.G. mk.3.2.

TCPZ: ITP READY All initialisation complete
and now ready to start. It is
now safe to reply to the "
NUMBER OF TASKS" message
(N.B. the NSIZ, TCPZ and "
NUMBER OF TASKS" messages
are output by 3 different tasks
and so may come out in any
interleaved order, DO NOT
REPLY to the " NUMBER OF
TASKS" message until the ITP
READY message has appeared)

NUMBER OF TASKSn Asks for the number of script
tasks to be loaded. This
number is currently 1,2, or 3
(for 1-16, 1-32 or 1-48
scripts) but will vary on core
size.

script task 1 started with x scripts

Each script task is loaded and
the corresponding parameter
file is read. The first
commands in the scripts are
found and the scripts are
started after the appropriate
delay. It is at this point
that many of the obvious errors
will occur ( SECTION 5).

The loading sequence of ERTE mk.3.1 differs in the following tasks:

CSLK LOADED C.S. departmental link
handler, replaces PROT and
DQSY.

The loading sequence of ERTE mk.4.0 differs in the following tasks:

DZAn LOADED n MULTIPLEXOR tasks, replaces
PROT and DQSY of mk.3.0.

TSIM LOADED Terminal simulator and prompt
checking task replaces TCP
and NSI of ERTE mk.3.0.

The SCRIPT TASKS loaded in mk.4.0 are also different and are
called TSCn rather than
TSKn. All the query
mechanisms and state numberings
within TSC remains the same as
that in TSK however.

From this point on ERTE runs automatically but the
following controls are available by using the DEIMOS INT
mechanism.

int z tskn or int z tscn where z may be

?: Prints a status report for each script under that
task. It is a table with script number, state,
number of command lines sent and the number of
times that the script has been held up due to the
next command not being brought off the disc in
time. This normally only happens with a zero think
time, as on start up and this number should be
relatively small compared to the number of
commands. State may be one of:-

0 about to send a command(typing one in)
1 waiting for tcp buffer(1st try)
2 waiting for tcp buffer(subsequent try)
3 waiting for emas to respond
4 in think delay
5 waiting for disc transfer to complete
6 start up state
7 end of script file reached
8 requesting prompt buffer from tsim ( mk.4 only )
9 typing ahead (mk.3.3 and mk.4 only )

Q: FULL STATUS - as for ? plus internal script
buffer information (see program listing for
details).

L: ENTER LOOP MODE. If a script reaches state 7 it
is restarted from the beginning.

A: ABORT the task immediately

N.B. The INT flag is only inspected every 5 seconds so
there may be some delay. A new INT command will overwrite the
old one (e.g. A will overwrite L but ? overwrites itself to 0
after typing the report).

The INT mechanism may be used with task CPUT to measure
the CPU Idle Time in the 11/40 while ERTE is running.

INT X CPUT where X may be:-

t: measure over 10 second interval
h: measure over 30 second interval
m: measure over 60 second interval
a: stop

closing down erte

The INT mechanism may be used with the INIT task (known in
DEIMOS as the task ERTE ) to close down ERTE. This is quicker
than doing an INT A to each of the SCRIPT tasks. The shutdown
command is:

INT A ERTE

Alternatively SCRIPTS tasks will terminate naturally when
all the scripts in a task have reached state 7 and loop mode is
not set. SCRIPT tasks can of course also be halted by an INT A.
When all the scripts in a task have finished or INT A is sent,
the task will produce a script status report and the message TASK
nn TERMINATED will appear (twice).

When all the SCRIPT tasks have terminated the TCP or TSIM
task is stopped and will produce data on the utilisation of its
internal queues, then the TIME task is stopped giving the run
time in MINS, and SECS, 1/10TH secs. Finally after a pause the
message ERTE STOPPED will appear.

N.B. This still leaves three tasks in core, DQS1 and PROT
which should be killed immediately, and CPUT which should be sent
an INT A. (It may be removed at any time using this method).
However ERTE often crashes at this point (but this should not be
a cause for alarm) so re IPL ing the system may be the best
course of action.

Section 5: error mesages

Most ERTE error messages are fatal in that they cause at
least part of ERTE to stop. The messages below are divided into
the tasks from which they originate.

5.1) init

INIT reports all error messages coming from the script tasks

(5.2) and its only other error condition is

unexpected message a b c

where A = TASK ID sending the message , B= P_A1, C= P_A3.
This usually indicates a faulty start up: reload & try again.
N.B. the INIT task usually takes the DEIMOS name of ERTE.

5.2) script tasks

All the SCRIPT TASK errors are reported by INIT with the

following format:-

fatal error number x task number n

where N=Script Task Number, X=Error Number as follows (
N.B. all these errors cause the script task to stop)

-1 Internal script buffers exhausted
-2 Bad disc read (script file)
-3 Bad disc read at start of script file (file may
not exist)
-4 Script file corrupt-verify the file system before
restarting
-5 Run out of prompt buffers - increase the number
held, PROMPTBMAX and PROMPTBTOTAL ( mk.4.0 ).
Not used in mk.3.
-6 Not Used
-7 Disc queue full
-8 Parameter file too short (end of file reached
before all scripts found or file corrupt)
-9 Parameter file disc read error
-10 Symbol in parameter data
-11 Parameter file does not exist
-12 Disc read error on first block of parameter file

5.3) tcp

All error messages cause the TCP task to stop and are in
the format

tcp <message> <time> <virtual console number>,

where the message may be:-

BREAK INT TO USER Bad control message from FEP

TARGET DOWN

TARGET JUST BACK UP

BUFF NOT SENT Bad replies from a transmit to TARGET
request

ABORTED CONSL Message received from script task for a
virtual console which has been aborted

MQ DN FULL Queue of messages to TARGET full

GAH Q FULL Queue of GO-AHEAD messages to TARGET
node is full.

5.4) nsi

All error messages cause the NSI task to stop and are in
the format:

nsiz: < message > < nsi state >

where the messages may be:

ITP Q FULL - Too many messages from TCP -> target.
( Cut down the number of outstanding
writes TCP may send ).

ITP READY Q FULL - Too many read from target messages
sent by TCP. ( Cut down on the number
of outstanding reads TCP can send. )

TOO MANY FREE SB'S - NSI SEND BLOCK buffering gone
haywire.

NO FREE SB'S - Have run out of NSI SEND BLOCKS. (
Increase the number of SB'S available
to NSI. )

STATE NOT ATTACH - NSI ATTACH to network reply received
at odd time. ( See B.G. or S.C. )

STATE NOT REMOVE - NSI REMOVE from network message
received at odd time. ( Target FRONT
END may have gone down. )

PROT NOT UP - PROT task does not wish to start. (
Check physical line exists. )

UGH FROM PROT - Lousy message from PROT. ( ?? )

LOUSY POFF - A DEIMOS taSks unknown to NSI sent
it a mesage. ( Check other tasks. )

The NSI states are:

1 - initialising
2 - attaching to network
3 - connecting to target
4 - running
5 - disconnecting from target
6 - removing from network

5.5) prot

The PROTOCOL HANDLER may produce mesages of the form

PROT:MESSAGE

where MESSAGE can be:-

DM Data miss - can be ignored

BAD ACK Bad ack from front end (fatal if many of them)

NOISE Ignore this

5.6) cslk

All error messages are in the format

" CSLK:" <MESSAGE>,

where message may be:

BUFFER NOT IN SEG 6

OUT STATE ERROR

IN STATE FAULT

5.7) dza

All error messages are in the format

" DZ11:*" <fault number><line number>

5.8) tsim

All error messages cause TSIM to stop with a fault dump.

The messages are in the format

" TSIM" <FAULT message><time of day><cnsl number>.

The fault messages are:

0 LENGTH Attempting to send an input line of length 0 to
the target.

MQDN FULL The array holding input to target messages is
full.

FT, MULTOUT The multiplexor number is out of range on input to
target.

MULT W REPLY The multiplexor task rejected an input to target
message for some reason.

5.9) system messages

DEIMOS may itself produce error mesages
especially during shutdown when BAD SER will
appear and can be ignored. See DEIMOS manual for
other messages.[Gilmore 1978]

Section 6: configuring e.r.t.e.

The principle tasks comprising ERTE (see
SECTION 1) each have several configuration
parameters to enable the user to build a system for
his requirements. These parameters are now
described on a task by task basis( NB In all
cases recompilation of the task source is
required). For further details see the self
documenting listings.

The Initialise Task

This task automatically loads any number of
script tasks (see below) but must be altered if the
log file name is to be modified. In this case
change the array TCPZ. The INIT task also passes
some network information to TCP (mk.3 ). This
data includes the network address of TCP and the
target as well as the target's name. This is all
held in array NETWORK. For ERTE mk.4.0 the INIT
task passes the initial target prompt, the
character to be passed to the target at logon, the
logon character held in the scripts ( will be
translated to the target logon character by TSIM
), the number of multiplexors available and their
DEIMOS service numbers. Again this is held in the
array NETWORK.

The Time Task

The constant ARSIZE is the size of the
request buffer and thus must be large enough to
cope with a request from each script plus several
other requests.The formula
arsize = number of scripts * 1.5
is recommended as a minimum buffer allocation.

The Script Tasks

The number of SCRIPT tasks required for a
particular configuration is a function of the
number of scripts. It is not recommended to have
more than 16 scripts per task as this may cause
excessive internal queuing.

To set up a script task edit the following

NUMSCR The number of scripts this task is to handle.

SYSLOT The system slot the task is to run in.These start
at 26 for TSK1 and descend,25 for TSK2,ETC.

PARMF This array holds the name of the parameter file to
be used by this task,normally TKPARN.

SCBUFFS This is the number of internal script buffers,
which should be at least 2*NUMSCR and must be
>NUMSCR. This is dependant on the number of
characters sent in on command lines by the scripts.
The buffers are each 20 characters long and there
must be sufficient to cope with the peak load.

PRMPTL This determines the maximum size of any piece of
"prompt text" ( mk.4.0 only ).

PRMPTBMAX This (along with PRMPTBTOTAL) determines the
number of prompt buffers held, current recommended
value of 8 ( mk.4.0 only ).

PRMPTEND This is the character which defines the end of
"prompt text" ina CHECK LINE or an empty CHECK
LINE, currently is set to "0" ( mk.4.0 only ).

TEXTEND This is the character which defines the end of a
command line to be passed on to the target,
currently set to be the newline symbol, however
there is no logical reason stopping any character
being used - though the format of the script files
will of course then change.

Compile the required script tasks with a stack of 200, no
streams and ALL WITH THE SAME NAME, TSK1 ( or TSC in mk.4.0 ). The
system will code share the tasks.

The Tcp Task

The sets of constants at the beginning of the TCP task
define (among other things) the number of virtual consoles this
TCP may multiplex, the number of SCRIPT tasks it may communicate
with and the amount of internal buffering it holds. The main
internal buffering has to do with text messages passing between
the SCRIPT tasks and the PROTOCOL tasks nearer the TARGET.
There is a separate queues for ITP protocol level GO-AHEAD
messages. The major constants are:-

TOTSCRIPTS The highest virtual console number expected(i. e.

the total number of virtual consoles -1,numbering

starts at 0).

PERTASK The number of virtual consoles per SCRIPT task.

MAXTASK The maximum number of SCRIPT tasks.

MAXREAD The maximum number of reads ( from target ) which
may be outstanding with the next PROTOCOL task
towards the TARGET.

MAXWRITE The maximum number of writes(to TARGET) which may
be outstanding with the PROTOCOL task towards
TARGET.

MDQL The maximum number of messages to target which may
be held in the TCP at a time

BUFFARL The number of message buffers which exist (
MAXREAD + MAXWRITE + MDQL+1).

GAHQL The size of the GO-AHEAD queue -1 (always a power
of 2 -1).

CHECKOUT ='Y' if contents of all messages are to be
recorded in the XOT file. ='N' if not (the
recommended mode for 'long distance' ERTEs).

TIMESTAMP ='Y' if a time stamp (in 1/10 second ticks) is to
be appended to all messages in the XOT file. ='N'
if not.

TOXOT ='Y' if an XOT file exists, rather than logging
directly to the operator's console. ='N' will log
to operator's console.

TRACEGAH ='N' if GO-AHEADS are to be logged. ='N' if they
are not.

The Nsi Task

As with TCP there are a number of constants in the NSI
task defining how many mesages it will buffer etc. The most
important are:

MAX RD SB The maximum number of SEND BLOCK reads (from
target) sent to the PROT task at any time
(currently 3).

SBMAX The maximm number of SB's in existence -1
(currently 7).

SBLMAX The maximum length of a SB in bytes (currently
256).

TO TARG MAX The maximum number of ITP messages queued towards
the target -1 (currently 7).

ITP READY MAX The maximum number of ITP read from target
buffers held at a time -1 (currently 7).

If the NSI task is to increase its SB throughput ( for
larger numbers of users) then the SB buffering will have to be
increased, the number of SB'S allowed outstanding each way over
the network (negotiated at attach time) will have to be increased
and probably a check will have to be made that none of the SB'S
in the buffer pool span a PDP 11 segment boundary (as in ERTE
mk.3.2).

The Tsim Task

Most of the constants involved in TSIM are the same as
those of TCP. The task assumes 1 physical multiplexor per
SCRIPT task ( TSC version of the SCRIPT task ).

Section 7: data analysis

This section describes some data analysis programs which
operate on the XOT file produced by the TCP (or TSIM) task.
XOT files are standard DEIMOS text files and can be inspected
using the standard system editor. The XOT file records, appart
from a header, *< TCP VERSION> ,and the terminator '+',have the
format:-

<time stamp><record type><virt consl><length><message>nl

where record type may be one of:-

1 = message from script to emas

2 = from emas to script

3 = prompt message sent to script

The length is in characters and there is no message text for
a type 3 record. The time stamp is in 1/10th second ticks (this
will wrap round approximately every 55 minutes ).

For ERTE mk.3, type 1 records are produced whenever a user
would have completed typing an input line and the packet
corresponding to that line is fired off into the network. For
ERTE mk.4 type 1 records are produced when the input line is
passed to the multiplexor task for transmission to the target,
there will still be some "typing delay" to come in this case
corresponding to L character transmission times on that line
(where L is the length of the input message). Type 2 and 3
messages are produced at similar points in both mk.3 and mk.4. (
however in mk.3 type 2 messages correspond to a packet being
received at a TCP on the network with several characters per
packet, in mk.4 type 2 messages are for individual characaters
being printed on a particular line, hence XOT files in mk.4 tend
to be larger). The analysis programs are set up to allow for the
difference in the timing points of type 1 messages so that the
final results are equivalent.

All the analysis programs described have evolved to meet
some of the needs of the original SRC project. Thus they have
been set up to obtain measurements from experiments using the F1
and CS1BM workloads, run under the standard experiment format
(once the first user has started to log on, an 8 minute settling
period is allowed so that all users can log on and the system
reach some kind of steady state, the target's performance is then
monitored for a 30 minutes window, the end of this window marks
the end of the experiment ). Monitoring utilities internal to the
targets used during the project have also been produced which will
follow this format, they are not described in this document.

The common performance metrics quoted are:

REACTION TIME The time from the user typing the last
character of his input line until the
time the target outputs the first
character of its reply (not counting any
echoed characters). Thus this represents
the time the user waits with nothing
happening on his console.

RESPONSE TIME The time from the user typing the last
character of his input line until all of
the target's reply has been typed and the
target's prompt message requesting
further input has also been typed. Thus

this represents the time (including
typing delay) it takes the target to deal
with a command and make itself ready for
the next.

THROUGHPUT The mean number of REACTIONS completed
per minute

SATISFACTION LEVEL The percentage of REACTIONS completing
within 2 seconds. The cut off point of 2
seconds is chosen as REACTION time of
greater than this level cease to be
interactive. The distributions of
REACTION and RESPONSE time are often
heavily skewed and may be heavily
influenced by a small number of very long
times, this figure gives some indication
of this skewing.

As with ERTE proper these programs are written in IMP-77
and should be easily modified. However the IMP-77 compiler on
the original configuration did not have real arithmetic and a
double word arithmetic package was produced to get round the
extreme limitations imposed by 16 bit integers. These programs
tend to use this double word arithmetic package heavily [ Currie
1976 ].

alog

ALOG is an analysis program devised to obtain means for
response and reaction times. To run ALOG, type:

alog <xotfile>/<data file>,<expanded log>

.alog will print:-

erte vrsn:

Reply with 3 or 4 corresponding to ERTE mk.3 or mk.4. For
replies of 4 (corresponding to ERTE mk.4 XOT files) , to enable
a correction to be made for character transmission times towards
the target in ERTE mk.4.0 , ALOG will then give two extra
prompts:

chars per unit:

The reply to this (and the next request) is to give an
indication of the line speed to which all the lines were set (must
currently all be the same). ALOG will then prompt (again mk.4
only)

units per 1/10 sec:

Reply with the number of units (as given as reply to the previous
prompt) per 1/10 second tick. E.G. 10 character per second
terminals would have 1 character per unit and 1 unit per 1/10
second tick. ALOG will then prompt (in all versions)

give mode: all data=1,expand log=2,summary only=3,fixed=4

Return the mode (meaning as follows)

1 Summary of activity of each virtual console; the
the number of records procesed ; the time interval
monitored and a summary of all console activity.

2 As for 1 to Stream 1 plus expanded XOT file to
Stream 2

3 As for 1 to Stream 1 missing out individual
console data

4 As for 1 but over fixed time period (skip first 8
mins then analyse for 30 mins)

For all modes except 4 , the following parameters are
requested by the program:-

MAX RECORDS: The maximum number of records to be analysed. (-1
means all possible records).

MAX TIME: The maximum time (in seconds ) to be analysed (-1
means the maximum possible time).

GRAPHS: Reply 1 means print graphs of REACTION times,
RESPONSE times, USER DELAY times (both for raw
data and normalised). A reply not equal to 1 means
do not.

SKIP FIRST 8:Reply 1 means skip first 8 minutes in file. A
reply not equal to 1 means do not.

All modes (including mode=4) will request a

TITLE: ALOG will read in the next line (until a 'newline'
symbol) to be output on all analysis files.

The virtual console data is of the form:-

1 number of interactions.

2 characters into and out of the target.

3 characters per line into and out of the target.

4 response time from a stimulus being given to the target and
the target being ready to take the next command.

5 reaction time from a stimulus being given to the target until
the first character being received from the target

6 think time.

7 tcp delay (time from first reply to prompt).

8 interaction rate per min.

Information is also produced on the number of
REACTIONS completing within certain time ranges
(satisfaction levels). N.B. interaction rates will be
incorrect if the time interval monitored is not an integeral
number of 10 minute periods.

The current version is 6.0 (14/3/79) and is set up for
upto 128 terminals.

blog

BLOG is an analysis program to obtain REACTION and
RESPONSE times, SATISFACTION LEVELS and a COUNT of
OCCURRENCES for specific TARGET commands. To run the various
versions of BLOG, type:-

f1blog <xotfile>/<datafile>,<logfile> (f1 standard commands mk.3)

csblog <xotfile>/<datafile>,<logfile> (cs1bm standard commands mk.3)

cvblog <xotfile>/<datafile>,<logfile> (cs1bm standard commands mk.4)

BLOG will prompt:-

erte vrsn:

Reply with a 3 (for ERTE mk.3) or a 4 (for ERTE mk.4).

For replies of 4 BLOG prompts for 2 additional pieces of

information:

chars per unit:

units per 1/10 sec:

Reply to these as for ALOG to indicate line speed settings.

BLOG then prompts:

mode:

Return the mode as follows:-

1 Measure response times for standard set of
commands F1 - (IMP, FORTE, EDIT, RUN, LIST ),
CS1BM - (IMP, COPY, E, RUN, FILES).

2 As for 1, but for a user-defined command set

3 As for 1, but over a fixed time period (skip 8
minutes, measure for 30)

4 As for 2, but over a fixed time period (skip 8
minutes, measure for 30)

BLOG next prompts:-

graphs:

Reply '1' if graphs of response times (both raw data and
normalised) for each command are required. Otherwise, reply '0'.

For modes 1 and 2, the number of records to be summarised is
asked for (MAX RECORDS), -1 means all; ditto the max time in
seconds. BLOG will analyse the max records or the max time
possible.

For modes 2 and 4, in response to the prompt:-

commands for analysis:

a maximum of 5 TARGET command names should be input, separated by
spaces on one line. If graphs are to be produced, the message:-

scale for time to prompt:

is output. For each command to be measured, the graph scale size
should be input, bearing in mind that the maximum response time
shown on the graph will be 50*(scale size) ticks. Similarly, the
message:-

scale for time to reply:

is output, and answered.

N.B. for versions before version 2.0 a 38 minute window
was used for modes 3 and 4. In this the first 8 minutes were not
skipped but included in the majority of the results, the
satisfaction levels quoted were also wrong as the count of good
reactions was reset at the end of the first 8 minutes but the
total count of all REACTIONS was not.

The LOG file produced on stream 2 contains records of the
following format

where:

RESPONSE TYPE =0 for RESPONSE times, =1 for REACTION
times.

COMMAND TYPE Lies between 0 and 5 (inclusive) for the
type of command found

TIME Is the actual RESPONSE or REACTION
time in 1/10 second ticks.

This file always starts with the title line of the BLOG
results file and ends with a "-1". This file is normally shipped
up to a larger mainframe (via T44) for further statistical
analysis which is impractical on the original PDP 11.

Current versions 2.0 (f1blog), 2.1 (cvblog), 2.2 (csblog)
(14/3/79) are set up for upto 128 users.

clog

CLOG is an analysis program to obtain the frequency of use
of specific TARGET commands by each virtual console.

To run CLOG, type:-

clog <xotfile>/<data file>

The prompts and responses for CLOG are similar to those for
BLOG. However only two are used (reply as for BLOG)

MODE:

COMMANDS FOR ANALYSIS:

Output from CLOG consists of a single table of commands
against virtual consoles, together with row and column sub-totals.

There is no timing involved with this program and it will
run on XOT files for both mk.3 and mk.4. CLOG is only set up for
the F1 group of standard commands.

Current version 2.2 (15/3/79) is set up for upto 128
termnals.

dlog

DLOG is an analysis program to check whether or not there
have been any untoward happenings during the run. It currently
searchs the XOT file for replies from the EMAS network which
would indicate some trouble. These messages currently are:

EMAS?

** 2970 DOWN

SYSTEM DOWN

NO USER SERVICE

SYSTEM FULL

INVALID USER

INVALID PASSWORD

INVALID NAME

NOT AVAILABLE

To run DLOG, type:-

dlog <xotfile>/<data file>

DLOG will prompt:-

TITLE:

It will then read in the next line as a title line to be out
put at the head of the datafile.

The output will tell the number of occurrences of the EVIL
messages over the first 8 minutes, the monitored window (the next
30 minutes) and the whole file. It will also check that all the
virtual consoles managed to log-on successfully. DLOG is
currently only set up for use with ERTE mk.3 and the EMAS
targets.

Current version 7 (15/11/78) is currently set up for upto
128 terminals.

plog

PLOG is an analysis program to reproduce the 'console log'
of any virtual console in the XOT file.

To run PLOG, type:-
plog <xotfile>/<datafile>

PLOG will prompt:-

MODE:

MODE=1 means print log over whole file. MODE=4 means print
log over monitored window only.

VIRT CNSL:

Reply with the number of the virtual console whose log is
required. If logs are wished for a range of virtual consoles then
reply -1. In the case of a -1 reply PLOG will then prompt

FIRST CNSL:

LAST CNSL:

The number of the lowest and highest virtual consoles of the
group of consoles whose logs are required should be the replies.

MAX RECORDS:

The maximum records in the XOT file which should be
analysed in printing the logs should be the reply (-1 means all
records).

MAX TIME:

The maximum amount of time in the XOT file to be considered
while printing out the logs should be the reply (-1 means the
whole file). All times are in seconds.

TITLE:

The program will read in the next line and will output it at
the head of all the logs it prints.

PLOG will then output all messages going to and from the
virtual consoles in question.It will append the times at which
there is any change in the direction of the message flow and will
indicate in which direction the messages are flowing (i. e. to
or from the TARGET).

PLOG will run on either mk.3 or mk.4 XOT files but has not
been adjusted to take into account the timing differences on input
between the mk.3 and mk.4 as it was not envisaged that this
utility would be used to guage those times to any great accuracy.

Current version 1.2 (24/1/79) is set up for upto 128
terminals.

overlord

OVERLORD is utility to analyse several XOT files in one
run. This program will search all the file systems on a logical
disc unit for XOT files; once it finds one it will call a version
of DLOG (named DLIG ) to check if the run was successfull. If
the run was a success the a version of ALOG ( ALIG ) will be
called to analyse the file as for mode 4 of ALOG, it will also
print out corrected values for the major performance metrics
taking into account any messages resulting from unsuccessfull log
ons. Then a version of BLOG ( BLIG ) is called as though for
mode 3 of BLOG. Once the entire logical unit has been scanned
the program will ask if the files created should be printed (via
the C.S. FILESTORE printer) and then destroyed. All replies to
OVERLORD prompts are on a single line. To run OVERLORD, type:

OVER

OVER will request

XOT UNIT:

reply with the number of the logical disc unit
to be scanned. OVER will then request

TITLE:

The line, typed in will be copied onto the
top of all files produced during the run. OVERLORD
will then, type out some information on the results
it is about to produce and then start to analyse
XOT files. When all the file systems have been
checked it will then request

PRINT:

Reply with "y" to have all files produced
printed on the FILESTORE printer, "n" if not.
OVER will then prompt

DELETE:

Reply with "y" if all files generated during
the run are to be destroyed, "n" if not.

During the running of OVER, DLIG will produce files called
CERT in the same file system as any XOT file it finds, ALIG (
if called ) will produce files called RESL and BLIG will produce
files called BLOG. All thses files are created on logical disc
unit 0. Each file produced will have a copy of the title line
printed at its head and will have the number of the filesystem in
which the corresponding XOT file was found appended to this title
line.

This program will require the C.S. department FILESTORE
to spool all printing of the results files. No version of
OVERLORD has been produced yet for ERTE mk.4.0 ( owing to the
lack of DLOG for these XOT files ). When the change is made to
run this on mk.4 XOT files both BLIG and ALIG will require
minor changes, the changes in BLIG are essentially the same as
those indicated in the BLOG listings.

Current version 1.3 (15/11/78) uses " LIG " versions set up

for upto 128 terminals. The current versions are:

ALIG - auto 1.3 (18/12/78).
BLIG - auto 2.0 (16/3/79), CS1BM standard commands.
BLIG - auto 2.1 (16/3/79), F1 standard commands.
DLIG - auto 1.4 (16/3/79).

Section 8: script file utilities

anal

ANAL is a utility for checking out individual SCRIPT files
made up to ERTE mk.3 standard. It will check that the file is in
the correct format and give a compacted listing of the file, some
information on the input character rate and think times contained
in the file and if required a cleaned up version of the file. To
run it, type:

ANAL <scriptfile>/<listing file>,<new script file>

ANAL will prompt

GIVE SCRIPT FILE name:

Reply with the name of the SCRIPT file involved (the whole
line is read and reproduced on top of all listing files as with
the TITLE line in the XOT analysis programs). ANAL will then
prompt

MODE:

Where

MODE=1 Print compacted listing file and produce summary
of think time and character input produced by this
script.

MODE=2 Only print think time and character input summary.

MODE=3 Create new SCRIPT file on stream 2, removing all
redundant spaces in check lines and think time
lines. This mode was also used to translate the
original F1 scripts which had the pre-network
logon sequences.

Current version 1.4 (15/3/79).

script analyser

The SCRIPT ANALYSER is a specially modified version of
ERTE which will run through a set of scripts (defined by a single
TKPAR file) and will check that they are valid and produce some
statistics on the expected typing and think time delays as well as
information on the distribution of distinct input lines. To run
it the TKPAR file, the SCRIPT ANALYSER and the specially
modified SCRIPT task (which currently takes upto 48 consoles)
must all be in the same file system on unit 0. It is not
recommended that this utility be run in file systems used for
normal ERTE work. This is currently only set up for mk.3. While
running the modified SCRIPT task removes lines of input from the
SCRIPT files, logs the think times and input line, and then
pauses for a fixed response time ( 3 seconds) before going onto
the next input line for that script. Currently upto 48 scripts
can be handled at once in this single modified SCRIPT task, but
there can only be 1 TKPAR file. To use this, type:

SCRIPY

The TIMER task will then be loaded and an appropriate

message put out. It will prompt:

Number of tasks:

Reply with a 1. There is no reason why further special
SCRIPT tasks should not be made up and run in parallel. However
they would effectively each produce information on the particular
benchmark defined in their own TKPAR file and this data would not
be merged in any way. There may also be some confusion as to what
information is coming from which special SCRIPT task as all
output is currently to the console and not to a file ( it is a
trivial operation to put the output to a file for each special
script task).

SCRIPY will next output a message saying how many scripts it
is analysing (similar to that put out by a normal ERTE SCRIPT
task on start up) and will proceed. The analysis can take some
time. All the INT mechanisms for the normal SCRIPT task apply
to this special SCRIPT task (which is also usually called TSK).
When the SPECIAL SCRIPT task has finished (either all scripts
reach state 7 or an INT A is given) then the following data is
put out on the console (the printing can take some time).

Buffer Usage Data on the usage of the internal script
buffers held by the SCRIPT task. This
can be very useful in tuning the buffer
size held by these tasks for any
particular benchmark.

Input Text Data on the number of occurences of
various lines of input text in the
benchmark. These distinct input lines
are currently defined as distinct sets of
letters occuring before a "(" or any
number. This can be useful in obtaining
counts of various target commands etc in
a benchmark for validation.

Distributions Graphs of the distributions of INPUT
LINE LENGTH, THINK TIME and TOTAL
DELAY from the USER ( THINK TIME +
TYPING DELAY ).

Command Count A count of the total number of commands
in each script in the benchmark.

When the test run is complete the TIME task will still be
running, this can be PURGED or the system may be re.ipl'd. The
source file for the special SCRIPT file is usually called SCAN.
As this is using a very non standard SCRIPT file it is advised
that this be run in a completely separate file system from normal
ERTE work.

Current version 2 (22/2/78).

script translator

This utility is set up for ERTE mk.3 scripts. It takes a
set of SCRIPT files all residing an the same unit and file system
whose file names all share the same first 4 characters (known as a
family) and creates a new family on a nominated unit and file
system. This new family is a duplicate of the original (perhaps
it should be called cloning). It also changes their target user
number family names to a new family ( E.G. it can translate all
ECSB to XXYY if required to make up a further set of scripts for
a particular benchmark). It is currently based heavily on
requirements to increase workload size on the EMAS targets and
has been used to set up new F1 and CS1BM benchmark units by
replicating current ones. To run this, type:

SCTR

It will prompt

OLD FILE GROUP:

Reply with something of the form

<logical unit>.<family name>(<file system>)

LOGICAL UNIT Is the logical disc unit holding the
original SCRIPT file family

FAMILY NAME Is the first 4 characters of the SCRIPT
file name, common to all family members.

FILE SYSTEM Is the file system holding the original
SCRIPT files (in octal).

E.G. 3.scrp(21)

NEW FILE GROUP:

Reply in the same format as above to define the new SCRIPT
file family name. SCTR will next prompt
OLD JOB NO:

Reply with the 4 character family name of the target user
number used by all the scripts in the original SCRIPT files.
NEW JOB NO.:

Reply with the 4 character family name of the target user
name to be used by all the scripts in the new SCRIPT files. SCTR
will call a program named TRIN for each file of the family it
comes across. TRIN will copy the original file into a new one and
at the same time will translate all occurences of text in the
format < OLD JOB NO >< 2 digits > into < NEW JOB NO >< 2
digits > E.G it could change the job numbers from ECSB to
GUWS.

Current version 1.1 (22/11/78).

Section 9: Other relevant documentation

ADAMS J.C. "The Experimentor's Guide for EMAS 4/75"
ESP Report 1978

ADAMS J.C. "The Experimentor's Guide for EMAS 2900"
ESP Report 1978

ADAMS J.C. "The Instant ERTE Guide"
ESP Report 1978

ADAMS J.C. CURRIE W.S. and GILMORE B.A.C. "The Structure and Uses of The Edinburgh Remote Terminal Emulator"
CS DEPT Report CSR-12-77 1977 and Software Practice and Experience vol. 8 no. 4 1978

BREBNER G.J. "The MAVIS User's Guide"
ESP Report 1977

BREBNER G.J. "MAVIS - A Script Generator for ERTE"
ESP Report 1977

BREBNER G.R. "Noddy Explores The Network - T44, The Single User NSI Work Station"
ESP Report NOV 1978

CURRIE W.S. "The Utility Routines"
ESP Report MARCH 1977

GILMORE B.A.C. "User Manual for DEIMOS - An Operating System for the PDP 11"
ERCC MAY 1978

ROBERTSON P.S.R. "The IMP-77 Language"
CS DEPT Report CSR-19-77 1977

SHAW S. "Benchmark Utilities on the 2970"
EMAS 2900 Documentation ERCC NOV 1978

SHAW S. "Setting Up Processes for the F1 Benchmark"
EMAS 2900 Documentation ERCC NOV 1978