PDP-9 SUPERVISORY PROGRAMS FOR THE DATA-LINKAGE • TO IBM 360/67 by NAM NG B.Sc. (Eng.) U n i v e r s i t y of Hong Kong, 1967 A THESIS SUBMITTED IN PARTIAL FULFILMENT OF THE REQUIREMENTS OF THE DEGREE OF MASTER OF APPLIED SCIENCE i n the Department of E l e c t r i c a l Engineering We accept t h i s thesis as conforming to the • required standard Research Supervisor Members of the Committee ., Acting Head of the Department Members of the Department of E l e c t r i c a l Engineering THE UNIVERSITY OF BRITISH COLUMBIA August, 1970 In p r e s e n t i n g t h i s t h e s i s i n p a r t i a l f u l f i l m e n t o f t h e r e q u i r e m e n t s f o r an advanced d e g r e e a t t h e U n i v e r s i t y o f B r i t i s h C o l u m b i a , I a g r e e t h a t t h e L i b r a r y s h a l l make i t f r e e l y a v a i l a b l e f o r r e f e r e n c e and s t u d y . I f u r t h e r a g r e e t h a t p e r m i s s i o n f o r e x t e n s i v e c o p y i n g o f t h i s t h e s i s f o r s c h o l a r l y p u r p o s e s may be g r a n t e d by t h e Head o f my Depar tment o r by h i s r e p r e s e n t a t i v e s . I t i s u n d e r s t o o d t h a t c o p y i n g o r p u b l i c a t i o n o f t h i s t h e s i s f o r f i n a n c i a l g a i n s h a l l not be a l l o w e d w i t h o u t my w r i t t e n p e r m i s s i o n . Depar tment The U n i v e r s i t y o f B r i t i s h C o l u m b i a V a n c o u v e r 8, Canada Date ABSTRACT PDP-9 programs are provided for the inter-computer linkage of the PDP-9 i n the Department of E l e c t r i c a l Engineering to the IBM 360/67 i n the Computing Centre of the U n i v e r s i t y of B r i t i s h Columbia. D e t a i l s of the communication procedure used are described. Automatic e r r o r detection and recovery i s incorporated to ensure correct message transmissions. A program "TRSFER" has been w r i t t e n to operate the PDP-9 as a conversational terminal to the IBM 360/67. I t also allows f i l e transfers between the two computers. D e t a i l s of the data-phone handler routine and operation of the program "TRSFER" are given i n the Appendix. i TABLE OF CONTENTS Page ABSTRACT i TABLE OF CONTENTS i i LIST OF ILLUSTRATIONS i v ACKNOWLEDGEMENT v 1. INTRODUCTION 1 2. COMMUNICATION PROCEDURES 4 2.1 Communication Code 4 2.2 Message Format 4 2.3 Message Transfer Control Procedures 6 2.4 Err o r Detection and E r r o r Recovery Procedures 7 3. PROVISIONS MADE FOR THE PDP-9 12 3.1.1 The Data-Phone Handler 12 3.1.2 The Macros 13 3.1.3 Data Modes 14 3.1.4 E r r o r Diagnostic Messages 14 3.1.5 The Handler Routine 15 3.2 The Program "TRSFER" 15 3.2.1 Operation as a Terminal Teletype . . . 15 3.2.2 Data F i l e Transfers 17 4. DISCUSSION 19 APPENDIX I Table of USASCII Codes for Inter-computer Communication . . 21 APPENDIX II The Data-Phone Handler . . . . . 22 i i Page APPENDIX I I I The Macros 24 APPENDIX IV Data Transmission Paths . . . . 33 APPENDIX V E r r o r Detection and Handling . . . . 35 APPENDIX VI Detailed Flow-Charts f o r the Handler Routine . . . . . . . 37 APPENDIX VII The Program "TRSFER" 42 APPENDIX VIII Detailed Flow-Charts f o r the Program "TRSFER" 45 REFERENCES . , 48 i i i LIST OF ILLUSTRATIONS Page F i g . 1. O v e r a l l View of the Communication Linkage between PDP-9 and the IBM 360/67 2 F i g . 2. T y p i c a l Communication Message Format . 4 F i g . 3. General Flow-chart f o r the Message Communication Scheme . . . . 8 F i g . 4. Schematic Flow-chart f or the data-phone handler routine . . . 16 F i g . 5. Schematic Flow-chart f o r the program TRSFER 18 i v ACKNOWLEDGEMENT I would l i k e to express my gratitude to my supervisor,.Dr. G.F. Schrack, f o r h i s constant advice and encouragement during the whole course ' of the pr o j e c t . I would also l i k e to thank Dr. J.S. MacDonald for reading the thesis and h i s valuable comments. A note of appreciation i s given to Mr. W. Dettwiler of the Computing Centre and h i s s t a f f f o r t h e i r co-operation during the experiments, and to Mr. G. Austin f o r h i s t e c h n i c a l assistance. Thanks to Mr. C.Y. Suen and Mr. N. Borowski f o r proof reading the th e s i s , and e s p e c i a l l y to Miss Heather DuBois f o r typing the manuscript. F i n a n c i a l assistance through National Research Council Grant (No. 67-0148) and a Un i v e r s i t y of B r i t i s h Columbia Graduate Fellowship i s g r a t e f u l l y acknowledged. v 1. INTRODUCTION With the development of time-sharing computers, and the f a s t growing v a r i e t y of data processing a p p l i c a t i o n s , the demand for d i g i t a l data transmission has been ever i n c r e a s i n g . I t brought about the interconnection of d i f f e r e n t computers, e s p e c i a l l y small s c i e n t i f i c computers at remote locations to large c e n t r a l time-sharing computers, enabling users at one i n s t a l l a t i o n to communi-cate with, and to make use of the f a c i l i t i e s of the other computer. For these reasons, the PDP-9 computer of the Department of E l e c t r i c a l Engineering i s l i n k e d to the IBM 360/67 of the Computer Centre. This enables users of the PDP-9 to communicate with the IBM 360/67, and to make use of the large storage capacity and f a s t computational a b i l i t y of the IBM 360/67. With t h i s linkage established, more s o p h i s t i c a t e d data-processing a p p l i c a t i o n s can be c a r r i e d out on the PDP-9. Communication between the two computers i s made over voice-grade telephone cables. Two p a i r s of telephone cables are used, one f o r transmission, and the other f o r reception. Full-duplex transmission i s p o s s i b l e , but the linkage operates e s s e n t i a l l y as a half-duplex system. However, there i s s t i l l the advantage of reducing time used i n l i n e reversals i n half-duplex systems, which serves to increase the transmission e f f i c i e n c y considerably. The linkage operates i n a standardized way. Communication code and procedures follow c l o s e l y those of USASCII standards"*" (United States of America Standard f o r Information Interchange)—now the ANS(American National Standard). Hardware has been purchased from The D i g i t a l Equipment Corp. and 2 i s b u i l t according to the EIA ( E l e c t r o n i c Industries Association) Standards . Transmission and reception of data follow binary synchronous con-3 ventions . Data i s transmitted s e r i a l - b y - b i t and s e r i a l - b y - c h a r a c t e r . Correct reception of data depends on b i t and character synchronization of both s t a t i o n s . This i s achieved at the beginning of each transmission by trans-m i t t i n g a synchronization pattern, and once synchronized, the character phase i s maintained u n t i l the end of the transmission. The two computers are li n k e d together i n such a way that the PDP-9 e s s e n t i a l l y operates as a conversational terminal to the IBM 360/67. Data transmission rate i s 2400 b i t s per sec. Due to the data processing a b i l i t y of the PDP-9, data received at the PDP-9 can be processed before they are sent to the IBM 360/67. However, because the IBM 360/67 i s a time-sharing computer and there i s no p r i o r i t y f o r data communication over the linkage, r e a l time data communication i s not po s s i b l e . To ensure correctness of data received, automatic er r o r recoveries by retransmission are incorporated. An o v e r a l l view of the communication linkage between the two com-puters i s shown i n F i g . 1. The PDP-9 i s connected to the communication 4 system v i a the data-phone DP09A from the D i g i t a l Equipment Corporation. The IBM 360/67 M u l t i -plexer PDP-8 Data phone Data set it Telephone cables Data set DP09A C O M P U T I N G C E N T R E ELECTRICAL ENGINEERING DEPARTMENT F i g . 1 O v e r a l l view of the communication linkage between PDP-9 and IBM 360/67 DP09A i s a binary synchronous f u l l - d u p l e x communication channel f o r interconnecting the P D P - 9 to the data set v i a the input-output i n t e r f a c e of the P D P - 9 . I t i s e s s e n t i a l l y a s e r i a l - p a r a l l e l binary data converter. Data from the PDP-9 accumulator are transferred to the DP09A v i a the I/O bus, where i t i s converted in t o a s e r i a l binary stream. I t i s then transmitted.over telephone cables to the IBM 360/67 v i a the data set. The data s e t s , t e c h n i c a l l y known as modems, are b u i l t according to the EIA standards. Data received from the data set are treated i n a reverse manner. They are f i r s t assembled to form p a r a l l e l 8-bit characters i n the data phone before they are transferred to the PDP-9 accumulator v i a the I/O bus. At the computing centre end, data are treated i n a s i m i l a r manner i n the PDP-8. But, before the data are transferred to the c e n t r a l processing u n i t of the IBM 360/67 v i a the multiplexer, a code conversion i s necessary since the communication code f o r the two DEC-computers i s USASCII code whereas the IBM 360/67 works with EBCDIC code (extended binary-coded-decimal interchange code) . The two computers are l i n k e d by dedicated l i n e s . Users of the PDP-9 can communicate with the IBM 360/67 at any time when the l a t t e r i s o p e r a t i o n a l . The procedure used f o r t h i s linkage i s s i m i l a r to any of the other remote terminals of the IBM 360/67. 2. COMMUNICATION PROCEDURES 2.1 Communication Code The USASCII code i s used as the communication code. A table of the codes i s shown i n Appendix I. Each communication character i s formed from the seven b i t s USASCII code with a p a r i t y b i t as the eighth b i t . Odd p a r i t y , as suggested by USASCII standards on communication codes"', i s used. Since the data-phone D P 0 9 A i n s t a l l e d with the PDP-9 works with even p a r i t y synchronous i d l e characters, the l o g i c a l c i r c u i t r y of the D P 0 9 A has been modified to make i t compatible with the communication system. 2.2 Message Format In deciding the message format, the proposed standards have been followed c l o s e l y . However, s l i g h t discrepancies are i n e v i t a b l e . A t y p i c a l communication message i s shown i n F i g . 2. s S S S S S S Y Y Y Y 0 E T N N N N H L X T E X T T E T B C Q X C F i g . 2 T y p i c a l communication message format To i n i t i a t e transmission, the transmitting s t a t i o n sends a number of-i n t h i s system, four—synchronous i d l e characters to e s t a b l i s h synchronization with the r e c e i v i n g s t a t i o n . Following the synchronization procedure, the S t a r t of Heading character (SOH) i s transmitted. This i n d i c a t e s the s t a r t of the heading of the message. The heading i s generally intended to give some i n d i c a t i o n of the content of the message and i s usually not revealed to the user. A Select Character i s included as the heading of the message, to increase the e r r o r detecting a b i l i t y of the communication scheme. This character can only assume two values, v i z . i n 7 b i t s o c t a l , 040 and 060, with p a r i t y included as the eighth b i t . Consecutive messages are transmitted with the Select Character assuming these two values a l t e r n a t e l y . Should re-transmission be necessary, the Select Character assumes i t s l a s t value. Thus, a message currently received i s considered correct and acceptable i f and only i f the Select Character i s d i f f e r e n t from the one i n the l a s t accepted message. This procedure provides v e r i f i c a t i o n on the proper sequence of the messages received. I t should be noted that the two values of the Select Character chosen are quite a r b i t r a r y . Any two values could have been chosen. 6 In some systems only one b i t rather than one character i s used f o r the same purpose. The Start of Text (STX) character i s transmitted following the Select Character. This character i n d i c a t e s the end of the heading and the s t a r t of the actual message or text that i s communicated. The text i s one complete l i n e of data under the Michigan Terminal System (MTS) used by the IBM 360/67. In terms of punch card mode, th i s i s equivalent to one card image] and i n teletype mode, one l i n e of text up to CNTRL Q (+Q) or carriage return. The +Q character i s always transmitted at the end of the message. The text i s terminated by the End of Text (ETX) character, followed by the Block Check Character (BCC, which i s also known as block p a r i t y ) . The BCC i s a text checking character. I t i s formed by taking the sum (modulo 2) of the message, s t a r t i n g from the character following the SOH character, i . e . 6 the Select Character, up to and i n c l u d i n g the ETX character. I t thus acts as a l o n g i t u d i n a l block p a r i t y checking character. Block Check Characters are formed at both ends of the linkage independently and the r e c e i v i n g s t a t i o n i s responsible f o r comparing them. I d e n t i c a l characters i n d i c a t e that the reception has been err o r free and w i l l be accepted i f no other errors are detected. Should the two be d i f f e r e n t , the message received i s considered to be i n c o r r e c t and request f o r retransmission i s made. Af t e r transmitting the BCC, an a l l zero b i t s character i s sent to i n d i c a t e the end of the transmission. The r e c e i v i n g s t a t i o n can then i n i t i a t e to send the acknowledgement or reply. 2.3 Message Transfer Control Procedures Though b a s i c a l l y a f u l l - d u p l e x system, the linkage i s operated i n half-duplex mode. Nevertheless, there i s s t i l l the advantage of obviating the need of l i n e r e v e r s a l s , and t h i s aids to s i m p l i f y the communication co n t r o l procedures. To i n i t i a t e communication, the transmitting s t a t i o n sends a complete l i n e of message i n the format described above. I t then waits i n search mode fo r the acknowledgement from the other s t a t i o n . While i n search mode, the s t a t i o n searches f o r synchronous i d l e characters. Once detected, data-reception i s i n i t i a t e d and the acknowledgement i s examined. The acknowledgement i s i n the form of two consecutive i d e n t i c a l characters. The only v a l i d acknowledgement characters are the P o s i t i v e Acknowledgement (ACK) and the Negative Acknowledgement (NAK). An ACK in d i c a t e s that the l a s t message has been c o r r e c t l y received, and the transmitting s t a t i o n can then proceed to transmit a new l i n e of message, with the Select Character value alternated. Message t r a n s f e r continues i n th i s manner u n t i l a l l messages have been transmitted. 7 I f a NAK i s received, i t indicates that the l a s t transmission has not been c o r r e c t l y received and re-transmission of the message i s required. The message i s re-transmitted with the Select Character value unaltered and the transmitting s t a t i o n waits f o r the acknowledgement again. Up to f i v e re-transmissions are attempted f o r erro r recovery f o r each message. If the er r o r condition s t i l l p e r s i s t s , the communication i s c a l l e d to a h a l t . An error message i s p r i n t e d on the PDP-9 teletype. Under such circumstances, human i n t e r v e n t i o n i s necessary f o r communication recovery. I f neither ACK nor NAK i s received, the acknowledgement i s assumed to be garbled. An Enquiry (ENQ) character i s sent f o r a re-transmission of the acknowledgement. Should t h i s occur f o r more than f i v e times, the communi-cation i s again halted and human i n t e r v e n t i o n i s required. A f t e r transmitting a l l messages, the transmitting s t a t i o n terminates transmission by sending an End of Transmission (EOT) character. I t then waits i n receive mode, giving up i t s r i g h t of transmission to the other s t a t i o n . The message tr a n s f e r procedure i s quite symmetrical f or both s t a t i o n s . However, communication can only be i n i t i a t e d by a request from the PDP-9 since the PDP-9 i s usually i n a passive s t a t e as f a r as this linkage i s con-cerned. The IBM 360/67, on re c e i v i n g the request, can proceed to i n i t i a t e message t r a n s f e r s . F i g . 3 shows a flow-chart f o r the above procedures imple-mented i n the linkage. 2.4 E r r o r Detection and E r r o r Recovery Procedures In e v i t a b l y , errors w i l l occur during message transmissions. I t i s desirable to be able to detect these errors and i f pos s i b l e correct them automatically without human i n t e r v e n t i o n . E r r o r detection and recovery schemes are incorporated for such purposes. Though the scheme i s not p e r f e c t , since i t i s not poss i b l e to detect a l l e r r o r s , the procedure i s quite s u f f i c i e n t to I n i t i a t e Transmission Send new text Wait for acknowledgement Alternate s e l e c t character Send o l d text without change Send l a s t acknowledgement Must be text check f o r e r r o r No Send NAK Output text • F i g . 3. General Flow-Chart of the Message Communication Scheme handle most of the e r r o r s . Errors are detected i n s e v e r a l ways. To ensure that b i t s and characters are sampled at proper times, reception of data i s i n i t i a t e d only a f t e r synchronization of the two s t a t i o n s . A "Time-out" r e s t r i c t i o n i s also imposed on data reception by the data-phone: I f any b i t i s not received 4 w i t h i n 1.5 b i t times, the endflag i s set and i n t e r r u p t s the computer , i n d i -c ating the l o s s of true character phase. The received data i s tested for v e r t i c a l p a r i t y before i d e n t i f i c a t i o n -whether data or c o n t r o l characters. This serves to detect a l l odd numbers of errors that occur i n the seven b i t s of each character. The message i s further tested f o r l o n g i t u d i n a l p a r i t y using the BCC. This detects a l l odd numbers of errors that occur i n any b i t p o s i t i o n of the seven-bit codes. The two p a r i t y checking methods combined act together i n such a way that errors are not detected only i f an even number of errors have occurrred both v e r t i c a l l y f o r each character i n the message and l o g i t u d i n a l l y f o r each of the b i t p o s i t i o n s of the message. Checking by means of the l o g i c a l sequence of the data received i s also performed. At every point of reception, data are tested to ensure that correct or acceptable c o n t r o l characters are received. Messages can only begin with SOH, followed by the Select Character and STX, and terminated by ETX and the BCC. F a i l u r e to detect the c o n t r o l characters i n correct sequence w i l l be flagged as an e r r o r , and an error recovery procedure i s c a l l e d i n t o e f f e c t . The Select Character also plays an important r o l e i n the detection of errors i n message block transmission. I t detects the proper sequence of successive message blocks received and prevents the loss of message blocks. I f there are an odd number of message drop-outs, the error i s always detected. A "Time-out" condition i s also imposed on the acknowledgement of messages. The transmitting s t a t i o n expects to receive the acknowledgement within a c e r t a i n period (10 seconds f o r the PDP-9 and 3 seconds f o r the IBM 360/67) a f t e r i t has transmitted a message. If no reply whatsoever i s received w i t h i n t h i s period, i t i s assumed that the r e c e i v i n g s t a t i o n has missed the l a s t message completely and re-transmission i s c a l l e d into e f f e c t . This safeguards the blank-out of the e n t i r e communication. F i n a l l y , to ensure that the key c o n t r o l characters are received c o r r e c t l y , they are always transmitted i n duplicate. M i s i n t e r p r e t i n g any of the c o n t r o l characters could be disastrous. A simple example i s the misin-t e r p r e t a t i o n of NAK as ACK. The transmitting s t a t i o n would proceed to a new message while the r e c e i v i n g s t a t i o n expects the l a s t message. Though t h i s condition can s t i l l be detected through the s e l e c t character, there i s no way to recover without human i n t e r v e n t i o n . The use of duplicate c o n t r o l characters should reduce the p o s s i b i l i t y of being confronted with such conditions. To correct the errors detected, recovery by means of re-transmission i s c a l l e d i n t o e f f e c t . The transmitting s t a t i o n , on detecting a negative acknowledgement, assumes that the l a s t transmission was i n e r r o r and w i l l r e -transmit the l a s t message. U n t i l i t receives an ACK from the r e c e i v i n g s t a t i o n , the transmitting s t a t i o n w i l l not proceed to the next message. The above err o r detection and c o r r e c t i o n scheme i s not i d e a l i n that i t cannot detect a l l e r r o r s , e s p e c i a l l y consecutive, m u l t i p l e or bursts of e r r o r s . However, the scheme i s quite s u f f i c i e n t f o r detecting s i n g l e or i s o l a t e d e r r o r s , which occur more frequently than multiple e r r o r s . With the incorporation of the above scheme, automatic operation of the linkage system i s p ossible to a great extent. This i s important as f a r as transmission e f f i -ciency i s concerned. With the reduction of human i n t e r v e n t i o n , the e f f e c t i v e roughput i s con s i d e r a b l y i n c r e a s e d . 12 3. PROVISIONS MADE FOR THE PDP-9 3.1.1 The data-phone handler In providing system programs for handling data communication w i t h i n the PDP-9,.the data l i n k to the IBM 360/67 i s treated as one"of the input-output devices of the PDP-9. The software i s made a v a i l a b l e i n the form of a standard I/O handler routine of the PDP-9 Input-Output Programming System 7. I/O macro d e f i n i t i o n s are provided and can be c a l l e d from PDP-9 assembly language programs. When any of these macros are c a l l e d , the handler i s entered v i a a CAL, the appropriate MTS command i s generated and transmitted to the IBM 360/67 v i a the l i n k . To the IBM 360/67, the PDP-9 looks l i k e one of the medium speed terminals. When a MTS command from'the PDP-9 i s received the command w i l l be executed and the output w i l l be di r e c t e d back to the PDP-9. This w i l l be dealt with by the message reception routine i n the PDP-9. The routine f i r s t checks f o r errors and i f any are detected, w i l l i n i t i a t e request f o r re-transmission; otherwise, the message received i s assumed to be correct and w i l l be output on one of the output devices of the PDP-9. Though treated as one of the I/O devices of the PDP-9, the data-l i n k d i f f e r s s l i g h t l y from the other handlers because the IBM 360/67 i s an i n t e r a c t i v e device. I t w i l l respond i n some fashion whenever i t receives a command from the PDP-9. There i s thus no d i s t i n c t i o n as to whether a data transfer on the device i s input or output alone. Message transmission from the PDP-9 i s always accompanied by message reception. Besides, since the IBM 360/67 i s a time-sharing computer, there i s no co n t r o l over the insta n t the IBM 360/67 responds. Once the handler has transmitted a message, i t has to wait i n a receive mode f o r the message from the IBM 360/67. Thus, both 13 input and output of data have to be handled whenever a macro i s c a l l e d . The p r o v i s i o n of the software as a standard I/O handler does not only r e l i e v e the programmer from w r i t i n g h i s own routine for handling data transfers over the l i n k , i t also ensures c o m p a t i b i l i t y with the Monitor System of the PDP-9. In t h i s way, the u n i f i e d way of handling a l l the I/O devices of the PDP-9 i s preserved. D e t a i l s p e r t a i n i n g to the handler are given i n Appendix I I . 3.1.2 The Macros Ten d i f f e r e n t macros are provided. D e t a i l s are given i n Appendix I I I . The Macros provided are by no means s u f f i c i e n t f o r a one to one conversion to a l l MTS commands. Only the more l i k e l y used commands are made a v a i l a b l e . They include commands f o r sending data to the IBM 360/67, s t o r i n g the data i n a f i l e , running the data with a compiled object program, and transmitting the subsequent output back to the PDP-9. To send a p a r t i c u l a r MTS command other than those provided by the macros, the macro .LINK can be c a l l e d . This macro not on.1y allows the user to make up his own commands, i t also allows the user to sp e c i f y the data mode, whether source or binary, and the p a r t i c u l a r output devices used. For data t r a n s f e r to and from the core of PDP-9, which i s the most e f f i c i e n t way of t r a n s f e r r i n g data, the macros .READ and .WRITE can be used. No data t r a n s f e r to any p e r i p h e r a l device i s made and th i s serves to increase the e f f e c t i v e throughput rate of data t r a n s f e r s . One disadvantage i s that the volume of data transferred i s l i m i t e d by the s i z e of the core a v a i l a b l e . 14 3.1.3 Data Modes Data t r a n s f e r i n USASCII codes i s the only data mode a v a i l a b l e at present. Binary data t r a n s f e r i s desirable since the PDP-9 works with binary data. This would require the incorporation of transparent mode binary data 3 communication procedures . Besides, because the PDP-9 has an 18-bit accumu-l a t o r whereas the IBM 360/67 uses bytes (8 b i t s ) , a compromise has to be made i n the number of b i t s used f o r each data word to ensure c o m p a t i b i l i t y . The procedures f o r th i s data t r a n s f e r scheme has not been f i x e d yet, but incorpor-at i o n of the scheme i s to be made. One data conversion scheme i s made a v a i l a b l e . This scheme converts the 18 b i t s binary data of the PDP-9 in t o s i x decimal d i g i t s i n USASCII* before transmitting them to the IBM 360/67. S i m i l a r l y , f o r data received, conversion back to binary i s made before they are stored i n the core of the PDP-9. The only r e s t r i c t i o n i s that the data must be p o s i t i v e integers with magnitude 18 less than 2 . Further d e t a i l s of the data modes are given i n Appendix IV. Any of the above data mode transfers can be made v i a the macro .READ, .WRITE and .LINK by s p e c i f y i n g the corresponding data mode when c a l l e d . D e t a i l s of the c a l l i n g procedures can be found i n Appendix I I I . 3.1.4 Erro r diagnostic messages Error diagnostic messages are pr i n t e d on the PDP-9 teletype whenever errors are detected by the error detection scheme and automatic recovery f a i l s . E rror messages are p r i n t e d i n the form DPERYY (Data-phone err o r YY) where YY indicates the type of the erro r that has caused the communication to come to a s t a n d s t i l l . Errors of this category are mainly due to the garbling of messages * ( 16 i n FORTRAN format s p e c i f i c a t i o n ) . 15 on the l i n e and hence errors are usually transients only, i . e . the same e r r o r may not occur again i f the transmission i s repeated. Another set of error messages, pe r t a i n i n g to the Input-Output Pro-gramming System (IOPS) of the PDP-9, i s also made use of. This set of error messages i s i n d i c a t i v e of the programming errors of the user, and i s not re l a t e d to errors encountered during data t r a n s f e r . A complete l i s t of the erro r diagnostic messages i s given i n Appendix V. I t i s hoped that these two sets of erro r diagnostic messages should provide s u f f i c i e n t diagnostic a b i l i t y f o r using the data-link. 3.1.5 The handler routine A schematic flow chart of the handler routine i s given i n F i g . 4. I t can be divided i n t o three sections. The f i r s t s e ction deals with the entry into the handler and i n i t i a l i z a t i o n f o r the p a r t i c u l a r macro that i s being c a l l e d . The second part deals with the actual handling of data transmission and recep-t i o n . The t h i r d part deals with er r o r detection. Detailed flow charts for the handler are given i n Appendix VI. 3.2 The program "TRSFER" 3.2.1 Operation as a terminal teletype The program "TRSFER", when operated under "command mode", works e s s e n t i a l l y i n the same way a terminal teletype does. Users can type i n commands from the keyboard i n the normal way the MTS operates. Outputs are pri n t e d on the teletype. 16 PDP -9 Monitor System > Data phone Other device handler handlers PART 1 PART 2 Macro entry and i d e n t i f i c a t i o n Data transmission and reception with e r r o r recovery Error routines PART 3 Data-phone e r r o r detection routine ,IOPS Erro r detection routine HALT Return to Monitor F i g . 4. Schematic Flow Chart f o r the Data-Phone Handler Routine 17 3.2.2 Data f i l e t ransfers When operated under " t r a n s f e r mode", the program "TRSFER" can be used f o r f i l e transfers between the I/O devices of the PDP-9 and the IBM 360/67. Operation i s e s s e n t i a l l y s i m i l a r to the Per i p h e r a l Interchange Program (PIP)'' used under the Monitor System. Input devices include key-board, paper tape reader and DECtapes. Output devices can be teletype, paper tape punch or DECtapes. The structure of a t y p i c a l f i l e t r a n s f e r command i s * as follows:- T OPDEV : OPFILE «- IPDEV : IPFILE ; EXT4-where OPDEV and IPDEV speci f y the output and input devices r e s p e c t i v e l y . OPFILE and IPFILE s p e c i f y the output and input filenames r e s p e c t i v e l y , and EXT i s the f i l e extension s p e c i f y i n g the type of data transfer—whether source or binary. For example, the command T 360 : FILE1 + DTI : FILE2 ; SRC 4-causes data stored i n source . f i l e FILE2 on DECtape unit 1 to be transferred to FILE1 i n IBM 360/67. Filenames are required only when the device i s f i l e - o r i e n t e d . For n o n - f i l e - o r i e n t e d devices, no filename s p e c i f i c a t i o n i s necessary. A schematic flow chart f o r th i s program (TRSFER) i s shown i n F i g . 5. Det a i l s of the operation procedure under both command and tr a n s f e r modes are given i n Appendix VII and d e t a i l flow charts are given i n Appendix VIII. * 4- denotes carriage return or alternate mode TRSFER Command mode Get command Send command to 360 y Output on teletype < Re turn Transfer mode < Decode command F i l e t r a n s f e r to PDP-9 Send command to 360 Store data i n PDP-9 F i l e t r a n s f e r to 360 Send data to 360 Return Return F i g . 5. Schematic Flow Chart f o r Program "TRSFER" 19 4. DISCUSSION The data-link was s t i l l not f u l l y operational at the time when th i s thesis was w r i t t e n . The cause of incompletion i s due to the lack of a device support routine i n the PDP-8 at the Computing Centre to handle the i n t e r a c t i v e operation of the linkage. Only data t r a n s f e r from the IBM 360/67 to the PDP-9 is p o s s i b l e at present. Command for the t r a n s f e r has to be entered from a teletype terminal. As f a r as t h i s part i s concerned, the linkage i s now operational. The tests have been c a r r i e d out quite s u c c e s s f u l l y . S l i g h t communication problems arose when output was made on the PDP-9 teletype. This i s because the teletype i s a slow device and i t usually takes more than 3 seconds—the "time-out" p e r i o d — t o complete typing out a l i n e . Very often, transmission and reception occur at the same time, r e s u l t i n g i n the l o s s of •the acknowledgement message. This problem has been overcome by sending an ACK whenever a message which has the same Select Character as the l a s t accepted message i s received. There i s the r i s k of missing message blocks, but that i s an i r r e c o v e r a b l e e r r o r under any circumstances. For a l l the tests that have been c a r r i e d out, no such problem has occurred. Transmission of data from the PDP-9 to the computing centre has also been tested by sending data to the DCT 2000 l i n e - p r i n t e r i n the Computing Centre. The DCT 2000 i s an ASCII communication output device and works with the same communication procedure as our linkage. Data received are p r i n t e d on the DCT 2000. No communication problem a r i s e s , e s p e c i a l l y a f t e r the i n -corporation of the "time-out" scheme i n the PDP-9. For completion of the linkage, the i n t e r a c t i v e communication scheme has to be tested. I t i s hoped that this w i l l be completed i n the near future. The present communication system, a f t e r completion, should provide u s e f u l applications f o r the PDP-9 users. More s o p h i s t i c a t e d data processing 20 problems than before can be c a r r i e d out on the PDP-9. However, there i s s t i l l room f o r improvement. A higher data transmission rate i s d e s i r a b l e . This w i l l be a f i r s t step to the process of carrying out real-time programming over the linkage. Of course, there w i l l s t i l l be the necessity of having p r i o r i t y over other I/O devices attached to the IBM 360/67. Also, i n increas-ing the transmission rate, although the present handler works with no timing problems at the transmission rate of 2400 b i t s / s e c . (and should s t i l l work properly when the rate i s increased to 4800 b i t s / s e c . which i s l i k e l y to be e f f e c t i v e soon), d e t a i l e d considerations have to be given to the execution time necessary to ensure that the program w i l l s t i l l execute without timing problems when the transmission rate i s increased beyond 4800 b i t s / s e c . The i n c o r p o r a t i o n of an a t t e n t i o n i n t e r r u p t i s also desirable so that PDP-9 users can i n t e r r u p t the data communication at any time. With the incorporation of these features, the linkage would become a very useful communication system f o r the two computers. 21 APPENDIX I: Table of USASCII codes f o r inter-computer communications* Third category designated as argument characters (includes the USASCII control charocfer DEL) Control character DEL included in the argumeijf set First category (standard USASCII definitions) • Control charocters Communication control characters Second cotegory designated os Key characters for odditional controls * This table i s taken from Bhushan and Stotz's paper . 22 APPENDIX II:... The Data-Phone Handler 2.1 General Communication between the user program and the handler i s made v i a a CAL i n s t r u c t i o n , followed by the pertinent argument l i s t . The handler i s of the non-reentrant type, which uses the DBR (debreak and restore) i n s t r u c t i o n to leave the handler at p r i o r i t y l e v e l 4, and r e s t o r i n g the l i n k , the extend mode and the memory protect. The content of the accumulator at the time of CAL i s not saved. 2.2 Incorporation of the handler i n t o the system tape The handler i s incorporated into the system tape i n the usual way. D e t a i l s can be found i n Section 3.4.4.7 (P .3-21) i n the PDP-9 Advanced Soft-ware System Monitors Manual (DEC-9A-MAA0-D). Information p e r t a i n i n g to t h i s handler i s as follows: a. The handler name i s DPH. b. Four skip IOTs should be i n SKIP CHAIN for t h i s device handler. STF 702521 SKIP ON TRANSMIT FLAG SRF 702621 SKIP ON RECEIVE FLAG SEF 702541 SKIP ON RECEIVE END FLAG SRI 702561 SKIP ON RING INDICATOR Since a l l the above IOT skips occur when the f l a g i s NOT s e t , i t i s necessary to precede each of these IOTs by a minus sign when entering them in t o the SKIP CHAIN. A f t e r the new system tape has been generated, the binary program DPH. has to be updated into the system l i b r a r y program (.LIBR). Once this has been completed, the data-phone handler i s then a v a i l a b l e f o r usage. The present working version of the data-phone handler has a memory s i z e of 3567 Q core l o c a t i o n s . A shorter version of the handler can be ob-o tained by dispensing with the macros that are not being used. For example, by deleting the .SIGON, .SIGOF. and .RUN macros, the handler would only require 3335fi core l o c a t i o n s . 24 APPENDIX I I I : The macros Macros; provided f o r using the linkage are as follows: NAME FUNCTION CODE PURPOSE .INIT 1 I n i t i a l i z e the device handler .SIGON 2 I n i t i a t e communication between PDP9 & 360 .COPY 3 I n i t i a t e .READ macro .CREAT 4 I n i t i a t e .WRITE macro .RUN 5 Send a gRUN command to 360 .SIGOF 6 Terminate, communication .LINK 7 Send commands as designated by user .READ 10 Transfer data to user l i n e b u f f e r .WRITE 11 Transfer data from user l i n e b u f f e r .WAIT 12 Detect completion of each command to 360 .TRAN 13 I l l e g a l function code to 360 3.1 .INIT FORM: .INIT a,F,R VARIABLES: a = Device Assignment Table (.DAT) s l o t number ( i n o c t a l radix) F (not used) Therefore can have e i t h e r the value 0 or 1 R (not used) EXPANSION: CAL + F ? _ g + a g _ 1 7 1 R 400 DESCRIPTION: The macro .INIT i n i t i a l i z e s the data-phone handler. I t performs a .SETUP f o r the I0T skip f l a g s . .INIT must be given p r i o r to any I/O commands referencing .DAT s l o t a; a separate .INIT command must be given f o r each .DAT.slot referenced by the program. No f i l e type s p e c i f i c a t i o n i s necessary f o r this device as input and output occurs f o r a l l commands. 3.2 .SIGON FORM: .SIGON a, D1,N1,D2,N2 VARIABLE: a = .DAT s l o t number ( o c t a l radix) Dl .= address of ID number Nl = ID number word count i n o c t a l (=4) D2 = address of password and other optimal parameters N2 = Password character count (octal) EXPANSION: CAL + a 2 Dl Nl , D2 N2 DESCRIPTION: The macro .SIGON i n i t i a t e s communication between the PDP-9 and the IBM 360/67. On encountering this macro, the handler sends the command: #SIG IDNO PW = PSWD * to the IBM 360/67. From then on, the linkage i s a c t i v e and data t r a n s f e r between the two computers can be made. Both IDNO and PSWD are assumed to be packed i n 5/7 ASCII at location s Dl and D2 r e s p e c t i v e l y . No header i s required. For the parameter PSWD, i t can include parameters other than the password i t s e l f * The underlined parameters must be replaced by the user with the appropriate parameter. by increasing the word count N2. Thus i f l o c a t i o n D2 contains 'PSWD T=50' and N2 i s s p e c i f i e d as 11 ( o c t a l ) , then the time l i m i t parameter i s also sent. 27 3.3 . C O P Y FORM: .COPY a,D,N VARIABLE: a = .DAT s l o t number ( o c t a l radix) D = address of filename f o r .READ N = filename character count (octal) EXPANSION: CAL + a 3 D N DESCRIPTION: The .COPY macro i n i t i a t e s a ction f o r subsequent .READ macros. D contains the IBM 360/67 filename which i s to be transferred to the PDP-9 core l o c a t i o n s p e c i f i e d by the ..READ macro. On encountering the .READ macro, the command g C O P FILENAME >SYN5 i s sent to the IBM 360/67. Note that '>SYN5' i s the device name . f o r d i r e c t i n g output of IBM 360/67 to PDP-9. 3.4 .CREAT FORM: .CREAT a,D,N VARIABLE: a = .DAT s l o t number ( o c t a l radix) D = address of filename f o r .WRITE N = filename character count (octal) EXPANSION: CAL + a 4 D N 28 DESCRIPTION: The .CREAT macro i n i t i a t e s action f o r subsequent .WRITE macros. D contains the name of the f i l e , packed i n 5/7 ASCII, which i s to be created i n the 360. I t must precede any .WRITE macros. On encountering this macro, the following two commands are sent. , gCRE FILENAME gNUM The user should check beforehand that he has s u f f i c i e n t f i l e space f o r entering user's data when the .WRITE macro i s executed. 3.5 .RUN FORM: .RUN a,Dl,Nl,D2,N2,D3,N3 VARIABLE: a = .DAT s l o t number ( o c t a l radix) Dl .= address of the object filename i n IBM 360/67 which i s to be executed Nl = Object f i l e filename character count (octal) D2 = address of the filename where data i s stored i n IBM 360/67 N2 = Data f i l e filename character count (octal) D3 = address of the f i l e name where r e s u l t i s to be stored i n IBM 360 N3 = Output f i l e filename character count (octal) EXPANSION: CAL + a 5 Dl Nl D2 N2 D3 N3 29 DESCRIPTION: The .RUN macro sends the command gRUN OBFILE 5 = DATAFILE 6 = OPFILE to the IBM 360/67. The object f i l e OBFILE stored i n 5/7 ASCII at l o c a t i o n Dl i s to be executed. Data i s obtained from DATAFILE which i s stored at D2, and r e s u l t s are output on OPFILE stored at D3. ^ 3.6 .SIGOF FORM: .SIGOF a VARIABLE: a = .DAT Sl o t number ( o c t a l radix) EXPANSION: CAL + a 6 DESCRIPTION: The .SIGOF macro when c a l l e d sends gSIG SHORT command to the IBM 360/67, thus terminating the communication between the two computers. Further communication i s re-established only i f .SIGON macro i s again c a l l e d . 3.7 .LINK FORM: .LINK a,M,D,L,N VARIABLE: a = .DAT s l o t number ( o c t a l radix) M = data mode D = output device 0-KTTA teletype 1+DT1 DECtape 1 2+DT2 DECtape 2 3->PP paper punch L = address of the l i n e b u f f e r where the user's command i s stored N = number of characters i n the command (octal) EXPANSION: CAL + M &_ 8 + a g _ 1 7 7 D L N DESCRIPTION: The .LINK macro when c a l l e d sends the user's command ( i n MTS) to the IBM 360/67 for execution. The command i s stored at l o c a t i o n L i n 5/7 ASCII. N i s the number ( i n octal) of charac-ters i n the command. D s p e c i f i e s the output device where the r e s u l t a f t e r the execution of the command i s to be transferred to, and M s p e c i f i e s the data mode (0 = binary, 2 = 5/7 ASCII). 3.8 .READ FORM: .READ a,M,L,W VARIABLES: a = .DAT s l o t number ( o c t a l radix) M = Data mode 0 = binary 1 = image 7 b i t s ASCII 2 = 5/7 ASCII L = Data b u f f e r address W = Data Buffer character count (decimal r a d i x ) , i n c l u d i n g the two word header EXPANSION: CAL + M, „ + a. . _ o-o y - i / 10 L .DEC -W 31 DESCRIPTION: The .READ macro causes the command gCOP FILENAME >'SYN5+to be sent to IBM 360/67. The FILENAME•must be s p e c i f i e d by a previous .COPY macro. Data i s transferred to the data b u f f e r area at l o c a t i o n L, and i n the data mode as s p e c i f i e d by M. The number of words read into L i s delimited by W or when an EOF i s encountered as i n d i c a t e d by the IBM 360/67. Each l i n e of data i s terminated by a carriage return. 3.9 .WRITE FORM: .WRITE a,M,L,W VARIABLES: a = .DAT s l o t number ( o c t a l radix) M = Data mode 0 = binary 1 = image 7 b i t s ASCII 2 = 5 / 7 ASCII L = Data b u f f e r address W = Data b u f f e r character count (decimal radix) i n c l u d i n g the two-word header EXPANSION: CAL + M, Q + a_ n n o—p y—i/ 11 L .DEC -W DESCRIPTION: The .WRITE macro transfers data s p e c i f i e d by L to the IBM 360/67. Data t r a n s f e r stops when the character count goes to zero or when an "alternate mode" i s encountered. Each, l i n e i s terminated by a"carriage return". The data i s transferred to the currently a c t i v e f i l e , and i s normally s p e c i f i e d by the .CREAT macro. At 32 the end of data t r a n s f e r , #UNN followed by $ENDFILE commands are sent before e x i t from t h i s macro. -3.10 .WAIT FORM: .WAIT a VARIABLE: a = .DAT s l o t number ( o c t a l radix) EXPANSION: CAL + A 12 DESCRIPTION: .WAIT macro detects the completion of each macro command. I t should be used a f t e r a l l the data-phone macros with the exception of .LINK before the l i n e b u f f e r associated'is used again, to ensure the data t r a n s f e r i s complete. I f .LINK i s used, l o c a t i o n 32 Q should be checked f o r input-output completion. When i t 8 contains a -1, a l l input and output for t h i s macro are f i n i s h e d , and control can then be returned to user's program. 33 APPENDIX IV: Data Transmission Paths 4.1 Line Buffer Headers Line b u f f e r s f o r th i s handler have the same format as those used by the I/O Monitor System.-. (Section 2.1.1 of PDP-9 Monitor Manual). This ensures co m p a t i b i l i t y with the other I/O devices of the system. Two header words are reserved f o r each b u f f e r and the ac t u a l data s t a r t s a f t e r header word 1. Header word 1 i s not used by this handler. For header word 0, b i t s 14-17 are used to i n d i c a t e the I/O mode. The po s s i b l e b i t combinations are as follows:-0000 = binary mode 0 0001 = Image ASCII mode 1 0010 = 5/7 ASCII mode 2 0101 = EOF (end of f i l e ) , no other b i t combinations being used. B i t s 1-8 are used f o r the word p a i r count, i n c l u d i n g the header word p a i r . But they only give the correct word 8 p a i r count i f the data input or output word p a i r count i s less than 2 -1. Bi t s 0, and b i t s 9-13 are not used. 4.2 Data Modes 4.2.1 Binary mode 0 In t h i s mode, data has the form of 18 b i t s binary i n the l i n e b u f f e r s . Each word i s f i r s t converted to decimal i n ASCII before transmission. I t i s converted i n t o the format 16. For data coming from the IBM 360/67, they are f i r s t converted back to 18 b i t s binary before, they are packed i n t o the l i n e b u f f e r s . Again the format of the data coming i n i s assumed to be 16. 4.2.2 Image ASCII mode 1 In t h i s mode, each word i n the b u f f e r i s assumed to be ready i n the form of 7 b i t s ASCII and i s thus transmitted d i r e c t l y without conversion word by word. Data received are packed i n a s i m i l a r way. 4.2.3 5/7 ASCII mode 2 Data i s assumed to be packed i n the form of 5/7 ASCII. They are compatible with the IOPS ASCII except that the eighth, b i t used during data tr a n s f e r i s taken as the odd p a r i t y b i t rather than even p a r i t y . 35 APPENDIX V: Erro r Detection and Handling Two sets of e r r o r messages are incorporated i n the data-phone handler. The f i r s t set, p e r t a i n i n g to the .IOPS, i s u s e f u l f o r debugging programs. The second set i s pertinent to data transmission over the linkage and usually i n d i c a t e s i r r e c o v e r a b l e e r r o r s . 5.1 Data-Phone Erro r Messages (DPER) Error messages are i n the form of DPERXX where XX in d i c a t e s the error code. (1) DPER00 = Message transmitted not accepted by IBM 360 (2) DPER01 = Acknowledgement from IBM 360 garbled (3) DPER02 = Acknowledgement not accepted by IBM 360 (4) DPER03 = End of transmission not received by the IBM 360 (5) DPER04 = Garbled co n t r o l characters received at the PDP-9 end (6) DPER05 = Data set not ready while entering receive mode. (IOPS04 i s in d i c a t e d i f power i s not turned on at the beginning of transmission) (7) DPER06 YY: Garbled text received by the PDP-9. YY indicates the cause of text garbling. YY = 01 Wrong s e l e c t characters i . e . an odd number of text l i n e s are missed. =02 -> No Sta r t of Text (STX) character received = 04 Wrong block checking character = 1 0 -> Wrong v e r t i c a l p a r i t y detected i n one or more characters of the text 36 = 20 -*• No end of text character received For multiple e r r o r s , YY w i l l appear as a combination of the above codes. Thus YY = 14 in d i c a t e s that both v e r t i c a l and l o n g i t u d i n a l p a r i t y error occurred. 5.2 .TOPS er r o r messages Erro r message i s i n the form of IOPS NN XXXXXX where NN i s the erro r code and XXXXXX the a d d i t i o n a l r e l a t e d i n f o r -mation, usually address of CAL. (Refer to PDP-9 Monitors Manual Section 2.6 f o r d e t a i l s ) . (1) IOPS04 - Data-set not ready (2) IOPS06 - I l l e g a l function f o r device handler. In t h i s handler, function code 13 (octal) i s i l l e g a l (3) IOPS07 - I l l e g a l data mode f o r device handler. At present, only mode 0,1,2 are l e g a l data modes f o r .READ and .WRITE (4) I0PS11 - .COPY (.CREAT) not executed before .READ (.WRITE) macro (5) I0PS16 - Output b u f f e r overflow. This occurs on .READ when more characters are received than s p e c i f i e d . The above set of erro r messages usually i n d i c a t e s errors made by the programmer. They do not i n d i c a t e errors encountered during t r a n s f e r of data over the data l i n k . APPENDIX VI Enter Handler Get function code Yes P r i n t E r r o r Return to Monitor .INIT I Jump to Service Routine Return Standard Buffer s i z e Setup f o r flags Clear I/O underway Interrupt Skip Chain Enter Save AC Memory Protect Yes — « — Service transmit f l a g Break from l e v e l 4 Yes Return to user's program Service receive f l a g Yes - « — Service end f l a g . Yes Service r i n g i n d i c a t o r Read status and h a l t (I) The Handler I n i t i a l i z a t i o n Routines 38 I n i t i a l i z e to re-transmit I n i t i a l i z e to transmit —^ *^-Send SOH, SEL, STX Send Text Send +Q, ETX, BCC Wait for acknowledgement I n i t i a l i z e time out Yes —«a— Turn Clock o f f Yes I n i t i a l send new ize to text A l t e r s e l e c t c nate naracter (II) Text Transmission Routine 39 Synchronize to receive Retransmit acknowledgement I n i t i a l i z e BCC No Set e r r o r i n d i c a t o r 1 Select OK? Yes No — STX? Set e r r o r i n d i c a t o r Yes Send i \ Outpu t b u f f e r No ETX? Yes BCC correct? Set error i n d i c a t o r Yes No Endflag No Erro r .Encountered?^ Yes Enough T r i a l s ? Send NAK Yes Return to transmit mode X Pack text into user's b u f f e r No P r i n t error and h a l t (III) Text Reception Routine 40 No No Error IQPS 11 Check Data mode Set output unpack routine Send #CRE command Send $NUM command r Send text from user's b u f f e r Send #UNN command Set input pack routine Send gCOPY command 1 Receive text and pack into user's bu f f e r No • «a—C Finished? > rYes E x i t Send gENDFILE command Exi t (IV) The .WRITE and .READ Macros 41 .LINK Set output mode .SIGON Get 'command' address Get 'command' character count I Send command Output data on device selected No Send gSIGNON command r E x i t .SIGOF Send gSIGNOFF command E x i t (V) The .LINK, .SIGON, .SIGOF and .RUN Macros 42 APPENDIX VII: The Program TRSFER 7.1 Loading procedure and commands The program TRSFER i s loaded by the Linking Loader. When i t i s loaded, the data-phone handler (DPH.), Dectape Handler (DTA.), paper tape punch handler (PPA.) and paper tape reader handler (PRA.) are a l l loaded. Before loading, the user's .DAT s l o t devices should be assigned as follows :-DTA1 1 DTA2 2 DPH 5 PRA 6 PPA 7 TTA 10 When TRSFER s t a r t s execution, i t p r i n t s the following on the teletype 360-LINK COMMAND MODE # This i n d i c a t e s that TRSFER i s ready to accept command from the keyboard to be typed on the same l i n e of '#' si g n . The user can now use the keyboard as an ordinary remote terminal teletype by entering MTS commands. Output i s pri n t e d on the teletype as w e l l . Successful completion and readiness f o r the next command i s again i n d i c a t e d by the '//' s i g n . To enter f i l e t r a n s f e r mode, the command TRANSFER followed by a carriage return (ALT mode i s i l l e g a l ) should be entered at the keyboard. The short form T followed by carriage return i s also v a l i d . On detecting T+ or TRANSFER-t-, the following message i s typed, TRANSFER MODE At t h i s point, the user should prepare the input/output devices which are required to be ready and then type the data f i l e t r a n s f e r command. When i n command mode, i f a command beginning with T but not t e r -minated i n one of the two allowed formats i s encountered, the message 'WHAT?' i s output on the teletype and the '#' sign i s again p r i n t e d . The user w i l l then have to re-type the command. To revert back to command mode when i n transfe r mode, the command C or COMMAND i s typed. The messages COMMAND MODE it w i l l again be pr i n t e d to i n d i c a t e that i t i s ready to accept further commands In Transfer Mode, the general format of a command s t r i n g i s as follows:-T DEVI : FILE1 -c- DEV2 : FILE2 ; EXT+ where T in d i c a t e s f i l e t ransfers DEVI i s the output device DEV2 i s the input device FILE1 i s the output filename FILE2 i s the input filename and EXT i s the f i l e extension which can be source (SRC) or binary (BIN) Ei t h e r the output or input device has to be the IBM 360/67, which i ; designated as 360. I t i s also i l l e g a l to have both DEVI and DEV2 as I/O devices of the PDP-9. Filename can be omitted i f the device i s not f i l e -o riented. PDP-9 filenames are l i m i t e d to s i x characters whereas 360 f i l e -names cannot be longer than 16 characters. Spaces i n between filenames and device names are ignored when encountered. 7.2 Error Messages 1. 'WHAT?1 i s pri n t e d when i n command mode, a command i s encountered which begins with T but i s not i n the form T4- or TRANSFER + . I t i s also p r i n t e d when i n transfe r mode, the command begins with C but i s not i n the form C4- or COMMANDS. 2. 'ILLEGAL COMMAND' i s printed when a transfe r mode command does not conform to the standard format. 3. 'NO OUTPUT DEVICE UNIT?* i s pri n t e d i f no output device unit i s s p e c i f i e d i n the t r a n s f e r mode command. 4. 'NO OUTPUT FILENAME?' i s pri n t e d i f no output filename i s s p e c i f i e d . 5. 'SAME DEVICE FOR INPUT AND OUTPUT' i s pri n t e d when both input and output device units are 360. 6. 'NO INPUT DEVICE UNIT?' i s p r i n t e d i f no input device unit i s s p e c i f i e d . 7. 'NO INPUT FILENAME?' i s pri n t e d i f no input filename i s s p e c i f i e d . 8. 'DATA MODE REQUIRED!' i s pri n t e d i f no f i l e extension i s given. 9. 'ILLEGAL DATA MODE' i s pr i n t e d i f the f i l e extension i s neither SRC nor BIN. 10. 'DEVICE NAME TOO LONG' i s pri n t e d i f device name i s more than 3 characters 11. 'FILE NAME TOO LONG' i s p r i n t e d i f filename i s more than the allowed length. 12. 'ILL DEVICE UNIT' i s pr i n t e d when the device name i s i l l e g a l or when neith e r the input or output device i s 360. Legal device names include 360, DTI, DT2, PPA (PP) , PRA(PR) and TTA (TT). A f t e r p r i n t i n g the e r r o r message, the r i g h t bracket sign (or the // sign when i n command mode) w i l l again be pr i n t e d . The command has to be r e -entered e n t i r e l y . APPENDIX VIII I n i t i a l i z e I/O devices Enter command mode 1 Wait f o r command from TTA Read i n command and tes t P r i n t Error No Send command to 360 and output on TTA Yes Enter Transfer mode Wait f o r command from TTA Read i n command and t e s t Yes P r i n t E r r o r Yes Decode command and complete data tran s f e r (I) O v e r a l l Flow-Chart for Program TRSFER 46 Get output device name and filename Get input device name and filename Check extension -source or binary No Set binary pack and unpack routines Yes Set ASCII pack and unpack routines No P r i n t e r r o r and return No I n i t i a t e f i l e t r ansfer to 360 I n i t i a t e f i l e t r a n s f e r to PDP-9 (II) Decoding f i l e Transfer Commands 47 I n i t i a l i z e i n p u t device I n i t i a l i z e output device Seek i n p u t f i l e on device Create f i l e on PDP- 9 Create output f i l e on 360 Send command to 360 f o r data t r a n s f e r T ransfer data from in p u t device to PDP-9 core Receive data from 360 Send to data 360 No Store data i n output device I/O Termination and r e t u r n Yes I/O Termination and r e t u r n ( I I I ) F i l e T r ansfer to 360 (IV) F i l e T r ansfer to PDP-9 48 REFERENCES 1. Proposed USA Standard Data Communication Control Procedures f o r the USA Standard Code f o r Information Exchange,Communication of the ACM. V o l . 12, No. 3, March 1969, p. 166-178. 2. EIA STANDARD RS-232-B Interface between Data Processing Terminal Equipment and Data Communication Equipment, October 1965. 3. Eisenbies, J.L., Conventions f o r D i g i t a l Data Communication Link Design. IBM Systems Journal, V o l . 6, No. 4, 1967, p. 267-302. 4. DP09A Bit-Synchronous Data Communication Channel I n s t r u c t i o n Manual. DEC-09-H8AA-D, D i g i t a l Equipment Corporation, Maynard, Mass., U.S.A. 5. Proposed USA Standard Character Structure and Character P a r i t y Sense for S e r i a l - b y - b i t Communication i n the American Standard Code for Information Interchange. Communication of the ACM. Vol. 8, No. 9, Sept. 1965, p. 553-556. 6. Lynch, W.C., R e l i a b l e Full-Duplex F i l e Transmission over Half Duplex Telephone Lines. Comm. of the ACM, Vol. 11, No. 6, June 1968, p. 407-410. 7. PDP-9 Advanced Software System Monitors Manual DEC-9A-MAA0-D, D i g i t a l Equipment Corporation, Maynard, Mass., U.S.A. 8. Bhushan, A.K. and Stotz, R.H., Procedures and Standards f o r Inter-Computer Communications. AFIPS Conference Proceedings, SJCC, 1968, Vol. 32, p. 95-104.