Trailing-Edge
-
PDP-10 Archives
-
BB-J845A-SM
-
source/dn60m.rnm
There are 2 other files named dn60m.rnm in the archive. Click here to see a list.
.SD 60;.LOWER CASE;.AUTOPARAGRAPH;.FLAG CAP;.FLAG INDEX
.VARIABLE COVER @ %
.NONUMBER
.IF COVER
.TS 5,25
TO: <DN60 ^INTEREST ^LIST DATE: 31-^OCT-77
.I 5
# FROM: ^MINOO ^MALHOTRA
.I 5
# #######^KALMAN ^RETI
.I 5
# #######^BARRY ^SUSSMAN
.I 5
# DEPT: <COMM/NETS ^SOFTWARE ^ENGINEERING
.I 5
# EXT: #6360
.I 5
# LOC/MAIL STOP: ^^MR1-2/E89\\
.I 5
# POLE: ^E15
.B 2
.LM 7;.TS 7;.I -7
SUBJ: ^MAINTENANCE ^MANUAL FOR <DN60 PROGRAM
.LM 0
^THE ENCLOSED MANUAL IS THE TENTH DRAFT OF THE
<DN60 ^MAINTENANCE ^MANUAL.
^THE NINTH DRAFT WAS SENT TO CUSTOMERS WITH RELEASE 3.0 OF MONITOR.
^THE EIGHT DRAFT WAS SENT TO CUSTOMERS AS PART OF THE ^SEPTEMBER, 1977, FIELD
TEST OF THE <DN64.
^THE SEVENTH DRAFT WAS SENT TO CUSTOMERS AS PART OF THE ^JUNE, 1977,
FIELD TEST OF THE <DN64.
^THE SIXTH DRAFT WAS PART OF THE FIRST RELEASE
OF THE <DN61.
^YOUR COMMENTS ARE SOLICITED.
^MAJOR CHANGES SINCE THE NINTH DRAFT: ADDED SECTIONS FOR <HASP-^MULTILEAVING AS PART OF THE <DN62 RELEASE.
^MAJOR CHANGES SINCE THE EIGHTH DRAFT: CHANGED DOCUMENT
NUMBER FROM 130-952-066 TO <JBS-77-001.
^MAJOR CHANGES SINCE THE SEVENTH DRAFT: ADDED <KMC11/DUP11 AND <DN61-B.
^MAJOR CHANGES SINCE THE SIXTH DRAFT: UPDATED ^CHAPTER 14 TO INCLUDE
SOME PERFORMANCE IMPROVEMENTS.
^MAJOR CHANGES SINCE THE FIFTH DRAFT: ADDED CHAPTER 14.
^REWROTE THE TITLE PAGE.
^ADDED REFERENCES TO <DECSYSTEM-20, <DUP11 AND <DN64.
^MAJOR CHANGES SINCE THE FOURTH DRAFT: CHANGED THE NAME TO '<DN60'.
^REFRESHED THE DISTRIBUTION LIST.
^MAJOR CHANGES SINCE THE THIRD DRAFT: SOME REARRANGEMENT OF SECTIONS
TO ISOLATE THE <DQ11 CODE, TO PROVIDE FOR LATER SUBSTITUTION
OF <DUP11<'S. ^BETTER HANDLING OF 0 TURN-AROUND-TIME
MODEMS.
^MANY STYLISTIC CHANGES. ^ADDITION OF A CHAPTER ON
<BISYNC.
^MAJOR CHANGES SINCE THE SECOND DRAFT:
A COMPLETE REWRITE OF THE CHAPTER ON PERFORMANCE.
^ADDITION OF A FUNCTION TO DUMP THE <DN60<'S OUTPUT BUFFERS.
^MAJOR CHANGES SINCE THE FIRST DRAFT: EXPANDED INTRODUCTION AND
COMPLETION OF CHAPTERS <BSC, <DL10 AND <XL3780.
^INCLUSION OF <DTE20 FEATURES, ALTHOUGH THE <DTE CHAPTER IS
STILL INCOMPLETE.
^ADDITION OF THE CHAPTER ON THE <CAL11_. <UUO.
^MORE INFORMATION ON <DDT60.
^INFORMATION ON REGISTER CONVENTIONS.
^ADDITION OF AN INDEX.
^ADDITION OF A CHAPTER ON DIFFERENCES FROM THE <DAS78
AND ONE ON PERFORMANCE ESTIMATES.
.NONUMBER
.TITLE #
.PAGE
.ENDIF COVER
.ST #
#
.B 8
.CENTER
<DN60
.B 1
.CENTER
^MAINTENANCE ^MANUAL
.B 4
.CENTER
^DOCUMENT ^NUMBER: <JBS-77-001-02-U
.B 1
.CENTER
(FORMERLY 130-952-066)
.B 6
.CENTER
^OCTOBER 31, 1978
.B 6
.LM +8;.RM -8
^THIS MANUAL IS WRITTEN FOR THE PERSON WHO HAS THE
RESPONSIBILITY TO MAINTAIN THE <DN60 SOFTWARE ON
A <DEC<SYSTEM-10 OR <DECSYSTEM-20.
.B 1;.LM +4;.I -4
^OPERATING ^SYSTEM AND VERSION: <TOPS-10 6.03 OR
<TOPS-20 3.0.
.B 1;.I -4
^SOFTWARE VERSION: <DN61D VERSION 2,
<DN61S VERSION 2,
<DN61B VERSION 1.
<DN64A VERSION 1.
<DN62S VERSION 1.
<DN62D VERSION 1 AND
<DN65S VERSION 1.
.LM -4;.LM -8;.RM +8
.B 11;.CENTER
DIGITAL EQUIPMENT CORPORTATION, MAYNARD, MASSACHUSETTS
.PAGE
.RIGHT
^FIRST ^PRINTING: ^JUNE 23, 1977
.RIGHT
^REVISED: ^SEPTEMBER 17, 1977
.RIGHT
^REVISED: ^OCTOBER 31, 1978
.B 3
"^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."
.B 2
.CENTER
^COPYRIGHT (^C) 1980, 1978 BY ^DIGITAL ^EQUIPMENT ^CORPORATION
.B 2
.CENTER
^THE FOLLOWING ARE TRADEMARKS OF
.CENTER
^DIGITAL ^EQUIPMENT ^CORPORATION:
.B 2
.TS 16,31,46,61
^^COMPUTER LABS\\ ^^DECUS\\ ^^FOCAL\\ ^^MASSBUS\\
.BREAK
^^COMTEX\\ ^^DEC\\SYSTEM-10 ^^INDAC\\ ^^RSTS\\
.BREAK
^^DDT\\ ^^DIBOL\\ ^^LAB-8\\ ^^RSX\\
.BREAK
^^DEC\\ ^^DIGITAL\\ ^^OMNIBUS\\ ^^TYPESET-8\\
.BREAK
^^DECCOMM\\ ^^EDUSYSTEM\\ ^^OS/8\\ ^^DECSYSTEM-20\\
.BREAK
^^DEC\\TAPE ^^FLIP CHIP\\ ^^PDP\\ ^^TYPESET-11\\
.BREAK
# # ^^PHA\\ ^^UNIBUS\\
.PAGE
.CENTER
^TABLE OF ^CONTENTS
.TITLE TABLE OF CONTENTS
.B 6;.LM +15
.I -15
^CHAPTER#01#--#<INTRODUCTION
.I -15
^CHAPTER#02#--#<DATA <STRUCTURES <OVERVIEW
.I -15
^CHAPTER#03#--#<PREFIX <SECTIONS
.I -15
^CHAPTER#04#--#<SECTION "<MININT"
.I -15
^CHAPTER#05#--#<SECTIONS "<INIT1", "<INITDQ", "<INITUP" AND "<INIT2"
.I -15
^CHAPTER#06#--#<SECTION "<STGMAN"
.I -15
^CHAPTER#07#--#<SECTION "<QUEING"
.I -15
^CHAPTER#08#--#<SECTIONS "<DQ11", "<DUP11" AND "<KMC11"
.I -15
^CHAPTER#09#--#<SECTION "<MDCODE"
.I -15
^CHAPTER#10#--#<SECTION "<MSGHDL"
.I -15
^CHAPTER#11#--#<SECTION "<DISPAT"
.I -15
^CHAPTER#12#--#<SECTION "<BSC"
.I -15
^CHAPTER#13#--#<SECTION "<DL10"
.I -15
^CHAPTER#14#--#<SECTIONS "<DTE10" AND "<DTE20"
.I -15
^CHAPTER#15#--#<SECTION "<XL3780"
.I -15
^CHAPTER#16#--#<SECTION "<XLHASP"
.I -15
^CHAPTER#17#--#<SECTION "<CHK11<"
.I -15
^CHAPTER#18#--#<DEBUGGING <FACILITIES
.I -15
^CHAPTER#19#--#<ASSEMBLY <INSTRUCTIONS
.I -15
^CHAPTER#20#--#<THE <CAL11_. <UUO
.I -15
^CHAPTER#21#--#<DIFFERENCES <FROM <THE <DAS78
.I -15
^CHAPTER#22#--#<PERFORMANCE <ESTIMATES <FOR <THE <DN61
.I -15
^CHAPTER#23#--#<BINARY <SYNCHRONOUS <PROTOCOL (<BISYNC)
.I -15
^APPENDIX#^A#--#<DTE10 <FORMATS
.LM -15
.NUMBER
.CHAPTER INTRODUCTION
.HL 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.
.HL 1 ^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
16^K WORDS OF PARITY MEMORY, A <>KW11-L
LINE FREQUENCY CLOCK AND A <>KG11-A
<>CRC CALCULATOR.
^IT INTERFACES TO A <DEC<SYSTEM-1070, 1080 OR 1090.
.INDEX <DEC<SYSTEM-1070
.INDEX <DEC<SYSTEM-1080
.INDEX <DEC<SYSTEM-1090
^THE <>DN61-S<> IS THE SAME EXCEPT THAT IT HAS 32^K OF MEMORY
AND USES A <>DTE20<>
IN PLACE OF THE <>DL10<>.
^IT INTERFACES TO THE <DEC<SYSTEM-1090.
.INDEX <DEC<SYSTEM-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
32^K WORDS OF PARITY MEMORY, UP TO 3 <>KMC11<>
MICROPROCESSORS AND A <>KW11-L<> COMPATABLE
LINE FREQUENCY CLOCK.
^IT INTERFACES TO THE <DEC<SYSTEM-1091.
.INDEX <DEC<SYSTEM-1091
^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.
.TEST PAGE 8
^THE PURPOSE OF THE <>DN60 FRONT END SOFTWARE IS TO
PROVIDE THE FOLLOWING FUNCTIONS:
.LIST
.LE;^DRIVING THE SYNCHRONOUS LINES, WHICH MAY REQUIRE
SERVICE AT
UP TO 100,000 BITS PER SECOND.
.LE;^CONVERTING <DEC<SYSTEM-10/20
.INDEX <DEC<SYSTEM-10
.INDEX <DECSYSTEM-20
DATA FORMATS TO THE FORMATS
REQUIRED BY THE <IBM 360<, <IBM 370<, <HASP ^MULTILEAVING ^WORKSTATION, <IBM 3780< AND <IBM 2780<.
.INDEX <IBM 360
.INDEX <IBM 370
.INDEX <HASP ^MULTILEAVING ^WORKSTATION
.INDEX <IBM 3780
.INDEX <IBM 2780
.LE;^CONVERTING THE DATA FORMATS USED BY THE
<IBM 360<, <IBM 370<, <IBM 3780< AND
.INDEX <IBM 360
.INDEX <IBM 370
.INDEX <HASP ^MULTILEAVING ^WORKSTATION
.INDEX <IBM 3780
<IBM 2780< TO THE FORMAT USED BY THE <DEC<SYSTEM-10/20.
.INDEX <DEC<SYSTEM-10
.INDEX <DECSYSTEM-20
.INDEX <IBM 2780
.LE;^SCANNING THE MESSAGES RECEIVED FROM THE SYNCHRONOUS
LINES TO EXTRACT THE DATA EMBEDDED IN THE <>BSC PROTOCOL.
.LE;^PUTTING DATA INTO A <>BSC "ENVELOPE" TO TRANSMIT IT.
.END LIST
^TO ACCOMPLISH THESE TASKS EFFICIENTLY AND RELIABLY, THE
<>DN60 FRONT END SOFTWARE IS ORGANIZED AS SEVERAL
LOOSELY COUPLED TASKS. ^THESE ARE:
.LIST
.LE;<>BSC - THE TASK THAT PERFORMS <>BSC INTERPRETATION.
.LE;<>XLATE - THE TASK THAT TRANSLATES DATA FORMATS.
.LE;<>XLHASP - THE TASK THAT TRANSLATES, COMPRESSES AND DECOMPRESSES DATA FOR <HASP ^MULTILEAVING.
.LE;<>DL10 - THE TASK THAT COMMUNICATES WITH THE <>PDP<-10>.
.LE;<>IDLE - THE TASK THAT PERFORMS BACKGROUND FUNCTIONS.
.END LIST
(^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:
.LIST
.LE;<>>S - SYMBOL DEFINITIONS COMMON TO MANY ^DIGITAL
^EQUIPMENT ^CORPORATION PRODUCTS.
.LE;<>DN61D - PARAMETERS FOR THE <>DN61-DA AND <>DN61-DB<>.
.LE;<>DN61S - PARAMETERS FOR THE <>DN61-SA AND <>DN61-SB<>.
.LE;<>DN61B<> - PARAMETERS FOR THE <>DN61-BA<> AND <>DN61-BB<>.
.LE;<>DN62S<> - PARAMETER FOR THE <>DN62S
.LE;<>DN64A - PARAMETERS FOR THE <>DN64-AA AND <>DN64-AB<>.
.LE;<>MACROS - SOME USEFUL <>PDP-11 MACROS.
.LE;<>DEFINE - DEFINITIONS FOR THE <>DN60<>.
.LE;<>MININT - "MINOR" INTERRUPT ROUTINES.
.LE;<>INIT2 - SECTION 2 OF INITIALIZATION.
.LE;<>STGMAN - SUBROUTINES TO MANAGE "FREE STORAGE".
.LE;<>QUEING - SUBROUTINES TO SEND AND RECEIVE INTER-TASK
DATA.
.LE;<>DQ11 - SUBROUTINES FOR DRIVING THE <>DQ11<>'S.
.LE;<>DUP11 - SUBROUTINES FOR DRIVING THE <>DUP11<>'S.
.LE;<>KMC11 - SUBROUTINES FOR DRIVING THE <>KMC11<>/<>DUP11<>
COMBINATION.
.LE;<>MSGHDL - SUBROUTINES FOR PROCESSING "MESSAGES".
.LE;<>DISPAT - THE TASK DISPATCHER.
.LE;<>BSC - THE <>BSC TASK.
.LE;<>DL10 - THE <>PDP-10 COMMUNICATIONS TASK, USING A <>DL10<>.
.LE;<>DTE10 - THE <>PDP-10 COMMUNICATIONS TASK, USING A <>DTE20<>
ON THE <DEC<SYSTEM-10.
.INDEX <DEC<SYSTEM-10
.LE;<>DTE20 - THE <>PDP-10 COMMUNICATIONS TASK, USING A <>DTE20<>
ON THE <DECSYSTEM-20.
.INDEX <DECSYSTEM-20
.LE;<>XLHASP - THE <HASP ^MULTILEAVING TRANSLATION, COMPRESSION AND DECOMPRESSION TASKS.
.INDEX <HASP ^MULTILEAVING
.LE;<>XL3780 - THE <IBM 3780/2780 TRANSLATION AND BACKGROUND TASKS.
.INDEX <IBM 3780
.INDEX <IBM 2780
.LE;<>INITDQ - INITIALIZATION FOR THE <>DQ11<>'S.
.LE;<>INITUP - INITIALIZATION FOR THE <>DUP11<>'S AND <>KMC11<>'S.
.LE;<>MDCODE - A BINARY IMAGE OF THE <>KMC11<> MICROCODE.
.LE;<>INIT1 - SECTION 1 OF INITIALIZATION.
.LE;<>CHK11 - ONCE-ONLY HARDWARE TESTING.
.END LIST
^THIS DOCUMENT WILL DISCUSS EACH OF THESE SECTIONS. ^FIRST,
HOWEVER, IT IS APPROPRIATE TO INTRODUCE THE DATA STRUCTURES.
.CHAPTER 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.
.HL 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.
.HL 1 ^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.
.HL 1 ^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.
.HL 1 ^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 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.
.HL 1 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.
.HL 1 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:
.B 1;.LM +9;.TS 7;.I -9
<R0 POINTS TO THE CURRENT MESSAGE OR CHUNK
.I -9
<R1 CONTAINS THE CURRENT CHARACTER
.I -9
<R2 CONTAINS A CHARACTER COUNT
.I -9
<R3 POINTS TO THE <>CSR> FOR THE CURRENT <>DQ11<>/<>DUP11<>
OR TO THE CURRENT <>KMC11<> SILO
.I -9
<R4 POINTS TO THE CURRENT <>LCB>
.I -9
<R5 POINTS TO THE CURRENT <>TCB> (^WHEN IN A TASK, ALWAYS
POINTS TO THAT TASK'S <>TCB>.)
.I -9
<R6 ALWAYS POINTS TO THE CURRENT STACK
.B 1;.LM -9
^WHEN THE FUNCTION LISTED FOR A REGISTER IS NOT NEEDED,
THE REGISTER IS FREE TO BE USED FOR OTHER PURPOSES.
^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 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.
.HL 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.
.HL 1 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.
.HL 1 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<>".
.HL 1 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 SECTION "<>MININT<>"
^THIS SECTION CONTAINS THE MINOR INTERRUPTS
AND MISCELLANEOUS SUBROUTINES.
.HL 1 MINOR INTERRUPTS
^THE MINOR INTERRUPTS ARE AS FOLLOWS:
.LIST
.LE;>^PARITY> ERROR
.LE;^BUS TRAP
.LE;^ILLEGAL INSTRUCTIONS, WHICH ARE:
^INVALID INSTRUCTIONS,
<IOT INSTRUCTION,
AND <EMT INSTRUCTION.
.LE;^TRACE TRAP:
<>BPT> INSTRUCTION
AND ^T-BIT TRAP.
.LE;^CLOCK
.LE;^POWER ^FAILURE
.LE;^UNKNOWN
.END LIST
^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.
.HL 1 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 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.
.HL 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.
.HL 1 <>INITDQ
<>INITDQ CONSISTS OF A SUBROUTINE CALLED BY <>CHK11 TO
TEST THE <>DQ11<>'S.
.HL 1 <>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<>.
.HL 1 <>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 <>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 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.)
.HL 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.
.HL 1 <>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:
.LIST
.LE;^TO SAVE TIME, THE FREE LIST IS NOT SORTED.
.LE;^INTERRUPT ROUTINES MAY OBTAIN A CHUNK AFTER THIS SUBROUTINE
DECIDES IT NEEDS IT BUT BEFORE IT GETS IT.
.END LIST
<>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.
.HL 1 <>FRESTG>
^THIS SUBROUTINE RETURNS A BLOCK OF STORAGE OBTAINED BY
<>GETSTG> TO THE FREE LIST BY BREAKING IT UP INTO CHUNKS AND
CALLING <>FRECHK>.
.HL 1 <>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.
.HL 1 <>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 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.
.HL 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.
.HL 1 <>DEQMSG>
^THIS SUBROUTINE OBTAINS FOR A TASK THE OLDEST MESSAGE SENT
TO IT.
.HL 1 <>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.
.HL 1 <>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.
.HL 1 <>DEQCHK>
^THIS SUBROUTINE OBTAINS FOR A TASK THE OLDEST CHUNK SENT
TO IT. ^THE ALGORITHM IS COMPLICATED BY TWO FACTORS:
.LIST
.LE;^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.
.LE;^FOR EFFICIENCY, A CHUNK CONTAINS ONLY ONE LINK,
SO THE LIST CAN BE LINKED ONLY ONE WAY.
.END LIST
.CHAPTER 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.
.HL 1 DRIVING SUBROUTINES
^THE DRIVING SUBROUTINES ARE AS FOLLOWS:
.LIST
.LE;<>DQINIT - INITIALIZES THE LINE DRIVER.
.LE;<>DQREAD> - CONDITIONS THE LINE DRIVER FOR INPUT.
.LE;<>DQWRIT> - CONDITIONS THE LINE DRIVER TO OUTPUT A DATA MESSAGE.
.LE;<>DQCNTL> - CONDITIONS THE LINE DRIVER TO OUTPUT A CONTROL MESSAGE.
.LE;<>DQINWQ<> - CHECKS FOR MORE CHARACTERS TO BE PROCESSED.
.LE;<>DQKILL<> - TERMINATES ANY LINE DRIVER ACTIVITY.
.END LIST
^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,
.INDEX <IBM 360
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.
.HL 1 ^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 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:
.B 1;.TS 9,17,25,33,41
^^
# MOV CHFST,R0 ;FIRST CHUNK ON FREE LIST
.BREAK
# CMP R0,CHLST ;ONLY ONE CHUNK LEFT?
.BREAK
# BEQ ERROR ;YES, OUT OF CHUNKS
.BREAK
# MOV (R0),R1 ;NO, GET NEXT CHUNK
.BREAK
# BIC _#1,R1 ;ZAP FREE FLAG
.BREAK
# MOV R1,CHFST ;NEXT IS NOW FIRST CHUNK
.BREAK
# CLR (R0) ;CLEAR "FREE" BIT
.BREAK
# # # # ;#AND FORWARD POINTER
.BREAK
# CLR 2(R1) ;CLEAR BACK POINTER
.BREAK
# DEC CHFREC ;ONE FEWER FREE CHUNK
\\
.B 1
^R0 NOW CONTAINS A POINTER TO THE CHUNK OBTAINED FROM
THE FREE LIST.
.HL 1 SUBROUTINES FOR MODEM SIGNALS
^THREE SUBROUTINES ARE USED TO MANIPULATE MODEM SIGNALS:
.HL 2 <>DQDTR0<>
^THIS SUBROUTINE CLEARS ^DATA ^TERMINAL ^READY (<>DTR<>).
.HL 2 <>DQDTR1<>
^THIS SUBROUTINE SETS ^DATA ^TERMINAL ^READY (<>DTR<>).
.HL 2 <>DQMDMS<>
^THIS SUBROUTINE RETURNS THE VALUES OF <>DTR<> AND <>DSR<>.
.HL 1 <>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.
.HL 1 ^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.
^ON THE <>KMC11<>/<>DUP11<>, THIS SUBROUTINE ALSO OPERATES
THE KEEP-ALIVE COUNTERS.
.HL 1 CONTROL MESSAGES
^THE CONTROL MESSAGES ARE THE FIXED MESSAGES USED BY <>BSC<>
TO ACKNOWLEDGE MESSAGES, REQUEST RETRANSMISSION,
DELAY, AND SO ON.
.CHAPTER 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.
.TS 5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100
^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.
.HL 1 <>KMC11 CONTROL BLOCK
^THE <>KMC11 ^CONTROL ^BLOCK LOOKS AS FOLLOWS (ONE PER <>KMC11<>):
.SKIP 1
.LM +30
.TS 15,30
.INDENT -25;OFFSET MEANING
.SKIP 1
.I -25;0 11 FLAGS BIT 0 SET = <>PDP-11 RUNNING. ^SET ON STARTUP, CLEARED ON CRASH.
.BREAK
BIT 4 = ACTIVE TOGGLE
.BREAK
BITS 1-3 AND 5-15 UNUSED
.I -25;2 <KMC FLAGS BIT 0 SET = <>KMC11 RUNNING
.BREAK
BIT 4 = ACTIVE RESPONSE
.BREAK
BITS 1-3 AND 5-15 = UNUSED
.INDENT -25;4 11-ALIVE COUNTED BY THE <>PDP-11 ONCE A SECOND
.INDENT -25;6 <>KMC11 ALIVE COUNTED BY THE <>KMC11 ONCE A SECOND
.INDENT -25;10 <>LCB 0 POINTER TO FIRST <>LCB
.INDENT -25;12 <>LCB 1 POINTER TO SECOND <>LCB
.INDENT -25;14 <>LCB 2 POINTER TO THIRD <>LCB
.INDENT -25;16 <>LCB 3 POINTER TO FOURTH <>LCB
.LM -30
.HL 1 LINE CONTROL BLOCK (<>LCB<>)
^THE FIRST WORD OF EACH LINE CONTROL BLOCK (<>LCB<>) HAS THE FOLLOWING
FLAGS:
.SKIP 1
.LM +15;.RM -5
.SKIP 1
.INDENT -10;BIT MEANING
.SKIP 1
.INDENT -10;12 KILL COMPLETE (SET BY <>KMC11<>)
.INDENT -10;9 RECEIVER RUNNING
.INDENT -10;8 TRANSMITTER RUNNING
.INDENT -10;7 ERROR HAS BEEN DETECTED BY THE <>KMC11
.INDENT -10;4 TRANSMISSION IS OF A CONTROL MESSAGE
.INDENT -10;1 FUNCTION COMPLETE (SET BY <>KMC11<>)
.INDENT -10;0 KILL
.LM -15;.RM +5
^THE FOLLOWING OFFSETS INTO THE <>LCB ARE RELAVENT TO THE <>KMC11<>:
.SKIP 1
.LM +15;.RM -5
.INDENT -10;OFFSET MEANING
.SKIP 1
.INDENT -10;4 ADDRESS OF <>DUP11<>'S <>CSR
.INDENT -10;10 POINTER TO DATA MESSAGE TO BE SENT
.INDENT -10;12 POINTER TO CONTROL MESSAGE TO BE SENT
.INDENT -10;14 LENGTH OF CONTROL MESSAGE TO BE SENT
.INDENT -10;16 POINTER TO INPUT SILO CONTROL BLOCK
.LM -15;.RM +5
.TEST PAGE 20
.HL 1 SILO CONTROL BLOCK (<>SCB<>)
^THE INPUT ^SILO ^CONTROL ^BLOCK (<>SCB<>) IS FORMATTED AS FOLLOWS:
.LM +30;.SKIP 1
.INDENT -25;OFFSET MEANING
.SKIP 1
.INDENT -25;0 SILO FLAGS BIT 0 SET = GIVE AN <XX0 INTERRUPT ON NEXT CHANGE OF THE SILO POINTER
.SUBINDEX <KMC11>^X^X0#INTERRUPT
.BREAK
BIT 1 SET = SILO FULL
.BREAK
BIT 2 SET = SILO HAS OVERFLOWED
.BREAK
BIT 4 SET = WARNING LEVEL REACHED
.BREAK
BIT 7 SET = <>KMC11 HAS FETCHED THE POINTERS BELOW
.INDENT -25;2 SILO POINTER NEXT CHARACTER GOES HERE
.INDENT -25;4 SILO WARNING GIVE THE <>PDP-11 AN <XX0 INTERRUPT
.SUBINDEX <KMC11>^X^X0#INTERRUPT
WHEN THIS IS REACHED AND SET BIT 4 IN THE SILO FLAGS
.INDENT -25;6 SILO LIMIT MAXIMUM SIZE OF SILO. GIVE
THE <>PDP-11 AN <XX0 INTERRUPT WHEN THIS IS REACHED AND
.SUBINDEX <KMC11>^X^X0#INTERRUPT
SET BIT 1 IN THE SILO FLAGS.
.LM -30
.HL 1 <>KMC11 INTERRUPTS
^THE <>KMC11 WILL INTERRUPT THE <>PDP-11 FOR THE FOLLOWING REASONS:
.LM +15;.RM -5;.SKIP 1
.INDENT -10;VECTOR REASON
.SKIP 1
.INDENT -10;<XX0 SILO NON-EMPTY
.SUBINDEX <KMC11>^X^X0#INTERRUPT
.INDENT -10;<XX4 FUNCTION COMPLETE
.SUBINDEX <KMC11>^X^X4#INTERRUPT
.INDENT -10;<XX4 ERROR
.SUBINDEX <KMC11>^X^X4#INTERRUPT
.LM -15;.RM +5
^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.
.TEST PAGE 30
.HL 1 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".
.TS 5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80
.TEST PAGE 20
.HL 2 SECTION ^A: ^INITIALIZATION
.LM +10
.SKIP 1
.INDENT -5;1. ^VERIFY THAT EACH LOCATION OF MEMORY CAN CONTAIN
ALL ONES AND ALL ZEROS.
.SKIP 1
.INDENT -5;2. ^WAIT FOR <>BSEL2 AND <>BSEL3 TO BE SET NON ZERO BY
THE <>PDP-11<>.
.SKIP 1
.INDENT -5;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.
.SKIP 1
.INDENT -5;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.
.SKIP 1
.INDENT -5;5. ^SET THE TIMER COUNTER (SCRATCH PADS <>SP.TCL AND
<>SP.TCH<>) TO 20.
.SKIP 1
.INDENT -5;6. ^ENTER THE <IDLE LOOP.
.LM -10
.TEST PAGE 20
.HL 2 SECTION ^B: ^IDLE ^LOOP
.SKIP 1
.LM +10
.I -5;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:
.LM +5;.SKIP 1
.I -5;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.
.SKIP 1
.I -5;B. ^IF BIT <>LA.XMT IS SET FETCH THE <>DUP11 TRANSMIT STATUS
AND IF BIT 7 IS SET (TRANSMIT DONE) GO TO ^SECTION ^E.
.SKIP 1
.I -5;C. ^GO TO STEP 1.
.LM -5;.SKIP 1
.I -5;2. ^FETCH THE <>PDP-11 FLAGS FROM THE <>KMC11 ^CONTROL ^BLOCK
IN THE <>PDP-11<>. (^LAST <>NPR<>)
.SKIP 1
.I -5;3. ^IF THE <>PDP-11 FLAGS (BITS 0-7) HAVE CHANGED, GO
TO ^SECTION ^C.
.SKIP 1
.I -5;4. ^WAIT FOR THE 50 MICROSECOND TIMER TO SET IN
THE ^MISCELLANEOUS ^REGISTER.
.SKIP 1
.I -5;5. ^READ THE ^MISCELLANEOUS ^REGISTER AND IF <BUS <RQ
(BIT 7) IS SET GO TO STEP 9.
.SKIP 1
.I -5;6. ^IF THE <>KMC11<>'S "<BR CYCLE WANTED ON <XX0" FLAG
.SUBINDEX <KMC11>^X^X0#INTERRUPT
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.
.SKIP 1
.I -5;7. ^IF THE <>KMC11<>'S "<BR CYCLE WANTED ON <XX4" FLAG
.SUBINDEX <KMC11>^X^X4#INTERRUPT
IS SET (<>SPF.X4 IN <>SP.FLG<>) SET <BUS <RQ AND <XX4 IN THE ^MISCELLANEOUS
.SUBINDEX <KMC11>^X^X4#INTERRUPT
^REGISTER AND CLEAR <>SPF.X4 IN <>SP.FLG<>.
.SKIP 1
.I -5;8. ^IF EITHER OF THE <>KMC11<>'S "<BR CYCLE WANTED
ON <XX0 OR <XX4" FLAGS WERE SET GO TO STEP 1.
.SUBINDEX <KMC11>^X^X4#INTERRUPT
.SUBINDEX <KMC11>^X^X0#INTERRUPT
.SKIP 1
.I -5;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.
.LM -10
.HL 2 SECTION ^C: <>PDP-11 ^FLAGS ^HAVE ^CHANGED
.SKIP 1
.LM +10
.I -5;1. ^FETCH THE <>PDP-11 FLAGS FROM THE <>KMC11 ^CONTROL
^BLOCK IN THE <>PDP-11<>. (^NOT LAST <>NPR<>)
.SKIP 1
.I -5;2. ^SAVE A COPY OF THE <>PDP-11 FLAGS IN A <SP.
.SK 1;.I -5;3. ^IF THE <>PDP-11 RUNNING BIT (BIT 0) IN THE <>PDP-11
FLAGS IS CLEAR GO TO ^SECTION ^G.
.SK 1;.I -5;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.
.SK 1;.I -5;5. ^CHECK THE FOUR ^LINE ^CONTROL ^BLOCKS (<>LCB<>) IN
THE <>PDP-11 AS FOLLOWS:
.SK 1
.LM +5
.I -5;A. ^FETCH THE <>LCB POINTER FROM THE <>KMC11 ^CONTROL BLOCK
(^NOT LAST <>NPR<>)
.SK 1;.I -5;B. ^IF THE POINTER IS ZERO GO TO STEP 5J.
.SK 1;.I -5;C. ^SAVE A COPY OF THE <>LCB POINTER IN THE <>KMC11
^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.
.SK 1;.I -5;D. ^FETCH THE <>LCB STATUS (^NOT LAST <>NPR<>)
.SK 1;.I -5;E. ^IF ^KILL WANTED (BIT 0) GO TO STEP 9.
.SK 1;.I -5;F. ^IF ^FUNCTION ^COMPLETE GO TO STEP 5J.
.SK 1;.I -5;G. ^IF THE LINE IS ACTIVE (BIT <>LA.ACT SET IN <>L.ACT<>) GO TO
STEP 5J.
.SK 1;.I -5;H. ^IF ^WRITE WANTED (BIT 8) GO TO STEP 15.
.SK 1;.I -5;I. ^IF ^READ WANTED (BIT 9) GO TO STEP 17.
.SK 1;.I -5;J. ^GO DO NEXT <>LCB<>. ^IF DONE ALL FOUR THEN STEP 6.
.LM -5
.SK 1;.I -5;6. ^COPY THE <>PDP-11 FLAGS BIT 4 INTO <>KMC11 FLAGS
BIT 4 AND STORE IN THE <>KMC11 ^CONTROL ^BLOCK. (^NOT ^LAST <>NPR<>)
.SK 1;.I -5;7. ^CLEAR BIT 1 OF <>KMC11 FLAGS AND STORE IN THE
<>KMC11 ^CONTROL ^BLOCK IN THE <>PDP-11<>.
.SK 1;.I -5;8. GO TO <IDLE (^SECTION ^B)
.SK 1;.I -5;9. [^HERE FOR KILL] ^IF ^KILL ^COMPLETE IS SET (BIT 12)
IN THE <>LCB STATUS GO TO STEP 5J.
.SK 1;.I -5;10. ^SET KILL COMPLETE (BIT 12) IN THE <>LCB STATUS WORD
IN THE <>PDP-11<>. (^LAST <>NPR<>)
.SK 1;.I -5;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<>.
.SK 1;.I -5;12. ^CLEAR THE ^ACTIVITY WORD <>L.ACT IN THE <>KMC11
^LINE BLOCK.
.SK 1;.I -5;13. ^FLAG THAT WE WANT A <BUS <RQ ON <XX4 BY
.SUBINDEX <KMC11>^X^X4#INTERRUPT
SETTING <>SPF.X4 IN <>SP.FLG<>.
.SK 1;.I -5;14. ^GO TO <IDLE (^SECTION ^B).
.SK 1;.I -5;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<>)
.SK 1;.I -5;16. ^GO TO <IDLE (^SECTION ^B).
.SK 1;.I -5;17. [^HERE IF ^READ ^WANTED] ^SETUP FOR READING AND FLAG THE
LINE IS ACTIVE BY SETTING <>LA.ACT IN <>L.ACT<>.
(^LAST <>NPR<>)
.SK 1;.I -5;18. ^GO TO <IDLE (^SECTION ^B).
.LM -10
.TEST PAGE 20
.HL 2 SECTION ^D: ^RECEIVER ^DONE
.LM +10
.SK 1;.I -5;1. ^FETCH A CHARACTER FROM THE <>DUP11 ^RECEIVER ^BUFFER.
.SK 1;.I -5;2. ^IF THE ^ERROR BIT (BIT 15) IS SET GO TO STEP 20.
.SK 1;.I -5;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.).
.SK 1;.I -5;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.)
.SK 1;.I -5;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.
.SK 1;.I -5;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.
.SK 1;.I -5;7. ^FETCH THE POINTER TO THE SILO FROM THE FROM THE LINE BLOCK IN THE <>KMC11<>.
.SK 1;.I -5;8. ^PUT IN THE <>KMC11<>'S ^OUTPUT <BA REGISTER.
.SUBINDEX <KMC11>^B^A#REGISTER
.SK 1;.I -5;9. ^INCREMENT THE SILO POINTER BY 2 AND STORE IN <>KMC11
MEMORY.
.SK 1;.I-5;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<>)
.SK 1;.I-5;11. ^STORE THE INCREMENTED SILO POINTER IN THE <>SCB<>.
(^LAST <>NPR<>)
.SK 1;.I -5;12. ^IF THE WARNING LEVEL REACHED BIT (BIT 4) IS SET IN
THE SILO FLAGS GO TO STEP 14.
.SK 1;.I -5;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.
.SK 1;.I -5;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.
.SK 1;.I -5;15. ^IF THE <>PDP-11 DOESN'T WANT A <XX0 INTERRUPT (BIT 0
.SUBINDEX <KMC11>^X^X0#INTERRUPT
CLEAR) GO TO STEP 17.
.SK 1;.I -5;16. ^FLAG THAT WE WANT A <XX0 INTERRUPT BY SETTING
.SUBINDEX <KMC11>^X^X0#INTERRUPT
<>SPF.X0 IN <>SP.FLG AND CLEAR BIT 0 IN THE <>KMC11 COPY OF THE SILO FLAGS.
.SK 1;.I -5;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<>)
.SK 1;.I -5;18. ^GO TO <IDLE. (^SECTION ^B)
.SK 1;.I -5;19. [^HERE IF THE ^SILO IS FULL] ^SET BIT 2 IN THE
SILO FLAGS AND STORE IN THE <>PDP-11<>.
.SK 1;.I -5;20. [^HERE TO ^KILL THE ^RECEIVER] ^CLEAR ^RECEIVER ^ENABLE
IN THE <>DUP11 ^RECEIVE ^STATUS REGISTER. (^NOT LAST <>NPR<>)
.SK 1;.I -5;21. ^ZERO THE ACTIVITY WORD FOR THE LINE. (<>L.ACT<>)
.SK 1;.I -5;22. ^SET <>KMC11 ^ERROR AND ^FUNCTION ^COMPLETE (BITS 1 AND 7)
IN THE <>LCB STATUS. (^LAST <>NPR<>)
.SK 1;.I -5;23. ^FLAG THAT WE WANT A <XX4 INTERRUPT BY SETTING
.SUBINDEX <KMC11>^X^X4#INTERRUPT
<>SPF.X4 IN <>SP.FLG<>.
.SK 1;.I -5;24. ^GO TO <IDLE (^SECTION ^B).
.LM -10
.TEST PAGE 20
.HL 2 SECTION ^E: ^TRANSMIT ^DONE
.LM +10
.SK 1;.I -5;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.
.SK 1;.I -5;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).
.SK 1;.I -5;3. ^IF THE POINTER POINTS TO AN ODD ADDRESS GO TO STEP 7.
.SK 1;.I -5;4. ^FETCH 2 CHARACTERS FROM THE CHUNK IN <>PDP-11 MEMORY
USING THE POINTER.
.SK 1;.I -5;5. ^SAVE THE CHARACTER IN THE HIGH BYTE (ODD ADDRESS) IN
THE LINE BLOCK (<>L.CHR<>).
.SK 1;.I -5;6. ^GO TO STEP 8.
.SK 1;.I -5;7. ^FETCH THE CHARACTER FROM THE LINE BLOCK (<>L.CHR<>)
.SK 1;.I -5;8. ^PUT THE CHARACTER IN THE <>DUP11 ^TRANSMIT ^BUFFER.
.SK 1;.I -5;9. ^INCREMENT THE <>KMC11<>'S COPY OF THE DATA
POINTER (<>L.DPNT<>).
.SK 1;.I -5;10. ^DECREMENT THE <>KMC11<>'S COPY OF THE DATA COUNT.
.SK 1;.I -5;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.
.SK 1;.I -5;12. ^FETCH THE <>KMC11 COPY OF THE POINTER TO
THE NEXT CHUNK (<>L.CPNT<>) AND IF ZERO GO TO STEP 21.
.SK 1;.I -5;13. ^FETCH THE POINTER TO THE NEXT CHUNK+1 AND SAVE A
COPY IN <>KMC11 MEMORY (<>L.CPNT<>).
.SK 1;.I -5;14. ^FETCH THE DATA COUNT FROM THE NEXT CHUNK AND IF
ZERO GO TO STEP 12.
.SK 1;.I -5;15. ^SAVE A COPY OF THE DATA COUNT IN <>KMC11 MEMORY (<>L.DCNT<>).
.SK 1;.I -5;16. ^SAVE A COPY OF THE POINTER TO THE DATA IN THE NEXT
CHUNK IN <>KMC11 MEMORY (<>L.DPNT<>).
.SK 1;.I -5;17. ^GO TO <IDLE (^SECTION ^B).
.SK 1;.I -5;18. ^REMOVED
.SK 1;.I -5;19. ^REMOVED
.SK 1;.I -5;20. ^REMOVED
.SK 1;.I -5;21. [^HERE BECAUSE ^TRANSMISSION IS ^ENDING]
^SET <>TEOM (BIT 9) IN THE <>DUP11 ^TRANSMIT ^DATA ^BUFFER.
.SK 1;.I -5;22. ^CLEAR <>SEND (BIT 4) IN THE <>DUP11 ^TRANSMIT ^STATUS REGISTER.
.SK 1;.I -5;23. ^FLAG THE TRANSMISSION IS ENDING BY SETTING BIT
<>LA.XME IN <>L.ACT<>.
.SK 1;.I -5;24. ^GO TO <IDLE (^SECTION ^B).
.SK 1;.I -5;25. [^HERE BECAUSE TRANSMISSION HAS ENDED]
^SET ^FUNCTION ^COMPLETE
(BIT 1) IN THE <>LCB STATUS. (^NOT LAST <>NPR<>)
.SK 1;.I -5;26. ^IF A ^READ IS WANTED (BIT 9 SET <>LCB STATUS)
GO TO STEP 28.
.SK 1;.I -5;27. ^GO TO ^SECTION ^C STEP 13.
.SK 1;.I -5;28. ^SETUP FOR A ^READ BY CLEARING <>LA.XMT AND <>LA.CM
IN THE ACTIVITY WORD <>L.ACT<>.
.SK 1;.I -5;29. ^SET ^RECEIVER ^ENABLE IN THE <>DUP11 ^RECEIVE ^STATUS
REGISTER. (^LAST <>NPR<>)
.SK 1;.I -5;30. ^GO TO ^SECTION ^C STEP 13.
.LM -10
.TEST PAGE 20
.HL 2 SECTION ^F: ^TIMER HAS EXPIRED (USUALLY ONE SECOND)
.LM +10
.SK 1;.I -5;1. ^SET THE TIMER COUNTER TO 20000 (DECIMAL).
.SK 1;.I -5;2. ^REMOVED
.SK 1;.I -5;3. ^INCREMENT THE <>KMC11 ^ALIVE COUNTER IN <>KMC11 MEMORY,
AND STORE IN THE <>KMC11 ^CONTROL ^BLOCK.
.SK 1;.I -5;4. ^IF BITS 0, 1, AND 2 OF <KMC ALIVE ARE ALL 0, GO
TO STEP 7.
.SK 1;.I -5;5. ^REMOVED.
.SK 1;.I -5;6. ^GO TO ^SECTION ^B.
.SK 1;.I -5;7. [^HERE EVERY 8 SECONDS] ^FETCH 11 ^ALIVE FROM
THE <>KMC11 ^CONTROL ^BLOCK.
.SK 1;.I -5;8. ^IF THE SAME AS LAST TIME (OLD VALUE STORED IN
<>KMC11 MEMORY) GO TO ^SECTION ^G.
.SK 1;.I -5;9. ^STORE THIS VALUE OF 11 ^ALIVE AS THE OLD VALUE
IN <>KMC11 MEMORY.
.SK 1;.I -5;10. ^GO TO <IDLE (^SECTION ^B)
.LM -10
.TEST PAGE 10
.HL 2 SECTION ^G: ^COME HERE WHEN SOMETHING IS ^WRONG
.LM +10
.SK 1;.I -5;1. ^CLEAR BIT 0 (<>KMC11 RUNNING) OF <>KMC11 FLAGS AND
STORE IN THE <>KMC11 ^CONTROL ^BLOCK. (^LAST <>NPR CYCLE)
.SK 1;.I -5;2. ^CLEAR BIT 7 IN <>BSEL1 AND BRANCH TO SELF.
.LM -10
.CHAPTER SECTION "<>MSGHDL<>"
^THIS SECTION CONTAINS SUBROUTINES WHICH MANIPULATE MESSAGES.
.HL 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.
.HL 1 <>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>.
.HL 1 <>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.
.HL 1 <>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 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<>.
.HL 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:
.LIST
.LE;^UPDATE EACH WAITING TASK'S TIMER.
.LE;^DO THE ONCE-A->JIFFY> LINE DRIVER FUNCTIONS
(SEE CHAPTER 8)
.LE;^DO THE ONCE-A->JIFFY> <>DL10> OR <>DTE20> FUNCTIONS
(SEE CHAPTERS 13 AND 14)
.LE;^ONCE A SECOND:
.LIST
.LE;^IF WE HAVE A <>DL10> OR <>DTE20>, DO THE ONCE-A-SECOND
<>DL10> OR <>DTE20> FUNCTIONS
(SEE CHAPTERS 13 AND 14)
.LE;^OTHERWISE, TRY TO BRING THE <>DL10> OR <>DTE20> ON LINE.
.END LIST
.END LIST
^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.
.HL 1 <>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.
.HL 1 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.
^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 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.
.HL 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.
.HL 2 <>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>.
.HL 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.
.HL 1 ^OUTPUT
^THE OUTPUT SUBSECTION IS THE SUBROUTINES
<>DQXMIT>, <>DQXRSP>, AND <>DQXNAV>.
.HL 2 <>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.
.HL 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.
.HL 2 <>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 >ABORT>ED 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.
.HL 1 ^INPUT
^THE INPUT SUBSECTION IS COMPRISED OF SEVERAL SUBROUTINES
LISTED BETWEEN <>DQRQIP> AND <>DQRBCC>. ^ONLY THE MOST IMPORTANT
OF THESE ARE DISCUSSED HERE.
.HL 2 <>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.
.HL 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 >ABORT>ED.
.HL 2 <>DQRPRP>
^THIS SUBROUTINE IS USED BY <>DQRECV> TO ACKNOWLEDGE A MESSAGE.
.HL 2 <>DQRNRP>
^THIS SUBROUTINE IS USED BY <>DQRECV> TO NEGATIVELY
ACKNOWLEDGE A MESSAGE. ^THIS WILL USUALLY CAUSE IT TO BE
SENT AGAIN.
.HL 2 <>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.
.HL 2 <>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.
.HL 2 <>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>".
.HL 1 ^SUBROUTINES
^THE FOURTH SUBSECTION CONTAINS THE SUBROUTINES USED BY
THE CODE DESCRIBED ABOVE. ^THE MOST IMPORTANT
SUBROUTINES ARE DESCRIBED.
.HL 2 <>CTLMSG>
^THIS SUBROUTINE SENDS A CONTROL MESSAGE SUCH AS <>ACK-0<> OR
<>NAK> AND INITIATES A READ FOR THE RESPONSE, UNLESS
REQUESTED NOT TO.
.HL 2 <>STOBCC>
^THIS SUBROUTINE STORES THE ACCUMULATED <>BCC> INTO
A MESSAGE.
.HL 2 <>DQABRO>
^THIS SUBROUTINE >ABORT>S THE OUTPUT STREAM.
.HL 2 <>DQABRI>
^THIS SUBROUTINE >ABORT>S THE INPUT STREAM.
.HL 2 <>DQSEOT>
^THIS SUBROUTINE CONDITIONALLY SENDS THE "<>EOT>"
CONTROL MESSAGE.
^IT DOES NOT READ ANY RESPONSE.
.HL 1 <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.
.HL 1 <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.
.HL 2 <>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.
.HL 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.
.HL 2 <>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.
.HL 2 <>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.
.HL 2 <>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.
.HL 2 <>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.
.HL 2 <>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..
.HL 2 <>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.
.HL 2 <>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.
.HL 2 <>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.
.HL 2 <>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.
.HL 2 <>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.
.HL 2 <>HSAWXL>
^THIS SUBROUTINE AWAKENS THE <>XLATE> TASK WHOSE DEVICE NUMBER IS IN <R1.
.HL 2 <>HSWALX>
^THIS SUBROUTINE AWAKENS ALL THE <>XLATE> TASKS
CONFIGURED ON THE LINE.
.HL 2 <>HSABRI>
^THIS SUBROUTINE ABORTS THE INPUT STREAM FOR A DEVICE.
.HL 2 <>HSABTI>
^THIS SUBROUTINE ABORTS INPUT STREAMS FOR ALL THE DEVICES
CONFIGURED ON THE LINE.
.HL 1 <>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>.
.HL 2 <>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.
.HL 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.
.HL 2 <>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.
.HL 2 <>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>.
.HL 2 <>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.
.HL 2 <>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.
.HL 2 <>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.
.HL 2 <>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.
.HL 2 <>HSCKTP>
^THIS SUBROUTINE CHECKS FOR TRANSPARENT MODE ON OUTPUT
AND INSERTS <>DLE> BEFORE A DATA <>DLE> OR <>SYN>.
.HL 2 <>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.
.HL 2 <>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.
.HL 2 <>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.
.HL 2 <>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.
.HL 2 <>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.
.HL 2 <>HSUNSP>
^THIS SUBROUTINE IS CALLED BY THE >HSDPG> SUBROUTINE
WHEN PERMISSION IS GRANTED FOR THE DEVICE.
TO ALLOW THE DEVICE STREAM TO CONTINUE.
.HL 2 <>HSABRO>
^THIS SUBROUTINE ABORTS THE OUTPUT STREAM FOR THE DEVICE.
.HL 2 <>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 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.
.HL 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.
.HL 2 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.
.HL 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 >ABORT>ED. ^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.
.HL 1 ^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.
.HL 1 <>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 <>STOPCODE><S.
.HL 1 ^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.
.HL 1 ^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>.
.HL 1 ^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.
^IF THE <>PDP-10> IS RELOADED, A FLAG IS SET SO THAT ALL
OUTSTANDING <>BSC> STREAMS WILL BE >ABORT>ED.
^THIS ONCE-A-SECOND SUBROUTINE ALSO SETS A FLAG
IN THE <>DL10> WINDOW TO REASSURE THE
<>PDP-10> THAT THE <>DN61> HAS NOT HALTED.
.HL 1 ^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.
.HL 2 <>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.
.HL 3 <>DLENDO>
^THIS SUBROUTINE DOES THE POST-COMMAND CLEAN UP.
<>DLENDO<> STORES <>DLXRST> AND <>DLXXFR> AND REQUESTS A <>PDP-10>
INTERRUPT.
.HL 3 <>DLDISP>
^THIS SUBROUTINE DOES THE DISPATCHING FOR THE COMMAND CODE.
<>DLDISP<> IS ALSO USED DURING THE PROCESSING OF SOME COMMANDS.
.HL 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>.
.HL 3 <>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.
.HL 3 <>DLPBYT>
^THIS SUBROUTINE STORES A BYTE THROUGH THE <>DL10> WINDOW.
<>DLPBYT<> ALSO OBSERVES THE COUNTERS IN <>DLXCBP>.
.HL 3 <>DLPWRD>
^THIS SUBROUTINE STORES A 16-BIT WORD THROUGH THE <>DL10> WINDOW.
<>DLPWRD<> WORKS BY CALLING <>DLPBYT>.
.HL 3 <>DLPSTR>
^THIS SUBROUTINE STORES A STRING OF WORDS THROUGH THE
<>DL10> WINDOW.
<>DLPSTR<> WORKS BY CALLING <>DLPWRD>.
.HL 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.
.HL 3 <>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 >ABORT>ED.
.HL 3 <>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.
.HL 3 <>DLTRDS>
^THIS SUBROUTINE PERFORMS THE "READ DEVICE STATUS" FUNCTION.
^THE STATUS INFORMATION IS OBTAINED FROM THE <>TCB> OF THE
TRANSLATE TASK.
.HL 3 <>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.
.HL 3 <>DLTRLS>
^THIS SUBROUTINE PERFORMS THE "READ LINE STATUS" FUNCTION.
<>DLTRLS<> COPIES DATA FROM THE <>LCB> TO THE <>PDP-10>.
.HL 3 <>DLTWLC>
^THIS SUBROUTINE PERFORMS THE "WRITE LINE COMMAND" FUNCTION.
<>DLTWLC<> DOES MOST OF ITS WORK BY CALLING SUBROUTINES.
^THESE SUBROUTINES ARE DESCRIBED BRIEFLY BELOW.
.HL 3 <>DLTRES>
^THIS SUBROUTINE PERFORMS THE "READ <>DN60> STATUS" FUNCTION.
<>DLTRES<> SIMPLY COPIES SOME DATA FROM THE <>GLOBAL<> AREA TO THE <>PDP-10>
USING <>DLPSTR>.
.HL 3 <>DLTWEC>
^THIS SUBROUTINE PERFORMS THE "WRITE <>DN60> COMMAND" FUNCTION.
<>DLTWEC<> IS A DUMMY, SINCE NO USE IS YET DEFINED FOR THIS FUNCTION.
.HL 3 <>DLTEXM>
^THIS SUBROUTINE PERFORMS THE "EXAMINE OF
A ELEVEN LOCATION" FUNCTION (#9).
.HL 3 <>DLTDEP>
^THIS SUBROUTINE PERFORMS THE "DEPOSIT IN ELEVEN MEMORY"
FUNCTION (#10) AND IS QUITE USEFUL FOR DEBUGGING.
.HL 3 <>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.
.HL 3 <>DLTWBN>
^THIS SUBROUTINE WILL BE SIMILAR TO THE WRITE DATA
WITH MODE CONSIDERATIONS SIMILAR TO ABOVE. (THIS FUNCTION
IS NOT YET IMPLEMENTED)
.HL 2 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 <>DLTL<NN> WHERE NN IS THE
NUMBER OF THE COMMAND. ^THE DEVICE SUBROUTINES ARE NAMED
<>DLTD<NN> 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.
.HL 3 <>DLDRAI>
^THIS SUBROUTINE DRAINS THE MESSAGE >QUEUE> FROM THE
TRANSLATE TASK. <>DLDRAI<> IS USED WHEN A MESSAGE STREAM IS >ABORT>ED.
.HL 3 <>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 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.
.HL 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.
.HL 1 <>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.
.HL 1 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".
.HL 1 ^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.
.HL 1 ^ONCE-^A-^JIFFY
^THIS SUBROUTINE (<>DSPDLT<>) IS A DUMMY SUBROUTINE PROVIDED
FOR COMPATABILITY WITH REST OF THE <>DN60<> SERIES SOFTWARE.
.HL 1 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.
.hl 1 ^task:
^MOST OF THE CODE IN THIS SECTION IS THE <>DTE20<> TASK WHICH CONSISTS
OF THREE DIFFERENT PARTS:
.LIST
.LE;^THE <>DTE20 ^TASK ^INTERFACE ^SUBROUTINES
.LE;^THE ^QUEUED ^PROTOCOL ^INTERFACE ^SUBROUTINES
.LE;^THE ^COMMAND ^INTERPRETER AND THEIR SUBROUTINES
.END LIST
^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.
.HL 2 <>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.
.HL 3 <>DTE10<>
^THE FOLLOWING PARAGRAPHS ARE RELEVANT IF THE
MODULE "<>DTE10.P11<>" HAS BEEN INCLUDED IN THE <>DN61<> ASSEMBLY.
.HL 4 <>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.
.HL 4 <>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.
.SKIP 1
<>DTSTHD<> = 2 ;WAITING FOR 11-DONE FOR HEADER
; DOORBELL AND 10-DONE INVALID
.SKIP 1
<>DTSTDD<> = 4 ; IS NOT USED.
.SKIP 1
<>DTSTIB = 6 ; WAITING FOR INDIRECT DOORBELL
(FOR IND. DATA) ; 11-DONE, 10-DONE ARE INVALID.
.SKIP 1
<>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.
.HL 4 <>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.
.HL 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.
.HL 4 <>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<>).
.HL 3 <>DTE20<>
^THE FOLLOWING
HOLDS IF "<>DTE20.P11<>" HAS BEEN INCLUDED IN <>DN64 ASSEMBLY.
.HL 4 ^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.
.SKIP 2
^THE FOLLOWING COMMENTS DESCRIBE THE STATES FOR THE STATE-
DRIVEN <>DTE<> PROCESSOR.
^ABBREVIATIONS USED IN THE DESCRIPTION BELOW ARE AS FOLLOWS:
.B 1;.LM 6;.I -6
<>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.
.B 1;.I -6
<>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.
.B 1;.I -6
<>ED<> - <>ED<> DATA. ^THIS IS THE INDIRECT MESSAGE
DESCRIBED BY THE <>EH<> MESSAGE ABOVE.
.B 1;.I -6
<>ACK<> - ACKNOWLEDGE. ^THIS MESSAGE ACKNOWLEDGES THE
RECEIPT AND PROCESSING OF THE LAST INDIRECT MESSAGE.
.B 1;.LM -6
^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.
^BELOW THE DESCRIPTION OF EACH STATE IS A BRIEF DESCRIPTION
OF THE
ACTION TAKEN WHEN THE APPROPRITE EVENT OCCURS.
.HL 4 ^STATE ^MACHINE "^A":
^STATE ^MACHINE
"^A" IS
DRIVEN BY 11-DONE INTERRUPTS AND BY DOORBELLS.
.B 1
.LM +4;.I -4
0:#WAITING FOR INITIAL DOORBELL. 11-DONE IS INVALID.
.LM +4;.I -2
READ <>FEH<> FOR <>EH<>.
.B 1;.LM -4;.I -4
2:#^WAITING FOR <>FEH<> FOR <>EH<>. ^DOORBELL IS INVALID.
.LM +4;.I -2
^IF DEVICE IS WRONG, GO TO STATE 34.
.I -2
^IF ALLOCATION MESSAGE, GO TO STATE 34.
.I -2
^OTHERWISE, READ <>EH<>.
.B 1;.LM -4;.I -4
4:#^WAITING FOR DOORBELL FOR <>EH<>. 11-DONE IS INVALID.
.LM +4;.I -2
^READ <>EH<>.
.B 1;.LM -4;.I -4
6:#^WAITING FOR <>EH<>. ^DOORBELL IS INVALID.
.LM +4;.I -2
SEND <>ACK<> ONLY IF AN <>ED<> TO COME. ^SET MACHINE ^B FROM STATE 0 TO 2.
.I -2
^IF THE FLAG <>DT10AK<> INDICATES THAT THERE IS NO <>ED<>, THEN SEND <>ACK<> + <>FEH<>, GO TO STATE
20, ELSE GO TO STATE 10.
.B 1;.LM -4;.I -4
10:#^WAITING FOR DOORBELL FOR <>FEH<> FOR <>ED<>.
11-DONE IS INVALID.
.LM +4;.I -2
^READ <>FEH<> FOR <>ED<>.
.B 1;.LM -4;.I -4
12:#^WAITING FOR <>FEH<> FOR <>ED<>. ^DOORBELL IS INVALID.
.LM +4;.I -2
^GO TO STATE 14.
.B 1;.LM -4;.I -4
14:#^WAITING FOR DOORBELL FOR <>ED<>. 11-DONE IS INVALID.
.LM +4;.I -2
^READ <>ED<>.
.B 1;.LM -4;.I -4
16:#^WAITING FOR <>ED<>. ^DOORBELL IS INVALID.
.LM +4;.I -2
^IF MACHINE "^B" IS AT STATE 4, SEND <>ACK<>+<>FEH<> AND SET
MACHINE "^B" TO STATE 10, THEN GO TO STATE 22.
.I -2
^IF MACHINE "^B" IS NOT AT STATE 4, GO TO STATE 20.
.B 1;.LM -4;.I -4
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.
.B 1;.I -4
22:#^WAITING FOR DOORBELL FOR <>ACK<> FOR <>EH<>.
11-DONE IS INVALID.
.LM +4;.I -2
^READ <>ACK<> FOR <>EH<>.
.B 1;.LM -4;.I -4
24:#^WAITING FOR <>ACK<> FOR <>EH<>. ^DOORBELL IS INVALID.
.LM +4;.I -2
^IF THE <>EH<> INICATES THAT NO <>ED<> WILL BE RETURNED,
AND MACHINE "^B" IS IN STATE 14, SET BOTH STATES TO ZERO.
.I -2
^IF MACHINE "^B" IS NOT IN STATE 14,
GO TO STATE 32.
.I -2
^IF THE <>EH<> INDICATES THAT AN <>ED<> WILL BE RETURNED,
AND MACHINE "^B" IS IN STATE 14,
SEND <>FEH<> FOR <>ED<>, SET MACHINE "^B" TO STATE 16
AND GO TO STATE 26.
.I -2
^IF MACHINE "^B" IS NOT IN STATE 14, JUST GO TO STATE 26.
.B 1;.LM -4;.I -4
26:#^WAITING FOR DOORBELL FOR <>ACK<> FOR <>ED<>.
11-DONE IS INVALID.
.B 1;.I -4
30:#^WAITING FOR <>ACK<> FOR <>ED<>. ^DOORBELL IS INVALID.
.LM +4;.I -2
^IF MACHINE "^B" IS IN STATE 22, SET THE STATES OF BOTH MACHINES
TO 0.
.I -2
^IF MACHINE "^B" IS NOT IN STATE 22, GO TO STATE 32.
.B 1;.LM -4;.I -4
32:#^GOT FINAL <>ACK<>. 11-DONE AND DOORBELL ARE INVALID.
.B 1;.I -4
34:#^IGNORING 11-DONE.
.LM +4;.I -2
^IF WE GET AN 11-DONE, IGNORE IT.
.I -2
^IF WE GET A DOORBELL, TREAT IT THE SAME AS FOR STATE 0.
.LM -8
.HL 4 ^STATE ^MACHINE "^B":
^STATE MACHINE "^B" IS DRIVEN BY 10-DONE.
.B 1;.LM +4;.I -4
0:#IDLE. 10-DONE IS INVALID.
.B 1;.I -4
2:#^WAITING FOR COMPLETION OF <>ACK<> FOR <>EH<> OR <>ACK<>+<>FEH<> .
.LM +4;.I -2
^IF MACHINE "^A" IS NOT IN STATE 20, JUST GO TO STATE 4.
.I -2
^IF MACHINE "^A" IS IN STATE 20, SET IT TO STATE 22.
.I -2
^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.
.I -2
^IF THE FLAG <>DT10AK<> INDICATES THAT AN <ED WILL NOT FOLLOW, SEND
AN <>EH<> AND GO TO STATE 10.
.B 1;.LM -4;.I -4
4:#^GOT COMPLETION OF <>ACK<> (OR <ACK + <FEH) FOR <>EH<>.
.LM +4;.I -2
10-DONE IS INVALID.
.B 1;.LM -4;.I -4
6:#^UNUSED STATE FOR NOW.
.B 1;.I -4
10:#^WAITING FOR COMPLETION OF <>ACK<> FOR <>ED<> +<>FEH<> FOR <>EH<>.
.LM +4;.I -2
^SEND <>EH<>.
.B 1;.LM -4;.I -4
12:#^WAITING FOR COMPLETION OF <>EH<>.
.LM +4;.I -2
^IF MACHINE "^A" IS IN STATE 26 THEN SEND <>FEH<> FOR <>ED<>
AND GO TO STATE 16.
.I -2
^IF MACHINE "^A" IS NOT IN STATE 26 THEN GO TO STATE 14.
.B 1;.LM -4;.I -4
14:#^WAITING FOR <>ACK<> FOR <>EH<>. 10-DONE IS INVALID.
.B 1;.I -4
16:#^WAITING FOR COMPLETION OF <>FEH<> FOR <>ED<>.
.LM +4;.I -2
^SEND <>ED<>.
.B 1;.LM -4;.I -4
20:#^WAITING FOR COMPLETION OF <>ED<>.
.LM +4;.I -2
^IF MACHINE "^A" IS IN STATE 32 THEN SET BOTH STATES TO 0,
OTHERWISE GO TO STATE 22.
.B 1;.LM -4;.I -4
22:#^WAITING FOR <>ACK<> FOR <>ED<>. 10-DONE IS INVALID.
.B 1;.LM -4
.HL 4 <>DLTXDN<>:
^THIS SUBROUTINE DECIDES WHAT TO DO WHEN A TO-10
INTERRUPT IS RECOGNIZED. ^IT IMPLEMENTS THE STATE MACHINE "^B" AS
DESCRIBED ABOVE.
.HL 4 <>DLELDN<>:
^THIS SUBROUTINE DECIDES WHAT TO
DO WHEN AN 11-DONE
INTERRUPT IS RECOGNIZED. ^IT IMPLEMENTS PART OF STATE
MACHINE "^A" DESCRIBED
ABOVE.
.HL 4 <>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".
.HL 4 <>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.
.HL 2 ^QUEUED ^PROTOCOL ^INTERFACE ^SUBROUTINES:
.HL 3 <>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<>.
.HL 3 <>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.
.HL 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<>.
.HL 3 <>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.
.HL 3 <>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.
.HL 3 <>DLSERR<>:
^THIS ROUTINE IS CALLED TO SET REJECT FLAGS
(3 IN <>DT10DF<>+1, AND <>DT11GW<>=-1) FOR CALLING ROUTINES TO SEE
.HL 3 <>DLSDLY<>:
^THIS ROUTINE IS CALLED TO FLAG "OPERATION
DELAYED: FOR CALLING ROUTINES TO SEE (2 IN <>DT10DF<>+1,
<>DT11GW<>=-1)
.HL 3 <>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.
.HL 3 <>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<>).
.HL 3 <>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.
.HL 2 FUNCTION DEPENDENT SUBROUTINES:
.HL 3 <>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.
.HL 4 <>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.
.HL 3 <>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.
.HL 3 <>DLTRLS<>:
^THIS SUBROUTINE PERFORMS THE "^READ
^LINE ^STATUS" FUNCTION. ^IT COPIES DATA FROM THE
^L^C^B INTO THE STATUS BLOCK WHICH IS PASSED ONTO THE TEN
AS AN INDIRECT DATA PACKET.
.HL 3 <>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.
.HL 4 <>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.
.HL 3 <>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.
.HL 3 <>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<>.
.HL 3 <>DLTWEC<>:
^THIS SUBROUTINE PERFORMS THE "^WRITE <>DN60<>
^COMMAND" FUNCTION <>DLTWEC<> IS A DUMMY SINCE NO USE IS YET
DEFINED FOR THIS FUNCTION.
.HL 4 <>DLTWS1<>:
^THIS SUBROUTINE IS CALLED FOR SETTING <>DN60<> STATUS - USE OF WHICH HAS NOT BEEN
DEFINED YET. ^ANY CALL TO IT SHOULD BE INVALID.
.HL 3 <>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.
.HL 3 <>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<>.
.HL 3 <>DLPWRD<>:
^THIS SUBROUTINE STORES A 16-BIT
WORD INTO THE BLOCK POINTED TO BY ^R2. <>DLPWRD<> WORKS
BY CALLING <>DLPBYT<>.
.HL 3 <>DLPSTR<>:
STORES A STRING OF WORDS IN THE AREA POINTED TO BY ^R2.
<>DLPSTR<> WORKS BY CALLING <>DLPWRD<>.
.HL 3 <>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.
.HL 2 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 <>DLTL<NN> WHERE NN IS THE
NUMBER OF THE COMMAND. ^THE DEVICE SUBROUTINES ARE NAMED
<>DLTD<NN> 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.
.HL 3 <>DLDRAI>
^THIS SUBROUTINE DRAINS THE MESSAGE >QUEUE> FROM THE
TRANSLATE TASK. <>DLDRAI<> IS USED WHEN A MESSAGE STREAM IS >ABORT>ED.
.HL 3 <>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.
.HL 1 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
.TEST PAGE 40
<>FEH<> DESCRIBED BELOW IS SENT TO THE TEN TO PRECEDE
(ALWAYS) THE "<>EH<>" OR "<>ED<>".
.B 2
<FEH <FORMAT:
.B 2
.LM +6
.NOFILL
----------------------------------------------
! ^COUNT OF BYTES IN HEADER (12 OCTAL) !
----------------------------------------------
! ^PROTOCOL ^FUNCTION ^CODE !
----------------------------------------------
! ^PROTOCOL ^DEVICE ^CODE !
----------------------------------------------
! <SPARE !
----------------------------------------------
! <FE_# (8-BITS) ! ^COUNT TO FOLLOW @ !
----------------------------------------------
.B 1
.LM -6
.FILL
.B 2
<NOTE1: ^THE <>ACK ^HEADER IS SIMILAR TO THE ABOVE WITH
^PROTOCOL ^FUNCTION BEING THE "^ACKNOWLEDGEMENT " FUNCTION
<>DTFSAK<>.
.B 2
<NOTE2: ^THE ^HEADER <>FEH IS SENT WITH BYTES SWAPPED TO
CORRECT DIRECTION OF TRANSFER SO THAT THE ^TEN OR <DECSYSTEM-20
.INDEX <DEC<SYSTEM-10
.INDEX <DECSYSTEM-20
RECEIVING IT DO NOT HAVE TO DO IT.
.B 2
<NOTE3: ^THE CHUNK SIZE HAS BEEN CHANGED TO 300 OCTAL BYTES
FOR THE <>DN64 AND <>DN61 PRODUCTS USING THE <>DTE20<>.
.CHAPTER 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.
.HL 1 THE <IBM 3780/2780 TRANSLATE TASK - <>XLATE<>
.INDEX <IBM 3780
.INDEX <IBM 2780
^THE TRANSLATE TASK IS RESPONSIBLE FOR TRANSLATING CHARACTER
SETS AND VERTICAL MOTION COMMANDS BETWEEN <>ASCII AS USED BY
THE <DEC<SYSTEM-10 AND <DECSYSTEM-20, AND <>EBCDIC AS USED BY
THE <IBM 3780, <IBM 2780 AND <IBM 360.
.INDEX <DEC<SYSTEM-10
.INDEX <DECSYSTEM-20
.INDEX <IBM 3780
.INDEX <IBM 2780
.INDEX <IBM 360
.HL 2 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>.
.HL 3 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
.INDEX <IBM 2780
TO 80 CHARACTERS WITH SPACES.
.HL 3 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
.INDEX <IBM 3780
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
.INDEX <IBM 3780
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< >OVERPRINT>ING IS IGNORED SINCE THIS PRINTER
.INDEX <IBM 2780
CANNOT >OVERPRINT>.
^THE FOLLOWING SUBROUTINES ARE USED BY <>XLASPR>. ^SOME OF THESE
ARE ALSO USED BY <>XLASCD>.
.LIST
.LE;<>XLASTF> - GO TO TOP OF FORM.
.LE;<>XLASSF> - SINGLE SPACE.
.LE;<>XLASSP> - OUTPUT A BLANK.
.LE;<>XLSNDL> - SEND A LINE TO THE <>BSC> TASK.
.END LIST
^IN ADDITION, <>XLSNDL> CALLS <>XLSNDM>, WHICH SENDS A MESSAGE
TO THE <>BSC> TASK, AND <>MSGSUP>, WHICH SETS UP THE <>BSC> MESSAGE.
.HL 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>.
.HL 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 <>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>.
.HL 3 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.
.HL 3 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
.INDEX <IBM 3780
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
.INDEX <IBM 3780
HORIZONTAL >TAB> STOPS. ^THIS FEATURE IS ALSO SIMULATED.
.HL 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
.INDEX <IBM 360
DECKS.
^THE FOLLOWING SUBROUTINES ARE USED BY <>XLIMSG>.
.LIST
.LE;<>XLITSP> - PROCESS A >TRANSPARENT> MESSAGE.
.LE;<>XLIPRS> - PROCESS AN "<>IRS>" CHARACTER IN PRINTER MODE.
^THIS CHARACTER SIGNALS THE END OF THE PRINT LINE.
.LE;<>XLCPUT> - WAIT IF THE TRANSLATE TASK HAS BEEN USING
AN EXCESSIVE AMOUNT OF <CPU TIME.
.LE;<>XLIPCR> - OUTPUT A CARRIAGE RETURN IN PRINTER MODE.
.LE;<>XLIPSP> - OUTPUT AN <>LP10 SINGLE SPACE, USING CARRIAGE
RETURN (IF NEEDED) FOLLOWED BY LINE FEED OR <>DC3>.
.LE;<>XLIPGS> - EXPAND COMPRESSED BLANKS USING "<>IGS>" >COMPRESSION>.
.LE;<>XLISHT> - SET HORIZONTAL >TAB> STOPS.
.LE;<>XLIPHT> - PROCESS A HORIZONTAL >TAB>, CONVERTING IT TO
BLANKS.
.END LIST
.HL 1 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.
.HL 1 ^TRANSLATE ^TABLES
^THERE ARE FOUR TRANSLATE TABLES USED BY <>XL3780<>.
.HL 2 <>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.
.HL 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
.INDEX <IBM 029
>KEYPUNCH> DIFFICULT TO USE: THE EXCLAMATION
POINT ON THE >KEYPUNCH> TRANSLATES TO <>ASCII> VERTICAL BAR, FOR
EXAMPLE.
.HL 2 <>ASCII> SPECIAL CHARACTER TABLE
^THIS TABLE IS USED FOR DISPATCHING WHEN TRANSLATING <>ASCII>
CONTROL CHARACTERS TO <>EBCDIC>.
.HL 2 <>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<>.
.HL 1 ^CARRIAGE ^CONTROL
^THE CARRIAGE CONTROL TABLE IS USED TO SIMULATE AN <>LP10
USING THE <IBM 3780<'S PRINTER. ^IT IS AN IMAGE OF THE
.INDEX <IBM 3780
<>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 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.
.HL 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.
.HL 1 <>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
.HL 2 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.
.HL 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
.INDEX <IBM <HASP
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
.INDEX <IBM <HASP
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>.
.LIST
.LE;<>XLHSTF> - GO TO TOP OF FORM.
.LE;<>XLHSSF> - SINGLE SPACE.
.END LIST
^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.
.HL 3 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:
.LIST
.LE;<>XHSNDL> - SEND A LINE TO THE <>BSC> TASK.
,LE;<>HSCMPS> - COMPRESS LINE AND PUT IN MESSAGE BUFFER
.LE;<>HSCMPO> - PUT LINE IN MESSAGE WITHOUT COMPRESSING
.LE;<>XHMSTP> - SET UP MESSAGE FOR RECEIVING COMPRESSED RECORDS.
.LE;<>XLHSON> - MAKE SIGNON BLOCK OF 80 CHARACTERS FOR <>BSC>.
.LE;<>XLHEOF> - APPEND AN <>EOF> TO THE MESSAGE AND MARK FOR <>BSC>.
.LE;<>XLHDMP> - DUMP THE CURRENT MESSAGES TO <>BSC> FOR XMIT.
.END LIST
.HL 2 ^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>.
.HL 3 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).
.HL 3 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>.
.LIST
.LE;<>XHIPRS> - PROCESS <>EOR> FOR <>LPT> TYPE DEVICES.
.LE;<>XHGTC> - GETS A CHACTER FROM THE RECEIVED <>EBCDIC> MESSAGE.
.LE;<>XLDPCM> - TRANSLATES CHARACTER FROM <>EBCDIC> TO <>ASCII> AND DEPOSITS IT IN MESSAGE.
.LE;<>XHIMSE> - SENDS <>ASCII> MESSAGE TO <>DTE> TASK.
^THIS CHARACTER SIGNALS THE END OF THE PRINT LINE.
.LE;<>XLCPUT> - WAIT IF THE TRANSLATE TASK HAS BEEN USING
AN EXCESSIVE AMOUNT OF <CPU TIME.
.LE;<>XLIPCR> - OUTPUT A CARRIAGE RETURN IN PRINTER MODE.
.LE;<>XLIPSP> - OUTPUT AN <>LP10 SINGLE SPACE, USING CARRIAGE
RETURN (IF NEEDED) FOLLOWED BY LINE FEED OR <>DC3>.
.LE;<>XLIPGS> - EXPAND COMPRESSED BLANKS USING "<>IGS>" >COMPRESSION>.
.LE;<>XLISHT> - SET HORIZONTAL >TAB> STOPS.
.LE;<>XLIPHT> - PROCESS A HORIZONTAL >TAB>, CONVERTING IT TO
BLANKS.
.END LIST
^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.
.HL 1 ^TRANSLATE ^TABLES
^THESE ARE THE SAME AS USED BY THE <>XL3780<>.
.CHAPTER 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.
.END NOTE
^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:
.LIST
.LE;RUN THE DIAGNOSTIC
FOR THE INDICATED DEVICE
.LE;IF IT DOES NOT FAIL RUN
<>DECX11<>, AN EXERCISER FOR THE WHOLE SYSTEM.
.LE;^IF <>DECX11<> DOESN'T FAIL, RUN ALL THE DIAGNOSTICS.
.END LIST
^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 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.
.HL 1 <>STOPCODE><S
^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.
.HL 1 ^CORE ^DUMPS ON <DEC<SYSTEM-10
.INDEX <DEC<SYSTEM-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 TO OBTAIN DUMPS AS FOR THE <>DN87S<>.
.HL 1 ^CORE ^DUMPS ON <DECSYSTEM-20
.INDEX <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.
.HL 1 <>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.
.HL 2 INITIAL SWITCHES
.TS 24;.LM +26;.B 1;.I -24
/<BINARY<:FILSPEC READ A ".<BIN" FILE (OUTPUT FROM <>MACDLX>)
.B 1;.I -24
/<DUMP<:FILESPEC READ A CORE DUMP LISTING (OUTPUT OF
<>BOOT11 OR <>DTELDR>)
.B 1;.I -24
/<DIMAGE<:FILESPEC READ A CORE DUMP IMAGE (OUTPUT OF
<>DNLOAD OR <>DTELDR<>)
.B 1;.I -24
/<EXIT RETURN TO MONITOR
.B 1;.I -24
/<LINE SPECIFY LINE FROM NODE (SIMILAR TO
<>NETLDR>)
.B 1;.I -24
/<NODE SPECIFY NODE TO DEBUG OR (WITH /<LINE)
NODE ADJACENT TO NODE TO DEBUG
.B 1;.I -24
/<PATCH ALLOW WRITING INTO CORE
.B 1;.I -24
/<PDP8 REMOTE <CPU IS A <>PDP-8> (I.E., <>DC71 OR <>DC72<>)
(THIS FACILITY IS ONLY PARTIALLY IMPLEMENTED)
.B 1;.I -24
/<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.)
.B 1;.I -24
/<SYMBOLS<:FILESPEC READ SYMBOL TABLE FROM A CROSS-REFERENCE
LISTING. (^OUTPUT FROM <>MACDLX>.)
.B 1;.LM -26
^NOTE: /<BINARY, /<DUMP, /<DIMAGE, /<NODE AND /<PORT CAUSE
IMMEDIATE EXIT FROM INITIAL DIALOG, WITHOUT PROCESSING
ANY SUBSEQUENT TEXT ON THE LINE.
.HL 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 <>ESC<>S, JUST AS IN <>DDT>-10.
^THE FOLLOWING IS THE LIST OF FUNCTION LETTERS INTRODUCED
BY <>ESC>.
.B 1;.TS 6;.LM +8;.I -8
^A SET ADDRESS TYPEOUT MODE. <TEMP/PERM. ARG=LENGTH
.B 1;.I -8
^B SET <BYTE TYPEOUT MODE. <TEMP/PERM. ARG=LENGTH
.B 1;.I -8
^C SET <NUMERIC (CONSTANT) TYPEOUT MODE. <TEMP/PERM.
ARG=LENGTH
.B 1;.I -8
^D DUMP MEMORY ONTO A FILE. THE RANGE IS SPECIFIED
AS: <LOW_<HIGH_>$D. ARG = DUMP TYPE: 0 = NORMAL,
1 = NO INSTRUCTION TYPEOUT
.B 1;.I -8
^G CAUSE <CPU TO BRANCH TO EXPRESSION. (ONLY WITH /<NODE)
.B 1;.I -8
^I SET <>EBCDIC> OUTPUT MODE. <TEMP/PERM. ARG=LENGTH
.B 1;.I -8
^K SUPPRESS TYPEOUT OF PRECEEDING SYMBOL.
.B 1;.I -8
^M LOCATION FOR <MASK FOR SEARCHES
.B 1;.I -8
^N <NOT <WORD SEARCH FOR PRECEEDING EXPRESSION. SEARCH
IS MASKED BY LOCATION $^M AND LIMITED BY RANGE,
EXPRESSED AS FOR $^D.
.B 1;.I -8
^P PUNCH BINARY TAPE OF CORE IMAGE (NOT YET
IMPLEMENTED)
.B 1;.I -8
^R SET RADIX IN RANGE 2 TO 15. <TEMP/PERM. ARG=RADIX
.B 1;.I -8
^S SET <INSTRUCTION OUTPUT MODE (DEFAULT). <TEMP/PERM.
ARG=LENGTH
.B 1;.I -8
^T SET <>ASCII> OUTPUT MODE. <TEMP/PERM. ARG=LENGTH
.B 1;.I -8
^V WATCH OPEN LOCATION, TYPE OUT CHANGES, STOP WHEN
CARRIAGE RETURN TYPED.
.B 1;.I -8
^W <WORD SEARCH, SIMILAR TO $^N.
.B 1;.LM -8
.HL 2 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.
.HL 1 "<>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.
.HL 2 ^EXTRA <>STOPCODE> ^INFORMATION
^WITH <>DEBUG<> = 1 THE FOLLOWING EXTRA INFORMATION IS
STORED WITH A <>STOPCODE>:
.LIST
.LE;^THE <CPU REGISTERS
.LE;^THE <DQ11 REGISTERS, INCLUDING ALL OF THE "INTERNAL"
REGISTERS, OR THE <>DUP11<> REGISTERS
.LE;^THE <>KG11-A REGISTERS (NOT AVAILABLE ON <>DN20<>-BASED SYSTEMS)
.LE;^THE <>DTE20> REGISTERS ARE SAVED IN <>DTESAV> TO <>DTESAV+20>
.END LIST
^THIS INFORMATION CAN SOMETIMES BE VERY USEFUL IN
FURTHER DEFINING THE REASON FOR THE <>STOPCODE>.
.HL 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.
.HL 2 ^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.
^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:
.LIST
.LE;<>TRCDQD> - TRACE ALL <>BSC> TASK DATA, ONE CHARACTER AT A TIME.
^THIS TRACES ONLY INPUT, SINCE OUTPUT
MESSAGES ARE BUILT BY <>XLATE>.
.LE;<>TRCDQF> - TRACE ALL <>DQ11 OR <>DUP11<> FUNCTIONS. ^THIS TRACE IS
OF INTERRUPTS AS WELL AS FUNCTION INITIATIONS.
.LE;<>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.
.LE;<>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.
.LE;<>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>.
.LE;<>TRCXLD> - TRACE ALL <>XLATE> DATA ONE CHARACTER AT A
TIME. ^THIS CAN BE USED TO FIND ERRORS IN THE TRANSLATION
ALGORITHMS.
.LE;<>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.
.LE;<>TRCABO> - RECORD A TRACE ENTRY IF THE <>BSC> STREAM
IS TERMINATED BEFORE THE NORMAL END-OF-FILE SEQUENCE.
^THIS IS KNOWN AS >ABORT>ING THE STREAM.
.LE;<>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.
.LE;<>TRCMDF<> - TRACE INTERACTIONS WITH THE <>KMC11<>.
^THIS HAS BEEN USEFUL FOR DEBUGGING THE <>KMC11<> MICROCODE.
.LE;<>TRCBCB<> - TRACE ALL <>BCB> RECEIVED AND EXPECTED BY THE <>DN62> OR <>DN65> SOFTWARE.
.END LIST
.TEST PAGE 35
^IN ADDITION, THERE IS A <>GLOBAL<> CELL <>TRCHLT> WHICH CAN
HAVE BITS SET IN IT TO CAUSE DEBUGGING <>STOPCODE><'S.
^THESE BITS ARE:
.LIST
.LE;<>TRCABO> - STOP IF THE <>BSC> STREAM IS >ABORT>ED.
^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.
.LE;<>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.
.LE;<>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.
.LE;<>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.
.END LIST
^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.
.HL 1 <>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
.LM +20;.B 1
^^MESSAGE ALL,LINE\\
.LM -20;.B 1
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 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:
.LIST
.LE;<>S<> - SYMBOL DEFINITIONS COMMON TO MANY ^DIGITAL
^EQUIPMENT ^CORPORATION PRODUCTS.
.LE;<>DN61D> - PARAMETER SETTINGS FOR THE <>DL10> VERSION.
.LE;<>MACROS<> - SOME USEFUL <>PDP-11<> MACROS.
.LE;<>DEFINE - DEFINITIONS FOR THE <>DN60>.
.LE;<>MININT> - MINOR INTERRUPT ROUTINES.
.LE;<>INIT2 - SECTION 2 OF INITIALIZATION.
.LE;<>STGMAN> - SUBROUTINES TO MANAGE FREE STORAGE.
.LE;<>QUEING> - SUBROUTINES TO SEND AND RECEIVE INTER-TASK
DATA.
.LE;<>DQ11 - SUBROUTINES FOR DRIVING THE <DQ11<'S.
.LE;<>MSGHDL> - SUBROUTINES FOR PROCESSING MESSAGES.
.LE;<>DISPAT> - THE TASK DISPATCHER.
.LE;<>BSC> - THE <>BSC> TASK.
.LE;<>DL10> - THE <>PDP-10 COMMUNICATIONS TASK.
.LE;<>XL3780> - THE <IBM 3780/2780 TRANSLATION AND BACKGROUND TASKS.
.INDEX <IBM 3780
.INDEX <IBM 2780
.LE;<>INITDQ<> - INITIALIZATION FOR THE <>DQ11<>'S.
.LE;<>INIT1 - SECTION 1 OF INITIALIZATION.
.LE;<>CHK11<> - ONCE-ONLY HARDWARE TESTING.
.END LIST
^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 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,
.INDEX <DECSYSTEM-20
A SUBROUTINE CALLED <>C11SIM<> IMPLEMENTS
ONLY THE FUNCTIONS DESCRIBED BELOW USING THE <>FE<> DEVICE
AND <>ENQ/DEQ<>.
.HL 1 PARAMETER BLOCK
^THE <.C11QU FUNCTION, WHEN APPLIED TO A <>DN60>,
USES THE FOLLOWING PARAMETER BLOCK:
.B 1;.TS 6;.LM +6;.I -6
WORD MEANING
.I -6
---- -------
.B 1;.I -6
1 <XWD PORT NUMBER, <.C11QU
.B 1;.LM +2
^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.
.B 1;.LM -2
.I -6
2 <XWD LINE NUMBER, DEVICE NUMBER
.B 1;.LM +2
^LINE NUMBER ZERO IS THE FIRST <>DQ11<>.
^DEVICE NUMBER IS NOT USED YET. ^IT SHOULD ALWAYS BE ZERO.
.B 1;.LM -2
.I -6
3 <XWD NUMBER OF BYTES, FUNCTION CODE
.B 1;.LM +2
^FUNCTION CODES ARE AS FOLLOWS:
.LM +4;.TS 12;.B 1;.I -4
0 NO OPERATION
.I -4
1 READ DATA
.I -4
2 WRITE DATA
.I -4
3 READ DEVICE STATUS
.I -4
4 WRITE DEVICE COMMAND
.I -4
5 READ LINE STATUS
.I -4
6 WRITE LINE COMMAND
.I -4
7 READ <>DN60> STATUS
.I -4
8 WRITE <>DN60> COMMAND
.LM -4
^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.
.LM -2;.B 1;.TS 6;.I -6
4 <XWD LENGTH, START ADDRESS OF BUFFER
.I -6
5 <BYTE (12) NUMBER OF BYTES PER WORD (24) POSITION OF FIRST BYTE
.B 1;.LM +2
^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.
.LM -2;.TS 6;.B 1;.I -6
6 <XWD NUMBER OF BYTES TRANSFERRED, RESULT CODE
.LM +2
^RESULT CODES ARE AS FOLLOWS:
.LM +4;.TS 12;.B 1;.I -4
1 OPERATION SUCCESSFUL
.I -4
2 OPERATION DELAYED
.I -4
3 OPERATION REJECTED BY THE <>DN60>, READ STATUS
.I -4
.LM -12
"^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 >ABORT>ING
THE <>BSC> STREAM OR BY END OF FILE. ^FOR "WRITE DATA" THIS IS
CAUSED BY >ABORT>ING THE <>BSC> STREAM. ^NOTE THAT THE <>BSC> STREAM CAN
BE >ABORT>ED FROM EITHER SIDE.
.HL 1 PROCEDURES
^THE FOLLOWING PROCEDURES ARE SIMPLIFIED DESCRIPTIONS OF THE
ALGORITHMS REQUIRED TO DRIVE THE <>DN60<>. ^SEE <>D60SPD<>
AND <>D60SPL<> FOR MORE DETAILS.
.HL 2 INITIALIZATION
.LIST
.LE;^DISABLE AND THEN ENABLE THE LINE.
.LE;^ABORT INPUT AND OUTPUT.
.LE;^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.
.LE;^BE SURE <EOF IS NOT SET.
.LE;^SET ALL THE REQUIRED LINE AND DEVICE PARAMETERS.
.END LIST
.HL 2 OUTPUT
.LIST
.LE;^ISSUE "^REQUEST OUTPUT PERMISSION".
.LE;^WAIT FOR "OUTPUT PERMISSION REQUESTED" TO CLEAR, THEN
CHECK FOR THE FOLLOWING:
.LIST
.LE;^OUTPUT PERMISSION GRANTED -- DATA TRANSFERS CAN NOW TAKE
PLACE.
.LE;^INPUT PERMISSION REQUESTED -- THE OTHER SIDE WANTS TO DO
OUTPUT. ^SEE BELOW FOR INPUT PROCEDURES.
.LE;^NONE OF THE ABOVE -- THERE WAS AN ERROR, TRY AGAIN IF
YOU WISH.
.END LIST
.LE;^WHEN DATA TRANSFERS ARE COMPLETE, ISSUE "^SIGNAL OUTPUT <>EOF>"
AND WAIT FOR "^OUTPUT <>EOF> COMPLETE".
.LE;^ISSUE "^CLEAR OUTPUT <>EOF> COMPLETE".
.END LIST
.TEST PAGE 8
.HL 2 INPUT
.LIST
.LE;^WAIT FOR "^INPUT PERMISSION REQUESTED".
.LE;^ISSUE "^GRANT INPUT PERMISSION".
.LE;^WAIT FOR "^INPUT PERMISSION GRANTED" TO CLEAR, THEN
CHECK FOR THE FOLLOWING:
.LIST
.LE;^INPUT RUNNING -- DATA CAN NOW BE READ.
.LE;^INPUT >ABORT> STARTED -- THE TRANSFER HAS BEEN >ABORT>ED.
.LE;^INPUT <>EOF> COMPLETED -- DATA CAN NOW BE READ. ^THE DATA
STREAM IS SO SHORT THAT IT ALL FIT INTO THE FRONT END'S BUFFERS.
.LE;^NONE OF THE ABOVE -- PERMISSION WAS NOT GRANTED SOON
ENOUGH OR THERE WAS AN ERROR. ^TRY AGAIN IF YOU WISH.
.END LIST
.LE;^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".
.END LIST
.TEST PAGE 8
<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.
.HL 1 ERROR CODES
^WITH THE INCLUSION OF THE <>DN60>, THE ERROR CODES
FOR THE <>CAL11_.> <>UUO>
ARE AS FOLLOWS:
.B 1;.TS 8
CODE MEANING
.BREAK
---- -------
.B 1;.LM +8;.I -8
1 CALLER DOES NOT HAVE THE <POKE PRIVILEGE
.I -8
2 THE FUNCTION IS UNDEFINED ON THIS TYPE OF FRONT END
.I -8
3 INVALID <>DL10> PORT NUMBER
.I -8
4 <>CAL11_.> FACILITY IN USE, TRY AGAIN LATER.
.I -8
5 NO ANSWER FROM FRONT END AFTER 1-2 SECONDS
.I -8
6 >QUEUE> ENTRY TOO SHORT (<>DC76 ONLY)
.I -8
7 NOT ENOUGH ARGUMENTS
.I -8
10 EXAMINE/DEPOSIT ADDRESS WAS INVALID (MORE THAN 16 BITS
OR FRONT END FLAGGED IT AS INVALID)
OR DEPOSIT DATA MORE THAN 16 BITS
.I -8
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<>)
.I -8
12 ^ON A <>DN61-S<>, <DTESER COULDN'T GET ANY FREE CORE
.I -8
13 ^ON A <>DN61-S<>, THE RELOAD BIT IS SET OR
PRIMARY PROTOCOL IS NOT RUNNING. ^THIS MEANS THAT THE FRONT END
IS DOWN.
.I -8
14 ^ON A <>DN61-S<>, THERE WILL NEVER BE ENOUGH
^EXECUTIVE ^VIRTUAL ^MEMORY TO PROCESS THE REQUEST.
.LM -8
^ON THE <DECSYSTEM-20,
.INDEX <DECSYSTEM-20
ERROR CODES WITH BITS 18 AND 19 SET ARE <>JSYS<>
ERRORS FROM <>TOPS-20<>.
.HL 1 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.
.TEST PAGE 14
.HL 1 STATUS
.HL 2 <>DN60> STATUS
<>DN60> STATUS IS AS FOLLOWS: (READ BY FUNCTION 7)
.B 1
.TS 8;.LM +8;.I -8
BYTES MEANING
.I -8
----- -------
.B 1;.I -8
0-7 <>DN60> VERSION NUMBER
.I -8
8-9 WINDOW VERSION NUMBER (MUST MATCH <D60SER)
.I -8
10-11 CURRENT NUMBER OF FREE "CHUNKS" IN THE <>DN60>
.I -8
12-13 NUMBER OF LINES ON THIS <>DN60>
.I -8
14-15 NUMBER OF BYTES OF DATA IN A CHUNK
.I -8
16-17 TRANSLATION OPTIONS AVAILABLE:
.LM +5;.I -5
^BIT 0 = <IBM 3780/2780 (ALWAYS 1)
.INDEX <IBM 3780
.INDEX <IBM 2780
.I -5
^BIT 1 = <HASP ^MULTILEAVING (ALWAYS 1 FOR <>DN62> AND <>DN65>)
.INDEX <HASP ^MULTILEAVING
.I -5
^BIT 2 = <IBM 3270 (ALWAYS 0)
.INDEX <IBM 3270
.I -5
^BITS 3-15 ARE RESERVED
.LM -5
.I -8
18-25 <>KMC11<> MICROCODE VERSION NUMBER
.I -8
26-27 ^ERROR ^CODE ON LAST ERROR
.I -8
28-29 ^LINE NUMBER ON LAST ERROR
.I -8
30-31 ^DEVICE NUMBER OR RCB ON LAST ERROR
.I -8
32-79 ACTIVE LINE DEVICE INFO (12*4=48 BYTES)
.LM -8
.TEST PAGE 18
.HL 2 LINE STATUS
^LINE STATUS IS AS FOLLOWS: (READ BY FUNCTION 5)
.LM +8;.TS 8;.B 1;.I -8
BYTE MEANING
.I -8
----- -------
.B 2;.I -8
0 TERMINAL TYPE: 0 = UNKNOWN,
.I 16
1 = <IBM 3780<,
.INDEX <IBM 3780
.I 16
2 = <IBM 2780<,
.INDEX <IBM 2780
.I 16
3 = <HASP ^MULTILEAVING
.I 16
4-255 = RESERVED.
.B 1;.I -8
1 FLAGS: BIT 0 SET = SIMULATE,
.I 14
CLEAR = SUPPORT.
.I 8
BIT 1 SET = PRIMARY <>BSC> STATION,
.I 14
CLEAR = SECONDARY <>BSC> STATION
.I 8
BIT 2 SET = TRANSPARENT OUTPUT
.I 14
CLEAR = NON-TRANSPARENT MODE
.I 8
BITS 3-7 = RESERVED.
.B 1;.I -8
2 LINE INFO: BIT 0 SET = LINE IS ENABLED
.I 12
BIT 1 = ^DATA ^TERMINAL ^READY (<>DTR>)
.I 12
BIT 2 = ^DATA ^SET ^READY (<>DSR>)
.I 12
BITS 3-7 = RESERVED
.B 1;.I -8
3 ERROR CODE INFORMATION ON LAST ERROR
.B 1;.I -8
4-5 COUNT OF <>DQ11<>/<>DUP11<> ERROR INTERRUPTS
.B 1;.I -8
6-7 <>DQ11<>/<>DUP11<> STATUS REGISTER 1 AT LAST ERROR
.B 1;.I -8
8-9 <>DQ11<>/<>DUP11<> STATUS REGISTER 2 AT LAST ERROR
.B 1;.I -8
10-11 COUNT OF TIMES RECEIVER WASN'T FAST ENOUGH
.B 1;.I -8
12-13 COUNT OF TIMES TRANSMITTER WASN'T FAST ENOUGH
.B 1;.I -8
14-15 COUNT OF CLEAR-TO-SEND (<>CTS>) FAILURES
.B 1;.I -8
16-17 COUNT OF MESSAGES SENT AND ACKED
.B 1;.I -8
18-19 COUNT OF <>NAK><'S RECEIVED (+WRONG ACKNOWLEDGE AFTER >TIMEOUT>)
.B 1;.I -8
20-21 COUNT OF INVALID RESPONSES TO <>TTD>
.B 1;.I -8
22-23 COUNT OF INVALID RESPONSES TO MESSAGES
.B 1;.I -8
24-25 COUNT OF <>TTD><'S SENT
.B 1;.I -8
26-27 COUNT OF <>WACK><'S RECEIVED IN RESPONSE TO MESSAGES
.B 1;.I -8
28-29 COUNT OF <>EOT><'S (>ABORT>S) IN RESPONSE TO MESSAGES
.B 1;.I -8
30-31 COUNT OF INVALID BIDS OR RESPONSES TO BIDS
.B 1;.I -8
32-33 COUNT OF <RVI<'S RECEIVED WHILE TRANSMITTING
.B 1;.I -8
34-35 COUNT OF MESSAGES RECEIVED <OK
.B 1;.I -8
36-37 COUNT OF BAD <>BCC><'S
.B 1;.I -8
38-39 COUNT OF <>NAK><'S SENT IN RESPONSE TO DATA MESSAGES
.B 1;.I -8
40-41 COUNT OF <>WACK><'S SENT
.B 1;.I -8
42-43 COUNT OF <>TTD><'S RECEIVED
.B 1;.I -8
44-45 COUNT OF <>EOT><'S SENT OR RECEIVED WHICH >ABORT> THE STREAM
.B 1;.I -8
46-47 COUNT OF MESSAGES IGNORED (OUT OF CHUNKS, UNRECOGNIZABLE
OR >TIMEOUT>)
.B 1;.I -8
48-49 COUNT OF >TRANSPARENT> MESSAGES WITH AN INVALID CHARACTER
AFTER <>DLE>
.B 1;.I -8
50-51 COUNT OF ATTEMPTS TO CHANGE BETWEEN >TRANSPARENT> AND NORMAL
(NON->TRANSPARENT>) MODE IN A BLOCKED MESSAGE
.B 1;.I -8
52-53 COUNT OF TRANSMITTER >TIMEOUT>S
.B 1;.I -8
54-55 CLEAR-TO-SEND DELAY, IN >JIFFIES>
.B 1;.I -8
56-57 COUNT OF SILO OVERFLOWS
.B 1;.I -8
58-59 NUMBER OF BYTES IN SILO WARNING AREA (USUALLY 64)
(MUST BE EVEN)
.B 1;.I -8
60-61 MAX NUMBER OF BYTES USED IN SILO WARNING AREA
SINCE ITS DEPTH WAS LAST SET
.B 1;.I -8
62-63 MAXIMUM TRANSMISSION BLOCK LENGTH
.B 1;.I -8
64-65 NUMBER OF LOGICAL RECORDS PER TRANSMISSION BLOCK
.B 1;.I -8
66-67 LINE DRIVER TYPE:
.LM +5;.I -5
1 = <>DQ11<>
.I -5
2 = <>KMC11<>/<>DUP11<>
.I -5
3 = <>DUP11<> WITHOUT <>KMC11<>
.LM -8
.TEST PAGE 50
.HL 2 DEVICE STATUS
^DEVICE STATUS IS AS FOLLOWS: (READ BY FUNCTION 3)
.B 1;.LM +8;.TS 8;.I -8
BYTES MEANING
.I -8
----- -------
.B 1;.I -8
0 DEVICE TYPE: 0 = UNKNOWN,
.I 14
1 = PRINTER,
.I 14
2 = PUNCH,
.I 14
3 = READER,
.I 14
4-255 = RESERVED.
.B 1;.I -8
1 COMPONENT SELECTION CODE: 0 = UNKNOWN,
.I 27
221 = CONSOLE IN
.I 27
222 = CONSOLE OUT
.I 27
223 = CARD READER UNIT 1
.I 27
224 = LINE PRINTER UNIT 1
.I 27
225 = CARD PUNCH UNIT 1
.I 27
OTHERS = RESERVED
^THE COMPONENT SELECTION CODE ARE IN OCTAL.
.B 1;.I -8
2-3 PRINTER LINE COUNTER
.B 1;.I -8
4-7 FLAGS: BITS 0-3 = RESERVED
.I 8
BIT 4 = INTERPRET INPUT CARRIAGE CONTROL
.I 8
BIT 5 = INTERPRET OUTPUT CARRIAGE CONTROL
.I 8
BIT 6 = RESERVED
.I 8
BIT 7 = DO COMPONENT SELECTION
.I 8
BIT 8 = DO COMPRESS/EXPAND
.I 8
BIT 9 = PAGE COUNTER HAS OVERFLOWED
.I 8
BIT 10 = PAGE COUNTER INTERRUPTS ENABLED
.I 8
BIT 11 = OLD <>BSC> PROTOCOL
.I 8
BIT 12 = OUTPUT BUFFERS BEING DUMPED
.I 8
BIT 13 = INPUT PERMISSION GRANT TO BE SENT TO HASP
.I 8
BIT 14 = DEVICE IN INPUT MODE (=1)
.I 8
BIT 15 = OUTPUT BEING COMPLETED FOR DUMP OR EOF
.I 8
BIT 16 = OUTPUT PERMISSION REQUESTED
.I 8
BIT 17 = OUTPUT PERMISSION GRANTED
.I 8
BIT 18 = OUTPUT RUNNING
.I 8
BIT 19 = OUTPUT <>EOF> SIGNALED
.I 8
BIT 20 = OUTPUT <>EOF> COMPLETE
.I 8
BIT 21 = OUTPUT >ABORT> STARTED
.I 8
BIT 22 = OUTPUT >ABORT> COMPLETED
.I 8
BIT 23 = INPUT PERMISSION REQUESTED
.I 8
BIT 24 = INPUT PERMISSION GRANTED
.I 8
BIT 25 = INPUT RUNNING
.I 8
BIT 26 = INPUT >ABORT> STARTED
.I 8
BIT 27 = INPUT >ABORT> COMPLETED
.I 8
BIT 28 = INPUT <>EOF> COMPLETED
.I 8
BIT 29 = INPUT PERMISSION WAS REQUESTED
.I 8
BIT 30 = OUTPUT PERMISSION WAS REQUESTED
.I 8
BIT 31 = DEVICE SUSPENDED (FOR HASP ONLY)
.I 8
FOR BSC TCB, THIS BIT ON = OUTPUT SUSPENDED
.B 1;.I -8
8-9 DEVICE RECORD SIZE
.LM -8;.B 3
.TEST PAGE 24
.HL 1 COMMANDS
^THE FIRST BYTE OF A COMMAND IS THE COMMAND CODE; SUBSEQUENT
BYTES PROVIDE THE ARGUMENTS TO THE COMMAND, IF ANY ARE NEEDED.
.HL 2 LINE COMMANDS
.TEST PAGE 10
^COMMANDS TO A LINE ARE AS FOLLOWS: (FUNCTION 6)
.LM +8;.B 1;.TS 8;.I -8
COMMAND MEANING
.I -8
------- -------
.B 1;.I -8
1 ENABLE LINE AND SET CHARACTERISTICS:
.LM +9;.TS 17;.I -9
BYTE 1 = TERMINAL TYPE: 0 = UNKNOWN,
.I 16
1 = <IBM 3780<,
.INDEX <IBM 3780
.I 16
2 = <IBM 2780<,
.INDEX <IBM 2780
.I 16
3 = <HASP ^MULTILEAVING
.I 16
4-255 = RESERVED.
.I -9
BYTE 2 = FLAGS: BIT 0 SET = SIMULATE,
.I 14
CLEAR = SUPPORT.
.I 8
BIT 1 SET = PRIMARY <>BSC> STATION
.I 14
CLEAR = SECONDARY <>BSC> STATION
.I 8
BITS 2-7 RESERVED
.LM -9;.TS 8;.B 1;.I -8
2 ALLOW ANSWERING OF >MODEM> AND RECEIPT OF DATA (I.E.,
SET ^DATA ^TERMINAL ^READY)
.B 1;.I -8
3 >ABORT> ALL DATA TRANSFERS AND HANG UP THE >MODEM>
.B 1;.I -8
4 DISABLE THE LINE
.B 1;.I -8
5 SET CLEAR-TO-SEND DELAY:
.LM +9;.TS 17;.I -9
BYTES 1-2 = CLEAR-TO-SEND DELAY, IN >JIFFIES>
.LM -9;.B 1;.TS 8;.I -8
6 SET NUMBER OF BYTES IN SILO WARNING AREA
AND CLEAR "MAX USED"
.LM +9;.TS 17;.I -9
BYTES 1-2 = NUMBER OF BYTES IN SILO WARNING AREA
.LM -9;.B 1;.TS 8;.I -8
7 SET OUTPUT IN TRANSPARENT MODE
.B 1;.I -8
8 SET OUTPUT IN NON-TRANSPARENT MODE
.B 1;.I -8
9 SET TRANSMISSION BLOCK SIZE
.B 1;.I -8
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
.INDEX <IBM 2780
.INDEX MULTI-RECORD FEATURE
WITH MULTI-RECORD FEATURE, 0 FOR <IBM 3780<.)
.INDEX <IBM 3780
.LM -8
.TEST PAGE 28
.HL 2 DEVICE COMMANDS
^COMMANDS TO A DEVICE ARE AS FOLLOWS: (FUNCTION 4)
.LM +8;.B 1;.TS 8;.I -8
COMMAND MEANING
.I -8
------- -------
.B 1;.I -8
1 SET CHARACTERISTICS:
.LM +9;.TS 17;.I -9
BYTE 1 = DEVICE TYPE: 0 = UNKNOWN,
.I 14
1 = CONSOLE OUT,
.I 14
2 = CONSOLE INPUT,
.I 14
3 = CARD READER,
.I 14
4 = LINE PRINTER
.I 14
5 = CARD PUNCH,
.I 14
6-255 = RESERVED.
.LM -9;.TS 8;.B 1;.I -8
2 RESERVED
.B 1;.I -8
3 DUMP OUTPUT BUFFERS
.B 1;.I -8
4 CLEAR ^INPUT ^PERMISSION WAS ^REQUESTED
.B 1;.I -8
5 RESERVED
.B 1;.I -8
6 SET ^INTERPRET ^CARRIAGE ^CONTROL ON ^INPUT (FOR
SIMULATING A PRINTER)
.B 1;.I -8
7 CLEAR ^INTERPRET ^CARRIAGE ^CONTROL ON ^INPUT (FOR
SIMULATING A PUNCH OR SUPPORTING A READER)
.B 1;.I -8
8 SET ^INTERPRET ^CARRIAGE ^CONTROL ON ^OUTPUT (FOR
SUPPORTING A PRINTER)
.B 1;.I -8
9 CLEAR ^INTERPRET ^CARRIAGE ^CONTROL ON ^OUTPUT (FOR
SUPPORTING A PUNCH OR SIMULATING A READER)
.B 1;.I -8
10 RESERVED
.B 1;.I -8
11 RESERVED
.B 1;.I -8
12 SPECIFY OUTPUT COMPONENT SELECTION
.LM +9;.TS 17;.I -9
BYTE 1 = COMPONENT CODE: 0 = UNKNOWN,
.I 17
221 = CONSOLE IN
.I 17
222 = CONSOLE OUT
.I 17
223 = CARD READER UNIT 1
.I 17
224 = LINE PRINTER UNIT 1
.I 17
225 = CARD PUNCH UNIT 1
.I 17
OTHERS = RESERVED
.LM -9
.B 1
^THIS IS USED BY <HASP ^MULTILEAVING ONLY.
.B 1;.TS 8;.I -8
13 DON'T DO OUTPUT COMPONENT SELECTION
.B 1;.I -8
14 SET PRINTER PAGE COUNTER AND ENABLE FOR OVERFLOW
.LM +12;.TS 20;.I -12
BYTES 1-2 = VALUE OF LINE COUNTER
.LM -12
^THIS IS NOT YET IMPLEMENTED.
.TS 8;.B 1;.I -8
15 DISABLE PRINTER PAGE COUNTER OVERFLOW
.B 1;.I -8
16 RESERVED
.LM +12;.TS 20;.I -12
BYTES 1-2 = MAX TRANSMISSION BLOCK SIZE
.LM -12
.B 1;.TS 8;.I -8
17 DO SPACE COMPRESSION ON OUTPUT (NOTE: EXPANSION ON
INPUT IS ALWAYS ENABLED)
.B 1;.I -8
18 DON'T DO SPACE COMPRESSION ON OUTPUT
.B 1;.I -8
19 USE OLD <>BSC> PROTOCOL (<>IUS>, <>ETB> AND <>ETX> IMPLY
<>IRS>, >OVERPRINT>ING IS IGNORED AND
CARD OUTPUT IS PADDED TO 80 CHARACTERS WITH SPACES)
.B 1;.I -8
20 DON'T USE OLD <>BSC> PROTOCOL
.B 1;.I -8
21 REQUEST OUTPUT PERMISSION
.B 1;.I -8
22 GRANT INPUT PERMISSION
.B 1;.I -8
23 SIGNAL OUTPUT <>EOF> (END-OF-FILE)
.B 1;.I -8
24 CLEAR OUTPUT <>EOF> COMPLETE
.B 1;.I -8
25 SIGNAL OUTPUT >ABORT>
.B 1;.I -8
26 CLEAR OUTPUT >ABORT> COMPLETE
.B 1;.I -8
27 CLEAR INPUT <>EOF> COMPLETE
.B 1;.I -8
28 SIGNAL INPUT >ABORT>
.B 1;.I -8
29 CLEAR INPUT >ABORT> COMPLETE
.B 1;.I -8
30 SUSPEND DEVICE (<HASP ONLY)
.B 1;.I -8
31 UNSUSPEND DEVICE (<HASP ONLY)
.B 1;.I -8
32 SET DEVICE RECORD SIZE
.LM -8
.CHAPTER 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.
.INDEX <IBM 3780
^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.
.LIST
.LE;^THE <>DN61> WILL NOT TRANSMIT IN >TRANSPARENT> MODE.
.LE;^THE <>DN61> DOES NOT HAVE BINARY MODE FILES.
(^IT IS NOT PERFECTLY CLEAR WHAT THIS IS.)
.LE;^THE <>DN61> DOES NOT MAINTAIN A LOG OF FILES SENT AND
RECEIVED. (^AN ABBREVIATED LOG IS MAINTAINED IN THE
<FACT OR <USAGE FILE
.INDEX <FACT FILE
.INDEX <USAGE FILE
AND HAS THE SAME FORMAT AS <>LPTSPL> ENTRIES.)
.LE;^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.
.LE;^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<.
.INDEX <IBM 2780
.LE;^THE <>DN61> DOES NOT PERMIT SPECIFICATION IN THE LOG FILE
OF NUMBER OF FORMS AND FORMS TYPE ON A "<PRINT" REQUEST.
.LE;^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.
.LE;^THERE IS NO PROVISION FOR STRIPPING OFF THE BANNER PAGE.
.LE;^THE PROCEDURE FOR SENDING A FILE OUTSIDE THE NORMAL
SPOOLING SEQUENCE IS DIFFERENT.
.LE;^THE PRINTER AND CARD READER ON THE <IBM 2780< ARE ACCESSIBLE
.INDEX <IBM 2780
ONLY FROM <>D60SPL AND <>D60SPD>,
BECAUSE THE <>DN61 IS PROGRAMMED USING THE
<>CAL11_.> <>UUO RATHER THAN <INPUT AND <OUTPUT <>UUO<>S.
.LE;^THE <>DN61> CORRECTS SOME ERRORS IN THE <DAS78<'S
TRANSLATE TABLES.
^SEE ^CHAPTER 15 ON THE <>XL3780<> SECTION FOR DETAILS.
.LE;^THE <>DN61> DOES NOT >SIMULATE> THE
<IBM 2780<'S
.INDEX <IBM 2780
CARRIAGE CONTROL TAPE, EXCEPT FOR TOP OF FORM
(CHANNEL 1).
^OTHER SKIP TO CHANNEL COMMANDS ARE TRANSLATED TO LINE FEED.
.LE;^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).
.INDEX <IBM 2780
.LE;^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.
.LE;^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.
.LE;^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<>.
.END LIST
.CHAPTER 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.
.HL 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.
.HL 1 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.
.HL 1 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 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.
.INDEX <IBM 3780
.INDEX <IBM 2780
^DISCUSSION WILL BE FURHER LIMITED TO THE FEATURES OF
THE <IBM 3780 AND 2780
.INDEX <IBM 3780
.INDEX <IBM 2780
WHICH ARE SUPPORTED OR SIMULATED BY THE <>DN61<> AND <>DN64<>.
.HL 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.
^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.
.HL 1 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.
.B 1;.TAB STOPS 10, 20, 30
"WORD" HEX MEANING
.BREAK
------ --- -------
.B 1;.LM +20;.I -20
<>HT 05 ^HORIZONTAL ^TAB
.I -20
<>NAK 3^D ^NEGATIVE ^ACKNOWLEDGE
.I -20
<>DLE 10 ^DATA ^LINK ^ESCAPE
.I -20
<>EOT 37 ^END OF ^TRANSMISSION
.I -20
<>STX 02 ^START OF ^TEXT
.I -20
<>ETX 03 ^END OF ^TEXT
.I -20
<>ETB 26 ^END OF ^TRANSMISSION ^BLOCK
.I -20
<>ENQ 2^D ^ENQUIRY
.I -20
<>IRS 1^E ^INTERCHANGE ^RECORD ^SEPARATOR
.I -20
<>IUS 1^F ^INTERCHANGE ^UNIT ^SEPARATOR
.I -20
<>ESC 27 ^ESCAPE
.I -20
<>SYN 32 ^SYNCH
.I -20
<>EM 19 ^END OF ^MEDIUM
.I -20
<>NL 15 ^NEW ^LINE
.I -20
<>ACK-0 <>DLE<> 70 ^ACKNOWLEDGE ^ZERO
.I -20
<>ACK-1 <>DLE<> 61 ^ACKNOWLEDGE ^ONE
.I -20
<>WACK <>DLE<> 6^B ^WAIT ^ACKNOWLEDGE
.I -20
<>RVI <>DLE<> 7^C ^REVERSE ^INTERRUPT
.I -20
<>TTD <>STX<> <>ENQ<> ^TEMPORARY ^TEXT ^DELAY
.I -20
<>LPD 55 ^LEADING ^PAD
.I -20
<>PAD <FF ^PAD (TRAILING)
.TEST PAGE 20
.B 1;.LM -20
.HL 1 ORGANIZING THE SERIAL DATA STREAM
.HL 2 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:
.B 1;.CENTER
^X'55', <>SYN<>, <>SYN<>, <>SYN<>
.B 1
^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.
.HL 2 IMBEDDED SYNCHRONIZATION
^IN SOME OLD >MODEM>S 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
.INDEX <IBM 3780
SENDS THIS, SO THE <>DN60 NEVER SENDS IT, BUT BOTH THE
<IBM 3780 AND THE <>DN60 PROCESS IT CORRECTLY WHEN
.INDEX <IBM 3780
THEY RECEIVE IT.
.HL 2 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
.INDEX <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 '^F^F'.
.HL 1 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.
.HL 2 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:
.B 1;.TEST PAGE 8;.LM +15;.TAB STOPS 22, 40
SOURCE # SINK
.BREAK
------ # ----
.B 1
<>ENQ ----------------_> #
.BREAK
# _<---------------- <>ACK-0
.B 1;.LM -15
^UPON RECIEPT OF THE <>ACK-0 THE BIDDING IS COMPLETE AND
THE "SOURCE" OWNS THE LINE. ^AN UNSUCCESSFUL
BID WOULD LOOK LIKE THIS:
.B 1;.TEST PAGE 8;.LM +15
SOURCE # SINK
.BREAK
------ ----
.B 1
<>ENQ ----------------_>
.BREAK
# _<---------------- <>NAK
.B 1;.LM -15
^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:
.B 1;.TEST PAGE 8;.LM +15;.TAB STOPS 22, 40
SOURCE # SINK
.BREAK
------ # ----
.BREAK
<>ENQ --------<ZOT
.B 1
<>ENQ ----------------_>
.BREAK
# _<---------------- <>ACK-0
.B 1;.LM -15
^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.
.HL 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 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:
.B 1;.TEST PAGE 8;.LM +15;.TAB STOPS 22, 40
SOURCE # SINK
.BREAK
------ # ----
.B 1
DATA1 -------/--------_>
.BREAK
# _<---------------- <>NAK
.BREAK
DATA1 ----------------_>
.BREAK
# _<---------------- <>ACK-1
.B 1;.LM -15
^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:
.B 1;.TEST PAGE 8;.LM +15;.TAB STOPS 22, 40
SOURCE # SINK
.BREAK
------ # ----
.B 1
DATA1 -------/--------_>
.BREAK
# _<---------------- <>NAK
.BREAK
# #######.
.BREAK
# #######.
.BREAK
# #######.
.BREAK
DATA1 -------/--------_>
.BREAK
# _<---------------- <>NAK
.BREAK
<>EOT ----------------_>
.B 1;.LM -15
^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:
.B 1;.TEST PAGE 8;.LM +15;.TAB STOPS 22, 40
SOURCE # SINK
.BREAK
------ # ----
.B 1
DATA1 ----------------_>
.BREAK
# _<---------------- <>ACK-1
.BREAK
DATA2 ----------------_>
.BREAK
# _<---------------- <>ACK-0
.BREAK
DATA3 ----------------_>
.BREAK
# _<---------------- <>ACK-1
.B 1;.LM -15
^THE FIRST DATA MESSAGE AFTER THE BIDDING IS COMPLETE IS
REPLIED TO WITH AN <>ACK-1 RATHER THAN AN <>ACK-0<>.
.HL 2 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.
.HL 2 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:
.B 1;.TEST PAGE 8;.LM +15;.TAB STOPS 22, 40
SOURCE # SINK
.BREAK
------ # ----
.B 1
DATA1 ----------------_>
.BREAK
# _<---------------- <>ACK-1
.B 1
<>TTD ----------------_>
.BREAK
# _<---------------- <>NAK
.B 1
DATA2 ----------------_>
.BREAK
# _<---------------- <>ACK-0
.B 1;.LM -15
^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:
.B 1;.TEST PAGE 8;.LM +15;.TAB STOPS 22, 40
SOURCE # SINK
.BREAK
------ # ----
.B 1
DATA1 ----------------_>
.BREAK
# _<---------------- <>ACK-1
.BREAK
DATA2 ----------------_>
.BREAK
# _<---------------- <>WACK
.B 1
<>ENQ ----------------_>
.BREAK
# _<---------------- <>ACK-0
.B 1;.LM -15
.HL 2 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.
.B 1;.TEST PAGE 8;.LM +15;.TAB STOPS 22, 40
SOURCE # SINK
.BREAK
------ # ----
.B 1
DATA1 ----------------_>
.BREAK
# _<---------------- <>ACK-1
.BREAK
DATA2 ------<ZOT
.B 1
<>ENQ ----------------_>
.BREAK
# _<---------------- <>ACK-1
.BREAK
DATA2 ----------------_>
.BREAK
# _<---------------- <>ACK-0
.B 1;.LM -15
^THE FOLLOWING EXAMPLE SHOWS A MISSED ACKNOWLEGDEMENT.
.B 1;.TEST PAGE 8;.LM +15;.TAB STOPS 22, 40
SOURCE # SINK
.BREAK
------ # ----
.B 1
DATA1 ----------------_>
.BREAK
# _<---------------- <>ACK-1
.BREAK
DATA2 ----------------_>
.BREAK
# #####<ZOT--------- <>ACK-0
.B 1
<>ENQ ----------------_>
.BREAK
# _<---------------- <>ACK-0
.BREAK
DATA3 ----------------_>
.BREAK
# _<---------------- <>ACK-1
.B 1;.LM -15
.HL 1 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 CARDS EACH
MINUTE.
.HL 2 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
.INDEX <IBM 3780
PUTS AN <>IRS<> CHARACTER IN THE DATA STREAM. ^THIS
CHARACTER IS NOT PRINTED OR PUNCHED.
.HL 2 <>IGS COMPRESSION
^MULTIPLE BLANKS IN THE MIDDLE OF A CARD OR LINE
OF PRINT CAN BE REPRESENTED USING <>IGS<>. ^THE SEQUENCE
.B 1;.CENTER
<>IGS<> CODE
.B 1
REPRESENTS UP TO 63 BLANKS. ^THE CODE IS A CHARACTER
FROM HEX '42' TO '7^F' TO REPRESENT
FROM TWO TO 63 BLANKS.
.HL 2 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.
.HL 2 VERTICAL POSITIONING
^INSTEAD OF SENDING BLANK LINES TO SPACE DOWN THE PAGE,
MULTIPLE SPACING CAN BE USED. ^IF THE SEQUENCE
.B 1;.CENTER
<>ESC<> CODE
.B 1
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:
.B 1;.TAB STOPS 6
CODE MEANING
.BREAK
---- -------
.B 1
^A SKIP TO TOP OF NEXT PAGE
.BREAK
/ SINGLE SPACE
.BREAK
^S DOUBLE SPACE
.BREAK
^T TRIPLE SPACE
.BREAK
^M NO SPACE
^THE "NO SPACE" FUNCTION IS FOR OVERPRINTING.
.HL 1 <IBM 2780 VERSUS <IBM 3780
.INDEX <IBM 2780
.INDEX <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
.INDEX <IBM 2780
IS LIMITED TO TWO OR SEVEN CARDS OR PRINT LINES IN ONE
TRANSMISSION BLOCK.
^WHEN THE <IBM 2780 SENDS
.INDEX <IBM 2780
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.
.HL 1 MORE INFORMATION
^MORE INFORMATION ON <>BISYNC<> IS CONTAINED IN
CERTAIN <>IBM<> DOCUMENTS.
^THE MOST USEFUL OF THESE ARE:
.LIST
.LE;^GENERAL ^INFORMATION -- ^BINARY ^SYNCHRONOUS
^COMMUNICATIONS, ORDER NUMBER <>GA27-3004<>.
.LE;^COMPONENT ^INFORMATION FOR THE <IBM 3780
.INDEX <IBM 3780
^DATA ^COMMUNICATIONS ^TERMINAL, ORDER NUMBER
<>GA27-3063<>.
.LE;<IBM 2780
.INDEX <IBM 2780
^DATA ^TRANSMISSION ^TERMINAL - ^COMPONENT
^DESCRIPTION, ORDER NUMBER <>GA27-3005<>.
.LE;<IBM 3770 ^DATA ^COMMUNICATIONS ^SYSTEM,
.INDEX <IBM 3770
^SYSTEM ^COMPONENTS, ORDER NUMBER <>GA27-3097<>.
.END LIST
^NOTE THAT <>IBM MANUALS ARE AVAILABLE FROM YOUR
<IBM REPRESENTATIVE OR THE <IBM BRANCH OFFICE SERVING
YOUR LOCALITY, NOT FROM ^DIGITAL ^EQUIPMENT ^CORPORATION.
.APPENDIX <>DTE10<> FORMATS
.TS 15,30,45,60
.HL 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.
.SKIP 1
.LIT
!----------------------------------------------------------!
! 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) ! ! !
!----------------------------------------------------------!
.END LIT
.SKIP 1
.LM +30
.TS 30
.I -30;^^MSG COUNT IN BYTES\\ ^THE NUMBER OF BYTES IN THIS MESSAGE HEADER = 14.
.SK 1;.I -30;^^PROTOCOL FUNCT CODE\\ <.EMD6D <>DN60<> DATA
.SK 1;.I-30;^^PROTOCOL DEV CODE\\ <.EMD60
.SK 1;.I-30;^^SPARE WORD\\ ^NOT USED
.SK 1;.I-30;0 ^NOT USED
.SK 1;.I-30;^^DN60 FUNCTION CODE\\ 2, 4, 6, OR 8
.SK 1;.I-30;^^DN60 LINE NUMBER\\ ^LINE NUMBER FROM THE <CAL11. BLK
.SK 1;.I-30;^^DN60 DEVICE NUMBER\\ ^DEVICE NUMBER FROM THE <CAL11. BLK
.SK 1;.I-30;^^LENGTH\\ ^LENGTH OF THE DATA IN BYTES IN THE INDIRECT MESSAGE. ^THE MAXIMUM LENGTH WILL BE 3095 BYTES.
.PAGE
.LM -30
.SKIP 2
^THE 11 SHOULD RESPOND WITH THE FOLLOWING DIRECT MESSAGE.
.SKIP 1
.LIT
!----------------------------------------------------------!
! 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) ! ! !
!----------------------------------------------------------!
.END LIT
.LM +30;.SK 1
.TS 30
.I -30;^^MSG COUNT IN BYTES\\ ^THE NUMBER OF BYTES IN THIS MESSAGE HEADER = 14.
.SK 1;.I -30;^^PROTOCOL FUNCT CODE\\ <.EMD6D <>DN60<> DATA
.SK 1;.I-30;^^PROTOCOL DEV CODE\\ <.EMD60
.SK 1;.I-30;^^SPARE WORD\\ ^NOT USED
.SK 1;.I-30;^^DN60 RESULT CODE\\ 1, 2, OR 3
.SK1;.I-30;^^DN60 FUNCTION CODE\\ 2, 4, 6, OR 8
.SK 1;.I-30;^^DN60 LINE NUMBER\\ ^LINE NUMBER GIVING RESULT CODE FOR
.SK 1;.I-30;^^DN60 DEVICE NUMBER\\ ^DEVICE NUMBER GIVING RESULT CODE FOR
.SK 1;.I-30;^^LENGTH\\ ^NUMBER OF DATA BYTES THE 11 ABSORBED FROM THE INDIRECT PORTION
.LM -30
.PAGE
.HL 1 <>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.
.SKIP 1
.LIT
!----------------------------------------------------------!
! 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) ! ! !
!----------------------------------------------------------!
.END LIT
.SKIP 1
.LM +30
.TS 30
.I -30;^^MSG COUNT IN BYTES\\ ^THE NUMBER OF BYTES IN THIS MESSAGE HEADER = 14.
.SK 1;.I -30;^^PROTOCOL FUNCT CODE\\ <.EMD6D <>DN60<> DATA
.SK 1;.I-30;^^PROTOCOL DEV CODE\\ <.EMD60
.SK 1;.I-30;^^SPARE WORD\\ ^NOT USED
.SK 1;.I-30;0 ^NOT USED
.SK 1;.I-30;^^DN60 FUNCTION CODE\\ 2, 4, 6, OR 8
.SK 1;.I-30;^^DN60 LINE NUMBER\\ ^LINE NUMBER FROM THE <CAL11. BLK
.SK 1;.I-30;^^DN60 DEVICE NUMBER\\ ^DEVICE NUMBER FROM THE <CAL11. BLK
.SK 1;.I-30;^^LENGTH\\ ^LENGTH OF THE DATA IN BYTES IN THE INDIRECT MESSAGE. ^THE MAXIMUM LENGTH WILL BE 3095 BYTES.
.PAGE
.LM -30
^THE 11 SHOULD RESPOND WITH A DIRECT MESSAGE AND THE DATA SHOULD
FOLLOW IN THE INDIRECT MESSAGE.
.SKIP 1
.LIT
!----------------------------------------------------------!
! 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) ! ! !
!----------------------------------------------------------!
.END LIT
.SKIP 1
.LM +30
.TS 30
.I -30;^^MSG COUNT IN BYTES\\ ^THE NUMBER OF BYTES IN THIS MESSAGE HEADER = 14.
.SK 1;.I -30;^^PROTOCOL FUNCT CODE\\ <.EMD6D <>DN60<> DATA
.SK 1;.I-30;^^PROTOCOL DEV CODE\\ <.EMD60
.SK 1;.I-30;^^SPARE WORD\\ ^NOT USED
.SK 1;.I-30;^^DN60 RESULT CODE\\ 1, 2, OR 3
.SK 1;.I-30;^^DN60 FUNCTION CODE\\ 1, 3, 5, OR 7
.SK 1;.I-30;^^DN60 LINE NUMBER\\ ^LINE NUMBER GIVING RESULT AND DATA FOR
.SK 1;.I-30;^^DN60 DEVICE NUMBER\\ ^DEVICE NUMBER GIVING RESULT AND DATA FOR
.SK 1;.I-30;^^LENGTH\\ ^LENGTH OF THE DATA IN BYTES IN THE INDIRECT MESSAGE
.LM -30
.PAGE
.HL 1 ^DEPOSIT ^FUNCTION
^TO PERFORM THE DEPOSIT FUNCTION (<>DN60<> FUNCTION CODE 10) THE
10 WILL SEND THE FOLLOWING DIRECT MESSAGE:
.SKIP 1
.LIT
!----------------------------------------------------------!
! 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) ! ! !
!----------------------------------------------------------!
.END LIT
.LM +30;.SK 1
.TS 30
.I -30;^^MSG COUNT IN BYTES\\ ^THE NUMBER OF BYTES IN THIS MESSAGE HEADER = 14.
.SK 1;.I -30;^^PROTOCOL FUNCT CODE\\ <.EMD6D <>DN60<> DATA
.SK 1;.I-30;^^PROTOCOL DEV CODE\\ <.EMD60
.SK 1;.I-30;^^SPARE WORD\\ ^NOT USED
.SK 1;.I-30;0 ^NOT USED
.SK 1;.I-30;^^DN60 FUNCTION CODE\\ 10
.SK 1;.I-30;^^ADR\\ ^ADDRESS TO DEPOSIT THE DATA INTO
.SK 1;.I-30;^^DATA\\ ^DATA TO BE DEPOSITED INTO <ADR
.PAGE
.LM -30
^THE 11 SHOULD RESPOND WITH THE RESULT CODE:
.SKIP 1
.LIT
!----------------------------------------------------------!
! MSG COUNT IN BYTES ! PROTOCOL FUNCT CODE (.EMD6D) !
!----------------------------------------------------------!
! PROTOCOL DEV CODE ! SPARE WORD !
!----------------------------------------------------------!
!RESULT CODE !DN60 FUN CODE ! ! !
!----------------------------------------------------------!
.END LIT
.LM +30;.SK 1
.TS 30
.I -30;^^MSG COUNT IN BYTES\\ ^THE NUMBER OF BYTES IN THIS MESSAGE HEADER = 10.
.SK 1;.I -30;^^PROTOCOL FUNCT CODE\\ <.EMD6D <>DN60<> DATA
.SK 1;.I-30;^^PROTOCOL DEV CODE\\ <.EMD60
.SK 1;.I-30;^^SPARE WORD\\ ^NOT USED
.SK 1;.I-30;^^DN60 RESULT CODE\\ 1, 2, OR 3
.SK 1;.I-30;^^DN60 FUNCTION CODE\\ 10
.LM -30
.PAGE
.HL 1 ^EXAMINE ^FUNCTION
^TO PERFORM THE EXAMINE FUNCTION (<>DN60<> FUNCTION CODE 9) THE 10
WILL SEND A DIRECT MESSAGE CONTAINING THE ADDRESS TO BE EXAMINED:
.SKIP 1
.LIT
!----------------------------------------------------------!
! MSG COUNT IN BYTES ! PROTOCOL FUNCT CODE (.EMD6D) !
!----------------------------------------------------------!
! PROTOCOL DEV CODE ! SPARE WORD !
!----------------------------------------------------------!
! 0 !DN60 FUN CODE ! ADR (MSB) ! ADR (LSB) !
!----------------------------------------------------------!
.END LIT
.LM +30;.SK 1
.TS 30
.I -30;^^MSG COUNT IN BYTES\\ ^THE NUMBER OF BYTES IN THIS MESSAGE HEADER = 12.
.SK 1;.I -30;^^PROTOCOL FUNCT CODE\\ <.EMD6D <>DN60<> DATA
.SK 1;.I-30;^^PROTOCOL DEV CODE\\ <.EMD60
.SK 1;.I-30;^^SPARE WORD\\ ^NOT USED
.SK 1;.I-30;0 ^NOT USED
.SK 1;.I-30;^^DN60 FUNCTION CODE\\ 9
.SK 1;.I-30;^^ADR\\ ^ADDRESS TO EXAMINE
.PAGE
.LM -30
^THE 11 THEN SHOULD RESPOND WITH THE DATA:
.SKIP 1
.LIT
!----------------------------------------------------------!
! 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) ! ! !
!----------------------------------------------------------!
.END LIT
.LM +30;.SK 1
.TS 30
.I -30;^^MSG COUNT IN BYTES\\ ^THE NUMBER OF BYTES IN THIS MESSAGE HEADER = 14.
.SK 1;.I -30;^^PROTOCOL FUNCT CODE\\ <.EMD6D <>DN60<> DATA
.SK 1;.I-30;^^PROTOCOL DEV CODE\\ <.EMD60
.SK 1;.I-30;^^SPARE WORD\\ ^NOT USED
.SK 1;.I-30;^^DN60 RESULT CODE\\ 1, 2, OR 3
.SK 1;.I-30;^^DN60 FUNCTION CODE\\ 9
.SK 1;.I-30;^^ADR\\ ^ADDRESS EXAMINED
.SK 1;.I-30;^^DATA\\ ^THE DATA IN <ADR
.LM -30
.DO INDEX
.B 6;.CENTER
[^^END OF DN60 MAINTENANCE MANUAL\\]