UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

PDP-9 supervisory programs for the data-linkage to IBM 360/67 Ng, Nam 1970

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
831-UBC_1970_A7 N4.pdf [ 2.44MB ]
Metadata
JSON: 831-1.0093320.json
JSON-LD: 831-1.0093320-ld.json
RDF/XML (Pretty): 831-1.0093320-rdf.xml
RDF/JSON: 831-1.0093320-rdf.json
Turtle: 831-1.0093320-turtle.txt
N-Triples: 831-1.0093320-rdf-ntriples.txt
Original Record: 831-1.0093320-source.json
Full Text
831-1.0093320-fulltext.txt
Citation
831-1.0093320.ris

Full Text

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. 

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.831.1-0093320/manifest

Comment

Related Items