Google
 

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]