Trailing-Edge
-
PDP-10 Archives
-
BB-J845A-SM
-
documentation/dn60m.man
There are 2 other files named dn60m.man in the archive. Click here to see a list.
DN60
Maintenance Manual
Document Number: JBS-77-001-02-U
(formerly 130-952-066)
October 31, 1978
This manual is written for the person who
has the responsibility to maintain the DN60
software on a DECsystem-10 or DECSYSTEM-20.
Operating System and version: TOPS-10 6.03
or TOPS-20 3.0.
Software version: DN61D version 2, DN61S
version 2, DN61B version 1. DN64A
version 1. DN62S version 1. DN62D
version 1 and DN65S version 1.
digital equipment corportation, maynard, massachusetts
First Printing: June 23, 1977
Revised: September 17, 1977
Revised: October 31, 1978
"The information in this document is subject to change
without notice and should not be construed as a commitment
by Digital Equipment Corporation. Digital Equipment
Corporation assumes no responsibility for any errors that
may appear in this document.
The software described in this document is furnished under a
license and may be used or copied only in accordance with
the terms of such license.
No responsibility is assumed for the use or reliability of
software on equipment that is not supplied by DIGITAL or its
affiliated companies."
Copyright (C) 1980, 1978 by Digital Equipment Corporation
The following are trademarks of
Digital Equipment Corporation:
COMPUTER LABS DECUS FOCAL MASSBUS
COMTEX DECsystem-10 INDAC RSTS
DDT DIBOL LAB-8 RSX
DEC DIGITAL OMNIBUS TYPESET-8
DECCOMM EDUSYSTEM OS/8 DECSYSTEM-20
DECtape FLIP CHIP PDP TYPESET-11
PHA UNIBUS
Table of Contents
Chapter 01 -- INTRODUCTION
Chapter 02 -- DATA STRUCTURES OVERVIEW
Chapter 03 -- PREFIX SECTIONS
Chapter 04 -- SECTION "MININT"
Chapter 05 -- SECTIONS "INIT1", "INITDQ", "INITUP" and
"INIT2"
Chapter 06 -- SECTION "STGMAN"
Chapter 07 -- SECTION "QUEING"
Chapter 08 -- SECTIONS "DQ11", "DUP11" and "KMC11"
Chapter 09 -- SECTION "MDCODE"
Chapter 10 -- SECTION "MSGHDL"
Chapter 11 -- SECTION "DISPAT"
Chapter 12 -- SECTION "BSC"
Chapter 13 -- SECTION "DL10"
Chapter 14 -- SECTIONS "DTE10" and "DTE20"
Chapter 15 -- SECTION "XL3780"
Chapter 16 -- SECTION "XLHASP"
Chapter 17 -- SECTION "CHK11"
Chapter 18 -- DEBUGGING FACILITIES
Chapter 19 -- ASSEMBLY INSTRUCTIONS
Chapter 20 -- THE CAL11. UUO
Chapter 21 -- DIFFERENCES FROM THE DAS78
Chapter 22 -- PERFORMANCE ESTIMATES FOR THE DN61
Chapter 23 -- BINARY SYNCHRONOUS PROTOCOL (BISYNC)
Appendix A -- DTE10 FORMATS
CHAPTER 1
INTRODUCTION
1.1 AUDIENCE
This document is intended to be read by persons having
responsibility for maintenance and/or modification of the
DN60 front end software. This document is intended to be
read together with the listing of the DN60 program, and, to
facilitate this, the information in this document is
generally presented in the same order as the reader will
find it in the listing.
Other persons may find this document interesting because of
the "inside" information it provides about the DN60
software, but such persons are not the intended audience.
Chapter 23, which is a tutorial on BISYNC, may be read
independently of the rest of this manual.
1.2 ORGANIZATION
The DN61-D hardware package consists of a PDP-11/40
processor interfaced to a DL10 and from one to 12 DQ11-D's
or DQ11-E's. Also included in the package are 16K words of
parity memory, a KW11-L line frequency clock and a KG11-A
CRC calculator. It interfaces to a DECsystem-1070, 1080 or
1090.
The DN61-S is the same except that it has 32K of memory and
uses a DTE20 in place of the DL10. It interfaces to the
DECsystem-1090.
The DN61-B hardware package consists of a PDP-11/34
processor interfaced to a DTE20 and from one to 12 DUP11's.
Also included in the package are 32K words of parity memory,
up to 3 KMC11 microprocessors and a KW11-L compatable line
frequency clock. It interfaces to the DECsystem-1091.
INTRODUCTION Page 1-2
ORGANIZATION
The DN64-A hardware package is the same as the DN61-B
hardware package. It interfaces to the DECSYSTEM-20.
The DN61-D hardware package is very similar to the DN87
hardware package. In the same way, the DN61-S is very
similar to the DN87S. The DN61-B and DN64-A use a subset of
the DN20 configurations. The DN62 and DN65 use same
hardware as the DN61 and DN64 respectively.
The purpose of the DN60 front end software is to provide the
following functions:
1. Driving the synchronous lines, which may require
service at up to 100,000 bits per second.
2. Converting DECsystem-10/20 data formats to the
formats required by the IBM 360, IBM 370, HASP
Multileaving Workstation, IBM 3780 and IBM 2780.
3. Converting the data formats used by the IBM 360,
IBM 370, IBM 3780 and IBM 2780 to the format used
by the DECsystem-10/20.
4. Scanning the messages received from the synchronous
lines to extract the data embedded in the BSC
protocol.
5. Putting data into a BSC "envelope" to transmit it.
To accomplish these tasks efficiently and reliably, the DN60
front end software is organized as several loosely coupled
tasks. These are:
1. BSC - the task that performs BSC interpretation.
2. XLATE - the task that translates data formats.
3. XLHASP - the task that translates, compresses and
decompresses data for HASP Multileaving.
4. DL10 - the task that communicates with the PDP-10.
5. IDLE - the task that performs background functions.
(Some of these task names are also section names.)
In addition to the tasks there are subroutines used by
several tasks, interrupt routines, initialization, and the
dispatcher that allocates time to the tasks. All of these
are organized into 26 sections, as follows:
INTRODUCTION Page 1-3
ORGANIZATION
1. S - symbol definitions common to many Digital
Equipment Corporation products.
2. DN61D - parameters for the DN61-DA and DN61-DB.
3. DN61S - parameters for the DN61-SA and DN61-SB.
4. DN61B - parameters for the DN61-BA and DN61-BB.
5. DN62S - parameter for the DN62S
6. DN64A - parameters for the DN64-AA and DN64-AB.
7. MACROS - some useful PDP-11 macros.
8. DEFINE - definitions for the DN60.
9. MININT - "minor" interrupt routines.
10. INIT2 - section 2 of initialization.
11. STGMAN - subroutines to manage "free storage".
12. QUEING - subroutines to send and receive inter-task
data.
13. DQ11 - subroutines for driving the DQ11's.
14. DUP11 - subroutines for driving the DUP11's.
15. KMC11 - subroutines for driving the KMC11/DUP11
combination.
16. MSGHDL - subroutines for processing "messages".
17. DISPAT - the task dispatcher.
18. BSC - the BSC task.
19. DL10 - the PDP-10 communications task, using a
DL10.
20. DTE10 - the PDP-10 communications task, using a
DTE20 on the DECsystem-10.
21. DTE20 - the PDP-10 communications task, using a
DTE20 on the DECSYSTEM-20.
22. XLHASP - the HASP Multileaving translation,
compression and decompression tasks.
23. XL3780 - the IBM 3780/2780 translation and
background tasks.
INTRODUCTION Page 1-4
ORGANIZATION
24. INITDQ - initialization for the DQ11's.
25. INITUP - initialization for the DUP11's and
KMC11's.
26. MDCODE - a binary image of the KMC11 microcode.
27. INIT1 - section 1 of initialization.
28. CHK11 - once-only hardware testing.
This document will discuss each of these sections. First,
however, it is appropriate to introduce the data structures.
CHAPTER 2
DATA STRUCTURES OVERVIEW
The data structures are the heart of the DN60 front end
program. Detailed discussion of some of the data structures
will be deferred to the appropriate chapter, but to make
this document comprehensible on first reading, the basic
ones must be given here.
2.1 CHUNKS
Initially all of storage beyond the end of the operational
program, including the once-only, go-nogo hardware test,
CHK11, is divided into "chunks". A chunk is 140 or 300
octal bytes of core storage. Initially all chunks are on
the "free list". When a chunk is on the free list it
contains a pointer to the chunk preceeding it on the free
list and to the chunk following it. In addition, bit 0 of
the first word of the chunk is set as a flag that the chunk
is "free".
A task or interrupt routine can obtain chunks for its use
from the free list, and a task can return chunks to the free
list. A task or interrupt routine can send chunks to a
task, and a task can receive, in the order sent, chunks sent
to it. In order to accomplish this, the first two words of
a chunk are reserved for a link word and a length word.
Chunks are used individually to store data received from the
DQ11's and from the PDP-10 through the DL10 or DTE20.
For constructing tables, a number of contiguous chunks can
be obtained from the free list. This ability is used to
construct almost all of the tabular data structures, such as
line control blocks, task control blocks, etc. In this
case, the first word of the first chunk contains the length
of the table and the rest of the chunks are considered part
of the table, without reservation of link or length words.
It is possible to free a table, but the subroutine to do
this is not used on the DN61 or DN64.
DATA STRUCTURES OVERVIEW Page 2-2
MESSAGES
2.2 MESSAGES
Chunks may be combined into messages. For this purpose
chunks are strung together by their link words, and each
length word indicates the number of message characters
stored in the chunk. The first chunk contains no data; it
contains information about the message needed for further
processing, such as its total length. The last chunk may
not be full if the message does not fit exactly in the
chunks provided. The last chunk can be recognized because
its link word is zero. In addition, it is possible for a
message to have several empty chunks allocated to its end to
simplify message translation. Messages produced by the
KMC11 may have all of their chunks less than completely full
to decrease the chances of the KMC11 trying to over-fill
one.
Messages may be sent from one task to another, and a task
can retrieve, in order, messages sent to it. This ability
is used to send extracted data from the BSC task to the
XLATE task, to send ASCII data from the XLATE task to the
DL10 or DTE task to be placed in PDP-10 memory; and to send
constructed messages from the XLATE task to the BSC task for
output. Some space in the first chunk of a message has been
reserved to provide for the transmitting and receiving
functions.
The current message is usually pointed to by R0, but R0 is
often used for other purposes.
2.3 LINE CONTROL BLOCKS
The line control block (LCB) is built from chunks when the
line is first enabled by a PDP-10 program. It is the root
of the data structure for a particular DQ11 synchronous
line. The LCB contains statistical data for monitoring line
performance, "tracks" for debugging the DQ11's, and pointers
to the BSC and XLATE task control blocks for processing data
to and from this line. There is a GLOBAL table called
"DQLCB" which points to each line control block.
The current LCB is often pointed to by R4.
2.4 TASK CONTROL BLOCK
As was mentioned above, each line control block has two task
control blocks: one for the BSC task and one for the XLATE
task. A task control block represents an "invocation" of
one of these reentrant tasks. The task control block holds
the information specific to each invocation: the program
DATA STRUCTURES OVERVIEW Page 2-3
TASK CONTROL BLOCK
counter, a pointer to the stack, a pointer to the line
control block, etc. In a front end with more than one
synchronous line, considerable savings in program storage is
achieved by using common code to drive each line. On a
machine with a fixed memory size, decreased program storage
is directly translated to increased data buffering
availability, which means improved performance.
The TCB of the current task is always pointed to by R5.
2.5 SILO
When reading data with the help of a KMC11, the input
characters are placed in a silo. Each LCB has two silos, of
which at most one is active. A silo points to the chunk
that is being filled and has provision for signaling the
PDP-11 when the next character is stored (in case the
process using the characters is waiting) and for signaling
the PDP-11 when the silo fill point has reached the "warning
level". When this warning level is reached the PDP-11
switches the KMC11 to the other silo and completes
processing of the chunk pointed to by the old silo. The
warning point is set so that the PDP-11 will have time to
perform this switch before the chunk is filled to capacity,
since if it is filled the KMC11 is forced to discard further
characters.
2.6 REGISTER CONVENTIONS
There are some "usual" register conventions. No CPU time is
ever wasted in merely conforming to these conventions, but
when there is an arbitrary choice of which register to use
(as is almost always the case), the following guidelines are
followed:
R0 points to the current message or chunk
R1 contains the current character
R2 contains a character count
R3 points to the CSR for the current DQ11/DUP11 or to
the current KMC11 silo
R4 points to the current LCB
R5 points to the current TCB (When in a task, always
points to that task's TCB.)
R6 always points to the current stack
When the function listed for a register is not needed, the
register is free to be used for other purposes.
DATA STRUCTURES OVERVIEW Page 2-4
REGISTER CONVENTIONS
In a few "inner loops" there is an extended comment
explaining register usage. Maximum use is made of registers
in these cases for efficiency.
CHAPTER 3
PREFIX SECTIONS
The prefix sections are used to define symbols and set
parameters. They are assembled before the code. Only
section DEFINE allocates any storage.
3.1 SECTION "S"
The section named "S" contains definitions for many Digital
Equipment Corporation products built from the same (or
similar) hardware base as the DN61 or DN64. Many of the
definitions here are not used by the DN60. "S" is a
cross-product file which has been evolving since the DC76,
so do not attempt to assemble the DN60 front end software
with any copy of "S" other than the one shipped with it.
(Comparison with other versions may prove interesting,
however.)
Because section "S" is a library of definitions, it may seem
to imply support for, for example, a PDP-11/03; the other
sections, however, are not written in as machine independent
a manner as "S", with the result that the DN60 front end
software is supported only on the hardware provided for it
by Digital Equipment Corporation.
3.2 SECTIONS "DN61D", "DN61S", "DN61B" AND "DN64A"
Sections "DN61D", "DN61S", "DN61B" and "DN64A" specify those
parameters which have different values in various versions
of the DN60. Only one of these sections is assembled for
each product. Eventually, other sections will be added
here: "DN62B", "DN62S" and "DN65A" are currently planned.
PREFIX SECTIONS Page 3-2
SECTION "MACROS"
3.3 SECTION "MACROS"
The "MACROS" section is a library similar to "S". It is
separate so that it can be conditionalized based on "DN61D",
"DN61S", "DN61B" and "DN64A".
3.4 SECTION "DEFINE"
The "DEFINE" section contains the definitions for the DN60
front end software. It defines parameters, data structures,
the layout of the DL10 window, and the GLOBAL storage
locations. The GLOBAL storage locations are available to
all tasks rather than duplicated for each task. The
parameters are defined symbolically only for the purpose of
making the reading of the program easier; the only
supported settings are the ones distributed.
CHAPTER 4
SECTION "MININT"
This section contains the minor interrupts and miscellaneous
subroutines.
4.1 MINOR INTERRUPTS
The minor interrupts are as follows:
1. Parity error
2. Bus trap
3. Illegal instructions, which are: Invalid
instructions, IOT instruction, and EMT instruction.
4. Trace trap: BPT instruction and T-bit trap.
5. Clock
6. Power Failure
7. Unknown
All of the minor interrupts except clock cause an error
stop. (See Chapter 18 on debugging for more information on
the T-bit trap.) The clock interrupt is covered in Chapter
11, the Dispacher chapter.
4.2 MISCELLANEOUS
Several miscellaneous subroutines, which could not be
reasonably calssified as belonging to another section, are
here. These include T-bit tracing, chunk ownership
recording and the KG11-A simulator. The KG11-A simulator is
needed on the DN64A and DN61B because the DN20 configuration
does not include a real KG11-A.
CHAPTER 5
SECTIONS "INIT1", "INITDQ", "INITUP" AND "INIT2"
These sections constitute the initialization code. Although
they perform only one function, they have been divided into
four sections so that INIT1 can be overlayed by the chunks
and to permit the DQ11's to be replaced by DUP11's in the
DN64A and DN61B. INIT1 and INIT2 contain the part of the
initialization that is done before chunks are created, and
INIT2 contains the chunk creation code and the parts which
must be done after chunks are created.
5.1 INIT1
INIT1 consists of message printing and a call to CHK11. The
purpose of CHK11 is to verify that the hardware is
operational. See Chapter 17 on CHK11 for more details.
5.2 INITDQ
INITDQ consists of a subroutine called by CHK11 to test the
DQ11's.
5.3 INITUP
INITUP consists of two subroutines called by CHK11 to test
the DUP11's and KMC11's. This section replaces INITDQ in
the DN64A and DN61B.
5.4 INIT2
INIT2 creates the chunks, puts them on the free list by
calling the subroutine FRECHK which returns chunks to the
free list, and creates one permanent task control block for
the IDLE task and one for PDP-10 communication. Finally
SECTIONS "INIT1", "INITDQ", "INITUP" AND "INIT2" Page 5-2
INIT2
INIT2 initializes the DL10 or DTE20, waiting as long as
necessary for the PDP-10 to come on line, and branches to
the dispatcher, which will distribute time between the
tasks. The branch to the dispatcher is done using the "RTI"
PDP-11 instruction to set the CPU priority level to zero,
thus enabling interrupts.
CHAPTER 6
SECTION "STGMAN"
The storage management section consists of a set of
subroutines which may be called from any task or from the
initialization code. These subroutines may not be called
from an interrupt routine. (The technique used by an
interrupt routine to obtain a chunk from the free list will
be discussed later.)
6.1 GETTCB
This subroutine allocates a task control block. GETTCB is
used by initialization (see above) and when a line is
enabled for the first time. It consists mostly of calls to
GETSTG (see below) and of storing linkage pointers in the
task control block. This is a subroutine because a task
control block consists of two non-contiguous parts: the TCB
itself and the stack.
6.2 GETSTG
This subroutine obtains contiguous space from free storage.
It works by scanning the free storage list looking for
enough contiguous free storage to satisfy the request. The
algorithm is complicated by two factors:
1. To save time, the free list is not sorted.
2. Interrupt routines may obtain a chunk after this
subroutine decides it needs it but before it gets
it.
GETSTG must thus scan the free list for the chunk it wants
and be prepared to free all of the storage it has obtained
and to try again if it misses a chunk.
SECTION "STGMAN" Page 6-2
FRESTG
6.3 FRESTG
This subroutine returns a block of storage obtained by
GETSTG to the free list by breaking it up into chunks and
calling FRECHK.
6.4 GETCHK
This subroutine gets a chunk from the free list. Unlike the
traditional calling sequence for this subroutine, this
version of GETCHK takes a parameter: the address of the
chunk to get. This parameter is for GETSTG, which wants a
particular chunk; all other callers just get the address of
a free chunk from CHLST, one of the GLOBAL cells.
The free list is structured as a doubly-linked list. Chunks
are on the free list in no particular order. Global cell
CHFST points to the first chunk and CHLST points to the
last. At least one chunk is always on the free list.
Every chunk on the free list has bit 0 of its first word set
so that GETCHK can detect that an interrupt routine has
taken the chunk it is working on.
6.5 FRECHK
This subroutine returns a chunk to the free list. It also
clears the chunk, since it is convenient to have a
just-gotten chunk be clear. Because clearing a chunk is
time consuming, most freeing of chunks is done by the IDLE
task. Other tasks pass chunks to be freed to the IDLE task.
CHAPTER 7
SECTION "QUEING"
This section contains subroutines to send and receive
messages and individual chunks between tasks. A chunk can
be sent by an interrupt routine, but all other functions can
be performed only by tasks.
7.1 QUEMSG
This subroutine sends a message to a specified task. A task
is specified by its task control block, since a
specification of "the BSC task" would be ambiguous if there
were more than one enabled line and therefore more than one
invocation of the BSC task.
7.2 DEQMSG
This subroutine obtains for a task the oldest message sent
to it.
7.3 DEQMID
This subroutine obtains for a task the oldest message sent
to it which has a certain identification. This is used by
the DL10 task to get a message from a particular line to
satisfy a PDP-10 program's request for data from a
particular line. This is necessary because there is only
one DL10 task (since there is only one DL10 or DTE20) and
all messages for the PDP-10 must be sent to it.
Note that the DL10 task drives either the DL10 or the DTE20
depending on which is present in the configuration.
SECTION "QUEING" Page 7-2
QUECHK
7.4 QUECHK
This subroutine sends a chunk to a task. QUECHK can be
called from an interrupt routine. The DQ11 and DUP11
interrupt routines use QUECHK to send chunks containing
received data to the BSC task.
7.5 DEQCHK
This subroutine obtains for a task the oldest chunk sent to
it. The algorithm is complicated by two factors:
1. Subroutine QUECHK may be called by an interrupt
routine to place a chunk on a task's list just as
this subroutine is trying to get a chunk off the
list.
2. For efficiency, a chunk contains only one link, so
the list can be linked only one way.
CHAPTER 8
SECTIONS "DQ11", "DUP11" AND "KMC11"
These sections contain subroutines to drive the DQ11, DUP11
or KMC11/DUP11. They are covered in one chapter because
they substitute for one another depending on the hardware
configuration. Most of the rest of the DN60 software is
unaware of the substitution. For this reason they have the
same entry points.
Each section contains driver subroutines, interrupt
subroutines, modem status subroutines, the TRAPDQ
subroutine, the "once per clock tick" subroutine (needed for
high-performance BSC interpretation on a DQ11), and the
control messages ACK-0, ACK-1, NAK, etc. used by BISYNC.
See Chapter 23 for more information on BISYNC.
The three sections will be discussed together, with
differences pointed out as they occurr. The phrase "line
driver" will be used to refer to the DQ11, DUP11 or
KMC11/DUP11 as appropriate.
8.1 DRIVING SUBROUTINES
The driving subroutines are as follows:
1. DQINIT - initializes the line driver.
2. DQREAD - conditions the line driver for input.
3. DQWRIT - conditions the line driver to output a
data message.
4. DQCNTL - conditions the line driver to output a
control message.
5. DQINWQ - checks for more characters to be
processed.
SECTIONS "DQ11", "DUP11" AND "KMC11" Page 8-2
DRIVING SUBROUTINES
6. DQKILL - terminates any line driver activity.
These subroutines are all highly device dependent.
Complicating the output-type calls is the possibility that
the program must wait a few milliseconds between the raising
of the request to send signal and the start of data so that
the IBM equipment can get ready to read the data. This is
done, when required, by waiting one or more jiffies after
asserting "request to send" before believing "clear to
send". Thus, if the modem does not provide the required
delay, the software will, and if the modem needs a longer
delay, the software will wait for it.
The delay is required because the IBM 360'S channels are
half-duplex, and under some of IBM's operating systems there
may be a delay of several milliseconds between the time the
communications adapter finishes a write and the time the
software instructs the adapter to start the read. Some IBM
systems may need no delay, so there are provisions to start
outputting data as soon as CTS comes up, even if that is
immediately.
On zero turn-around-time modems the DQ11 is given its "read"
command without waiting for the carrier signal, to avoid
missing the first character of a reply due to interrupt
overhead. The DUP11 is always given its "read" command
without waiting for the carrier signal because some DUP11's
don't interrupt upon transition of the carrier signal.
In the KMC11/DUP11, when the write is complete there is a
special case check for a read, and the read is started
immediately by the KMC11 if it is requested. (See Chapter 9
for more information on the KMC11 microcode.)
The DQINWQ subroutine is used to check for more characters
to be processed. On the DQ11, the hardware registers are
checked to see if the current chunk has had unprocessed
characters stored in it. On the DUP11, since it gives an
interrupt per character, there are never more characters to
be processed. On the KMC11/DUP11, the silo is checked for
the presence of unwanted characters. If we are running
short of CPU time (which can happen if the line is running
faster than we can process the characters) we wait for the
chunk to fill even if it contains unprocessed characters.
8.2 INTERRUPT ROUTINE
The interrupt routine uses the four condition code bits in
the PS to select among the twelve possible line drivers.
Thus the interrupt routine is common to all the lines. This
routine does error recording, chaining of writes from chunk
SECTIONS "DQ11", "DUP11" AND "KMC11" Page 8-3
INTERRUPT ROUTINE
to chunk of a message (except when using a KMC11) and
chaining of reads to chunks obtained from the free list.
Modem interrupts are also processed by this routine. The
algorithm is complicated by the double buffered nature of
the DQ11; since the DQ11 contains no silo (as the DV11, for
example, does), it must have a new buffer available
immediately when it finishes with an old buffer. This means
that the program must always stay one buffer ahead of it,
since a buffer interrupt means that the DQ11 has one buffer
left.
The DUP11 is worse since it is a character-at-a-time
interrupt device running at low priority. The interrupt
routine must allow other DUP11's to interrupt in certain
cases in which an interrupt takes a long time to process.
In the KMC11/DUP11 much of the work is done by the KMC11
microprocessor. The KMC11 provides two interrupts. The "A"
or "XX0" interrupt is used to inform the PDP-11 of a silo
condition. A silo can be flagged to cause an interrupt when
the next character is stored in it. Even if it is not so
flagged it will cause an interrupt when it reaches the
warning level and when it is about to overflow. The
interrupt code goes through all the silos processing any
that need attention. This processing is done by subroutine
MDSLEM, which usually just updates the length field in the
chunk being filled so that the BSC task can "see" the new
character(s). If, however, the chunk has been filled to its
warning level, then a new chunk is obtained and the silo
pointer is changed so that subsequent characters will be
placed in it.
The "B" or "XX4" interrupt is used to inform the PDP-11 of
the completion of a write or kill operation, or of an error.
As for the silo interrupt, the interrupt code scans the
LCB's and processes each LCB which is marked as "complete"
or "kill complete".
The GETCHK subroutine cannot be called from an interrupt
routine; to get a chunk the interrupt code removes a chunk
from the free list by executing the sequence:
MOV CHFST,R0 ;FIRST CHUNK ON FREE LIST
CMP R0,CHLST ;ONLY ONE CHUNK LEFT?
BEQ ERROR ;YES, OUT OF CHUNKS
MOV (R0),R1 ;NO, GET NEXT CHUNK
BIC #1,R1 ;ZAP FREE FLAG
MOV R1,CHFST ;NEXT IS NOW FIRST CHUNK
CLR (R0) ;CLEAR "FREE" BIT
; AND FORWARD POINTER
CLR 2(R1) ;CLEAR BACK POINTER
DEC CHFREC ;ONE FEWER FREE CHUNK
R0 now contains a pointer to the chunk obtained from the
SECTIONS "DQ11", "DUP11" AND "KMC11" Page 8-4
INTERRUPT ROUTINE
free list.
8.3 SUBROUTINES FOR MODEM SIGNALS
Three subroutines are used to manipulate modem signals:
8.3.1 DQDTR0
This subroutine clears Data Terminal Ready (DTR).
8.3.2 DQDTR1
This subroutine sets Data Terminal Ready (DTR).
8.3.3 DQMDMS
This subroutine returns the values of DTR and DSR.
8.4 TRAPDQ
If the debugging assembly-time switch has been set, this
subroutine is used in the event of a fatal error to store
the DQ11's or DUP11's registers in the line block (LCB).
This information can sometimes be valuable for debugging.
8.5 ONCE A JIFFY
Once each clock tick (jiffy) the dispatcher calls the DQ11
section to flush out any characters that might be "caught"
in the current receive buffer. This is needed because a
message might be very short (for example, EOT) and if no
data arrives after the message ends (which happens with some
modems), a delay would occur for the receiver timeout before
processing of the message could proceed. Thus, once per
jiffy, any unprocessed characters in the current receive
buffer are made available to the BSC task for processing.
On the DUP11 this subroutine mearly checks the modem signals
and processes any transitions which may have occurred.
Since the DUP11 interrupts for each character the BSC task
is awakened, if necessary, at interrupt level.
SECTIONS "DQ11", "DUP11" AND "KMC11" Page 8-5
ONCE A JIFFY
On the KMC11/DUP11, this subroutine also operates the
keep-alive counters.
8.6 CONTROL MESSAGES
The control messages are the fixed messages used by BSC to
acknowledge messages, request retransmission, delay, and so
on.
CHAPTER 9
SECTION "MDCODE"
The KMC11 microcode is not intended to be maintained in the
field. We are not releasing its source code, assembler or
debugging tools. In this chapter we present its interface
specifications and flow of code to assist in the
understanding of the KMC11 driver.
The KMC11 is a UNIBUS compatible general purpose
microprocessor with writable control store. It is used to
reduce the input/output load of the PDP-11 CPU by putting
characters from the DUP11 into a silo in PDP-11 memory and
outputing characters from "chunks" in the PDP-11 to the
DUP11. It is the PDP-11 that understands the BISYNC
protocol and not the KMC11.
The KMC11 has 4 16-bit registers which are on the PDP-11
UNIBUS. Some bits in SEL0 (the first register) are for
maintenance functions. The KMC11 driver stores in SEL2 (the
second register) a pointer to the KMC11 Control Block for
this KMC11. SEL4 and SEL6 are unused.
9.1 KMC11 CONTROL BLOCK
The KMC11 Control Block looks as follows (one per KMC11):
offset meaning
0 11 flags bit 0 set = PDP-11 running.
Set on startup, cleared on
crash.
bit 4 = active toggle
bits 1-3 and 5-15 unused
2 KMC flags bit 0 set = KMC11 running
bit 4 = active response
bits 1-3 and 5-15 = unused
4 11-alive counted by the PDP-11 once a
second
6 KMC11 alive counted by the KMC11 once a
second
SECTION "MDCODE" Page 9-2
KMC11 CONTROL BLOCK
10 LCB 0 pointer to first LCB
12 LCB 1 pointer to second LCB
14 LCB 2 pointer to third LCB
16 LCB 3 pointer to fourth LCB
9.2 LINE CONTROL BLOCK (LCB)
The first word of each line control block (LCB) has the
following flags:
bit meaning
12 kill complete (set by KMC11)
9 receiver running
8 transmitter running
7 error has been detected by the KMC11
4 transmission is of a control message
1 function complete (set by KMC11)
0 kill
The following offsets into the LCB are relavent to the
KMC11:
offset meaning
4 address of DUP11's CSR
10 pointer to data message to be sent
12 pointer to control message to be sent
14 length of control message to be sent
16 pointer to input silo control block
9.3 SILO CONTROL BLOCK (SCB)
The input Silo Control Block (SCB) is formatted as follows:
offset meaning
0 silo flags bit 0 set = give an XX0
interrupt on next change of
the silo pointer
bit 1 set = silo full
bit 2 set = silo has
overflowed
bit 4 set = warning level
reached
bit 7 set = KMC11 has fetched
the pointers below
2 silo pointer next character goes here
4 silo warning give the PDP-11 an XX0
SECTION "MDCODE" Page 9-3
SILO CONTROL BLOCK (SCB)
interrupt when this is reached
and set bit 4 in the silo
flags
6 silo limit maximum size of silo. give
the PDP-11 an XX0 interrupt
when this is reached and set
bit 1 in the silo flags.
9.4 KMC11 INTERRUPTS
The KMC11 will interrupt the PDP-11 for the following
reasons:
vector reason
XX0 silo non-empty
XX4 function complete
XX4 error
Bit 4 of 11-flags changing means that the PDP-11 has
something for the KMC11 to do. The action is specified by
the first word of the LCB; bit 0 = kill, bit 8 = transmit,
bit 9 = receive. The KMC11 must check all four LCB's and
initiate the specified action, then copy bit 4 of 11-flags
into bit 4 of KMC11 flags. If more than one bit is set in
the first word of the LCB, only the first action is
initiated.
When a write operation is complete bit 1 is set in the LCB
status and a check is made for bit 9. If it is set then
start a receive immediately.
SECTION "MDCODE" Page 9-4
FLOW OF KMC11 CODE
9.5 FLOW OF KMC11 CODE
This description is an updated version of the original
Detailed Design Specification. Some of the steps in the
original design were found to be unnecessary; these are
called "removed".
9.5.1 Section A: Initialization
1. Verify that each location of memory can contain
all ones and all zeros.
2. Wait for BSEL2 and BSEL3 to be set non zero by the
PDP-11.
3. Read BSEL2 and BSEL3 again which is the address of
the KMC11 Control Block in PDP-11 memory and save
a copy in "KMCCBA" in KMC11 memory.
4. Tell the PDP-11 that the KMC11 is running by
setting KF.RUN (bit 0) in the KMC11 Flags word in
the KMC11 Control Block.
5. Set the timer counter (scratch pads SP.TCL and
SP.TCH) to 20.
6. Enter the IDLE loop.
9.5.2 Section B: Idle Loop
1. Look at the activity word in each line block in a
round robin manner. If after looking at all 4
lines and none of them were flagged active (bit
LA.ACT set in L.ACT) go to step 2. If an active
line is found do the following:
a. Fetch the activity word (L.ACT) from the line
block and if bit LA.XMT is clear fetch the
DUP11 receiver status and if bit 7 is set
(receiver done) go to Section D. Otherwise
go to step 2.
b. If bit LA.XMT is set fetch the DUP11 transmit
status and if bit 7 is set (transmit done) go
to Section E.
c. Go to step 1.
SECTION "MDCODE" Page 9-5
FLOW OF KMC11 CODE
2. Fetch the PDP-11 flags from the KMC11 Control
Block in the PDP-11. (Last NPR)
3. If the PDP-11 flags (bits 0-7) have changed, go to
Section C.
4. Wait for the 50 microsecond timer to set in the
Miscellaneous Register.
5. Read the Miscellaneous Register and if BUS RQ (bit
7) is set go to step 9.
6. If the KMC11's "BR cycle wanted on XX0" flag is
set (SPF.X0 in SP.FLG) set BUS RQ in the
Miscellaneous Register and clear SPF.X0 in SP.FLG
and go to step 8.
7. If the KMC11's "BR cycle wanted on XX4" flag is
set (SPF.X4 in SP.FLG) set BUS RQ and XX4 in the
Miscellaneous Register and clear SPF.X4 in SP.FLG.
8. If either of the KMC11's "BR cycle wanted on XX0
or XX4" flags were set go to step 1.
9. Decrement the double precision counter contained
in SP.TCH and SP.TCL and if it goes to zero go to
Section F. Otherwise go to step 1.
9.5.3 Section C: PDP-11 Flags Have Changed
1. Fetch the PDP-11 flags from the KMC11 Control
Block in the PDP-11. (Not last NPR)
2. Save a copy of the PDP-11 flags in a SP.
3. If the PDP-11 running bit (bit 0) in the PDP-11
flags is clear go to Section G.
4. If the active toggle bit in the PDP-11 flags is
the same as the active response bit in the KMC11
flags go to step 7.
5. Check the four Line Control Blocks (LCB) in the
PDP-11 as follows:
a. Fetch the LCB pointer from the KMC11 Control
block (Not last NPR)
b. If the pointer is zero go to step 5j.
c. Save a copy of the LCB pointer in the KMC11
SECTION "MDCODE" Page 9-6
FLOW OF KMC11 CODE
Line Block L.LCB so the LCB can be referenced
without having to fetch the pointer to the
LCB from the Silo Control Block each time.
d. Fetch the LCB status (Not last NPR)
e. If Kill wanted (bit 0) go to step 9.
f. If Function Complete go to step 5j.
g. If the line is active (bit LA.ACT set in
L.ACT) go to step 5j.
h. If Write wanted (bit 8) go to step 15.
i. If Read wanted (bit 9) go to step 17.
j. Go do next LCB. If done all four then step
6.
6. Copy the PDP-11 flags bit 4 into KMC11 flags bit 4
and store in the KMC11 Control Block. (Not Last
NPR)
7. Clear bit 1 of KMC11 flags and store in the KMC11
Control Block in the PDP-11.
8. go to IDLE (Section B)
9. [Here for kill] If Kill Complete is set (bit 12)
in the LCB status go to step 5j.
10. Set kill complete (bit 12) in the LCB status word
in the PDP-11. (Last NPR)
11. Clear SEND (bit 4) in the DUP11 Transmit Status
register if LA.XMT is set in L.ACT, or clear
Receiver Enable (bit 4) if LA.XMT is clear in
L.ACT.
12. Clear the Activity word L.ACT in the KMC11 Line
block.
13. Flag that we want a BUS RQ on XX4 by setting
SPF.X4 in SP.FLG.
14. Go to IDLE (Section B).
15. [Here if Write Wanted] Setup for Data or Control
Message based on LCB status bit 4 and flag the
line is active by setting LA.ACT in L.ACT. If
this is a Control Message also set LA.CM. (Last
NPR)
SECTION "MDCODE" Page 9-7
FLOW OF KMC11 CODE
16. Go to IDLE (Section B).
17. [Here if Read Wanted] Setup for reading and flag
the line is active by setting LA.ACT in L.ACT.
(Last NPR)
18. Go to IDLE (Section B).
9.5.4 Section D: Receiver Done
1. Fetch a character from the DUP11 Receiver Buffer.
2. If the Error bit (bit 15) is set go to step 20.
3. If the KMC11 is holding a character (LA.XME set in
the activity word L.ACT) flag that the KMC11 is no
longer holding a character (in L.CHR) and go to
step 4. If the KMC11 is not holding a character
store the character fetched from the DUP11 in the
line block in the KMC11 (in L.CHR) and flag the
KMC11 is holding a character (LA.XME set in L.ACT)
and go to IDLE (Section B step 1.).
4. Fetch the pointer to the input Silo Control Block
(SCB) from the LCB, and save the pointer in KMC11
memory. (LCB pointer was put in KMC11 memory
L.LCB on activation of a read.)
5. Fetch a copy of the silo flags from the SCB, and
if the silo full bit is set (bit 1) go to step 19.
6. If the KMC11 already has a copy of the silo
pointer, warning limit address, and end limit
address (bit 7 set in the silo flags) go to step
7. Fetch the silo pointer, warning level address,
and end limit address and store in the line block
in KMC11 memory and set bit 7 in the silo flags
indicating the pointers have been fetched.
7. Fetch the pointer to the silo from the from the
line block in the KMC11.
8. Put in the KMC11's Output BA register.
9. Increment the silo pointer by 2 and store in KMC11
memory.
10. Store the character fetched from the DUP11 and the
saved character from the line block in the KMC11
in the silo. (Not last NPR)
SECTION "MDCODE" Page 9-8
FLOW OF KMC11 CODE
11. Store the incremented silo pointer in the SCB.
(Last NPR)
12. If the warning level reached bit (bit 4) is set in
the silo flags go to step 14.
13. Fetch the silo warning level from the line block
in the KMC11 and if the pointer equals the warning
level set bit 4 and go to step 16.
14. [Here if passed the warning level] Fetch the end
limit address of the silo from the line block in
the KMC11 and if the pointer equals the end limit
address, set silo full (bit 1) and go to step 16.
15. If the PDP-11 doesn't want a XX0 interrupt (bit 0
clear) go to step 17.
16. Flag that we want a XX0 interrupt by setting
SPF.X0 in SP.FLG and clear bit 0 in the KMC11 copy
of the silo flags.
17. If the KMC11's copy of the silo flags differ from
the silo flags fetched in step 5, store them in
the SCB. (Last NPR)
18. Go to IDLE. (Section B)
19. [Here if the Silo is full] Set bit 2 in the silo
flags and store in the PDP-11.
20. [Here to Kill the Receiver] Clear Receiver Enable
in the DUP11 Receive Status register. (Not last
NPR)
21. Zero the activity word for the line. (L.ACT)
22. Set KMC11 Error and Function Complete (bits 1 and
7) in the LCB status. (Last NPR)
23. Flag that we want a XX4 interrupt by setting
SPF.X4 in SP.FLG.
24. Go to IDLE (Section B).
SECTION "MDCODE" Page 9-9
FLOW OF KMC11 CODE
9.5.5 Section E: Transmit Done
1. If the transmission is ending (bit LA.XME set in
L.ACT) go to step 25. If the data late bit is set
(bit 15) go to Section D step 21.
2. Fetch the pointer to the data in the chunk from
L.DPNT in the line block. (Initially it was put
there on activitation of a write).
3. If the pointer points to an odd address go to step
7.
4. Fetch 2 characters from the chunk in PDP-11 memory
using the pointer.
5. Save the character in the high byte (odd address)
in the line block (L.CHR).
6. Go to step 8.
7. Fetch the character from the line block (L.CHR)
8. Put the character in the DUP11 Transmit Buffer.
9. Increment the KMC11's copy of the data pointer
(L.DPNT).
10. Decrement the KMC11's copy of the data count.
11. If the count went to zero and this was a Control
Message (bit LA.CM set in L.ACT) go to step 21.
If the count didn't go to zero go to step 17.
12. Fetch the KMC11 copy of the pointer to the next
chunk (L.CPNT) and if zero go to step 21.
13. Fetch the pointer to the next chunk+1 and save a
copy in KMC11 memory (L.CPNT).
14. Fetch the data count from the next chunk and if
zero go to step 12.
15. Save a copy of the data count in KMC11 memory
(L.DCNT).
16. Save a copy of the pointer to the data in the next
chunk in KMC11 memory (L.DPNT).
17. Go to IDLE (Section B).
18. Removed
SECTION "MDCODE" Page 9-10
FLOW OF KMC11 CODE
19. Removed
20. Removed
21. [Here because Transmission is Ending] Set TEOM
(bit 9) in the DUP11 Transmit Data Buffer.
22. Clear SEND (bit 4) in the DUP11 Transmit Status
register.
23. Flag the transmission is ending by setting bit
LA.XME in L.ACT.
24. Go to IDLE (Section B).
25. [Here because transmission has ended] Set Function
Complete (bit 1) in the LCB status. (Not last
NPR)
26. If a Read is wanted (bit 9 set LCB status) go to
step 28.
27. Go to Section C step 13.
28. Setup for a Read by clearing LA.XMT and LA.CM in
the activity word L.ACT.
29. Set Receiver Enable in the DUP11 Receive Status
register. (Last NPR)
30. Go to Section C step 13.
9.5.6 Section F: Timer Has Expired (usually One Second)
1. Set the timer counter to 20000 (decimal).
2. Removed
3. Increment the KMC11 Alive counter in KMC11 memory,
and store in the KMC11 Control Block.
4. If bits 0, 1, and 2 of KMC alive are all 0, go to
step 7.
5. Removed.
6. Go to Section B.
7. [Here every 8 seconds] Fetch 11 Alive from the
KMC11 Control Block.
SECTION "MDCODE" Page 9-11
FLOW OF KMC11 CODE
8. If the same as last time (old value stored in
KMC11 memory) go to Section G.
9. Store this value of 11 Alive as the old value in
KMC11 memory.
10. Go to IDLE (Section B)
9.5.7 Section G: Come Here When Something Is Wrong
1. Clear bit 0 (KMC11 running) of KMC11 flags and
store in the KMC11 Control Block. (Last NPR
cycle)
2. Clear bit 7 in BSEL1 and branch to self.
CHAPTER 10
SECTION "MSGHDL"
This section contains subroutines which manipulate messages.
10.1 MSGGTC
This subroutine gets a character from the input stream.
MSGGTC is used by the BSC task to get a character from the
data being received by the DQ11 or DUP11 interrupt routine.
It interacts with the interrupt routine and the once per
jiffy subroutine to keep data flowing to the BSC task. The
subroutine waits if necessary for a character from the line.
See Chapter 11 on the dispatcher for a discussion of
waiting.
If the interrupt level detects an error the message is
truncated.
10.2 MSGGTE, MSGGTT, AND MSGGT2
These subroutines terminate the input stream. They are
called when the BSC task recognizes the end of a message or
a timeout.
10.3 MSGAPC
This subroutine appends a character to a message. MSGAPC is
called by the BSC task to assemble the data portion of a BSC
message for the XLATE task and by the XLATE task to build a
BSC message for the BSC task. The register conventions of
this subroutine and MSGGTC have been arranged to make the
BSC task efficient. This subroutine will allocate chunks
and append them to the message, if necessary, and will
observe pre-allocated chunks.
SECTION "MSGHDL" Page 10-2
MSGAPE
10.4 MSGAPE
This subroutine returns any unused pre-allocated chunks from
a message. MSGAPE is called by the XLATE task when a
message is complete.
CHAPTER 11
SECTION "DISPAT"
This section is the dispatcher. Its function is to allocate
time among the tasks. (Time is given to the interrupt
routines independently by means of hardware interrupts.)
This section has two entry points: DISPATCH and WAIT.
11.1 DISPATCH
This entry point is used after initialization to start up
the dispatcher and after WAIT has finished processing to
restart the dispatcher. The task control blocks are scanned
in priority order; the highest priority, non-blocked task
is given control of the CPU. If a task is blocked some
tests are made to see if the dispatcher can unblock it.
These are tests on GLOBAL variables. Normally a task is
unblocked by another task or by the timer. If all tasks are
idle the dispatcher checks the line frequency clock and, if
it has ticked, does the once-a-jiffy functions. These are:
1. Update each waiting task's timer.
2. Do the once-a-jiffy line driver functions (see
chapter 8)
3. Do the once-a-jiffy DL10 or DTE20 functions (see
chapters 13 and 14)
4. Once a second:
1. If we have a DL10 or DTE20, do the
once-a-second DL10 or DTE20 functions (see
chapters 13 and 14)
2. Otherwise, try to bring the DL10 or DTE20 on
line.
SECTION "DISPAT" Page 11-2
DISPATCH
If the dispatcher doesn't get any idle time for about two
seconds, the clock interrupt (back in the MININT section)
will indicate a fatal error. Similarly, if the clock
doesn't tick for a long while (measured in dispatcher idle
cycles), the dispatcher will indicate a fatal error. In
this way the clock keeps watch over the tasks, and the
dispatcher keeps watch over the clock. Note, however, that
a large increase or decrease in CPU speed could cause an
error to be detected falsely. If the CPU is very fast, the
dispatcher will get too many idle cycles and will think the
clock has stopped. If the CPU is very slow, a task which
ought to take a short time may take so long that the clock
interrupt code will think that the task is looping.
11.2 WAIT
The WAIT entry point is used by a task to wait for an event
to occur. The task indicates in its TCB that it is blocked
and indicates the event or events it is waiting for. The
call to WAIT causes the task's PC to be saved in the TCB and
the tasks to be scanned as described above for the highest
priority unblocked task. Note that the task's registers are
not saved, except for its stack pointer. Thus, if a task
needs to save any registers over the call to WAIT, it must
push them into the stack. When one or more of the events
specified in the TCB happen, the task is unblocked and the
dispatcher will eventually find it and run it. When a task
is run, R5 points to its TCB, R6 is restored to the state as
of the last call to WAIT and R0 through R4 are undefined.
Note that the requirement that a task must call WAIT before
another task will run makes this a "non-preemptive"
scheduler. This decreases the real-time response, but
greatly simplifies the coding of the tasks, since the shared
data structures can be manipulated without fear that another
task will take control away from the manipulating task while
the data structure is in an intermediate state.
11.3 T-BIT - RTI INSTRUCTION
Because a task may be running with the T-bit set (see
Chapter 18 on debugging) WAIT and INIT2 branch to the
dispatcher by using the RTI instruction. This instruction
both lowers the priority level of the CPU to 0 and clears
the T-bit. This is the safest way to clear the T-bit, since
some PDP-11 models have restrictions on direct manipulation
of the PS register.
SECTION "DISPAT" Page 11-3
T-BIT - RTI INSTRUCTION
To set the priority of the CPU properly and set the T-bit,
if required, the dispatcher branches to a task using the RTI
instruction.
CHAPTER 12
SECTION "BSC"
This section contains the BSC (or BISYNC) task. This task
uses the line driver subroutines to communicate with an
IBM-compatible BSC device, point-to-point. Many error and
statistical counters are kept. Communication with the
translate task is by sending and receiving messages and by
changing and observing status bits in the task control
block.
This section is divided into four parts: Control, Output,
Input and Subroutines.
12.1 CONTROL
The code implementing the control functions of BSC extends
from the label DQDRVR to, but not including, the label
DQXMIT. For HASP Multileaving the control starts at the
same place but branches off to HSPLIN for HASP lines.
12.1.1 HASP Control
The HASP Multileaving control section also starts at DQDRVR,
skips over the IBM 3780 part all the way to HSPLIN, and ends
before HSRECV label. The HASP bid sequence is SOH-ENQ and
is diffrent from the IBM 3780/2780 bids. The line once bid
remains so and the DECSYSTEM-10/20 will maintain
communications by transmitting an ACK0 message every 2
seconds. Initially if the response to bid was an ACK0, DN62
can start sending sending data starting at HPXMIT. However
if the response to the bid was another bid, DN62 will send
an ACK0 and the remote has the choice of sending data or
ACK0 as the requirements may be. The receive data routine
begins at HSRECV.
SECTION "BSC" Page 12-2
CONTROL
12.1.2 IBM 3780/2780 Control
This subsection sends and receives the BSC "bid" message,
and branches to Input or Output as required. It is in the
form of a loop which bids if required and then listens for a
response. If the response is an acknowledgment of the bid,
then it calls the output subroutine, DQXMIT. If the
response is another bid, then it calls the input subroutine,
DQRECV.
Please recognize that this is a simplified description.
More details are available in the listing.
12.2 OUTPUT
The output subsection is the subroutines DQXMIT, DQXRSP, and
DQXNAV.
12.2.1 DQXMIT
This subroutine sends messages queued to it from the
translate task. DQXMIT returns when all the messages have
been sent or when there has been an unrecoverable error.
The translate task has built the output messages to have the
proper form for the DQ11 or DUP11, so the BSC task has no
need to manipulate them.
12.2.2 DQXRSP
This subroutine is used by DQXMIT to read the response to a
transmitted message. If the other computer liked the
message, it will respond with positive acknowledge. If it
didn't like it, then the other computer will respond with
negative acknowledge. It is possible for the other computer
to miss the message entirely, in which case there is no
response.
If the other computer liked the message but has no room for
any more messages, it will respond with wait acknowledge.
In this case the other computer must be polled occasionally
to see when it is ready.
SECTION "BSC" Page 12-3
OUTPUT
12.2.3 DQXNAV
This subroutine is called by DQXMIT when there is no data to
send. DQXNAV determines if this is due to the message
stream being aborted or ended and returns if this is the
case. Otherwise it sends a special message to the other
computer indicating that no data exists for it as yet. The
other computer will respond with a negative acknowledge, and
the possibility of additional messages to be sent can then
be considered.
12.3 INPUT
The input subsection is comprised of several subroutines
listed between DQRQIP and DQRBCC. Only the most important
of these are discussed here.
12.3.1 DQRQIP
This subroutine is called by the Control code to see if the
PDP-10 will allow the other computer to send data to it.
12.3.2 DQRECV
This subroutine receives a stream of messages from the other
computer. It returns when the stream is ended either by the
end-of-file sequence or by being aborted.
12.3.3 DQRPRP
This subroutine is used by DQRECV to acknowledge a message.
12.3.4 DQRNRP
This subroutine is used by DQRECV to negatively acknowledge
a message. This will usually cause it to be sent again.
SECTION "BSC" Page 12-4
INPUT
12.3.5 DQRNRM
This subroutine is used by DQRECV to process a normal
(non-transparent) message. DQRNRM watches for "ETX" and
"ETB" to end the message and checks and removes block
checking characters.
12.3.6 DQRXPM
This subroutine is used by DQRECV to process a transparent
message. It serves the same purposes as DQRNRM, but it must
work a bit harder, because it must also strip the DLE
characters.
12.3.7 DQRBCC
This subroutine is used by DQRNRM and DQRXPM to read the BCC
sequence which follows each message. Sometimes DQRBCC is
also used to read an "intermediate BCC".
12.4 SUBROUTINES
The fourth subsection contains the subroutines used by the
code described above. The most important subroutines are
described.
12.4.1 CTLMSG
This subroutine sends a control message such as ACK-0 or NAK
and initiates a read for the response, unless requested not
to.
12.4.2 STOBCC
This subroutine stores the accumulated BCC into a message.
12.4.3 DQABRO
This subroutine aborts the output stream.
SECTION "BSC" Page 12-5
SUBROUTINES
12.4.4 DQABRI
This subroutine aborts the input stream.
12.4.5 DQSEOT
This subroutine conditionally sends the "EOT" control
message. It does not read any response.
12.5 HASP MULTILEAVING
The following sections describe the subroutines used by the
HASP Multileaving protocol for doing input and output. The
input and output are interleaved. A data message may be
positively acknowledged by sending data or an ACK0. The
messages may be in the form of data less records and may
indicate a request to transmit a file, permission to
transmit a file, signon, or a block sequence error. There
can also be status-only blocks which indicate whether the
transmitting station is able to receive data records and if
ready, on which devices. these kind of blocks may be used
to slow down the data transmission to itself. The
"information" part of the block may appear after the status
(FCS) bytes in the form of data records with source or
destination information (RCB and SRCB). Each data record
may have a series of compressed data controls (SCB). The
RCB defines the source or destination and SRCB may have
carriage control information or indication that a record is
in binary mode.
The positive acknowledgement is used when preceding block
transmission is acceptable. The status only block may also
be used as may the status-data block to indicate positive
response. The current relase supports reception of data in
transparent and non-transparent mode. The output is always
in non-transparent mode.
12.6 HASP INPUT
The input section comprises of various subroutines which
also overlap with output subroutines in their functionality.
The major receive routines are HSRECV, HSPXM5, HSARSP and
they are described with other helper routines.
SECTION "BSC" Page 12-6
HASP INPUT
12.6.1 HSRECV
This subroutine checks for enough (30.) chunks and goes to
HSPXM5 to read the incoming data. Shortage of chunks will
result in suspending the incoming streams from the remote.
12.6.2 HSPXM5
This subroutine calls HSARSP to read the data coming in on
the bisync link. This could be response to tranmitted
message. An ACK0 or "good" data may be considered as
positive acknowledgement to transmitted data. In turn, data
or ACK0 may be sent to the remote to acknowledge his data.
Thus their is a two way data transfer though only in one
direction at a time.
12.6.3 HSARSP
This subroutine performs most of the vital role of receiving
the data and analysing it and then reporting it to HSPXM5.
All NAKS, ACK0, transparent text and special requests are
HANDLED by calling HSRXPM.
12.6.4 HSRXPM
This subroutine receives data which is more than ACK0 and
NAK. It recognizes special records for device request,
device permission granted, BCB error as well as data for the
input mode devices like console, card reader, line printer
or punch. The records are collected in messages of the same
device type and if BCC checks correctly at the end of the
message, the data messages formed by HSRXPM are distributed
to the various device's translate tasks for processing.
12.6.5 HSRQMS
This subroutine analyzes the requests a step furthur and
marks input request or output permission granted and also
wakes up the relevant XLATE task who must notice the
requests or grants just arrived. It also makes a check of
the incoming data formats and return an error if format is
found in error.
SECTION "BSC" Page 12-7
HASP INPUT
12.6.6 HSRSON
This subroutine is called by HSRXPM when a SIGNON control
record is detected. The SIGNON record is special in the
sense that it is the only record transmitted with no
compression and must be 80. characters long. HSRSON
assembles this record with appropriate message i.d. of
signon.
12.6.7 HSEOB
This subroutine is called when an end-of-block is
encountered in the incoming stream. This signals arrival of
ETB character after receiving which a BCC check is made and
data distributed to various devices. It must be noted that
the all received data is separated into messages for the
diffrent devices and these messages are chained together
with the most current pointer being in TCRMSG offset in the
BSC TCB. This greatly eases the job of releasing the
received messages in the event of errors like the BCC etc..
12.6.8 HMSGTC
This subroutine gets a received character from the receiver
and checks it for DLE or SYN, eats them and excludes them
from BCC also. It also marks ETB received if one was
encountered. If the character is not DLE or SYN, it is
included in the BCC check.
12.6.9 HSTRCB
This subroutine is called to pick up the incoming record's
RCB (record control byte) and SRCB (sub-record control byte)
which are used in identifying the record for a device.
12.6.10 HSTFCS
This subroutine gets the received FCS byte 1 and 2 and sets
it in TCRFCS where the status recognizer routine can look at
it to find out what devices the remote has suspended or
unsuspended.
SECTION "BSC" Page 12-8
HASP INPUT
12.6.11 HSCHST
This subroutine processes the status just received in the
FCS (function control sequence). It marks the devices or
the system suspended as indicated by the function control
byte1 and byte2 received from the remote.
12.6.12 HSDRIP
This subroutine is called by HSRQMS when an input request
has been received for a device. It is also called by HSEOB
when it detects an incoming data for a device.
12.6.13 HSAWXL
This subroutine awakens the XLATE task whose device number
is in R1.
12.6.14 HSWALX
This subroutine awakens all the XLATE tasks configured on
the line.
12.6.15 HSABRI
This subroutine aborts the input stream for a device.
12.6.16 HSABTI
This subroutine aborts input streams for all the devices
configured on the line.
12.7 HASP OUTPUT
This section will describe all the subroutines involved in
transmission of a message. The output section starts at
HPXMIT and has embedded in it the reading logic used by the
receiver routines to find out the response to the
transmitted message. Output of data is done at HSPXM1 but
all the message building is done by HSGTMS.
SECTION "BSC" Page 12-9
HASP OUTPUT
12.7.1 HPXMIT
This routine is called by receiver and transmitter logic to
look for more data to transfer. If data is not available,
an ACK0 is used as filler every second. HSPXM1 takes over
if data is available and calls DQWRIT to do actual
transmission of data on the BISYNC link. Any abnormal
conditions or unrecoverable errors will result in output
being aborted for all devices. The response to the
transmitted message is read by falling thru to HSPXM5 and
depending upon the response the message is retransmitted
(for NAK or bad BCC) or a new message sent over.
12.7.2 HSMSAK
This subroutine processes the acknowledgement received for a
message sent over. It releases any messages sent and for
signon message fakes completion of EOF output by clearing
TCOTC bit in TCFG2 flag word for the card redaer.
12.7.3 HSGTMS
This subroutine is called by HPXMIT to get a block of data.
It in turn calls HSONB to look for signon message and if
none goes to look for any pending requests to be serviced by
the remote. HSMTBK is the routine which builds the real
data message if any available for output. The pointer to
the message is passed in LB.MSG in the line cntrol block for
HPXMIT to look at.
12.7.4 HSONB
This subroutine is called by HSGTMS to check for any SIGNON
block to be sent over to remote. If one is found, a signon
block is built and message pointer passed in the LCB cell
LB.MSG.
12.7.5 HSRQPT
This subroutine is called by HSGTMS to look for any
outstanding permissions for devices to be sent to remote.
If a device is found with request flag on, its RCB is saved
in TCRQPT cell where building message routine can look at
it.
SECTION "BSC" Page 12-10
HASP OUTPUT
12.7.6 HSDPG
This subroutine is also called by HSGTMS to look for any
permission grant messages to be sent to remote in response
to an earlier request sent by the remote. Flag TCIPH is
used to indicate if permission has been sent already so that
it is not sent repeatedly. The RCB of the device whose
permission has been granted is saved in TCDPG for message
builder to look at.
12.7.7 HSMTBK
This subroutine builds messages (data + requests) for hpxmit
to see. The data message may contain data records from same
or diffrent devices The last record may be a device
permission granted or a request for a device to be sent to
remote. The devices are polled for data in the following
order of priorities: console output, card reader output,
line printer output, punch data output.
12.7.8 HSCDOT
This subroutine checks on all devices for data to output and
makes a message block for transmission if it finds data to
output. The BCB error reporting ,request to go out and
status for system suspend take precedence in going out as
messages.
12.7.9 HSCKTP
This subroutine checks for transparent mode on output and
inserts DLE before a data DLE or SYN.
12.7.10 HSCKRQ
This subroutine is called by the message builder at the end
to accomodate any requests, grants to go out as last record
in the transmission block. It may also be called if HSMTBK
finds that BCB error has to be reported which is sent as a
lone record. HSTRL routine is called to append the ETB, CRC
and PADS at the end of the message.
SECTION "BSC" Page 12-11
HASP OUTPUT
12.7.11 HSCKDO
This subroutine is called by HSCDOT and HSCKAB to check if a
device is permitted to output and as such any aborts noticed
are taken care in this task.
12.7.12 MSGHDR
This subroutine is called by HSMTBK message builder to put
BCB, FCS1, FCS2 in the transmission block being built. Note
STX is included in the BCC for non-transparent mode.
12.7.13 HSRLOM
This subroutine releases all out going messages which may
remain stuck in between the tasks. It is called by the
aborts procedures when DSR drops or a line is disabled.
12.7.14 HSUSPD
This subroutine is called by the HSDRIP routine to send
suspend the device's stream from remote when input
permission is not seen as granted.
12.7.15 HSUNSP
This subroutine is called by the hsdpg subroutine when
permission is granted for the device. to allow the device
stream to continue.
12.7.16 HSABRO
This subroutine aborts the output stream for the device.
12.7.17 HSABTO
This subroutine aborts all the output streams for all output
devices.
A number of other subroutines are used which are part of the
IBM 3780 protocol and their description is not repeated
here.
CHAPTER 13
SECTION "DL10"
This section contains the DL10 memory-sharing interface
code. Included are the interrupt routine, the
initialization subroutine, STOPCODE storing subroutine, a
once-a-jiffy subroutine, a once-a-second subroutine and the
DL10 driver task. First, however, it is appropriate to
discuss the DL10 window layout.
13.1 DL10 WINDOW
Early in section "DEFINE" is the layout of the DL10 window.
Section "DEFINE" defines symbols which facilitate direct
reference by the DL10 section to various locations in the
DL10 window. The first part of the window is mostly the
interface to TOPS-10 routines which are common to all DL10
interfaces: DLXNAM is used to identify the program running
on the PDP-11, DLXOK and DLXTA are "keep alive" counters,
DLXHLT and DLXDWN control the "not running" messages that
print once a minute, DLXSWD, DLXADR and DLXSWD are the
examine/deposit interface, and so on. The part which is
important to the DN61 is the end of the window from DLXOPE
to DLEND. This handles the passing of data, status and
control across the DL10 interface.
13.1.1 11-initiated Functions
Locations DLXOPE, DLXLNE and DLXDVE are used by the DN61 to
alert the PDP-10 to a condition which it should check. No
condition is currently defined, so these locations are not
used.
SECTION "DL10" Page 13-2
DL10 WINDOW
13.1.2 10-initiated Functions
Locations DLXOPX, DLXLNX and DLXDVX are used by the PDP-10
to signal to the DN61. Locations DLXRST and DLXXFR are used
by the DN61 to indicate the results of the signal. DLXCBP
is storage for the counts and byte pointers which describe
the area of PDP-10 memory to be read or written.
When the PDP-10 wishes to read data from the DN61, it sets
DLXCBP to point to the user's buffer (which may be split
across non-continuous page boundries, hence the allowance
for up to sixteen separate areas). Then DLXLNX and DLXDVX
are set to the user-specified line number and device number.
(The device number is not used in the DN61; this number is
expected to be used in the DN62.) Last, the PDP-10 sets
DLXOPX to 1 and interrupts the DN61. The DN61 fetches
DLXOPX, clears it, and attempts to perform the read. Either
the read subroutine succeeds in passing some data, no data
was available, or the input stream has been ended. These
three possible conditions are indicated by setting DLXRST to
1, 2 or 3, respectively. Also, DLXXFR is set to the number
of bytes transfered over the DL10. This is used by the
PDP-10 to know how many bytes to process in its buffer. If
the result is 2 or 3, DLXXFR is always set to zero.
Reading status works just the same way except for setting a
different value into DLXOPX.
Writing data is the same in the PDP-10; locations DLXCBP,
DLXLNX, DLXDVX and DLXOPX are all set up as described above.
In the DN61 the Write Data subroutine is called. It may
succeed in passing all the data, it may pass some of it, or
the output stream may have been aborted. At the end of the
operation location DLXRST is set to 1, 2 or 3, respectively,
depending on which of these things happens. Location DLXXFR
is set to the number of bytes transfered so that the PDP-10
program can re-issue the Write Data command, if necessary,
starting at the byte from which the last command ended. If
no data is passed, DLXRST is set to 2 and DLXXFR is set to
0, indicating that the command should be re-issued just as
it was.
The other write-type commands work just like Write Data
except for a different value in DLXOPX. None of the other
commands can set DLXRST to 2 except the subfunction of Write
Line Command which enables a line. If there is not enough
core available to create the tables necessary to enable a
line for the first time, DLXRST is set to 2.
SECTION "DL10" Page 13-3
INTERRUPT ROUTINE
13.2 INTERRUPT ROUTINE
The interrupt code is very simple; it merely awakens the
DL10 task if that task is waiting for a DL10 interrupt. The
real-time responsiveness of the DN61 is kept high by keeping
the number of instructions executed at interrupt level
small.
13.3 STOPCODE STORING
The stopcode storing subroutine stores the STOPCODE in the
DL10 window so that TOPS-10 can print it for the operator's
information. This subroutine is called only after a fatal
error is detected. See Chapter 18 on debugging facilities
for more information on STOPCODEs.
13.4 INITIALIZATION
The initialization subroutine attempts to bring the PDP-10
on-line by requesting an interrupt through the closed
window. This causes TOPS-10 to open the window so that this
subroutine can store the name "DN60 ". TOPS-10 then
initializes itself for the DN61. This subroutine is full of
timers and traps so that it will not run forever if the -10
is not working. It is called from the initialization code
and from the dispatcher if the -10 is down.
13.5 ONCE-A-JIFFY
The once-a-jiffy code performs the examine and deposit
functions, maintains the lights and sends an interrupt to
the PDP-10 if requested. The function of interrupting the
PDP-10 is used by the DL10 task when an operation is
complete. The lights show the amount of unused capacity in
the DN61 using the top row of lights in the DL10.
13.6 ONCE-A-SECOND
The once-a-second subroutine watches out for the PDP-10
halting. The purpose of the code is not only to allow the
PDP-10 to reach a DDT breakpoint and continue from it
without hurting the DN61, but also to stop doing all work if
the PDP-10 is reloaded. These cases can be distinguished
from one another because the window will be closed if the
PDP-10 is reloaded and will remain open if it simply hits a
breakpoint.
SECTION "DL10" Page 13-4
ONCE-A-SECOND
If the PDP-10 is reloaded, a flag is set so that all
outstanding BSC streams will be aborted.
This once-a-second subroutine also sets a flag in the DL10
window to reassure the PDP-10 that the DN61 has not halted.
13.7 TASK
Most of the code in this section is the DL10 task. It is
divided into three parts: the DL10 interface subroutines,
the command interpreters, and their subroutines.
13.7.1 DL10 Interface Subroutines
This task is mostly table driven. The first table is for
the command code from the PDP-10. Following this in the
listing are several subroutines used to discover the command
code and dispatch based on it and to fetch and store data
through the window.
13.7.1.1 DLENDO - This subroutine does the post-command
clean up. DLENDO stores DLXRST and DLXXFR and requests a
PDP-10 interrupt.
13.7.1.2 DLDISP - This subroutine does the dispatching for
the command code. DLDISP is also used during the processing
of some commands.
13.7.1.3 DLGOPR - This subroutine gets the command code
from the PDP-10. The task spends most of its time here,
waiting for the next command from the PDP-10.
13.7.1.4 DLGBYT - This subroutine fetches a byte through
the DL10 window. DLGBYT observes the counters stored in
DLXCBP so that it can go from one byte pointer to the next,
thus crossing user's page boundries even if the user's
buffer is checkerboarded in physical core.
SECTION "DL10" Page 13-5
TASK
13.7.1.5 DLPBYT - This subroutine stores a byte through the
DL10 window. DLPBYT also observes the counters in DLXCBP.
13.7.1.6 DLPWRD - This subroutine stores a 16-bit word
through the DL10 window. DLPWRD works by calling DLPBYT.
13.7.1.7 DLPSTR - This subroutine stores a string of words
through the DL10 window. DLPSTR works by calling DLPWRD.
13.7.2 Command Interpreters
The first part of this subsection consists of eight
subroutines, one for each of the eight commands. The second
part consists of subroutines for interpreting subcommands of
two of the eight major commands.
13.7.2.1 DLTRDT - This subroutine performs the "read data"
function. DLTRDT copies to the PDP-10 data from the oldest
message received over the specified line by the translate
task. The message is then sent to the IDLE task to be
broken down into chunks and freed. DLTRDT handles the cases
of no message being available and of the input stream being
aborted.
13.7.2.2 DLTWDT - This subroutine performs the "write data"
function. DLTWDT copies data from the PDP-10 into chunks
which it then sends to the translate task for the specified
line. If it runs out of chunks while copying data, it so
informs the PDP-10 so that the PDP-10 can restart the
transfer at a later time.
13.7.2.3 DLTRDS - This subroutine performs the "read device
status" function. The status information is obtained from
the TCB of the translate task.
SECTION "DL10" Page 13-6
TASK
13.7.2.4 DLTWDC - This subroutine performs the "write
device command" function. DLTWDC does most of its work by
calling subroutines using the same dispatch subroutine that
was used to call it. These subroutines are described
briefly below.
13.7.2.5 DLTRLS - This subroutine performs the "read line
status" function. DLTRLS copies data from the LCB to the
PDP-10.
13.7.2.6 DLTWLC - This subroutine performs the "write line
command" function. DLTWLC does most of its work by calling
subroutines. These subroutines are described briefly below.
13.7.2.7 DLTRES - This subroutine performs the "read DN60
status" function. DLTRES simply copies some data from the
GLOBAL area to the PDP-10 using DLPSTR.
13.7.2.8 DLTWEC - This subroutine performs the "write DN60
command" function. DLTWEC is a dummy, since no use is yet
defined for this function.
13.7.2.9 DLTEXM -
This subroutine performs the "examine of a eleven location"
function ( 9).
13.7.2.10 DLTDEP -
This subroutine performs the "deposit in eleven memory"
function ( 10) and is quite useful for debugging.
13.7.2.11 DLTRBN -
This subroutine is essentially the same as the read data
function with the exception that the data is in binary mode.
Since the ten does not know that 11 has binary data, the -11
will reject a wrong mode read data operation with code 6
which the ten uses to reissue the CALL11.UUO in the correct
mode.
SECTION "DL10" Page 13-7
TASK
13.7.2.12 DLTWBN -
This subroutine will be similar to the write data with mode
considerations similar to above. (this function is not yet
implemented)
13.7.3 Command Interpreter Subroutines
There are two sets of command interpreter subroutines: one
set for the line commands and one set for the device
commands. The line command subroutines are named DLTLnn
where nn is the number of the command. The device
subroutines are named DLTDnn where nn is, again, the number
of the command. It would be tedious to list all of the
subroutines here; they are all very short and each is
headed by a comment specifying its function. These
functions are also listed in Chapter 20 which specifies how
to use the CAL11. UUO.
After the line and device subroutines are some subroutines
which they use. The most important ones are listed here.
13.7.3.1 DLDRAI - This subroutine drains the message queue
from the translate task. DLDRAI is used when a message
stream is aborted.
13.7.3.2 DLNWCK - This subroutine sends the current chunk
to the translate task and obtains a new one from free
storage. DLNWCK is used when doing the "write data"
function and is responsible for making sure that the output
stream from the PDP-10 does not use up all the chunks. If
the PDP-10 were permitted to use up all the chunks then data
could not be received and one line might "hog" chunks, thus
preventing other lines from transmitting.
CHAPTER 14
SECTIONS "DTE10" AND "DTE20"
This section contains the DTE20 interface code which serves
as a substitute for the DL10 section in the DN61-SA,
DN61-SB, DN64-AA, and DN64-AB. Most of the other sections
are unaware of the substitution, since this section has the
same functions and entry points as the DL10 section.
14.1 COMMUNICATIONS REGION
The communications regions are defined by the RSX-20F Queued
(KL10/PDP-11-DTE20) Protocol, Document No. 200-205-034-00,
to ease the exchange of status and other information between
the KL10 Processors and their PDP-11 Front Ends.
Communications regions are composed of sequential areas,
each processor owning one and only one area which is the
only part of the communications region the processor is
allowed to write into. During initialization, however, a
ten processor is responsible for setup of the entire region.
Each area has a single section for the processor owning the
area, and a section for each processor that the processor
that the processor owning the area will communicate to.
Each section has cells to house name of the owning
processor, size of communications area, keep-alive counter,
status word, transfer size which are frequently accessed to
perform almost any function. Keep-alive counter is
incremented by the owning processor once a second (at least)
and the monitoring processor may examine it periodically to
see that it has changed. If no change is noticed for 6
seconds, the owning processor is declared dead and a reboot
requested by setting the load bit in the comm. area. Word
DTEPCA is the first location in each "to" processor section.
SECTIONS "DTE10" AND "DTE20" Page 14-2
DTE20 INTERRUPT ROUTINE:
14.2 DTE20 INTERRUPT ROUTINE:
This routine is entered as a result of DTE20 hardware
interrupts. DT.INT saves the status (register 34 (octal))
in DLSSAV for debugging purposes and then checks for the
conditions which caused the interrupt. The three relevant
conditions or events are:
The eleven done (when the -11 is done receiving data from
-10)
The ten done (when the -10 is done receiving data from -11)
The doorbell (when the -10 wants -11's attention it
interrupts)
These events causing the interrupt are recorded in three
different words DTIEDN, DTIXDN , DTIDBL for eleven done,
ten-done and doorbell respectively, by incrementing the
relevant word. In the event of a hardware error, the
routine executes a Stop Code DL10(02). Otherwise the
routine simply records the interrupt condition and awakens
the DTE20 driver task (by turning bits off in the TCB of
driver task) if the task happens to be waiting for that
condition. The actual processing is done by tasks scheduled
and therefore the response time is improved by doing minimum
work at interrupt level.
14.3 STOPCODE STORING:
The stopcode storing subroutine stores the stopcode in a
cell at location TRPCOD so that it can be examined by the
TEN -user (TOPS-10/20). The PC of location +1 which
executed the stopcode is stored at TRPERR. Other important
information stored includes the registers starting at
location STOPRO. Of special interest may be STOPR5 which
normally points to the TCB of the task and once that's known
it is easier to examine various TCB offsets for message
headers received and sent accross the DTE20. If the DEBUG
switch is on,all the DTE20 registers are saved in global
locations starting at DTESAV. The status is in location
DTESAV +34(octal). This subroutine is called only after a
fatal error is detected. Refer to Chapter 18 for details on
debugging facilities and more information on stopcodes. The
meaning of various stopcodes is listed in Section "S".
SECTIONS "DTE10" AND "DTE20" Page 14-3
INITIALIZATION:
14.4 INITIALIZATION:
The initialization subroutine INITDL is called at startup
from the initialization code (and also from the dispatcher
if the -10 is down) to initialze the DTE20 Queued Protocol
Interface. It makes sure that the -10 is out of primary
protocol before restarting the Queued Protocol. Ten's
doorbell is rung and after waiting for a while the -10
should get back into primary protocol again which means we
can do examines of the communication region. After we get
into primary protocol, the communication region data base is
set up and initialized by calling DLINDB. For information
on Queued Protocol, Primary Protocol and communication
regions, the reader is refered to Appendix A.
14.5 ONCE-A-JIFFY
This subroutine (DSPDLT) is a dummy subroutine provided for
compatability with rest of the DN60 series software.
14.6 ONCE-A-SECOND
The once-a-second subroutine (DSPDLS) watches out for
KL10-halting, by monitoring the keep-alive counter of the
Ten in the Eleven's area. In addition it performs examines
of Ten's communication area to confirm that Ten is really
up. Failure to perform an examine means that Ten has just
gone down and DLGONE is set to -1 to tell the world about
the catastrophe. Following this the dispatcher will notice
that Ten's gone down and it will call initialization
subroutine INITDL to pull Ten out of primary protocol.
Until the Ten comes up with valid examine (after hearing
Eleven ringing Ten's doorbell), the initialization will not
put the Ten back in primary protocol. DSPDLS also
increments its own keep- alive-counter which the -10 may be
monitoring.
14.7 TASK:
Most of the code in this section is the DTE20 task which
consists of three different parts:
1. The DTE20 Task Interface Subroutines
2. The Queued Protocol Interface Subroutines
SECTIONS "DTE10" AND "DTE20" Page 14-4
TASK:
3. The Command Interpreter and their subroutines
Before we proceed any further, it is very pertinent to give
a very simple background of the procedure or discipline for
communicating between the -10 and the -11 using the Queued
Protocol. This discipline (DN60 Communications Protocol) is
one level higher protocol than the queued protocol and
basically assumes the Ten as the master and the Eleven as
the slave driver through the DTE20. The Ten initiates all
operations like examine/ deposit of Eleven memory, data
reads/writes and line/device status checks/writes/etc. The
Ten always requests the operation by sending a Header (FEH)
to the Eleven. The header format is described in Appendix
A. All the pertinent information about the function
requested is included in the header. After performing the
function, the Eleven sends a response back to the Ten
returning result code (1=successful, 2=delayed, 3=rejected)
to inform the Ten about the status of the operation. The
exact message format of response for each function is given
in Appendix A, which also defines the DN60 Communication
Protocol.
14.7.1 DTE20 Task Interface Subroutines:
The DLDRVR subroutine interfaces the DTE20 task to the
events occuring at the hardware level. It checks for
occurance of the Eleven-done, the Ten-done, and doorbell by
examining locations DTIEDN, DTIXDN, DTIDBL, respectively in
the order indicated. Even if Eleven-done and doorbell occur
simultaneously, Eleven done must be honored first and then
Ten done and lastly doorbell to implement queued protocol
correctly. A non -zero event count in the above three cells
would cause the appropriate processing routine to be
dispatched. Time limits are set so that any loops or wild
code jumps are not executed indefinitely. The three
interrupt processing routines the driver dispatches to are
The subroutine DLTXDN for Ten-done, DLELDN for Eleven done,
and DLDRBL for the doorbell event.
14.7.1.1 DTE10 - The following paragraphs are relevant if
the module "DTE10.P11" has been included in the DN61
assembly.
SECTIONS "DTE10" AND "DTE20" Page 14-5
TASK:
14.7.1.1.1 DLTXDN: - This routine performs the To Ten-done
processing which may be as a result of direct Header or
Indirect data received by the -10 (and sent by the -11 to
the -10). As mentioned in the Appendix A., the -11 has to
send a response back to -10 after completing the requested
function from the -10. The direct message may be as a
result of the response having been sent to the -10. In
addition if the requested function was a read data or read
status (line/device/DN60), an indirect data message would
follow the header after the -10 has acknowledged the -10 the
receipt of the header by a -10 done. The state variable
used here in the Protocol Function word DT10FN of the
message being sent. The header starts at offset DT10HD in
the TCB of the DTE20 driver task. On direct messages, like
header, DT10FN will be positive and after direct portion of
the indirect message, it will be negative. In the latter
case the indirect portion will be sent to the Ten and the
state variable DT10FN cleared to The Ten and the state
variable DT10FN indirect message.
14.7.1.1.2 DLELDN: - This subroutine performs the To-11
done processing. The To -11 transfers are controlled by
both the 11-done and the doorbell events and everything is
synchronized by state variable DT11ST. This state variable
may assume one of the following values: DTSTDB = 0;idle
state, waiting for direct doorbell ;11-done and 10-done are
invalid.
DTSTHD = 2 ;waiting for 11-done for header ; doorbell and
10-done invalid
DTSTDD = 4 ; is not used.
DTSTIB = 6 ; waiting for indirect doorbell
(for ind. data) ; 11-done, 10-done are invalid.
DTSTID = 10 ;waiting for to 11-done for indirect data ;
doorbell and 10-done invalid.
The routine decrements the 11-done count (DTIEDN) and calls
a subroutine depending on current state of variable DT11ST
If 11-done occurs in a state when it is invalid, a stopcode
(64) will be executed.
SECTIONS "DTE10" AND "DTE20" Page 14-6
TASK:
14.7.1.1.3 DLDRBL: - This routine performs the processing
for the doorbell rung by the Ten. If valid examine is off,
the doorbells are ignored. Doorbell count is decremented
(DTIDBL) and status word in communication area (His to me
i.e. 11 area in 10's) is examined to see if indirect
transfer is in progress. If it is, the doorbell is
interpreted as indirect data doorbell and DTINST is called
to initiate indirect data transfer. In case it is a
direct-doorbell, routine DTHDST is called to initiate
transfer the header. The header is placed in TCB area
starting at offset DT11HD. Indirect data is stored in
chunks for write function. If the 11-done is in a state
when the doorbells are invalid, a stopcode (61) will be
executed.
14.7.1.1.4 DTHDIN: - This subroutine is called after the
header of the to-11 message is safely in the TCB area
starting at offset DT11HD. Then checks are made to see if
protocol funciton and device codes are legal. Then
depending on the function requested (in byte DT11DF) by the
ten, appropriate routine is called to perform the function.
After returning from the function performing routines state
of 11-done (variable DT11ST) is updated to expect either an
indirect data doorbell if the function DT11FN was indirect
or direct data doorbell for next possible header.
14.7.1.1.5 DTDIND: - This subroutine is called when 11-done
occurs and the state variable for 11-done is expecting
indirect data. This may be as a result of filling up a
chunk or reaching the end of the to-11 message. Since for
status writes there is only one block transfer, these
functions are dispatched to appropriate routines for command
interpreting and status setting and 11-done is initialized
back to DTSTDB while exiting from the routines via DTIPDN.
For write data function, if more data is left (DLMCTL=0) to
transfer to-eleven, call is made to DLTEDN to obtain a new
chunk and then DTSRT is called to fill data in the chunk If
nothing is left to transfer, then DLTEDN returns a zero in
register R0 implying that data transfer is complete and
state variable DT11ST is initialized and a success code (=1
in DT10DF+1) is sent to the ten along with amount of bytes
it was able to accept (in DT10DT).
SECTIONS "DTE10" AND "DTE20" Page 14-7
TASK:
14.7.1.2 DTE20 - The following holds if "DTE20.P11" has
been included in DN64 assembly.
14.7.1.2.1 Interface Between Hardware And DTE20 Task: - The
interface between the DTE20 hardware events and the DTE20
task is defined by DTE20 processor. The DTE20 processor is
driven by two finite state loosely coupled, state machines
"A" and "B" described below. The three hardware events as
mentioned earlier are the 11-done, the 10-done and the
doorbell interrups. The 11-done and doorbell drive the
finite state machine "A". The 10-done drives the other
state machine "B" for the DTE processor.
The following comments describe the states for the state-
driven DTE processor.
Abbreviations used in the description below are as follows:
FEH - Front-end header. This is a direct message that
describes the indirect data that follows as "string
data". For details on FEH format, refer to the
miscellaneous notes in section 14.8.
EH - ED header. This is an indirect message that describes
the following indirect message (if any) as "write
data", "write line command", "read data", etc.
ED - ED data. This is the indirect message described by the
EH message above.
ACK - acknowledge. This message acknowledges the receipt
and processing of the last indirect message.
A proper sequence consists of FEH, EH, FEH, ED. Where
relavent, an FEH is referred to as "FEH for EH" or "FEH for
ED" based on the message that follows the FEH
Each message is preceeded by a doorbell.
Before an FEH may be sent the previous FEH and its following
EH or ED must be acknowledged. This is a simplification of
the TOPS-20 rule.
A complete transaction is always initiated by the -20 with
an FEH followed by an EH. Depending on the contents of the
EH, it may be followed by FEH, ED. The PDP-11 replies with
FEH EH and, depending on the contents of the first EH, may
follow this by FEH, ED. Examine and deposit do not use ED
in either direction. No functions use ED in both
directions.
SECTIONS "DTE10" AND "DTE20" Page 14-8
TASK:
Below the description of each state is a brief description
of the action taken when the approprite event occurs.
14.7.1.2.2 State Machine "A": - State Machine "A" is driven
by 11-done interrupts and by doorbells.
0: waiting for initial doorbell. 11-done is invalid.
read FEH for EH.
2: Waiting for FEH for EH. Doorbell is invalid.
If device is wrong, go to state 34.
If allocation message, go to state 34.
Otherwise, read EH.
4: Waiting for doorbell for EH. 11-done is invalid.
Read EH.
6: Waiting for EH. Doorbell is invalid.
send ACK only if an ED to come. Set machine B from
state 0 to 2.
If the flag DT10AK indicates that there is no ED, then
send ACK + FEH, go to state 20, else go to state 10.
10: Waiting for doorbell for FEH for ED. 11-done is
invalid.
Read FEH for ED.
12: Waiting for FEH for ED. Doorbell is invalid.
Go to state 14.
14: Waiting for doorbell for ED. 11-done is invalid.
Read ED.
16: Waiting for ED. Doorbell is invalid.
If machine "B" is at state 4, send ACK+FEH and set
machine "B" to state 10, then go to state 22.
If machine "B" is not at state 4, go to state 20.
20: Waiting for ACK of EH to complete. (i.e., for machine
"B" to go from state 2 to state 6 or 10.) Neither
11-done nor doorbell are valid.
22: Waiting for doorbell for ACK for EH. 11-done is
invalid.
Read ACK for EH.
24: Waiting for ACK for EH. Doorbell is invalid.
If the EH inicates that no ED will be returned, and
machine "B" is in state 14, set both states to zero.
If machine "B" is not in state 14, go to state 32.
If the EH indicates that an ED will be returned, and
machine "B" is in state 14, send FEH for ED, set
SECTIONS "DTE10" AND "DTE20" Page 14-9
TASK:
machine "B" to state 16 and go to state 26.
If machine "B" is not in state 14, just go to state
26.
26: Waiting for doorbell for ACK for ED. 11-done is
invalid.
30: Waiting for ACK for ED. Doorbell is invalid.
If machine "B" is in state 22, set the states of both
machines to 0.
If machine "B" is not in state 22, go to state 32.
32: Got final ACK. 11-done and doorbell are invalid.
34: Ignoring 11-done.
If we get an 11-done, ignore it.
If we get a doorbell, treat it the same as for state
0.
14.7.1.2.3 State Machine "B": - State machine "B" is driven
by 10-done.
0: idle. 10-done is invalid.
2: Waiting for completion of ACK for EH or ACK+FEH .
If machine "A" is not in state 20, just go to state 4.
If machine "A" is in state 20, set it to state 22.
If the EH indicates that an ED will follow it, send an
ACK+FEH (machine "A" has already processed the ED or
it would not be in state 20) and go to state 10.
If the flag DT10AK indicates that an ED will not
follow, send an EH and go to state 10.
4: Got completion of ACK (or ACK + FEH) for EH.
10-done is invalid.
6: Unused state for now.
10: Waiting for completion of ACK for ED +FEH for EH.
Send EH.
12: Waiting for completion of EH.
If machine "A" is in state 26 then send FEH for ED and
go to state 16.
If machine "A" is not in state 26 then go to state 14.
14: Waiting for ACK for EH. 10-done is invalid.
16: Waiting for completion of FEH for ED.
Send ED.
20: Waiting for completion of ED.
SECTIONS "DTE10" AND "DTE20" Page 14-10
TASK:
If machine "A" is in state 32 then set both states to
0, otherwise go to state 22.
22: Waiting for ACK for ED. 10-done is invalid.
14.7.1.2.4 DLTXDN: - This subroutine decides what to do
when a to-10 interrupt is recognized. It implements the
state machine "B" as described above.
14.7.1.2.5 DLELDN: - This subroutine decides what to do
when an 11-done interrupt is recognized. It implements part
of state machine "A" described above.
14.7.1.2.6 DLDRBL: - This subroutine decides what to do
when a doorbell (rung by the ten for eleven) is recognized.
It implements the remainder of machine "A".
14.7.1.2.7 DTSACK And DTSAK: - The subroutine DTSACK sends
an ACK alongwith FEH header ,the ACK riding piggyback on the
FEH in conformance to the concatenation rules of Queued
Protocol Specifications. The subroutine DTSAK sends an ACK
only to the Ten in response to the data receved by the
Eleven. The reason for concatenation is to reduce the
number of DTE20 transactions and speed up the communications
thereby.
14.7.2 Queued Protocol Interface Subroutines:
14.7.2.1 DTHDST: - This subroutine is called by the
doorbell processor to initiate a to-11 transfer of a header
in response to a direct doorbell received when 11-done state
(DT11ST) was in state DTSTDB. The next 11-done will
continue processing by examining the header after swapping
bytes to correct direction of transfer. The header is
stored at the TCB starting at offset DT11HD.
SECTIONS "DTE10" AND "DTE20" Page 14-11
TASK:
14.7.2.2 DTINST - This routine initiates an indirect data
transfer to the PDP-11 when the doorbell requesting indirect
data rings. Byte size of transfer is found by examining
communication area (status word) and sets the size in
DTEQSZ, DLMBCT and DLMCTL. Size information is also passed
(in R0) on to DLEDBL subroutine. DLEDBL returns the address
(of either a chunk for data writes or status block for
status write function) of block where data must be sent, for
further processing. Notice that it isnot necessry to
allocate space for entire message because gather-write is
implemented on the the Eleven writes. A to-11 transfer is
initiated by calling subroutine DTSTRT, and a new state is
entered to wait for indirect data done.
14.7.2.3 DTSTRT: - This subroutine is responsible for
starting a to-11 transfer and it requires two arguments:
No. of bytes to transfer in R0, and address of where to put
the data in R1. If this transfer would complete the to-11
transfer in in progress, both processors are interrupted to
give -11 done, otherwise only the Eleven is interrupted by
11-done for gather write operation. If the chunk obtaining
routines fails to get a chunk , operation delayed flag is
up, a dummy to-11 transfer of one byte is done to get an
11-done for both processors to finish the delayed to-11
transfer. This routine keeps a count of numbers of bytes
left to transfer for the next transfer (in word DLMCTL). If
the debug switch is on, the address and byte count are saved
in DT11AS and DT11BS offsets in the TCB.
14.7.2.4 DLEDBL: - This subroutine is called when queued
protocol finds it received an indirect data doorbell.
DLEDBL sets up the address of a block to receive the
indirect data. For status (line/device on DN60) writes it
simply passes the address of dedicated block DTTTSB in
global area while for data write requests, it fetches a
chunk from free storage and passes address onto calling
subroutine. If it fails to get a chunk, flags are set to
indicate the delayed operation.
14.7.2.5 DLTEDN: - This subroutine queues the previously
filled chunk (by data write operation) for XLATE and obtains
a new chunk to pass on to 11-done interrupt routine. It
keeps track of count left (in cell DLMCTL) for next transfer
and in case the count is exhausted, clears R0 to so indicate
to the calling routine. If unable to obtain new chunk, it
flags operation delayed and shortage of chunks for calling
routines to see.
SECTIONS "DTE10" AND "DTE20" Page 14-12
TASK:
14.7.2.6 DLSERR: - This routine is called to set reject
flags (3 in DT10DF+1, and DT11GW=-1) for calling routines to
see
14.7.2.7 DLSDLY: - This routine is called to flag
"operation delayed: for calling routines to see (2 in
DT10DF+1, DT11GW=-1)
14.7.2.8 DTSHDR: - This subroutine sets up header for
sending it to the Ten. The header is in TCB area starting
at offset DT10HD. The protocol function, device, line no.
and DN60 function are set up properly. The indirect
transfer bit and result code are set by the operation
responding to the requested function. The header is 16
(octal) bytes long except for deposit function when it is
only 12 (octal) bytes long.
14.7.2.9 DTCMRT: - This subroutine sets up the remaining
information in the header being sent to the Ten like number
of bytes transfered and calls DTXMSD to send to the header
to Ten. It also initializes the value (to DTSTDB) of
11-done state variable DT11ST).
14.7.2.10 DTIPDN: - This routine is called to clear
processing in queue status to indicate to Ten that 11 is
done with the current transfer, and return to either the
eleven done or doorbell processing.
14.7.3 Function Dependent Subroutines:
14.7.3.1 DLTWDT: - This subroutine is called then the Ten
has requested a write data function meaning that the Eleven
is is ready to receive data from the ten. The subroutine
essentially checks validity of line number passed in the
header and other conditions (are all right) for transfer to
proceed. If XLATE task (to which data chunks are passed on)
is running behind, the operation is delayed unless it was
due to an abort or EOF in which case operation is rejected.
SECTIONS "DTE10" AND "DTE20" Page 14-13
TASK:
14.7.3.1.1 DLTWD1: - To set device status, the status is
written into a global block starting at location DTTTSB.
This is a one block transfer and amount of data from the Ten
must not exceed the size of status block area. The status
block is then examined for device command functions by the
command interpreter routines and control is transferred to
appropriate device routines to set up the status conditions
at the device level.
14.7.3.2 DLTRDT: - This subroutine performs "Read Data"
function DLTRDT examines the queue for the oldest message
received over the specified line by the translate task. If
one is found, it becomes the current message. The user may
ask for maximum of one chunk and request for any more will
result in transmitting only the current chunk or rather what
is left in the current chunk. If the user asks for less
than a chunk then the byte pointer in the chunk is updated
after the data is sent to the Ten. The data is always sent
as indirect packet. The message is not freed till the end
of the current message is encountered when it is sent to the
IDLE task to be broken down into chunks and freed. DLTRDT
handles cases of no message being available and that of
input being aborted.
14.7.3.3 DLTRLS: - This subroutine performs the "Read Line
Status" function. It copies data from the LCB into the
status block which is passed onto the ten as an indirect
data packet.
14.7.3.4 DLTWLC: - This subroutine performs the "Write Line
commands" function. DLTWLC checks for validity of relevant
arguements passed in header but the real work is performed
by the subroutines which are called by DLTWL1. The
subroutines are described briefly below.
14.7.3.4.1 DLTWL1: - is called when indirect data has been
received for setting up the line status. The operation is
similar to one in DLTWD1 except at the end control is
transferred to line status routines.
SECTIONS "DTE10" AND "DTE20" Page 14-14
TASK:
14.7.3.5 DLTEXM: - This subroutine performs the actual
examine/deposit function of the Eleven memory and is called
after the DN60 protocol header has been received and
requested function recognized to be an examine or deposit.
For examines, the address passed is used to look into
contents of the cell and result stored into DT10DT to pass
data back to the Ten. For deposit function, the data (in
DT11T) is stored into the address (in DT11AD) passed is the
header. Any illegal addresses will be trapped and a reject
code will be sent back to the Ten.
14.7.3.6 DLTRES: - This subroutine performs the "Read DN60
status" function. DLTRES simply copies some data from
global area to the status block using DLPSTR and then this
data is sent indirectly to the Ten following the header.
Indirect transfer bits are set in protocol function code and
amount of data to be transferred in indirect packet is set
in DT10DT.
14.7.3.7 DLTWEC: - This subroutine performs the "Write DN60
Command" function DLTWEC is a dummy since no use is yet
defined for this function.
14.7.3.7.1 DLTWS1: - This subroutine is called for setting
DN60 status - use of which has not been defined yet. Any
call to it should be invalid.
14.7.3.8 DLGBYT: - Is a subroutine to get a byte of
transfer from the block pointed to by R2. Count of no. of
bytes must set in R4. It keeps count of bytes fetched in
cell TCXFR in TCB. It is called by status routines.
14.7.3.9 DLPBYT: - This subroutine stores a byte of data in
the block pointed to by R2. Count number of number of bytes
in R4 and byte to store must be passed in R1. The count of
bytes transfered is kept in TCB offset TCXFR.
SECTIONS "DTE10" AND "DTE20" Page 14-15
TASK:
14.7.3.10 DLPWRD: - This subroutine stores a 16-bit word
into the block pointed to by R2. DLPWRD works by calling
DLPBYT.
14.7.3.11 DLPSTR: - stores a string of words in the area
pointed to by R2. DLPSTR works by calling DLPWRD.
14.7.3.12 DTCERR: - Is a common error return routine called
when a fatal error occurs like abort or Ten error or
protocol breakdown. If debug switch is on it executes a
stopcode TER (54) meaning Ten error. If the debug switch is
off, all outstanding data streams are aborted.
14.7.4 Command Interpreter Subroutines
There are two sets of command interpreter subroutines: one
set for the line commands and one set for the device
commands. The line command subroutines are named DLTLnn
where nn is the number of the command. The device
subroutines are named DLTDnn where nn is, again, the number
of the command. It would be tedious to list all of the
subroutines here; they are all very short and each is
headed by a comment specifying its function. These
functions are also listed in Chapter 20 which specifies how
to use the CAL11. UUO.
After the line and device subroutines are some subroutines
which they use. The most important ones are listed here.
14.7.4.1 DLDRAI - This subroutine drains the message queue
from the translate task. DLDRAI is used when a message
stream is aborted.
14.7.4.2 DLNWCK - This subroutine sends the current chunk
to the translate task and obtains a new one from free
storage. DLNWCK is used when doing the "write data"
function and is responsible for making sure that the output
stream from the PDP-10 does not use up all the chunks. If
the PDP-10 were permitted to use up all the chunks then data
could not be received and one line might "hog" chunks, thus
preventing other lines from transmitting.
SECTIONS "DTE10" AND "DTE20" Page 14-16
MISCELLANEOUS NOTES
14.8 MISCELLANEOUS NOTES
For references to the KL10/PDP-11 DTE20 PROTOCOL the reader
is advised to read DOC. NO. 200-205-034-00
For references to the DN60-communications PROTOCOL see
Appendix A.
For references to the QUEUED PROTOCOL, please see the DTE20
QUEUED PROTOCOL V1 DOC. NO. 200-205-036-00
FEH described below is sent to the ten to precede (always)
the "EH" or "ED".
FEH FORMAT:
----------------------------------------------
! Count of bytes in header (12 octal) !
----------------------------------------------
! Protocol Function Code !
----------------------------------------------
! Protocol Device Code !
----------------------------------------------
! SPARE !
----------------------------------------------
! FE# (8-bits) ! Count to follow @ !
----------------------------------------------
NOTE1: The ACK Header is similar to the above with
Protocol Function being the "Acknowledgement " function
DTFSAK.
NOTE2: The Header FEH is sent with bytes swapped to correct
direction of transfer so that the Ten or DECSYSTEM-20
receiving it do not have to do it.
NOTE3: The chunk size has been changed to 300 octal bytes
for the DN64 and DN61 products using the DTE20.
CHAPTER 15
SECTION "XL3780"
This section contains the translate task, the background
task, and the tables used by the translate task to convert
between ASCII and EBCDIC and to simulate a line printer
carriage control tape.
15.1 THE IBM 3780/2780 TRANSLATE TASK - XLATE
The translate task is responsible for translating character
sets and vertical motion commands between ASCII as used by
the DECsystem-10 and DECSYSTEM-20, and EBCDIC as used by the
IBM 3780, IBM 2780 and IBM 360.
15.1.1 Output Processing -- ASCII To EBCDIC
The output processor starts by waiting for the PDP-10 to
request output permission and then passes this request on to
the BSC task. The BSC task will bid for the line. If the
BSC task gets an ACK-0 in response to its bid, it considers
that output permission has been granted. The translate task
passes this grant on to the PDP-10 and then begins
converting data from the PDP-10 from ASCII to IBM EBCDIC for
transmission to the BSC task.
The subroutine that translates a chunk of PDP-10 data from
ASCII to EBCDIC is called XLOCNK.
15.1.1.1 Card-style - When XLOCNK translates a character
from ASCII to EBCDIC in "card style" it calls XLASCD. This
subroutine was modeled after the card punch logic in
TOPS-10. It ignores DEL and most control characters, as
well as all printable characters after column 80. A line
feed releases a card. A horizontal tab is converted to
spaces. For the IBM 2780, cards shorter than 80 characters
are padded to 80 characters with spaces.
SECTION "XL3780" Page 15-2
THE IBM 3780/2780 TRANSLATE TASK - XLATE
15.1.1.2 Printer-style - When XLOCNK translates a character
from ASCII to EBCDIC in "printer style", it calls XLASPR.
XLASPR is much more complex than XLASCD since it uses the
IBM 3780'S printer to simulate an LP10. XLASPR worries
about vertical motion characters (using a software carriage
control tape), horizontal tabulation and line overflow. The
IBM 3780'S printer is assumed to have only the minimum
carriage control functions: top of form, no spacing, single
space, double space and triple space. Multiple spacing from
the PDP-10 is indicated by multiple line feeds, and these
are retained using a "look ahead" technique so that they can
be translated into a multiple spacing function. Any
carriage control which causes the top of form to be reached
(including a line feed) is translated to a top of form
command.
On the IBM 2780 overprinting is ignored since this printer
cannot overprint.
The following subroutines are used by XLASPR. Some of these
are also used by XLASCD.
1. XLASTF - go to top of form.
2. XLASSF - single space.
3. XLASSP - output a blank.
4. XLSNDL - send a line to the BSC task.
In addition, XLSNDL calls XLSNDM, which sends a message to
the BSC task, and MSGSUP, which sets up the BSC message.
15.1.1.3 End-of-file - Subroutine XLEOFO does end-of-file
processing for output. It completes the current line and
message and flags the BSC task that all the data has been
placed in its message queue.
15.1.2 Input Processing -- EBCDIC To ASCII
When the output processor is waiting for an output request
or grant, it calls XLWAIT. This subroutine looks for a
request from the BSC task for input permission. (This
request is produced by the BSC task receiving an ENQ.) The
request is passed on to the PDP-10, and if the PDP-10 gives
its permission, the grant of permission is passed down to
the BSC task, which will cause it to respond to the ENQ with
an ACK-0. If all of this happens before the BSC timeouts
expire then the translate task arranges to translate the
SECTION "XL3780" Page 15-3
THE IBM 3780/2780 TRANSLATE TASK - XLATE
EBCDIC data coming from the BSC task to ASCII and pass it on
to the PDP-10.
The subroutine which translates an EBCDIC message to ASCII
is called XLIMSG.
15.1.2.1 Card-style - When XLIMSG translates a character
from EBCDIC to ASCII using "card style", it simply puts a
carriage return line feed at the end of each line,
translating all the EBCDIC characters in the card to ASCII.
Untranslatable characters are discarded. Blanks which have
been compressed using "IGS" are expanded.
15.1.2.2 Printer-style - When XLIMSG translates a character
from EBCDIC to ASCII using "printer style", it also converts
the IBM 3780 carriage control commands into ASCII control
characters suitable for an LP10. A single spacing command
is translated to a line feed if the printer is near the top
of the page, but if the printer is near the bottom it is
translated to a DC3. A top of form command is translated to
a form feed. Carriage returns are output only if the
horizontal position has advanced from the left margin. It
would have been possible to always convert the single space
command to a DC3, but TECO and SOS do not recognize DC3 as
being an end-of-line indicator, so line feed is used
whenever possible to make returned files easier to edit.
The IBM 3780 has a feature which permits setting of
horizontal tab stops. This feature is also simulated.
15.1.2.3 Transparent - In transparent mode the end of the
card is determined by counting characters. Otherwise it is
essentially the same as card-style input. Note that EBCDIC
characters which are not translatable to ASCII are
discarded, so the DN60 is not suitable for reading IBM 360
"binary" card decks.
The following subroutines are used by XLIMSG.
1. XLITSP - process a transparent message.
2. XLIPRS - process an "IRS" character in printer
mode. This character signals the end of the print
line.
3. XLCPUT - wait if the translate task has been using
an excessive amount of CPU time.
SECTION "XL3780" Page 15-4
THE IBM 3780/2780 TRANSLATE TASK - XLATE
4. XLIPCR - output a carriage return in printer mode.
5. XLIPSP - output an LP10 single space, using
carriage return (if needed) followed by line feed
or DC3.
6. XLIPGS - expand compressed blanks using "IGS"
compression.
7. XLISHT - set horizontal tab stops.
8. XLIPHT - process a horizontal tab, converting it to
blanks.
15.2 THE BACKGROUND TASK - IDLE
The IDLE task is used to free messages and chunks since this
is a time-consuming activity. If IDLE finds itself using
too much CPU time it will wait until the dispatcher gets
some idle time before freeing messages and chunks. The IDLE
task runs as the lowest priority dispatched task. Messages
and chunks which it is to free are sent to it on its message
and chunk queues.
The IDLE task is also used to check any disabled lines and
get rid of their BSC TCB and LCB so that when a new line is
enabled it will have all cells initialized. The subroutine
DLCKCL in DTE10 task does this job.
15.3 TRANSLATE TABLES
There are four translate tables used by XL3780.
15.3.1 EBCDIC To ASCII
This table converts graphics and some control characters.
Untranslatable characters are entered as zero. The table is
addressed from the middle because of the sign-spreading
function of the PDP-11 "MOVB" instruction.
SECTION "XL3780" Page 15-5
TRANSLATE TABLES
15.3.2 ASCII To EBCDIC
This table translates ASCII graphics to EBCDIC. All
graphics are translatable. IBM has defined a standard
translation between EBCDIC and ASCII in their XLATE macro in
OS/360 release 20 and later. The DN60 uses this same
translation, even though it makes the IBM 029 keypunch
difficult to use: the exclamation point on the keypunch
translates to ASCII vertical bar, for example.
15.3.3 ASCII Special Character Table
This table is used for dispatching when translating ASCII
control characters to EBCDIC.
15.3.4 EBCDIC Special Character Table
This table is used for dispatching when scanning EBCDIC
characters in the BSC task and for recognizing data link
control characters in XL3780.
15.4 CARRIAGE CONTROL
The carriage control table is used to simulate an LP10 using
the IBM 3780'S printer. It is an image of the LP10 carriage
control tape. Each byte has a bit position for each
vertical motion character, and if the bit is set, then a
"hole" is "punched" in the tape, and so a skip to the
channel should stop here. The next table, XLLPCH,
translates from the ASCII control character to the channel.
There is currently no provision for "loading" the carriage
control tape from the PDP-10.
CHAPTER 16
SECTION "XLHASP"
This section handles the translation, compression,
decompression, simulation of line printer carriage control
tape, recognition of binary mode etc.. for all HASP
Multileaving devices.
16.1 XLHASP
This task checks for line to be bid and if it is not waits
till line is "bid". The device can run in either input or
output mode. control is given to XHDINP for input
processing and to XHDOUT for doing the output processing.
16.2 XHDOUT OUTPUT PROCESSING
This subroutine starts by looking for any aborts on the
device and services them first before doing any other
processing. The ten must issue output request for the
XLHASP and BSC tasks to see so they can send request message
to remote. The XLHASP will wait for output permission to be
granted by the remote before going any furthur in XHDOUT.
ASCII to EBCDIC translation is done by XLHSEB on a chunk
basis on chunks coming from the ten. XLHSCD does the card
style translation from ASCII to EBCDIC on character basis.
The line printer style translation is done by XLHSPR. The
following subroutines are
16.2.1 Card-style
When XLHCNK translates a character from ASCII to EBCDIC in
"card style" it calls XLHSCD. This subroutine was modeled
after the card punch logic in TOPS-10. It ignores DEL and
most control characters, as well as all printable characters
after column 80. A line feed releases a card. A horizontal
tab is converted to spaces.
SECTION "XLHASP" Page 16-2
XHDOUT OUTPUT PROCESSING
16.2.2 Printer-style
When XLHCNK translates a character from ASCII to EBCDIC in
"printer style", it calls XLHSPR. XLHSPR is much more
complex than XLHSCD since it uses the IBM HASP's printer to
simulate an LP10. XLHSPR worries about vertical motion
characters (using a software carriage control tape),
horizontal tabulation and line overflow. The IBM HASP's
printer is assumed to have only the minimum carriage control
functions: top of form, no spacing, single space, double
space and triple space. Multiple spacing from the PDP-10 is
indicated by multiple line feeds, and these are retained
using a "look ahead" technique so that they can be
translated into a multiple spacing function. Any carriage
control which causes the top of form to be reached
(including a line feed) is translated to a top of form
command.
The following subroutines are used by XLHSPR. Some of these
are also used by XLHSCD.
1. XLHSTF - go to top of form.
2. XLHSSF - single space.
The XHSNDL subroutine also calls a compressor subroutine
HSCMPS which takes a line buffer and puts it in a compreesed
buffer. The buffer is transferred into a message being
built for BSC. The message will keep on building till next
record cannot be accomodated or an EOF or DUMP bit has been
set as a result of ten informing that to the XLATE. The
message is then queued for BSC to do the transmission.
In addition, XHSNDL calls XHSNDM, which sends a message to
the BSC task, and MSGSUP, which sets up the BSC message.
16.2.2.1 End-of-file - Subroutine XLHEOF does end-of-file
processing for output. It completes the current line and
message and flags the BSC task that all the data has been
placed in its message queue. The output processor also uses
some of the subroutines listed below:
1. XHSNDL - send a line to the BSC task. ,le;HSCMPS -
compress line and put in message buffer
2. HSCMPO - put line in message without compressing
3. XHMSTP - set up message for receiving compressed
records.
SECTION "XLHASP" Page 16-3
XHDOUT OUTPUT PROCESSING
4. XLHSON - make signon block of 80 characters for
BSC.
5. XLHEOF - append an EOF to the message and mark for
BSC.
6. XLHDMP - dump the current messages to BSC for xmit.
16.2.3 Input Processing
This section starts at XHDINP and checks for input aborts.
XHDIAB does the input abort processing by releasing all the
messages queued for this task. If run conditions are true,
then control goes to XHEBAS which starts dequeing any
incoming messages from the BSC task. When no more messages
arrive, EOF or abort are expected. For EOF dectected, it
marks EOF received and waits for ten to notice and clear
complete bit. XHDINP subroutine looks for a request from
the BSC task for input permission. (This request is
produced by the BSC as a result of receipt of a device
request message from remote.) The request is passed on to
the PDP-10, and if the PDP-10 gives its permission, the
grant of permission is passed down to the BSC task, which
permits the remote in turn to resume the stream for the
device. If all of this happens before the BSC timeouts
expire then the translate task arranges to translate the
EBCDIC data coming from the BSC task to ASCII and pass it on
to the PDP-10.
The subroutine which translates an EBCDIC message to ASCII
is called XHIMSG.
16.2.3.1 Card-style - When XHIMSG translates a character
from EBCDIC to ASCII using "card style", it simply puts a
carriage return line feed at the end of each line,
translating all the EBCDIC characters in the card to ASCII.
Untranslatable characters are discarded. The receipt of a
special record is also detected by searching each record
header for RCB and SRCB. For a signon record, the control
goes to XLDSON which assembles the 80 character message and
directs it to card stream (for Termination only).
SECTION "XLHASP" Page 16-4
XHDOUT OUTPUT PROCESSING
16.2.3.2 Printer-style - When XLIMSG translates a character
from EBCDIC to ASCII using "printer style", it also converts
the HASP systems send a sub-record control byte (SRCB) which
is translated into carriage control commands characters
suitable for an LP10. A single spacing command is
translated to a line feed if the printer is near the top of
the page, but if the printer is near the bottom it is
translated to a DC3. A top of form command is translated to
a form feed. Carriage returns are output only if the
horizontal position has advanced from the left margin. It
would have been possible to always convert the single space
command to a DC3, but TECO and SOS do not recognize DC3 as
being an end-of-line indicator, so line feed is used
whenever possible to make returned files easier to edit.
The following subroutines are used by XLIMSG.
1. XHIPRS - process EOR for LPT type devices.
2. XHGTC - gets a chacter from the received EBCDIC
message.
3. XLDPCM - translates character from EBCDIC to ASCII
and deposits it in message.
4. XHIMSE - sends ASCII message to DTE task. This
character signals the end of the print line.
5. XLCPUT - wait if the translate task has been using
an excessive amount of CPU time.
6. XLIPCR - output a carriage return in printer mode.
7. XLIPSP - output an LP10 single space, using
carriage return (if needed) followed by line feed
or DC3.
8. XLIPGS - expand compressed blanks using "IGS"
compression.
9. XLISHT - set horizontal tab stops.
10. XLIPHT - process a horizontal tab, converting it to
blanks.
The input EOF is detected by receipt of zero RCB after
receiving a zero length record from the remote. This is
signalled to the ten and a wait is done till EOF complete is
cleared by the ten. The bits for permission granted,
permitted to run are cleared to make way for next requests
by the remote.
SECTION "XLHASP" Page 16-5
TRANSLATE TABLES
16.3 TRANSLATE TABLES
These are the same as used by the XL3780.
CHAPTER 17
SECTION "CHK11"
Previous versions of CHK11 acted as hardware test modules
for PDP-11 communications systems such as the DAS44, DAS78,
DN80, DN81, DN82, DN85 and DN87. The DN60 front end
software also includes a version of CHK11.
NOTE
Do not be fooled by the
similarity of names. Many of
these PDP-11 based products
use a different version of
CHK11. Only the CHK11 that is
included with a product should
be used with it.
During initialization, before chunk space is allocated,
CHK11 tests all of the I/O devices supported on the front
end (and many that are not) and prints information about
them. CHK11 also prints the version number of the software
loaded.
If there is a minor hardware problem, CHK11 will usually
recognize it and print a meaningful message. If there is a
serious problem such as a faulty Unibus or a missing memory
stack, CHK11 may be unable to print a meaningful message.
It has been our experience that in the serious cases (and in
most non-serious cases) the diagnostics supplied with the
system will find the problem. Sometimes CHK11 will give an
incorrect indication of which device is having problems.
For example, once CHK11 indicated that the DL10 was not
giving interrupts when the fault was actually in the DQ11.
This happened because the DQ11 was ahead of the DL10 on the
Unibus but the DL10 was tested before the DQ11. The DQ11
was causing Unibus troubles that rendered the DL10
unuseable. A good rule of thumb is:
SECTION "CHK11" Page 17-2
1. run the diagnostic for the indicated device
2. if it does not fail run DECX11, an exerciser for
the whole system.
3. If DECX11 doesn't fail, run all the diagnostics.
This will usually spot the device that is in error.
Some kinds of Unibus troubles are manifested as a device
answering to several addresses. CHK11 will sometimes
indicate this by claiming that several "strange" devices are
present, such as a TC11 or RK11.
A detailed discussion of the internals of CHK11 will not be
included in this document, since it contributes nothing to
the operational capabilities of the software and merely
serves to provide confidence that the hardware is in working
order.
There is more information about CHK11 in the operator's
manual.
CHAPTER 18
DEBUGGING FACILITIES
This chapter is a guide to the debugging facilities in the
DN60 front end software. These facilities were useful in
the development of the software. Some of them are probably
no longer useful, but all were left, because it is hard to
predict which will be needed.
18.1 STOPCODES
If the DN60 software discovers an error in itself, it issues
a fatal error, called a "STOPCODE". The meaning of each
STOPCODE is listed in section "S". Usually the STOPCODE
number plus the listing will give the maintainer a good idea
of what went wrong (at least the obvious symptom), but often
a dump of the front end's core at the time of the stop
helps.
Under normal operation with working CPU and memory the
software should never issue a STOPCODE. If it does then
there is a problem which should be fixed. If, however, the
front end is being run beyond its rated limits, such as a
DN61 with more than 12 DQ11's or with more than 100,000 baud
aggregate termination, then a STOPCODE can be expected and
does not indicate a problem which should be fixed unless the
STOPCODE can be reproduced with the front end running within
its specifications.
Of course, any unauthorized modifications to the front end
software may cause STOPCODE's.
18.2 CORE DUMPS ON DECSYSTEM-10
The utility program BOOT11 can be used to obtain core dumps
of the DN60 front end software in the same way as it is used
to obtain core dumps of, for example, the DC76. BOOT11 is
distributed as a standard part of the TOPS-10 software.
When using the DN60 software on a DTE20, DTELDR can be used
DEBUGGING FACILITIES Page 18-2
CORE DUMPS ON DECSYSTEM-10
to obtain dumps as for the DN87S.
18.3 CORE DUMPS ON DECSYSTEM-20
The utility program DNLOAD can be used to obtain core dumps
of the DN64 by using the DUMP command. DNLOAD is
distributed with the DN64 software.
18.4 DDT60
Some other DEC products that use CHK11 also make available a
program called DDT11. DDT60 is a modified version of DDT11
for the DN60 front end software. It can be used to examine
the DN60's data structures while it is running, and it is
also useful for interactive examination of core dumps.
The following list shows all of the facilities of DDT60,
including those intended for debugging network nodes. If
you are interested in debugging network nodes, however, you
should use DDT11 as distributed with the network software.
18.4.1 Initial Switches
/BINARY:filspec read a ".BIN" file (output from
MACDLX)
/DUMP:filespec read a core dump listing (output of
BOOT11 or DTELDR)
/DIMAGE:filespec read a core dump image (output of
DNLOAD or DTELDR)
/EXIT return to monitor
/LINE specify line from node (similar to
NETLDR)
/NODE specify node to debug or (with
/LINE) node adjacent to node to
debug
/PATCH allow writing into core
/PDP8 remote CPU is a PDP-8 (i.e., DC71 or
DC72) (this facility is only
partially implemented)
DEBUGGING FACILITIES Page 18-3
DDT60
/PORT specify port for DC76, DN85, DN87 or
DN60. (0-3 on DL10 number 1, 4-7
on DL10 number 2, 10-13 on DTE20
0-3.)
/SYMBOLS:filespec read symbol table from a
cross-reference listing. (Output
from MACDLX.)
Note: /BINARY, /DUMP, /DIMAGE, /NODE and /PORT cause
immediate exit from initial dialog, without processing any
subsequent text on the line.
18.4.2 Debugging Language
The language mimics DDT-10 for examining memory and building
symbols. Special functions are introduced by ESC. Numeric
arguments go between the ESC and the letter. Lower case
letters are permitted. The notation TEMP/PERM means the
mode is set until a carriage return is input unless it is
introduced by two ESCs, just as in DDT-10.
The following is the list of function letters introduced by
ESC.
A set address typeout mode. TEMP/PERM. arg=length
B set BYTE typeout mode. TEMP/PERM. arg=length
C set NUMERIC (constant) typeout mode. TEMP/PERM.
arg=length
D dump memory onto a file. the range is specified as:
LOW<HIGH>$D. arg = dump type: 0 = normal, 1 = no
instruction typeout
G cause CPU to branch to expression. (only with /NODE)
I set EBCDIC output mode. TEMP/PERM. arg=length
K suppress typeout of preceeding symbol.
M location for MASK for searches
N NOT WORD search for preceeding expression. search is
masked by location $M and limited by range,
expressed as for $D.
P punch binary tape of core image (not yet implemented)
R set radix in range 2 to 15. TEMP/PERM. arg=radix
DEBUGGING FACILITIES Page 18-4
DDT60
S set INSTRUCTION output mode (default). TEMP/PERM.
arg=length
T set ASCII output mode. TEMP/PERM. arg=length
V watch open location, type out changes, stop when
carriage return typed.
W WORD search, similar to $N.
18.4.3 Deliberately Crashing The DN60
If you want to get a core dump of the DN60 front end
software, but it hasn't hit a STOPCODE, use DDT60 to store a
TRAP 377 at location DISPAT. This will cause the DN60 to
issue a STOPCODE 377 as soon as all tasks are waiting.
BOOT11, DTELDR or DNLOAD can then be used to get a core dump
without concern that the data structures might have been in
an intermediate state when the front end was stopped.
18.5 "DEBUG=1"
One of the parameters in section DEFINE is DEBUG, which is
set to zero for production versions of the DN60 front end
software. If you are having a problem which is either not
being caught by a STOPCODE or for which the STOPCODE
information is inadequate to trace the cause, you might try
reassembling the software with DEBUG set to 1. This will
provide some extra information on a STOPCODE and generate
code to support a lot of useful debugging features, some of
which are always present (with DEBUG = 1) and some of which
can be enabled selectively using DDT60. Note, however, that
the software is not supported with DEBUG set to 1; the only
excuse for changing this parameter is to trace a problem
that happens with DEBUG set to 0. Note also that the DN60
will not meet its documented throughput specifications with
DEBUG set to 1 because of the increased overhead involved in
tracing, even when trace recording is disabled.
18.5.1 Extra STOPCODE Information
With DEBUG = 1 the following extra information is stored
with a STOPCODE:
1. The CPU registers
DEBUGGING FACILITIES Page 18-5
"DEBUG=1"
2. The DQ11 registers, including all of the "internal"
registers, or the DUP11 registers
3. The KG11-A registers (not available on DN20-based
systems)
4. The DTE20 registers are saved in DTESAV to
DTESAV+20
This information can sometimes be very useful in further
defining the reason for the STOPCODE.
18.5.2 Chunk Ownership Recording
With DEBUG = 1 the owner of each owned chunk is recorded in
a table. The owner information is the PC of the call to
GETCHK (except for interrupt routines, in which case it is a
PC inside the interrupt routine). When a chunk is freed,
the low order bit of the table entry is set so that the
chunk is flagged as free but the name of the last owner is
not destroyed. This table can sometimes be valuable if
chunks are being lost; eventually the culprit will make
himself obvious by getting and then losing a lot of chunks,
and a simple scan of the table will find him. Other times a
careful comparison of the free list with the owner table
will be required to track down the bad guy.
18.5.3 Tracing
Two kinds of tracing are possible: T-bit tracing and event
tracing. T-bit tracing can be useful when the program is
running absolutely wild and eventually halting. This can be
caused, for example, by getting the stack out of synch in a
subroutine, and trying to return to data. The instruction
set of the PDP-11 makes it likely that the program will
commit an error fairly quickly, but sometimes the registers
can be destroyed before the halt. In this case T-bit
tracing can be used to examine the last few values of the PC
in order to find the source of the error.
T-bit tracing is enabled for a task by setting bit 4 in word
TCPS of the task control block of the task to be traced. In
a crash, there is usually a pointer to the executing task in
GLOBAL cell DSPTCB and in R5. To trace a lot of tasks it
may be simpler to set bit 4 in GLOBAL cell TRCFLG. This
will cause all tasks created to be traced.
DEBUGGING FACILITIES Page 18-6
"DEBUG=1"
An interrupt routine can be traced by setting bit 4 of the
interrupt PS word.
On each T-bit interrupt the PC and PS of the interrupted
instruction stream is stored in the trace table. This table
extends from location TRCTBS to location TRCTBE. Location
TRCPTR points to the next entry to be stored. This table
can be examined with DDT60 after a crash to determine the
last several values of the PC. The length of the trace
table is by default 80 entries (when DEBUG = 1), but it can
be changed by changing the parameter TRCTBL.
Event tracing can only be used if T-bit tracing is not being
used. This tracing facility uses the same trace table and
pointer as T-bit tracing, but instead of recording every PC
and PS, the table entries are the address of a TRACE macro
and a word specified by that macro as being interesting.
This is a selective trace; any one or more of ten event
categories can be independently enabled. This is done by
setting bits in GLOBAL cell TRCBTS as follows:
1. TRCDQD - trace all BSC task data, one character at
a time. This traces only input, since output
messages are built by XLATE.
2. TRCDQF - trace all DQ11 or DUP11 functions. This
trace is of interrupts as well as function
initiations.
3. TRCCNK - trace chunk manipulations. This will
record the recent history of GETCHK and FRECHK
calls (and interrupt routines getting chunks) as an
adjunct to the chunk owner recording feature.
4. TRCDSP - trace all dispatcher functions. This is
not useful by itself, but in combination with other
events it serves as a marker for task changes.
5. TRCQUE - trace queuing of messages and chunks.
This can spot problems such as a message being
placed twice on a queue, with disastrous results
for the structure of the queue.
6. TRCXLD - trace all XLATE data one character at a
time. This can be used to find errors in the
translation algorithms.
7. TRCBCC - trace computation of BCC (block check
characters). If a message is built with incorrect
BCC, this can find the error in either the KG11-A
or the algorithm which determines which characters
to include in the BCC. This should be used in
conjunction with TRCXLD so that the data can be
traced, as well.
DEBUGGING FACILITIES Page 18-7
"DEBUG=1"
8. TRCABO - record a trace entry if the BSC stream is
terminated before the normal end-of-file sequence.
This is known as aborting the stream.
9. TRCTEN - trace PDP-10 data flow. This will trace
the data that flows through the DL10 task and will
leave some markers for start and end of messages.
This can be valuable for tracking down DL10 or
DTE20 problems and for errors in the PDP-10 program
itself.
10. TRCMDF - trace interactions with the KMC11. This
has been useful for debugging the KMC11 microcode.
11. TRCBCB - trace all BCB received and expected by the
DN62 or DN65 software.
In addition, there is a GLOBAL cell TRCHLT which can have
bits set in it to cause debugging STOPCODE's. These bits
are:
1. TRCABO - stop if the BSC stream is aborted. In
combination with other bits to record BSC activity
this can be used to preserve a maximum amount of
information about the abort by ceasing to put
entries into the trace table when the abort is
recognized. It also provides a convenient point to
stop in order to get a core dump.
2. TRCPAD - stop if an EBCDIC PAD character is
received in the body of non-transparent text.
Strictly speaking this is valid, but it is quite
unusual, since the EBCDIC PAD character,
hexadecimal FF, has no printing or control function
and no translation into ASCII. Probably,
therefore, it means that there is an error in the
part of the BSC code that recognizes the end of a
message. This stop, in combination with bits to
record the input stream, should help to debug the
BSC recognizer.
3. TRCTER - stop if the PDP-10 program makes a
protocol error in the messages it sends. Normally
such an error causes all the BSC lines to abort
their transfers. This bit will preserve the
evidence of the problem.
4. TRCTBO - stop if the trace table overflows. If you
are tracing some repetitious event, it is sometimes
convenient to get a stop for a core dump when the
trace table is full. This bit provides that
function.
DEBUGGING FACILITIES Page 18-8
"DEBUG=1"
A special feature of T-bit tracing, which is not easy to use
but can be quite valuable in difficult cases, is stopping on
an arbitrary condition. In the body of the T-bit interrupt
routine is a place for PDP-11 code to be inserted to check
for a condition. Since this code can be arranged to get
control after every task and/or interrupt instruction, when
the condition is detected, the interrupt PC points directly
at the culprit. The condition tested for can be as simple
as a location being wiped out or as complex as a linkage
error in a piece of the data structure.
A word of warning on T-bit tracing: using this feature
slows down the processor a lot, possibly by a factor of 10.
You should not try to run anywhere near the rated line speed
with this facility enabled.
18.6 D60SPL TRACING
When running the DN60 from D60SPL it is sometimes valuable
to get a running trace of line activity. This is provided
in D60SPL with the
MESSAGE ALL,LINE
command. This command will cause D60SPL to print a message
for each significant line activity that it sees. This may
be especially helpful in conjunction with the other
debugging facilities described above, since it provides
notice that an interesting event has happened.
CHAPTER 19
ASSEMBLY INSTRUCTIONS
The DN60 front end software is assembled using MACDLX by
concatenating the source files for an appropriate selection
of the sections. MACDLX is distributed with the DN60
software. It is a standard TOPS-10 cusp. For the DN61-DA
and DN61-DB, the sections are concatenated as follows:
1. S - symbol definitions common to many Digital
Equipment Corporation products.
2. DN61D - parameter settings for the DL10 version.
3. MACROS - some useful PDP-11 macros.
4. DEFINE - definitions for the DN60.
5. MININT - minor interrupt routines.
6. INIT2 - section 2 of initialization.
7. STGMAN - subroutines to manage free storage.
8. QUEING - subroutines to send and receive inter-task
data.
9. DQ11 - subroutines for driving the DQ11's.
10. MSGHDL - subroutines for processing messages.
11. DISPAT - the task dispatcher.
12. BSC - the BSC task.
13. DL10 - the PDP-10 communications task.
14. XL3780 - the IBM 3780/2780 translation and
background tasks.
15. INITDQ - initialization for the DQ11's.
ASSEMBLY INSTRUCTIONS Page 19-2
16. INIT1 - section 1 of initialization.
17. CHK11 - once-only hardware testing.
To assemble the DN61-SA or DN61-SB version, substitute DN61S
for DN61D and DTE10 for DL10 in the list above.
To assemble the DN64-AA or DN64-AB version, substitute DN64A
for DN61D, DTE20 for DL10, KMC11 for DQ11 and INITUP plus
MDCODE for INITDQ in the list above.
To assemble the DN61-BA or DN61-BB version, substitute DN61B
for DN61D, DTE10 for DL10, KMC11 for DQ11 and INITUP plus
MDCODE for INITDQ in the list above.
Distributed with the sources are control files which
assemble them. See the installation guide for more details.
CHAPTER 20
THE CAL11. UUO
The purpose of the CAL11. UUO is to provide TOPS-10 user
programs access to PDP-11'S running on DL10 and DTE20 ports.
The UUOPRV document, which is printed in the Software
Notebooks, describes how the CAL11. UUO is used with other
products.
The CAL11. UUO has been extended for the DN60 by
implementing the examine and deposit functions in a way
compatible with the DC76. One new function has been added
to permit PDP-10 programs to interact with the DN60. Its
parameter block is formatted as described in the following
sections. (see UUOPRV page 4 for background)
On the DECSYSTEM-20, a subroutine called C11SIM implements
only the functions described below using the FE device and
ENQ/DEQ.
20.1 PARAMETER BLOCK
The .C11QU function, when applied to a DN60, uses the
following parameter block:
word meaning
---- -------
1 XWD port number, .C11QU
The first DL10 has ports 0 to 3. The second DL10
has ports 4 to 7. DTE20 number 0 is port 10, number
1 is port 11, number 2 is port 12 and number 3 is
port 13.
2 XWD line number, device number
Line number zero is the first DQ11. Device number
is not used yet. It should always be zero.
3 XWD number of bytes, function code
THE CAL11. UUO Page 20-2
PARAMETER BLOCK
Function codes are as follows:
0 no operation
1 read data
2 write data
3 read device status
4 write device command
5 read line status
6 write line command
7 read DN60 status
8 write DN60 command
Functions 0 and 5-8 do not use the device number;
functions 0 and 7-8 do not use the line number
either. Functions 9 and 10 are used internally to
implement examine and deposit on the DN61-S and
DN64-A. Functions 11 to 255 are reserved for future
assignment.
4 XWD length, start address of buffer
5 BYTE (12) number of bytes per word (24) position of
first byte
Bytes per word may be four or five (eight- or
seven-bit bytes). Position of first byte counts
from the left of the PDP-10 word.
6 XWD number of bytes transferred, result code
Result codes are as follows:
1 operation successful
2 operation delayed
3 operation rejected by the DN60, read status
"Number of bytes transferred" is set to the number of bytes
actually transferred over the DL10. For write functions
this will be equal to "number of bytes" (left half of word
3) unless the DN60 ran out of chunks ("write data" and
"enable" only). In this case the result code will be
"delayed" (code 2). The UUO should be re-issued with
"number of bytes" and "position of first byte" (word 5)
adjusted to only write the remainder of the buffer. For
read functions "number of bytes transferred" will be the
number of bytes stored in the buffer. "Number of bytes" in
this case is the maximum number that will be stored.
If the result code is "rejected" (code 3), this means that
there is a status condition which prevents the operation
from being performed. For "read data" this is caused by
aborting the BSC stream or by end of file. For "write data"
this is caused by aborting the BSC stream. Note that the
BSC stream can be aborted from either side.
THE CAL11. UUO Page 20-3
PROCEDURES
20.2 PROCEDURES
The following procedures are simplified descriptions of the
algorithms required to drive the DN60. See D60SPD and
D60SPL for more details.
20.2.1 Initialization
1. Disable and then enable the line.
2. Abort input and output.
3. Wait for the aborts to complete, then clear them.
They may complete in either order, and the first
must be cleared before the second will complete.
4. Be sure EOF is not set.
5. Set all the required line and device parameters.
20.2.2 Output
1. Issue "Request output permission".
2. Wait for "output permission requested" to clear,
then check for the following:
1. Output permission granted -- data transfers can
now take place.
2. Input permission requested -- the other side
wants to do output. See below for input
procedures.
3. None of the above -- there was an error, try
again if you wish.
3. When data transfers are complete, issue "Signal
output EOF" and wait for "Output EOF complete".
4. Issue "Clear output EOF complete".
THE CAL11. UUO Page 20-4
PROCEDURES
20.2.3 Input
1. Wait for "Input permission requested".
2. Issue "Grant input permission".
3. Wait for "Input permission granted" to clear, then
check for the following:
1. Input running -- data can now be read.
2. Input abort started -- the transfer has been
aborted.
3. Input EOF completed -- data can now be read.
The data stream is so short that it all fit
into the front end's buffers.
4. None of the above -- permission was not granted
soon enough or there was an error. Try again
if you wish.
4. When all data has been read (an attempt to read
data gives return code 3 and "Input EOF completed"
is set) issue "Clear input EOF complete".
D60SER, upon receiving the .C11QU function of the CAL11.
UUO, checks its interlocks and, if they are clear, presents
the information to the DN60 and starts a one-second timer.
The DN60 always completes its processing quickly, if
necessary by using the "delayed" return.
20.3 ERROR CODES
With the inclusion of the DN60, the error codes for the
CAL11. UUO are as follows:
code meaning
---- -------
1 caller does not have the POKE privilege
2 the function is undefined on this type of front end
3 invalid DL10 port number
4 CAL11. facility in use, try again later.
5 no answer from front end after 1-2 seconds
6 queue entry too short (DC76 only)
7 not enough arguments
10 examine/deposit address was invalid (more than 16
bits or front end flagged it as invalid) or deposit
data more than 16 bits
THE CAL11. UUO Page 20-5
ERROR CODES
11 in QUE11., illegal function code, address check,
illegal byte size, byte offset is outside buffer or
buffer too large (requires more than 16 DL10 byte
pointers or more than 4095 bytes through a DTE20)
12 On a DN61-S, DTESER couldn't get any free core
13 On a DN61-S, the reload bit is set or primary
protocol is not running. This means that the front
end is down.
14 On a DN61-S, there will never be enough Executive
Virtual Memory to process the request.
On the DECSYSTEM-20, error codes with bits 18 and 19 set are
JSYS errors from TOPS-20.
20.4 OPERATION
The job issuing the CAL11. UUO is locked in core for the
duration of the UUO so that the DL10 can read or write the
job's core image. This is similar to the effect of having
an active I/O device.
On the DECSYSTEM-20, the CAL11. simulator uses ENQ and DEQ
to prevent interference by other jobs with the sequence of
JSYS's it must issue to perform the simulation.
The structure described above provides a data path and two
control/status paths for each I/O device attached through
the DN60. There are two control/status paths, because some
kinds of control/status information is more naturally
associated with the I/O device (card reader, line printer)
and some with the control unit that provides the BSC
interface. Reading status and writing commands are intended
to always be done with 8-bit bytes. Note that the front end
stores multiple-byte fields low-order byte before
higher-order bytes.
There is also a control/status path for the DN60 as a whole.
This is not yet used much; it is included primarily as a
hedge against future needs.
THE CAL11. UUO Page 20-6
STATUS
20.5 STATUS
20.5.1 DN60 Status
DN60 status is as follows: (read by function 7)
bytes meaning
----- -------
0-7 DN60 version number
8-9 window version number (must match D60SER)
10-11 current number of free "chunks" in the DN60
12-13 number of lines on this DN60
14-15 number of bytes of data in a chunk
16-17 translation options available:
Bit 0 = IBM 3780/2780 (always 1)
Bit 1 = HASP Multileaving (always 1 for DN62 and
DN65)
Bit 2 = IBM 3270 (always 0)
Bits 3-15 are reserved
18-25 KMC11 microcode version number
26-27 Error Code on last error
28-29 Line number on last error
30-31 Device number or rcb on last error
32-79 active line device info (12*4=48 bytes)
20.5.2 Line Status
Line status is as follows: (read by function 5)
byte meaning
----- -------
0 terminal type: 0 = unknown,
1 = IBM 3780,
2 = IBM 2780,
3 = HASP Multileaving
4-255 = reserved.
1 flags: bit 0 set = simulate,
clear = support.
bit 1 set = primary BSC station,
clear = secondary BSC station
bit 2 set = transparent output
clear = non-transparent mode
bits 3-7 = reserved.
2 line info: bit 0 set = line is enabled
bit 1 = Data Terminal Ready (DTR)
bit 2 = Data Set Ready (DSR)
bits 3-7 = reserved
THE CAL11. UUO Page 20-7
STATUS
3 error code information on last error
4-5 count of DQ11/DUP11 error interrupts
6-7 DQ11/DUP11 status register 1 at last error
8-9 DQ11/DUP11 status register 2 at last error
10-11 count of times receiver wasn't fast enough
12-13 count of times transmitter wasn't fast enough
14-15 count of clear-to-send (CTS) failures
16-17 count of messages sent and acked
18-19 count of NAK's received (+wrong acknowledge after
timeout)
20-21 count of invalid responses to TTD
22-23 count of invalid responses to messages
24-25 count of TTD's sent
26-27 count of WACK's received in response to messages
28-29 count of EOT's (aborts) in response to messages
30-31 count of invalid bids or responses to bids
32-33 count of RVI's received while transmitting
34-35 count of messages received OK
36-37 count of bad BCC's
38-39 count of NAK's sent in response to data messages
40-41 count of WACK's sent
42-43 count of TTD's received
44-45 count of EOT's sent or received which abort the
stream
46-47 count of messages ignored (out of chunks,
unrecognizable or timeout)
48-49 count of transparent messages with an invalid
character after DLE
50-51 count of attempts to change between transparent and
normal (non-transparent) mode in a blocked message
THE CAL11. UUO Page 20-8
STATUS
52-53 count of transmitter timeouts
54-55 clear-to-send delay, in jiffies
56-57 count of silo overflows
58-59 number of bytes in silo warning area (usually 64)
(must be even)
60-61 max number of bytes used in silo warning area since
its depth was last set
62-63 maximum transmission block length
64-65 number of logical records per transmission block
66-67 line driver type:
1 = DQ11
2 = KMC11/DUP11
3 = DUP11 without KMC11
THE CAL11. UUO Page 20-9
STATUS
20.5.3 Device Status
Device status is as follows: (read by function 3)
bytes meaning
----- -------
0 device type: 0 = unknown,
1 = printer,
2 = punch,
3 = reader,
4-255 = reserved.
1 component selection code: 0 = unknown,
221 = console in
222 = console out
223 = card reader
unit 1
224 = line printer
unit 1
225 = card punch
unit 1
others = reserved
The component selection code are in octal.
2-3 printer line counter
4-7 flags: bits 0-3 = reserved
bit 4 = interpret input carriage
control
bit 5 = interpret output carriage
control
bit 6 = reserved
bit 7 = do component selection
bit 8 = do compress/expand
bit 9 = page counter has overflowed
bit 10 = page counter interrupts
enabled
bit 11 = old BSC protocol
bit 12 = output buffers being dumped
bit 13 = input permission grant to be
sent to hasp
bit 14 = device in input mode (=1)
bit 15 = output being completed for
dump or eof
bit 16 = output permission requested
bit 17 = output permission granted
bit 18 = output running
bit 19 = output EOF signaled
bit 20 = output EOF complete
bit 21 = output abort started
bit 22 = output abort completed
bit 23 = input permission requested
THE CAL11. UUO Page 20-10
STATUS
bit 24 = input permission granted
bit 25 = input running
bit 26 = input abort started
bit 27 = input abort completed
bit 28 = input EOF completed
bit 29 = input permission was requested
bit 30 = output permission was
requested
bit 31 = device suspended (for hasp
only)
for bsc tcb, this bit on = output suspended
8-9 device record size
20.6 COMMANDS
The first byte of a command is the command code;
subsequent bytes provide the arguments to the command,
if any are needed.
20.6.1 Line Commands
Commands to a line are as follows: (function 6)
command meaning
------- -------
1 enable line and set characteristics:
byte 1 = terminal type: 0 = unknown,
1 = IBM 3780,
2 = IBM 2780,
3 = HASP Multileaving
4-255 = reserved.
byte 2 = flags: bit 0 set = simulate,
clear = support.
bit 1 set = primary BSC
station
clear = secondary BSC
station
bits 2-7 reserved
2 allow answering of modem and receipt of data (i.e.,
set Data Terminal Ready)
3 abort all data transfers and hang up the modem
THE CAL11. UUO Page 20-11
COMMANDS
4 disable the line
5 set clear-to-send delay:
bytes 1-2 = clear-to-send delay, in jiffies
6 set number of bytes in silo warning area and clear
"max used"
bytes 1-2 = number of bytes in silo warning
area
7 set output in transparent mode
8 set output in non-transparent mode
9 set transmission block size
10 set max number of logical records per transmission
block. Bytes 1 and 2 = max number of logical
records per transmission block. 0 = no limit.
(Set to 2 for IBM 2780'S without multi-record
feature, 7 for IBM 2780'S with multi-record
feature, 0 for IBM 3780.)
20.6.2 Device Commands
Commands to a device are as follows: (function 4)
command meaning
------- -------
1 set characteristics:
byte 1 = device type: 0 = unknown,
1 = console out,
2 = console input,
3 = card reader,
4 = line printer
5 = card punch,
6-255 = reserved.
2 reserved
3 dump output buffers
4 clear Input Permission was Requested
5 reserved
6 set Interpret Carriage Control on Input (for
simulating a printer)
7 clear Interpret Carriage Control on Input (for
simulating a punch or supporting a reader)
THE CAL11. UUO Page 20-12
COMMANDS
8 set Interpret Carriage Control on Output (for
supporting a printer)
9 clear Interpret Carriage Control on Output (for
supporting a punch or simulating a reader)
10 reserved
11 reserved
12 specify output component selection
byte 1 = component code: 0 = unknown,
221 = console in
222 = console out
223 = card reader
unit 1
224 = line printer
unit 1
225 = card punch unit
1
others = reserved
This is used by HASP Multileaving only.
13 don't do output component selection
14 set printer page counter and enable for overflow
bytes 1-2 = value of line counter
This is not yet implemented.
15 disable printer page counter overflow
16 reserved
bytes 1-2 = max transmission block size
17 do space compression on output (note: expansion on
input is always enabled)
18 don't do space compression on output
19 use old BSC protocol (IUS, ETB and ETX imply IRS,
overprinting is ignored and card output is
padded to 80 characters with spaces)
20 don't use old BSC protocol
21 request output permission
22 grant input permission
23 signal output EOF (end-of-file)
24 clear output EOF complete
THE CAL11. UUO Page 20-13
COMMANDS
25 signal output abort
26 clear output abort complete
27 clear input EOF complete
28 signal input abort
29 clear input abort complete
30 suspend device (HASP only)
31 unsuspend device (HASP only)
32 set device record size
CHAPTER 21
DIFFERENCES FROM THE DAS78
The DAS78 was the predecessor to the DN61. It therefore
seems appropriate to list the differences for the sake of a
customer who might be upgrading.
The following differences between the DAS78 and the DN61 may
be important to an installation that is upgrading.
Differences which are mearly extensions to the functions
provided by the DAS78, such as IBM 3780 support, are not
listed. Some of the features not carried over into the DN61
were not used by DEC software, and so their impact upon
users may be very small. On the other hand, some users may
have written special programs to use these features.
1. The DN61 will not transmit in transparent mode.
2. The DN61 does not have binary mode files. (It is
not perfectly clear what this is.)
3. The DN61 does not maintain a log of files sent and
received. (An abbreviated log is maintained in the
FACT or USAGE file and has the same format as
LPTSPL entries.)
4. The DAS78 expects operator messages to be prefixed
("comment" switch) whereas the DN61 considers a
file shorter than 200 characters to be an operator
message.
5. The DN61 has no provision for appending an EBCDIC
EM character to transmitted messages. This reduces
the DN61's throughput when emulating an IBM 2780.
6. The DN61 does not permit specification in the log
file of number of forms and forms type on a "PRINT"
request.
7. The DN61 does not use the "programmer name" field
of the IBM job card to specify the output file
disposition. Instead it uses comments in the IBM
job. See the user's guide for details.
DIFFERENCES FROM THE DAS78 Page 21-2
8. There is no provision for stripping off the banner
page.
9. The procedure for sending a file outside the normal
spooling sequence is different.
10. The printer and card reader on the IBM 2780 are
accessible only from D60SPL and D60SPD, because the
DN61 is programmed using the CAL11. UUO rather than
INPUT and OUTPUT UUOs.
11. The DN61 corrects some errors in the DAS78's
translate tables. See Chapter 15 on the XL3780
section for details.
12. The DN61 does not simulate the IBM 2780'S carriage
control tape, except for top of form (channel 1).
Other skip to channel commands are translated to
line feed.
13. The DN61 does simulate the LP10's carriage control
tape, without depending on the carriage control
tape in the IBM 2780, except for channel 1 (top of
form).
14. The DAS78 uses a different number of jobs than the
DN61 for most configurations. The DAS78 required
one job for each three support lines and two jobs
for each simulate line. The DN61 requires one job
for each line, whether in simulate or support mode,
plus one job to cover all of the support lines.
15. For support mode the SIGNON card has a different
format and the password is contained in LPFORM.INI
rather than in ACCT.SYS. For details, see the
operator's manual.
16. It was not one of the goals of the DN61 to avoid
crashing in the face of operator error. Hence a
poorly trained operator is more likely to crash the
DN61 than the DAS78.
CHAPTER 22
PERFORMANCE ESTIMATES FOR THE DN61
This chapter attempts to guide the user of the DN61 by
presenting some performance information gathered in a
laboratory. Digital does not represent that the DN61 will
perform as described below under all circumstances. The
information contained in this chapter is not part of the
DN61 specification.
22.1 ASSUMPTIONS
The performance data was gathered by making the following
assumptions about the DN61's environment: 48 milliseconds
modem turn-around time, 402 data characters and 17 overhead
characters per message and 100 microseconds of processing
time per data character. Note that the modem turn around
time happens twice per message. Also, the 402 data
characters are composed of 132 graphic characters, carriage
return and line feed, repeated three times in a block. The
overhead is LPD, three SYN and one STX in front of the data
message, three IRS inside it and ETB and two BCC after it.
The CR LF in the ASCII data is converted to ESC SLASH in
EBCDIC. Added to overhead is the acknowledge message which
consists of LPD, three SYN, DLE and the acknowledge
character.
22.2 LOW SPEED LINES
At line speeds less than 9600 baud, throughput is limited by
line speed. In our experience, each 1200 baud line runs at
about 137 characters per second, each 2400 baud line runs at
about 262 characters per second, and each 4800 baud line
runs at about 482 characters per second.
PERFORMANCE ESTIMATES FOR THE DN61 Page 22-2
HIGH SPEED LINES
22.3 HIGH SPEED LINES
At line speeds of 9600 baud and greater, throughput is
limited by the turn-around time of the modem and the speed
of the processor. Thus the number of lines becomes much
more important than their speed. We have timed a single
100,000 baud line at about 1840 characters per second,
whereas three 9600 baud lines run at about 2100 characters
per second, three 19,200 baud lines run at about 2800
characters per second and two 38,400 baud lines and one
19,200 baud line run at about 3,000 characters per second.
We have not tried configurations with more than three lines.
CHAPTER 23
BINARY SYNCHRONOUS PROTOCOL - BISYNC
This chapter presents a brief tutorial on BISYNC, a
communications protocol developed by IBM and used by them on
several products.
Since its development BISYNC has evolved with little
discipline, so that today it is not much more more than an
"umbrella" term for a family of incompatible protocols.
This tutorial will discuss EBCDIC, point-to-point BISYNC for
the IBM 3780 and for the IBM 2780. Discussion will be
furher limited to the features of the IBM 3780 and 2780
which are supported or simulated by the DN61 and DN64.
23.1 MOTIVATION
There are three important factors in computer-to-computer
communications which led to the development of BISYNC.
First, computer-to-computer communication is done using a
serial bit stream. This means that the sending computer
must transmit bits one at a time, and the receiving computer
receives them in the same way.
Second, the error rate over these serial lines is too high
to be acceptable as an error rate in user data. It is much
higher than, for example, the error rate of disks or tapes.
Third, the serial lines have a very low transmission rate.
The rate is much slower than is required to operate disks
and tapes; it is barely fast enough to run medium speed
card readers and line printers at their full capacity. Two
of the consequences of this are directly significant. The
first is that, in order to make maximum use of a
transmission line, only one side may be sending at any one
time. This permits the one sender to use all of the line's
information-carrying capacity. Second, user data (which
should comprise the bulk of the information passed) needs to
be sent with as little overhead as possible.
BINARY SYNCHRONOUS PROTOCOL - BISYNC Page 23-2
MOTIVATION
These factors mean that BISYNC must organize the serial line
so that user data may be extracted from it, BISYNC must be
prepared to recover from a large fraction of the errors
which occur on the serial line, and BISYNC must transmit
data very cleverly so as to make maximum use of the limited
number of bits which can be sent each second.
23.2 VOCABULARY
The vocabulary of BISYNC is built from 8-bit bytes. Some of
the "words" of this vocabulary are single characters and
others are two characters in length. The table below shows
the BISYNC vocabulary.
"word" hex meaning
------ --- -------
HT 05 Horizontal Tab
NAK 3D Negative Acknowledge
DLE 10 Data Link Escape
EOT 37 End of Transmission
STX 02 Start of Text
ETX 03 End of Text
ETB 26 End of Transmission Block
ENQ 2D Enquiry
IRS 1E Interchange Record Separator
IUS 1F Interchange Unit Separator
ESC 27 Escape
SYN 32 Synch
EM 19 End of Medium
NL 15 New Line
ACK-0 DLE 70 Acknowledge Zero
ACK-1 DLE 61 Acknowledge One
WACK DLE 6B Wait Acknowledge
RVI DLE 7C Reverse Interrupt
TTD STX ENQ Temporary Text Delay
LPD 55 Leading Pad
PAD FF Pad (trailing)
BINARY SYNCHRONOUS PROTOCOL - BISYNC Page 23-3
ORGANIZING THE SERIAL DATA STREAM
23.3 ORGANIZING THE SERIAL DATA STREAM
23.3.1 Leading Synchronization
The first task of BISYNC, faced with a serial data stream,
is to organize it in terms of 8-bit bytes so that the
"words" above can be recognized. This is done by preceeding
every tansmission with a "synchronizing sequence". The DN60
transmits a four character synchronizing sequence and
depends upon receiving at least the last two characters of
it. The DN60's synchronizing sequence looks like this:
X'55', SYN, SYN, SYN
The leading X'55' is used to exercise the transmitting
modem. It is mearly alternate bits, and is not expected to
be received by the receiving modem. The three SYN
characters are to align the receiver to a byte boundry. The
character SYN is constructed in such a way that, if you look
at the bit stream eight bits at a time, the only way you can
see a SYN in a string of SYN's is if you are properly
aligned. To improve reliability, the DN60 uses a 16-bit
window and looks for two SYN's in a row.
After the synchronizing sequence the receiver and
transmitter are aligned on the same 8-bit byte boundry, so
the transmitter may now send an 8-bit byte with some
assurance that the receiver will recognize it.
Every BISYNC transmission starts with this synchronizing
sequence. In the interests of brevity it will not be
included explicitly in the examples below.
23.3.2 Imbedded Synchronization
In some old modems certain bit strings, if continued long
enough, would cause transmission failure. To combat this
BISYNC permits a synchronization sequence to be imbedded in
a data message. One or two SYN's are inserted occasionally
in the data message to prevent a user's data from causing
modem troubles. In transparent messages DLE SYN is used.
It is also permitted to place an IUS in the data stream
followed by the Block Check Character described below for
the end of a message. This intermediate block check is to
improve reliability by permitting more check bits to be
transmitted with long messages. The IBM 3780 never sends
this, so the DN60 never sends it, but both the IBM 3780 and
the DN60 process it correctly when they receive it.
BINARY SYNCHRONOUS PROTOCOL - BISYNC Page 23-4
ORGANIZING THE SERIAL DATA STREAM
23.3.3 Trailing Pad
With some old modems, when the computer indicated that the
message was complete the modem would discard the last
character sent to it because of internal buffering. To
combat this the IBM 3780 sends a trailing pad character at
the end of each transmission. Receivers do not depend on
its being present. The pad is a single character with all
bits on, that is, hex 'FF'.
23.4 MESSAGE STREAMS
The top-level element of BISYNC is the message stream. The
purpose of the message stream is to convey an arbitrarily
long string of characters from a data source to a data sink.
The message stream provides for resolution of conflicts for
the use of the transmission line, error detection and
correction. These facilities are provided by dividing the
process of sending a message stream into three parts:
bidding, data transfer and ending.
23.4.1 Bidding
When a data source wishes to send a message stream to a data
sink the source bids for use of the transmission line. Upon
receiving permission to use the line, data can pass from
source to sink. Bidding is done with the ENQ, ACK-0 and NAK
"words".
In a typical bidding situation, these "words" are used as
follows:
source sink
------ ----
ENQ ---------------->
<---------------- ACK-0
Upon reciept of the ACK-0 the bidding is complete and the
"source" owns the line. An unsuccessful bid would look like
this:
BINARY SYNCHRONOUS PROTOCOL - BISYNC Page 23-5
MESSAGE STREAMS
source sink
------ ----
ENQ ---------------->
<---------------- NAK
The "sink" returns a NAK if it does not wish the "source" to
transmit data. Another possibility is that the "sink" is
broken, in which case there is no reply. The "source" then
sends another ENQ, hopeing that its first one was simply
garbaged by line noise. For example:
source sink
------ ----
ENQ --------ZOT
ENQ ---------------->
<---------------- ACK-0
If after several tries the source cannot get an ACK-0, it
decides that it cannot send data.
If bidding is successful the source and sink go to the data
transfer part of the message stream procedure, which
involves sending data messages.
23.4.2 Data Transfer
Transfer of user data is done using data messages. There
are two kinds of data messages: normal and transparent. A
normal data message starts with STX and ends with ETX or
ETB. Such a message may not contain any of BISYNC's data
link control characters: STX, ETX, ETB, DLE, SYN, etc.
For some applications this restriction on the user
characters which can be transmitted cannot be tolerated, so
there is a way of transmitting any 8-bit byte. This is done
using transparent messages. A transparent message starts
with DLE STX and ends with DLE ETX or DLE ETB. A user
character which would be mistaken for a DLE by the receiver
is preceeded by a DLE by the transmitter. Thus the sequence
DLE DLE means one user DLE, whereas DLE ETB or DLE ETX means
the end of the message. Transparent messages cannot be
compressed.
Data messages are always followed (right after the ETB or
ETX) by a 16-bit check sequence known as the Block Check
Character. This "character" is computed by the transmitter
from the data, and the receiver re-computes it and compares
its computation with the bits sent by the transmitter. If
BINARY SYNCHRONOUS PROTOCOL - BISYNC Page 23-6
MESSAGE STREAMS
the computed value doesn't match the bits received then the
receiver corrects the error by requesting the transmitter to
send the data message again. This would look as follows:
source sink
------ ----
data1 -------/-------->
<---------------- NAK
data1 ---------------->
<---------------- ACK-1
If the source gets too many NAK's in a row then it decides
that it cannot transmit a data message and aborts the
message stream. This is done by sending an EOT message.
For example:
source sink
------ ----
data1 -------/-------->
<---------------- NAK
.
.
.
data1 -------/-------->
<---------------- NAK
EOT ---------------->
Alternate data messages are acknowledged with ACK-0 and
ACK-1 to facilitate retransmission of messages that are
missed entirely. So if the source sends three data messages
the exchange would look like this:
source sink
------ ----
data1 ---------------->
<---------------- ACK-1
data2 ---------------->
<---------------- ACK-0
data3 ---------------->
<---------------- ACK-1
The first data message after the bidding is complete is
replied to with an ACK-1 rather than an ACK-0.
BINARY SYNCHRONOUS PROTOCOL - BISYNC Page 23-7
MESSAGE STREAMS
23.4.3 Ending A Data Stream
When a source is sending its last data message it ends the
message with an ETX instead of an ETB. This is an
indication to the sink that the message stream is about to
terminate. The sink replies to this message with ACK-0 or
ACK-1 (not with WACK) and processes it normally. When the
source has received the acknowledge it sends an EOT. This
EOT means to the sink that the message stream is complete.
23.4.4 Flow Control
There are two flow control problems: either the source may
have no message to send when the sink is ready, or the sink
may have no room for another message when the source is
ready. If the source has no message to send it sends
instead a TTD. The sink replies with a NAK, and the source
then has another opportunity to send a TTD or a data
message. For example:
source sink
------ ----
data1 ---------------->
<---------------- ACK-1
TTD ---------------->
<---------------- NAK
data2 ---------------->
<---------------- ACK-0
If, upon successful reciept of a message, the sink finds it
has no room for another then it replies with WACK instead of
ACK-0 or ACK-1. The source responds to the WACK with an
ENQ. When the sink receives the ENQ it replies with another
WACK if it still has no room or with ACK-0 or ACK-1 if it
can now accept another data message. For example:
source sink
------ ----
data1 ---------------->
<---------------- ACK-1
data2 ---------------->
<---------------- WACK
ENQ ---------------->
<---------------- ACK-0
BINARY SYNCHRONOUS PROTOCOL - BISYNC Page 23-8
MESSAGE STREAMS
23.4.5 Missed Data Messages
If the sink misses a data message entirely, it, of course,
does not respond to it. The source times out its data
messages and will notice that the sink has not replied. The
source, however, has no way of knowing if the sink missed
the data message or if the source (itself) missed the
acknowledge. To find out, the source sends an ENQ. The
sink responds to the ENQ with its last positive response.
If that is WACK or the expected acknowledge then the
response to the data message was missed. If the response to
ENQ is the wrong acknowledge then the sink missed the data
message, and the source should send it again.
The following example shows a missed data message.
source sink
------ ----
data1 ---------------->
<---------------- ACK-1
data2 ------ZOT
ENQ ---------------->
<---------------- ACK-1
data2 ---------------->
<---------------- ACK-0
The following example shows a missed acknowlegdement.
source sink
------ ----
data1 ---------------->
<---------------- ACK-1
data2 ---------------->
ZOT--------- ACK-0
ENQ ---------------->
<---------------- ACK-0
data3 ---------------->
<---------------- ACK-1
23.5 COMPRESSION
Within a block of normal (non-transparent) data BISYNC
provides for four compression techniques. A compression
technique is a way of sending user data "by implication"
rather than having to actually send each bit. Use of these
techniques improves the efficiency of the transmission line
and thus leads to higher print speed and reading of more
BINARY SYNCHRONOUS PROTOCOL - BISYNC Page 23-9
COMPRESSION
cards each minute.
23.5.1 Trailing Blank Truncation
If a card or line of print ends in blanks (a common
occurence) these trailing blanks need not be transmitted.
To mark the boundry between cards or print lines the IBM
3780 puts an IRS character in the data stream. This
character is not printed or punched.
23.5.2 IGS Compression
Multiple blanks in the middle of a card or line of print can
be represented using IGS. The sequence
IGS code
represents up to 63 blanks. The code is a character from
hex '42' to '7F' to represent from two to 63 blanks.
23.5.3 Horizontal Tabs
If a message to an IBM 3780's printer starts with ESC HT,
then the rest of the message (up to an NL character) sets
horizontal tab stops. Once this message has been processed,
the HT character in a message to be printed represents
enough blanks to reach the next tab stop.
23.5.4 Vertical Positioning
Instead of sending blank lines to space down the page,
multiple spacing can be used. If the sequence
ESC code
appears in a message then the IRS which ends the message
represents the end of the current line and some extra line
spacing. The codes are as follows:
code meaning
---- -------
A skip to top of next page
/ single space
S double space
T triple space
BINARY SYNCHRONOUS PROTOCOL - BISYNC Page 23-10
COMPRESSION
M no space
The "no space" function is for overprinting.
23.6 IBM 2780 VERSUS IBM 3780
The IBM 2780 and the IBM 3780 differ in their
implementations of BISYNC. The IBM 2780 does not have IGS
compression or the "print without spacing" function (ESC M).
Also, the IBM 2780 uses IUS (with its following Block Check
Character) to separate print lines and cards in a
transmission block. The ETB or ETX which ends a
transmission block also marks the end of a card or print
line.
The IBM 2780 is limited to two or seven cards or print lines
in one transmission block.
When the IBM 2780 sends multiple cards in one transmission
block all trailing blanks are transmitted, unless an EM
character is found in the card, in which case the rest of
the card is not transmitted.
23.7 MORE INFORMATION
More information on BISYNC is contained in certain IBM
documents. The most useful of these are:
1. General Information -- Binary Synchronous
Communications, order number GA27-3004.
2. Component Information for the IBM 3780 Data
Communications Terminal, order number GA27-3063.
3. IBM 2780 Data Transmission Terminal - Component
Description, order number GA27-3005.
4. IBM 3770 Data Communications System, System
Components, order number GA27-3097.
Note that IBM manuals are available from your IBM
representative or the IBM branch office serving your
locality, not from Digital Equipment Corporation.
APPENDIX A
DTE10 FORMATS
A.1 DN60 WRITE FUNCTIONS
To perform the DN60 functions 2, 4, 6, and 8 using the DTE
the 10 will send a direct message followed by the data in
the indirect message.
!----------------------------------------------------------!
! MSG COUNT IN BYTES ! PROTOCOL FUNCT CODE (.EMD6D) !
!----------------------------------------------------------!
! PROTOCOL DEV CODE ! SPARE WORD !
!----------------------------------------------------------!
! 0 !DN60 FUN CODE ! DN60 LINE # ! DN60 DEV # !
!----------------------------------------------------------!
! LENGTH(MSB) ! LENGTH(LSB) ! ! !
!----------------------------------------------------------!
MSG COUNT IN BYTES The number of bytes in this
message header = 14.
PROTOCOL FUNCT CODE .EMD6D DN60 data
PROTOCOL DEV CODE .EMD60
SPARE WORD Not used
0 Not used
DN60 FUNCTION CODE 2, 4, 6, or 8
DN60 LINE NUMBER Line number from the CAL11.
blk
DN60 DEVICE NUMBER Device number from the CAL11.
blk
LENGTH Length of the data in bytes in
the indirect message. The
maximum length will be 3095
bytes.
DTE10 FORMATS Page A-2
DN60 WRITE FUNCTIONS
The 11 should respond with the following direct message.
!----------------------------------------------------------!
! MSG COUNT IN BYTES ! PROTOCOL FUNCT CODE (.EMD6D) !
!----------------------------------------------------------!
! PROTOCOL DEV CODE ! SPARE WORD !
!----------------------------------------------------------!
!RESULT CODE !DN60 FUN CODE ! DN60 LINE # ! DN60 DEV # !
!----------------------------------------------------------!
! LENGTH(MSB) ! LENGTH(LSB) ! ! !
!----------------------------------------------------------!
MSG COUNT IN BYTES The number of bytes in this
message header = 14.
PROTOCOL FUNCT CODE .EMD6D DN60 data
PROTOCOL DEV CODE .EMD60
SPARE WORD Not used
DN60 RESULT CODE 1, 2, or 3
DN60 FUNCTION CODE 2, 4, 6, or 8
DN60 LINE NUMBER Line number giving result code
for
DN60 DEVICE NUMBER Device number giving result
code for
LENGTH Number of data bytes the 11
absorbed from the indirect
portion
DTE10 FORMATS Page A-3
DN60 READ FUNCTIONS
A.2 DN60 READ FUNCTIONS
To perform the DN60 functions 1,3,5, or 7 using the DTE the
10 will request data by using a direct message.
!----------------------------------------------------------!
! MSG COUNT IN BYTES ! PROTOCOL FUNCT CODE (.EMD6D) !
!----------------------------------------------------------!
! PROTOCOL DEV CODE ! SPARE WORD !
!----------------------------------------------------------!
! 0 !DN60 FUN CODE ! DN60 LINE # ! DN60 DEV # !
!----------------------------------------------------------!
! LENGTH(MSB) ! LENGTH(LSB) ! ! !
!----------------------------------------------------------!
MSG COUNT IN BYTES The number of bytes in this
message header = 14.
PROTOCOL FUNCT CODE .EMD6D DN60 data
PROTOCOL DEV CODE .EMD60
SPARE WORD Not used
0 Not used
DN60 FUNCTION CODE 2, 4, 6, or 8
DN60 LINE NUMBER Line number from the CAL11.
blk
DN60 DEVICE NUMBER Device number from the CAL11.
blk
LENGTH Length of the data in bytes in
the indirect message. The
maximum length will be 3095
bytes.
DTE10 FORMATS Page A-4
DN60 READ FUNCTIONS
The 11 should respond with a direct message and the data
should follow in the indirect message.
!----------------------------------------------------------!
! MSG COUNT IN BYTES ! PROTOCOL FUNCT CODE (.EMD6D) !
!----------------------------------------------------------!
! PROTOCOL DEV CODE ! SPARE WORD !
!----------------------------------------------------------!
!RESULT CODE !DN60 FUN CODE ! DN60 LINE # ! DN60 DEV # !
!----------------------------------------------------------!
! LENGTH(MSB) ! LENGTH(LSB) ! ! !
!----------------------------------------------------------!
MSG COUNT IN BYTES The number of bytes in this
message header = 14.
PROTOCOL FUNCT CODE .EMD6D DN60 data
PROTOCOL DEV CODE .EMD60
SPARE WORD Not used
DN60 RESULT CODE 1, 2, or 3
DN60 FUNCTION CODE 1, 3, 5, or 7
DN60 LINE NUMBER Line number giving result and
data for
DN60 DEVICE NUMBER Device number giving result
and data for
LENGTH Length of the data in bytes in
the indirect message
DTE10 FORMATS Page A-5
DEPOSIT FUNCTION
A.3 DEPOSIT FUNCTION
To perform the deposit function (DN60 function code 10) the
10 will send the following direct message:
!----------------------------------------------------------!
! MSG COUNT IN BYTES ! PROTOCOL FUNCT CODE (.EMD6D) !
!----------------------------------------------------------!
! PROTOCOL DEV CODE ! SPARE WORD !
!----------------------------------------------------------!
! 0 !DN60 FUN CODE ! ADR (MSB) ! ADR (LSB) !
!----------------------------------------------------------!
! DATA(MSB) ! DATA(LSB) ! ! !
!----------------------------------------------------------!
MSG COUNT IN BYTES The number of bytes in this
message header = 14.
PROTOCOL FUNCT CODE .EMD6D DN60 data
PROTOCOL DEV CODE .EMD60
SPARE WORD Not used
0 Not used
DN60 FUNCTION CODE 10
ADR Address to deposit the data
into
DATA Data to be deposited into ADR
DTE10 FORMATS Page A-6
DEPOSIT FUNCTION
The 11 should respond with the result code:
!----------------------------------------------------------!
! MSG COUNT IN BYTES ! PROTOCOL FUNCT CODE (.EMD6D) !
!----------------------------------------------------------!
! PROTOCOL DEV CODE ! SPARE WORD !
!----------------------------------------------------------!
!RESULT CODE !DN60 FUN CODE ! ! !
!----------------------------------------------------------!
MSG COUNT IN BYTES The number of bytes in this
message header = 10.
PROTOCOL FUNCT CODE .EMD6D DN60 data
PROTOCOL DEV CODE .EMD60
SPARE WORD Not used
DN60 RESULT CODE 1, 2, or 3
DN60 FUNCTION CODE 10
DTE10 FORMATS Page A-7
EXAMINE FUNCTION
A.4 EXAMINE FUNCTION
To perform the examine function (DN60 function code 9) the
10 will send a direct message containing the address to be
examined:
!----------------------------------------------------------!
! MSG COUNT IN BYTES ! PROTOCOL FUNCT CODE (.EMD6D) !
!----------------------------------------------------------!
! PROTOCOL DEV CODE ! SPARE WORD !
!----------------------------------------------------------!
! 0 !DN60 FUN CODE ! ADR (MSB) ! ADR (LSB) !
!----------------------------------------------------------!
MSG COUNT IN BYTES The number of bytes in this
message header = 12.
PROTOCOL FUNCT CODE .EMD6D DN60 data
PROTOCOL DEV CODE .EMD60
SPARE WORD Not used
0 Not used
DN60 FUNCTION CODE 9
ADR Address to examine
DTE10 FORMATS Page A-8
EXAMINE FUNCTION
The 11 then should respond with the data:
!----------------------------------------------------------!
! MSG COUNT IN BYTES ! PROTOCOL FUNCT CODE (.EMD6D) !
!----------------------------------------------------------!
! PROTOCOL DEV CODE ! SPARE WORD !
!----------------------------------------------------------!
!RESULT CODE !DN60 FUN CODE ! ADR (MSB) ! ADR (LSB) !
!----------------------------------------------------------!
! DATA(MSB) ! DATA(LSB) ! ! !
!----------------------------------------------------------!
MSG COUNT IN BYTES The number of bytes in this
message header = 14.
PROTOCOL FUNCT CODE .EMD6D DN60 data
PROTOCOL DEV CODE .EMD60
SPARE WORD Not used
DN60 RESULT CODE 1, 2, or 3
DN60 FUNCTION CODE 9
ADR Address examined
DATA The data in ADR
Page Index-1
INDEX
Abort . . . . . . . . . . . . 12-3 to 12-5, 13-2, 13-4 to 13-5,
13-7, 14-15, 18-7, 20-2,
20-4, 20-7, 20-9 to 20-10,
20-13
ACCT.SYS . . . . . . . . . . . 21-2
ACK . . . . . . . . . . . . . 14-7 to 14-10, 14-16
ACK-0 . . . . . . . . . . . . 8-1, 12-4, 15-1 to 15-2,
23-2, 23-4 to 23-8
ACK-1 . . . . . . . . . . . . 8-1, 23-2, 23-6 to 23-8
ACK0 . . . . . . . . . . . . . 12-1, 12-5 to 12-6, 12-9
ASCII . . . . . . . . . . . . 2-2, 15-1 to 15-5, 16-1 to 16-4,
18-4, 18-7, 22-1
Baud . . . . . . . . . . . . . 18-1
BCB . . . . . . . . . . . . . 12-10, 18-7
BCB, . . . . . . . . . . . . . 12-11
BCC . . . . . . . . . . . . . 12-4, 12-6 to 12-7, 12-9,
12-11, 18-6, 20-7, 22-1
BISYNC . . . . . . . . . . . . 1-1, 8-1, 9-1, 12-1,
12-9, 23-1 to 23-5, 23-8,
23-10
BOOT11 . . . . . . . . . . . . 18-1 to 18-2, 18-4
BPT . . . . . . . . . . . . . 4-1
BSC . . . . . . . . . . . . . 1-2 to 1-3, 2-2, 7-1 to 7-2,
8-1, 8-3 to 8-5, 10-1,
12-1 to 12-2, 12-7, 13-4,
15-1 to 15-5, 16-1 to 16-3,
18-6 to 18-7, 19-1, 20-2,
20-5 to 20-6, 20-9 to 20-10,
20-12
BSEL1 . . . . . . . . . . . . 9-11
BSEL2 . . . . . . . . . . . . 9-4
BSEL3 . . . . . . . . . . . . 9-4
C11SIM . . . . . . . . . . . . 20-1
CAL11. . . . . . . . . . . . . 13-7, 14-15, 20-1, 20-4 to 20-5,
21-2
CHFST . . . . . . . . . . . . 6-2
CHK11 . . . . . . . . . . . . 1-4, 2-1, 5-1, 17-1 to 17-2,
18-2, 19-2
CHLST . . . . . . . . . . . . 6-2
Compression . . . . . . . . . 15-4, 16-4
CRC . . . . . . . . . . . . . 1-1, 12-10
CSR . . . . . . . . . . . . . 2-3, 9-2
CTLMSG . . . . . . . . . . . . 12-4
CTS . . . . . . . . . . . . . 8-2, 20-7
D60SPD . . . . . . . . . . . . 20-3, 21-2
D60SPL . . . . . . . . . . . . 18-8, 20-3, 21-2
Page Index-2
DAS44 . . . . . . . . . . . . 17-1
DAS78 . . . . . . . . . . . . 17-1, 21-1 to 21-2
DC3 . . . . . . . . . . . . . 15-3 to 15-4, 16-4
DC71 . . . . . . . . . . . . . 18-2
DC72 . . . . . . . . . . . . . 18-2
DC76 . . . . . . . . . . . . . 3-1, 18-1, 18-3, 20-1,
20-4
DDT . . . . . . . . . . . . . 13-3, 18-3
DDT11 . . . . . . . . . . . . 18-2
DDT60 . . . . . . . . . . . . 18-2, 18-4, 18-6
DEBUG . . . . . . . . . . . . 14-2, 18-4 to 18-6
DEC . . . . . . . . . . . . . 18-2, 21-1
DECsystem-10 . . . . . . . . . 1-2 to 1-3, 14-16, 15-1,
18-1
DECsystem-1070 . . . . . . . . 1-1
DECsystem-1080 . . . . . . . . 1-1
DECsystem-1090 . . . . . . . . 1-1
DECsystem-1091 . . . . . . . . 1-1
DECSYSTEM-20 . . . . . . . . . 1-2 to 1-3, 14-16, 15-1,
18-2, 20-1, 20-5
DECX11 . . . . . . . . . . . . 17-2
DEFINE . . . . . . . . . . . . 1-3, 3-1 to 3-2, 13-1,
19-1
DEL . . . . . . . . . . . . . 15-1, 16-1
DEQ . . . . . . . . . . . . . 20-5
DEQCHK . . . . . . . . . . . . 7-2
DEQMID . . . . . . . . . . . . 7-1
DEQMSG . . . . . . . . . . . . 7-1
DISPAT . . . . . . . . . . . . 1-3, 11-1, 18-4, 19-1
DISPATCH . . . . . . . . . . . 11-1
DL10 . . . . . . . . . . . . . 1-1 to 1-3, 2-1 to 2-2,
3-2, 5-2, 7-1, 11-1,
13-1 to 13-5, 14-1, 17-1,
18-3, 18-7, 19-1 to 19-2,
20-1 to 20-2, 20-4 to 20-5
DLCKCL . . . . . . . . . . . . 15-4
DLDISP . . . . . . . . . . . . 13-4
DLDRAI . . . . . . . . . . . . 13-7, 14-15
DLDRBL . . . . . . . . . . . . 14-4, 14-6, 14-10
DLDRVR . . . . . . . . . . . . 14-4
DLE . . . . . . . . . . . . . 12-4, 12-7, 12-10, 20-7,
22-1, 23-2 to 23-3, 23-5
DLEDBL . . . . . . . . . . . . 14-11
DLELDN . . . . . . . . . . . . 14-4 to 14-5, 14-10
DLEND . . . . . . . . . . . . 13-1
DLENDO . . . . . . . . . . . . 13-4
DLGBYT . . . . . . . . . . . . 13-4, 14-14
DLGONE . . . . . . . . . . . . 14-3
DLGOPR . . . . . . . . . . . . 13-4
DLINDB . . . . . . . . . . . . 14-3
DLMBCT . . . . . . . . . . . . 14-11
DLMCTL . . . . . . . . . . . . 14-6, 14-11
DLNWCK . . . . . . . . . . . . 13-7, 14-15
DLPBYT . . . . . . . . . . . . 13-5, 14-14 to 14-15
Page Index-3
DLPSTR . . . . . . . . . . . . 13-5 to 13-6, 14-14 to 14-15
DLPWRD . . . . . . . . . . . . 13-5, 14-15
DLSDLY . . . . . . . . . . . . 14-12
DLSERR . . . . . . . . . . . . 14-12
DLSSAV . . . . . . . . . . . . 14-2
DLTDEP . . . . . . . . . . . . 13-6
DLTDnn . . . . . . . . . . . . 13-7, 14-15
DLTEDN . . . . . . . . . . . . 14-6, 14-11
DLTEXM . . . . . . . . . . . . 13-6, 14-14
DLTLnn . . . . . . . . . . . . 13-7, 14-15
DLTRBN . . . . . . . . . . . . 13-6
DLTRDS . . . . . . . . . . . . 13-5
DLTRDT . . . . . . . . . . . . 13-5, 14-13
DLTRES . . . . . . . . . . . . 13-6, 14-14
DLTRLS . . . . . . . . . . . . 13-6, 14-13
DLTWBN . . . . . . . . . . . . 13-7
DLTWD1 . . . . . . . . . . . . 14-13
DLTWDC . . . . . . . . . . . . 13-6
DLTWDT . . . . . . . . . . . . 13-5, 14-12
DLTWEC . . . . . . . . . . . . 13-6, 14-14
DLTWL1 . . . . . . . . . . . . 14-13
DLTWLC . . . . . . . . . . . . 13-6, 14-13
DLTWS1 . . . . . . . . . . . . 14-14
DLTXDN . . . . . . . . . . . . 14-4 to 14-5, 14-10
DLXADR . . . . . . . . . . . . 13-1
DLXCBP . . . . . . . . . . . . 13-2, 13-4 to 13-5
DLXDVE . . . . . . . . . . . . 13-1
DLXDVX . . . . . . . . . . . . 13-2
DLXDWN . . . . . . . . . . . . 13-1
DLXHLT . . . . . . . . . . . . 13-1
DLXLNE . . . . . . . . . . . . 13-1
DLXLNX . . . . . . . . . . . . 13-2
DLXNAM . . . . . . . . . . . . 13-1
DLXOK . . . . . . . . . . . . 13-1
DLXOPE . . . . . . . . . . . . 13-1
DLXOPX . . . . . . . . . . . . 13-2
DLXRST . . . . . . . . . . . . 13-2, 13-4
DLXSWD . . . . . . . . . . . . 13-1
DLXTA . . . . . . . . . . . . 13-1
DLXXFR . . . . . . . . . . . . 13-2, 13-4
DN20 . . . . . . . . . . . . . 1-2, 4-1, 18-5
DN60 . . . . . . . . . . . . . 1-1 to 1-3, 2-1, 3-1 to 3-2,
8-1, 13-3, 13-6, 14-3 to 14-5,
14-11 to 14-12, 14-14,
15-3, 15-5, 17-1, 18-1 to 18-4,
18-8, 19-1, 20-1 to 20-6,
23-3, A-1 to A-8
DN61 . . . . . . . . . . . . . 1-2, 3-1, 13-1 to 13-4,
14-4, 14-16, 18-1, 21-1 to 21-2,
22-1, 23-1
DN61-B . . . . . . . . . . . . 1-1 to 1-2
DN61-BA . . . . . . . . . . . 1-3, 19-2
DN61-BB . . . . . . . . . . . 1-3, 19-2
DN61-D . . . . . . . . . . . . 1-1 to 1-2
Page Index-4
DN61-DA . . . . . . . . . . . 1-3, 19-1
DN61-DB . . . . . . . . . . . 1-3, 19-1
DN61-S . . . . . . . . . . . . 1-1 to 1-2, 20-2, 20-5
DN61-SA . . . . . . . . . . . 1-3, 14-1, 19-2
DN61-SB . . . . . . . . . . . 1-3, 14-1, 19-2
DN61B . . . . . . . . . . . . 1-3, 3-1 to 3-2, 4-1,
5-1, 19-2
DN61D . . . . . . . . . . . . 1-3, 3-1 to 3-2, 19-1 to 19-2
DN61S . . . . . . . . . . . . 1-3, 3-1 to 3-2, 19-2
DN62 . . . . . . . . . . . . . 1-2, 12-1, 13-2, 18-7,
20-6
DN62B . . . . . . . . . . . . 3-1
DN62S . . . . . . . . . . . . 1-3, 3-1
DN64 . . . . . . . . . . . . . 1-2, 3-1, 14-7, 14-16,
18-2, 23-1
DN64-A . . . . . . . . . . . . 1-1 to 1-2, 20-2
DN64-AA . . . . . . . . . . . 1-3, 14-1, 19-2
DN64-AB . . . . . . . . . . . 1-3, 14-1, 19-2
DN64A . . . . . . . . . . . . 1-3, 3-1 to 3-2, 4-1,
5-1, 19-2
DN65 . . . . . . . . . . . . . 1-2, 18-7, 20-6
DN65A . . . . . . . . . . . . 3-1
DN80 . . . . . . . . . . . . . 17-1
DN81 . . . . . . . . . . . . . 17-1
DN82 . . . . . . . . . . . . . 17-1
DN85 . . . . . . . . . . . . . 17-1, 18-3
DN87 . . . . . . . . . . . . . 1-2, 17-1, 18-3
DN87S . . . . . . . . . . . . 1-2, 18-2
DNLOAD . . . . . . . . . . . . 18-2, 18-4
DQ11 . . . . . . . . . . . . . 1-3 to 1-4, 2-1 to 2-2,
5-1, 7-2, 8-1 to 8-4,
10-1, 12-2, 17-1, 18-1,
18-6, 19-1 to 19-2, 20-1,
20-8
DQ11-D . . . . . . . . . . . . 1-1
DQ11-E . . . . . . . . . . . . 1-1
DQABRI . . . . . . . . . . . . 12-5
DQABRO . . . . . . . . . . . . 12-4
DQCNTL . . . . . . . . . . . . 8-1
DQDRVR . . . . . . . . . . . . 12-1
DQDTR0 . . . . . . . . . . . . 8-4
DQDTR1 . . . . . . . . . . . . 8-4
DQINIT . . . . . . . . . . . . 8-1
DQINWQ . . . . . . . . . . . . 8-1 to 8-2
DQKILL . . . . . . . . . . . . 8-2
DQLCB . . . . . . . . . . . . 2-2
DQMDMS . . . . . . . . . . . . 8-4
DQRBCC . . . . . . . . . . . . 12-3 to 12-4
DQREAD . . . . . . . . . . . . 8-1
DQRECV . . . . . . . . . . . . 12-2 to 12-4
DQRNRM . . . . . . . . . . . . 12-4
DQRNRP . . . . . . . . . . . . 12-3
DQRPRP . . . . . . . . . . . . 12-3
DQRQIP . . . . . . . . . . . . 12-3
Page Index-5
DQRXPM . . . . . . . . . . . . 12-4
DQSEOT . . . . . . . . . . . . 12-5
DQWRIT . . . . . . . . . . . . 8-1, 12-9
DQXMIT . . . . . . . . . . . . 12-1 to 12-3
DQXNAV . . . . . . . . . . . . 12-2 to 12-3
DQXRSP . . . . . . . . . . . . 12-2
DSPDLS . . . . . . . . . . . . 14-3
DSPDLT . . . . . . . . . . . . 14-3
DSPTCB . . . . . . . . . . . . 18-5
DSR . . . . . . . . . . . . . 8-4, 12-11, 20-6
DT.INT . . . . . . . . . . . . 14-2
DT10AK . . . . . . . . . . . . 14-8 to 14-9
DT10DF . . . . . . . . . . . . 14-6, 14-12
DT10DT . . . . . . . . . . . . 14-6, 14-14
DT10FN . . . . . . . . . . . . 14-5
DT10HD . . . . . . . . . . . . 14-5, 14-12
DT11AD . . . . . . . . . . . . 14-14
DT11AS . . . . . . . . . . . . 14-11
DT11BS . . . . . . . . . . . . 14-11
DT11DF . . . . . . . . . . . . 14-6
DT11FN . . . . . . . . . . . . 14-6
DT11GW . . . . . . . . . . . . 14-12
DT11HD . . . . . . . . . . . . 14-6, 14-10
DT11ST . . . . . . . . . . . . 14-5 to 14-6, 14-10,
14-12
DT11T . . . . . . . . . . . . 14-14
DTCERR . . . . . . . . . . . . 14-15
DTCMRT . . . . . . . . . . . . 14-12
DTDIND . . . . . . . . . . . . 14-6
DTE . . . . . . . . . . . . . 2-2, 14-7, 16-4
DTE10 . . . . . . . . . . . . 1-3, 14-1, 14-4, 15-4,
19-2, A-1
DTE10.P11 . . . . . . . . . . 14-4
DTE20 . . . . . . . . . . . . 1-1, 1-3, 2-1, 5-2, 7-1,
11-1, 14-1 to 14-5, 14-7,
14-16, 18-1, 18-3, 18-5,
18-7, 19-2, 20-1, 20-5
DTE20.P11 . . . . . . . . . . 14-7
DTELDR . . . . . . . . . . . . 18-1 to 18-2, 18-4
DTEPCA . . . . . . . . . . . . 14-1
DTEQSZ . . . . . . . . . . . . 14-11
DTESAV . . . . . . . . . . . . 14-2, 18-5
DTESAV+20 . . . . . . . . . . 18-5
DTFSAK . . . . . . . . . . . . 14-16
DTHDIN . . . . . . . . . . . . 14-6
DTHDST . . . . . . . . . . . . 14-6, 14-10
DTIDBL . . . . . . . . . . . . 14-2, 14-4, 14-6
DTIEDN . . . . . . . . . . . . 14-2, 14-4 to 14-5
DTINST . . . . . . . . . . . . 14-6, 14-11
DTIPDN . . . . . . . . . . . . 14-6, 14-12
DTIXDN . . . . . . . . . . . . 14-2, 14-4
DTR . . . . . . . . . . . . . 8-4, 20-6
DTSACK . . . . . . . . . . . . 14-10
DTSAK . . . . . . . . . . . . 14-10
Page Index-6
DTSHDR . . . . . . . . . . . . 14-12
DTSRT . . . . . . . . . . . . 14-6
DTSTDB . . . . . . . . . . . . 14-5 to 14-6, 14-10
DTSTDD . . . . . . . . . . . . 14-5
DTSTHD . . . . . . . . . . . . 14-5
DTSTIB . . . . . . . . . . . . 14-5
DTSTID . . . . . . . . . . . . 14-5
DTSTRT . . . . . . . . . . . . 14-11
DTTTSB . . . . . . . . . . . . 14-11, 14-13
DTXMSD . . . . . . . . . . . . 14-12
DUMP . . . . . . . . . . . . . 16-2
DUP11 . . . . . . . . . . . . 1-1, 1-3 to 1-4, 2-3,
5-1, 7-2, 8-1 to 8-4,
9-1 to 9-2, 9-4, 9-6 to 9-10,
10-1, 12-2, 18-5 to 18-6,
20-7 to 20-8
DV11 . . . . . . . . . . . . . 8-3
EBCDIC . . . . . . . . . . . . 15-1 to 15-5, 16-1 to 16-4,
18-3, 18-7, 21-1, 22-1,
23-1
ED . . . . . . . . . . . . . . 14-7 to 14-10, 14-16
EH . . . . . . . . . . . . . . 14-7 to 14-9, 14-16
EM . . . . . . . . . . . . . . 21-1, 23-2, 23-10
ENQ . . . . . . . . . . . . . 15-2, 20-5, 23-2, 23-4 to 23-5,
23-7 to 23-8
ENQ/DEQ . . . . . . . . . . . 20-1
EOF . . . . . . . . . . . . . 12-9, 14-12, 16-2 to 16-4,
20-3 to 20-4, 20-9 to 20-10,
20-12 to 20-13
EOR . . . . . . . . . . . . . 16-4
EOT . . . . . . . . . . . . . 8-4, 12-5, 20-7, 23-2,
23-6 to 23-7
ESC . . . . . . . . . . . . . 18-3, 22-1, 23-2, 23-9 to 23-10
ETB . . . . . . . . . . . . . 12-4, 12-7, 12-10, 20-12,
22-1, 23-2, 23-5, 23-7,
23-10
ETX . . . . . . . . . . . . . 12-4, 20-12, 23-2, 23-5,
23-7, 23-10
FACT file . . . . . . . . . . 21-1
FCS . . . . . . . . . . . . . 12-5, 12-7 to 12-8
FCS1 . . . . . . . . . . . . . 12-11
FCS2 . . . . . . . . . . . . . 12-11
FE . . . . . . . . . . . . . . 20-1
FEH . . . . . . . . . . . . . 14-4, 14-7 to 14-9,
14-16
FRECHK . . . . . . . . . . . . 5-1, 6-2, 18-6
FRESTG . . . . . . . . . . . . 6-2
GA27-3004 . . . . . . . . . . 23-10
GA27-3005 . . . . . . . . . . 23-10
GA27-3063 . . . . . . . . . . 23-10
GA27-3097 . . . . . . . . . . 23-10
Page Index-7
GETCHK . . . . . . . . . . . . 6-2, 8-3, 18-5 to 18-6
GETSTG . . . . . . . . . . . . 6-1 to 6-2
GETTCB . . . . . . . . . . . . 6-1
GLOBAL . . . . . . . . . . . . 2-2, 3-2, 6-2, 11-1,
13-6, 18-5 to 18-7
HASP . . . . . . . . . . . . . 12-1, 12-8, 16-1
HASP Multileaving . . . . . . 1-3, 20-6
HASP Multileaving Workstation 1-2
HMSGTC . . . . . . . . . . . . 12-7
HPXMIT . . . . . . . . . . . . 12-1, 12-8 to 12-9
HSABRI . . . . . . . . . . . . 12-8
HSABRO . . . . . . . . . . . . 12-11
HSABTI . . . . . . . . . . . . 12-8
HSABTO . . . . . . . . . . . . 12-11
HSARSP . . . . . . . . . . . . 12-5 to 12-6
HSAWXL . . . . . . . . . . . . 12-8
HSCDOT . . . . . . . . . . . . 12-10 to 12-11
HSCHST . . . . . . . . . . . . 12-8
HSCKAB . . . . . . . . . . . . 12-11
HSCKDO . . . . . . . . . . . . 12-11
HSCKRQ . . . . . . . . . . . . 12-10
HSCKTP . . . . . . . . . . . . 12-10
HSCMPO . . . . . . . . . . . . 16-2
HSCMPS . . . . . . . . . . . . 16-2
HSDPG . . . . . . . . . . . . 12-10
Hsdpg . . . . . . . . . . . . 12-11
HSDRIP . . . . . . . . . . . . 12-8, 12-11
HSEOB . . . . . . . . . . . . 12-7 to 12-8
HSGTMS . . . . . . . . . . . . 12-8 to 12-10
HSMSAK . . . . . . . . . . . . 12-9
HSMTBK . . . . . . . . . . . . 12-9 to 12-11
HSONB . . . . . . . . . . . . 12-9
HSPLIN . . . . . . . . . . . . 12-1
HSPXM1 . . . . . . . . . . . . 12-8 to 12-9
HSPXM5 . . . . . . . . . . . . 12-5 to 12-6, 12-9
HSRECV . . . . . . . . . . . . 12-1, 12-5 to 12-6
HSRLOM . . . . . . . . . . . . 12-11
HSRQMS . . . . . . . . . . . . 12-6, 12-8
HSRQPT . . . . . . . . . . . . 12-9
HSRSON . . . . . . . . . . . . 12-7
HSRXPM . . . . . . . . . . . . 12-6 to 12-7
HSTFCS . . . . . . . . . . . . 12-7
HSTRCB . . . . . . . . . . . . 12-7
HSTRL . . . . . . . . . . . . 12-10
HSUNSP . . . . . . . . . . . . 12-11
HSUSPD . . . . . . . . . . . . 12-11
HSWALX . . . . . . . . . . . . 12-8
HT . . . . . . . . . . . . . . 23-2, 23-9
IBM . . . . . . . . . . . . . 8-2, 12-1 to 12-2, 12-11,
15-1, 15-5, 21-1, 23-1,
23-10
IBM 029 . . . . . . . . . . . 15-5
Page Index-8
IBM 2780 . . . . . . . . . . . 1-2 to 1-3, 15-1 to 15-2,
19-1, 20-6, 20-10 to 20-11,
21-1 to 21-2, 23-1,
23-10
IBM 3270 . . . . . . . . . . . 20-6
IBM 360 . . . . . . . . . . . 1-2, 8-2, 15-1, 15-3
IBM 370 . . . . . . . . . . . 1-2
IBM 3770 . . . . . . . . . . . 23-10
IBM 3780 . . . . . . . . . . . 1-2 to 1-3, 15-1 to 15-3,
15-5, 19-1, 20-6, 20-10 to 20-11,
21-1, 23-1, 23-3 to 23-4,
23-9 to 23-10
IBM HASP . . . . . . . . . . . 16-2
IDLE . . . . . . . . . . . . . 1-2, 5-1, 6-2, 13-5,
14-13, 15-4
IGS . . . . . . . . . . . . . 15-3 to 15-4, 16-4, 23-9 to 23-10
INIT1 . . . . . . . . . . . . 1-4, 5-1, 19-2
INIT2 . . . . . . . . . . . . 1-3, 5-1 to 5-2, 11-2,
19-1
INITDL . . . . . . . . . . . . 14-3
INITDQ . . . . . . . . . . . . 1-4, 5-1, 19-1 to 19-2
INITUP . . . . . . . . . . . . 1-4, 5-1, 19-2
IRS . . . . . . . . . . . . . 15-3, 20-12, 22-1, 23-2,
23-9
IUS . . . . . . . . . . . . . 20-12, 23-2 to 23-3,
23-10
Jiffies . . . . . . . . . . . 8-2, 20-8, 20-11
Jiffy . . . . . . . . . . . . 8-4, 10-1, 11-1, 13-1,
13-3
JSYS . . . . . . . . . . . . . 20-5
Keypunch . . . . . . . . . . . 15-5
KF.RUN . . . . . . . . . . . . 9-4
KG11-A . . . . . . . . . . . . 1-1, 4-1, 18-5 to 18-6
KL10 . . . . . . . . . . . . . 14-1, 14-3
KL10/PDP-11 . . . . . . . . . 14-16
KMC11 . . . . . . . . . . . . 1-1, 1-3 to 1-4, 2-2 to 2-3,
5-1, 8-1 to 8-3, 9-1 to 9-11,
18-7, 19-2, 20-6, 20-8
BA register . . . . . . . . 9-7
XX0 interrupt . . . . . . . 9-2 to 9-3, 9-5, 9-8
XX4 interrupt . . . . . . . 9-3, 9-5 to 9-6, 9-8
KMCCBA . . . . . . . . . . . . 9-4
KW11-L . . . . . . . . . . . . 1-1
L.ACT . . . . . . . . . . . . 9-4, 9-6 to 9-10
L.CHR . . . . . . . . . . . . 9-7, 9-9
L.CPNT . . . . . . . . . . . . 9-9
L.DCNT . . . . . . . . . . . . 9-9
L.DPNT . . . . . . . . . . . . 9-9
L.LCB . . . . . . . . . . . . 9-6 to 9-7
LA.ACT . . . . . . . . . . . . 9-4, 9-6 to 9-7
LA.CM . . . . . . . . . . . . 9-6, 9-9 to 9-10
Page Index-9
LA.XME . . . . . . . . . . . . 9-7, 9-9 to 9-10
LA.XMT . . . . . . . . . . . . 9-4, 9-6, 9-10
LB.MSG . . . . . . . . . . . . 12-9
LCB . . . . . . . . . . . . . 2-2 to 2-3, 8-3 to 8-4,
9-2 to 9-3, 9-5 to 9-8,
9-10, 12-9, 13-6, 15-4
LP10 . . . . . . . . . . . . . 15-2 to 15-5, 16-2, 16-4,
21-2
LPD . . . . . . . . . . . . . 22-1, 23-2
LPFORM.INI . . . . . . . . . . 21-2
LPT . . . . . . . . . . . . . 16-4
LPTSPL . . . . . . . . . . . . 21-1
MACDLX . . . . . . . . . . . . 18-2 to 18-3, 19-1
Macro . . . . . . . . . . . . 18-6
MACROS . . . . . . . . . . . . 1-3, 3-2, 19-1
MDCODE . . . . . . . . . . . . 1-4, 9-1, 19-2
MDSLEM . . . . . . . . . . . . 8-3
MININT . . . . . . . . . . . . 1-3, 4-1, 11-2, 19-1
Modem . . . . . . . . . . . . 8-2, 20-10, 22-1 to 22-2,
23-3
Modules . . . . . . . . . . . 17-1
MSGAPC . . . . . . . . . . . . 10-1
MSGAPE . . . . . . . . . . . . 10-2
MSGGT2 . . . . . . . . . . . . 10-1
MSGGTC . . . . . . . . . . . . 10-1
MSGGTE . . . . . . . . . . . . 10-1
MSGGTT . . . . . . . . . . . . 10-1
MSGHDL . . . . . . . . . . . . 1-3, 10-1, 19-1
MSGHDR . . . . . . . . . . . . 12-11
MSGSUP . . . . . . . . . . . . 15-2, 16-2
Multi-record feature . . . . . 20-11
NAK . . . . . . . . . . . . . 8-1, 12-4, 12-6, 12-9,
20-7, 23-2, 23-4 to 23-7
NAKS . . . . . . . . . . . . . 12-6
NETLDR . . . . . . . . . . . . 18-2
NL . . . . . . . . . . . . . . 23-2, 23-9
NPR . . . . . . . . . . . . . 9-5 to 9-8, 9-10 to 9-11
OS/360 . . . . . . . . . . . . 15-5
Overprint . . . . . . . . . . 15-2, 20-12
PAD . . . . . . . . . . . . . 23-2
PADS . . . . . . . . . . . . . 12-10
Parity . . . . . . . . . . . . 4-1
PC . . . . . . . . . . . . . . 14-2
PDP-10 . . . . . . . . . . . . 1-2 to 1-3, 2-1 to 2-2,
5-1 to 5-2, 7-1, 12-3,
13-1 to 13-7, 14-15,
15-1 to 15-3, 15-5, 16-2 to 16-3,
18-7, 19-1, 20-1 to 20-2
PDP-11 . . . . . . . . . . . . 1-3, 2-3, 5-2, 8-3, 9-1 to 9-6,
9-8 to 9-9, 11-2, 13-1,
14-1, 14-7, 14-11, 15-4,
17-1, 18-5, 18-8, 19-1,
20-1
PDP-11/03 . . . . . . . . . . 3-1
PDP-11/34 . . . . . . . . . . 1-1
PDP-11/40 . . . . . . . . . . 1-1
PDP-8 . . . . . . . . . . . . 18-2
Printable . . . . . . . . . . 15-1, 16-1
QUECHK . . . . . . . . . . . . 7-2
QUEING . . . . . . . . . . . . 1-3, 7-1, 19-1
QUEMSG . . . . . . . . . . . . 7-1
Queue . . . . . . . . . . . . 13-7, 14-15, 15-2, 16-2,
18-6, 20-4
Queued . . . . . . . . . . . . 12-2
RCB . . . . . . . . . . . . . 12-5, 12-7, 12-9 to 12-10,
16-3 to 16-4
RSX-20F . . . . . . . . . . . 14-1
RVI . . . . . . . . . . . . . 23-2
S . . . . . . . . . . . . . . 3-1 to 3-2, 18-1, 19-1
SCB . . . . . . . . . . . . . 9-2, 9-7 to 9-8, 12-5
SEL0 . . . . . . . . . . . . . 9-1
SEL2 . . . . . . . . . . . . . 9-1
SEL4 . . . . . . . . . . . . . 9-1
SEL6 . . . . . . . . . . . . . 9-1
SEND . . . . . . . . . . . . . 9-6, 9-10
SIGNON . . . . . . . . . . . . 12-7, 12-9
Silo . . . . . . . . . . . . . 8-3
Simulate . . . . . . . . . . . 21-2
SOS . . . . . . . . . . . . . 15-3, 16-4
SP.FLG . . . . . . . . . . . . 9-5 to 9-6, 9-8
SP.TCH . . . . . . . . . . . . 9-4 to 9-5
SP.TCL . . . . . . . . . . . . 9-4 to 9-5
SPF.X0 . . . . . . . . . . . . 9-5, 9-8
SPF.X4 . . . . . . . . . . . . 9-5 to 9-6, 9-8
SRCB . . . . . . . . . . . . . 12-5, 12-7, 16-3 to 16-4
STGMAN . . . . . . . . . . . . 1-3, 6-1, 19-1
STOBCC . . . . . . . . . . . . 12-4
STOPCODE . . . . . . . . . . . 13-1, 13-3, 18-1, 18-4 to 18-5,
18-7
STOPR5 . . . . . . . . . . . . 14-2
STOPRO . . . . . . . . . . . . 14-2
STX . . . . . . . . . . . . . 12-11, 22-1, 23-2, 23-5
Subcommands . . . . . . . . . 13-5
Subfunction . . . . . . . . . 13-2
SYN . . . . . . . . . . . . . 12-7, 12-10, 22-1, 23-2 to 23-3,
23-5
Synchronous . . . . . . . . . 2-2 to 2-3
Tab . . . . . . . . . . . . . 15-1, 15-3 to 15-4, 16-1,
16-4
TCB . . . . . . . . . . . . . 2-3, 6-1, 11-2, 12-7,
13-5, 14-2, 14-5 to 14-6,
14-10 to 14-12, 14-14,
15-4
TCDPG . . . . . . . . . . . . 12-10
Page Index-11
TCFG2 . . . . . . . . . . . . 12-9
TCIPH . . . . . . . . . . . . 12-10
TCOTC . . . . . . . . . . . . 12-9
TCPS . . . . . . . . . . . . . 18-5
TCRFCS . . . . . . . . . . . . 12-7
TCRMSG . . . . . . . . . . . . 12-7
TCRQPT . . . . . . . . . . . . 12-9
TCXFR . . . . . . . . . . . . 14-14
TECO . . . . . . . . . . . . . 15-3, 16-4
TEN . . . . . . . . . . . . . 14-2
TEOM . . . . . . . . . . . . . 9-10
TER . . . . . . . . . . . . . 14-15
Throughput . . . . . . . . . . 18-4
Timeout . . . . . . . . . . . 8-4, 10-1, 20-7 to 20-8
TOPS-10 . . . . . . . . . . . 13-1, 13-3, 15-1, 16-1,
18-1, 19-1, 20-1
TOPS-10/20 . . . . . . . . . . 14-2
TOPS-20 . . . . . . . . . . . 14-7, 20-5
Transparent . . . . . . . . . 12-4, 15-3, 18-7, 20-7,
21-1
TRAPDQ . . . . . . . . . . . . 8-1, 8-4
TRCABO . . . . . . . . . . . . 18-7
TRCBCB . . . . . . . . . . . . 18-7
TRCBCC . . . . . . . . . . . . 18-6
TRCBTS . . . . . . . . . . . . 18-6
TRCCNK . . . . . . . . . . . . 18-6
TRCDQD . . . . . . . . . . . . 18-6
TRCDQF . . . . . . . . . . . . 18-6
TRCDSP . . . . . . . . . . . . 18-6
TRCFLG . . . . . . . . . . . . 18-5
TRCHLT . . . . . . . . . . . . 18-7
TRCMDF . . . . . . . . . . . . 18-7
TRCPAD . . . . . . . . . . . . 18-7
TRCPTR . . . . . . . . . . . . 18-6
TRCQUE . . . . . . . . . . . . 18-6
TRCTBE . . . . . . . . . . . . 18-6
TRCTBL . . . . . . . . . . . . 18-6
TRCTBO . . . . . . . . . . . . 18-7
TRCTBS . . . . . . . . . . . . 18-6
TRCTEN . . . . . . . . . . . . 18-7
TRCTER . . . . . . . . . . . . 18-7
TRCXLD . . . . . . . . . . . . 18-6
TRPCOD . . . . . . . . . . . . 14-2
TRPERR . . . . . . . . . . . . 14-2
TTD . . . . . . . . . . . . . 20-7, 23-2, 23-7
UNIBUS . . . . . . . . . . . . 9-1
USAGE file . . . . . . . . . . 21-1
UUO . . . . . . . . . . . . . 13-7, 14-15, 20-1 to 20-2,
20-4 to 20-5, 21-2
UUOPRV . . . . . . . . . . . . 20-1
WACK . . . . . . . . . . . . . 20-7, 23-2, 23-7 to 23-8
WAIT . . . . . . . . . . . . . 11-1 to 11-2
Page Index-12
XHDIAB . . . . . . . . . . . . 16-3
XHDINP . . . . . . . . . . . . 16-1, 16-3
XHDOUT . . . . . . . . . . . . 16-1
XHEBAS . . . . . . . . . . . . 16-3
XHGTC . . . . . . . . . . . . 16-4
XHIMSE . . . . . . . . . . . . 16-4
XHIMSG . . . . . . . . . . . . 16-3
XHIPRS . . . . . . . . . . . . 16-4
XHMSTP . . . . . . . . . . . . 16-2
XHSNDL . . . . . . . . . . . . 16-2
XHSNDM . . . . . . . . . . . . 16-2
XL3780 . . . . . . . . . . . . 1-3, 15-1, 15-4 to 15-5,
16-5, 19-1, 21-2
XLASCD . . . . . . . . . . . . 15-1 to 15-2
XLASPR . . . . . . . . . . . . 15-2
XLASSF . . . . . . . . . . . . 15-2
XLASSP . . . . . . . . . . . . 15-2
XLASTF . . . . . . . . . . . . 15-2
XLATE . . . . . . . . . . . . 1-2, 2-2, 10-1 to 10-2,
12-6, 12-8, 14-11 to 14-12,
15-1, 16-2, 18-6
XLCPUT . . . . . . . . . . . . 15-3, 16-4
XLDPCM . . . . . . . . . . . . 16-4
XLDSON . . . . . . . . . . . . 16-3
XLEOFO . . . . . . . . . . . . 15-2
XLHASP . . . . . . . . . . . . 1-2 to 1-3, 16-1
XLHCNK . . . . . . . . . . . . 16-1 to 16-2
XLHDMP . . . . . . . . . . . . 16-3
XLHEOF . . . . . . . . . . . . 16-2 to 16-3
XLHSCD . . . . . . . . . . . . 16-1 to 16-2
XLHSEB . . . . . . . . . . . . 16-1
XLHSON . . . . . . . . . . . . 16-3
XLHSPR . . . . . . . . . . . . 16-1 to 16-2
XLHSSF . . . . . . . . . . . . 16-2
XLHSTF . . . . . . . . . . . . 16-2
XLIMSG . . . . . . . . . . . . 15-3, 16-4
XLIPCR . . . . . . . . . . . . 15-4, 16-4
XLIPGS . . . . . . . . . . . . 15-4, 16-4
XLIPHT . . . . . . . . . . . . 15-4, 16-4
XLIPRS . . . . . . . . . . . . 15-3
XLIPSP . . . . . . . . . . . . 15-4, 16-4
XLISHT . . . . . . . . . . . . 15-4, 16-4
XLITSP . . . . . . . . . . . . 15-3
XLLPCH . . . . . . . . . . . . 15-5
XLOCNK . . . . . . . . . . . . 15-1 to 15-2
XLSNDL . . . . . . . . . . . . 15-2
XLSNDM . . . . . . . . . . . . 15-2
XLWAIT . . . . . . . . . . . . 15-2
Page A-13
[END OF DN60 MAINTENANCE MANUAL]