pn-166 The RSX-11M Communications Driver Ben Burch Vicky White Fermilab P.O.Box 500, Batavia, Il 60510 This document describes the system interface to the RSX communications driver. The QIO and GETLUN system service calls are described in detail. Those wishing to write applications software for interprocessor or inter-task communication are referred to FORTRAN callable routines CDPACK, which give simpler and RT-11/RSX/VMS independent access to the communications driver functions described here (see PN-159). November 23rd 1982 The RSX-11M Communications Driver Page 2 1.0 INTRODUCTION . . . . . . . . . . . . . . . . . . . . 2 1.1 DR11-W Links . . . . . . . . . . . . . . . . . . . 2 1.2 Logical Link Protocol . . . . . . . . . . . . . . 2 1.3 References For Further Information . . . . . . . . 2 2.0 GET LUN INFORMATION MACRO . . . . . . . . . . . . . 3 3.0 LOGICAL UNITS AND CD UNIT NUMBERS . . . . . . . . . 4 4.0 QIO MACRO . . . . . . . . . . . . . . . . . . . . . 4 4.1 Subfunction Bits . . . . . . . . . . . . . . . . . 5 4.2 IO.SPA - Set Packet Type Code Affinity . . . . . . 6 4.2.1 Pending Message AST Routine . . . . . . . . . . 6 4.3 IO.RPA - Remove Packet Type Code Affinity . . . . 7 4.4 IO.RLB - Read Logical Block . . . . . . . . . . . 7 4.5 IO.WLB - Write Logical Block . . . . . . . . . . . 7 4.6 IO.SIG - Send Signal . . . . . . . . . . . . . . . 8 4.7 IO.REJ - Reject Data Block . . . . . . . . . . . . 8 4.8 IO.STU - Get Driver Status . . . . . . . . . . . . 8 4.9 IO.KIL - Cancel All Reads And Writes To Link . . . 9 4.10 IO.CLN - Cancel All Packet Type Code Affinities . 9 5.0 LINK HIBERNATION SERVICES . . . . . . . . . . . . . 9 5.1 SF.SLP - Sleep Subfunction . . . . . . . . . . . . 9 5.1.1 IO.AWA - Awaken CD Driver . . . . . . . . . . . 9 6.0 PROGRAMMING HINTS . . . . . . . . . . . . . . . . 10 6.1 Vertical Parity Support And Data Validation . . 10 6.2 Retry Of Unsucessful Transfer . . . . . . . . . 10 6.3 Speed And Space Considerations . . . . . . . . . 10 6.4 Full Duplex - Half Duplex Considerations . . . . 10 6.5 Redirection Of Device . . . . . . . . . . . . . 11 6.6 Unloading A Loadable Driver . . . . . . . . . . 11 7.0 POWERFAIL . . . . . . . . . . . . . . . . . . . . 11 8.0 SYSGEN OPTIONS REQUIRED . . . . . . . . . . . . . 11 9.0 IO FUNCTION AND SUB-FUNCTION CODES . . . . . . . . 11 10.0 STATUS RETURNS . . . . . . . . . . . . . . . . . . 13 The RSX-11M Communications Driver Page 3 1.0 INTRODUCTION The Communications Driver (CD: driver) is a loadable driver which primarily handles communication between tasks running in machines connected together by a DR11-W to DR11-W link. The driver can support multiple DR11-W links. This driver also handles communication between tasks within the same machine. "Communication between tasks" means the sending of a message from one task to another. A message may be either a single byte of control information (termed a _ _______ Signal) or a block of data up to 32K 16 bit words long. A block of data is transferred directly from the sending task's buffer to the receiving task's buffer, either across the DR11-W link or by a memory-to-memory copy. Notification of the arrival of signals is made using the RSX AST mechanism. 1.1 DR11-W Links A DR11-W link between two machines consists of a DR11-W DMA controller on each of the machines, connected by a parallel cable not longer than 50ft. Each machine has independent control of its DR11-W but can interrupt the other machine by manipulation of CSR bits, and can pass single 16 bit data words to the other machine, via registers provided for such programmed I/O transfers. The communication driver implements a link level transmission protocol (see references below) in order to allow data to pass bi-directionally across the link. This protocol assures 'fair' access to the link and allows the sender of a block of data to know whether the data has been successfully transferred to by the other machine. 1.2 Logical Link Protocol The communication driver, in addition to controlling the link hardware implements the protocol necessary for task to task communication. The destination of a message is denoted by a single word identifier, called a packet type code (PTC). The driver handles ownership of packet type codes and the delivery of data to the correct destination. 1.3 References For Further Information For a more detailed discussion of the DR11-W hardware, the link level protocol, the general concepts of routing of blocks of data to the appropriate task and the overall framework of interprocessor communication in which this driver serves as a tool; the reader is referred to the following documents. The RSX-11M Communications Driver Page 4 1. Digital Equipment Corporation: DR11-W Direct Memory Interace Module User's Guide. 2. DS-77 - DR11-W as a link device - The Transmission Protocol. 3. DS-80 - Application Level Protocol. 4. PN-160 - High Speed Interprocessor Data links using the DR11-W. 5. PN-161 - Using the DR11-W DMA device for Interprocessor Communications in RT-11. 6. PN-162 - An RSX-11M Device Driver Implementing Network Protocols on the DR-11W. The purpose of this document is not to discuss the whole framework of interprocessor and inter-task communication but rather to list the functions performed by the CD driver.The document is in a similar form to the RSX-11M I/O driver's reference manual. All information necessary to interface directly with the CD driver can be found in the sections following. 2.0 GET LUN INFORMATION MACRO Word 2 of the buffer filled by the Get LUN Information system ____ _ directive contains the first device characteristics word. This word is 0 for the CD: device. Word 3 contains the driver State word (shown in octal) ____ _ 1 = IDLE No transfer of message in progress 2 = ASTQUE Data transfer in progress - awaiting receiver's buffer 4 = RECPEN DMA in progress receiving data block 10 = WTLACK Link bid initiated, waiting link acknowledge 40 = WTPTC Have acknowledged link bid, waiting for PTC 200 = WTSGAK Have sent Signal, waiting for Signal acknowledge 400 = WTRCWC Have sent word count, waiting Receivers word count 1000 = TRANSF DMA in progress sending data block 2000 = WTXMWC Have sent PTC acknowledge, waiting for word count 4000 = DOWN Link down 10000 = STWAIT Waiting for Start acknowledge 60000 = FORKED Waiting to execute, or executing Fork level code Word 4 contains the total number of link level protocol starts or ____ _ re-starts which have been attempted by the driver. When the other end of the link is not responding to link start requests (either turned off, or not running DR11-W link software) this number rapidly becomes large. Once the link is "up" this number is incremented by one only The RSX-11M Communications Driver Page 5 when a failure in the link protocol occurs. Word 5 is not used by the driver at present. In future it may be used ____ _ for flow control on the link when we would like to favour the flow of data in one direction. It corresponds to the fourth device characteristic word whose value can be modified by the MCR command SET /BUF=CDn: 3.0 LOGICAL UNITS AND CD UNIT NUMBERS Each physical link (DR11-W to DR11-W connection) has a different CD device If the driver is assembled with the intraprocessor option then the internal link is the highest CD unit number. A task may assign logical units to CD device units in the normal way. In principal more than one LUN can be assigned to the same CD unit number. The driver's data bases however, are on the basis of CD unit numbers, not task logical units. When a task declares which types of messages it intends to receive this information is correlated with the CD unit number of the LUN on which the declaration is made. Similarly Read requests on a LUN are correlated with the CD unit number and type of message rather than the LUN number. This means that if multiple LUNs are assigned to the same CD unit number, cancellation of I/O requests such as IO.KIL and IO.CLN made on any one of the LUNs will cancel all outstanding request for a particular CD unit number, regardless of which LUN those requests were made on. 4.0 QIO MACRO Table 1 lists both the standard and non-standard functions of the QIO macro which are valid for the CD driver. Table 1 _____ _ QIO functions for CD Driver ___ _________ ___ __ ______ ------------------------------------------------------------------------------ Format Function ------------------------------------------------------------------------------ QIO$C IO.SPA,...., Declare Packet type code affinity QIO$C IO.RPA,...., Remove Packet type code affinity QIO$C IO.RLB,...., Read logical block QIO$C IO.WLB,...., Write logical block QIO$C IO.SIG,...., Send signal QIO$C IO.REJ,.... Reject data block awaiting receiver buffer space The RSX-11M Communications Driver Page 6 QIO$C IO.STU,...., Return Driver Status QIO$C IO.KIL,.... Cancel IO.RLB,IO.WLB and IO.SIG request QIO$C IO.CLN,.... Remove all packet type code affinities QIO$C IO.AWA,.... Restore driver ownership of DR11W interrupt vector ------------------------------------------------------------------------------- where: PTC is the packet type code value. This must be a value between 0 and 255. astadd is the address of an AST routine which will be entered whenever a signal for the specified PTC arrives, or when a sender wishes to send a data block with the specified PTC, but no IO.RLB function has been issued. The AST address must be within the task's address space. stadd is the starting address of a data buffer. The address must be word aligned. size is the size of the stadd data buffer in bytes. The specified size must be even, non-zero and will be interpreted as an unsigned integer between 1 and 65,534 The buffer muxt be within the task's address space. signal is a data word, the low byte of which will be interpreted as a signal value. 4.1 Subfunction Bits Three subfunction bits are used by the communications driver. Table 2 shows which QIO functions each of the subfunction bits may be applied to. Any valid combination of subfunction bits may be used on an I/O function code Table 2 _____ _ QIO sub-functions for CD driver ___ _____________ ___ __ ______ ------------------------------------------------------------------------------- Subfunction May be used with Description ------------------------------------------------------------------------------- SF.SLP IO.RLB,IO.WLB On successful (or truncated transfer) completion of the I/O function, driver must 'sleep'. This means surrender control of the DR11W device interrupt vector. SF.RSW IO.RLB,IO.WLB,IO.SIG Resource wait subfunction. The I/O request will be queued even if the link is not 'UP'. It will await successful startup of link protocol. SF.RDQ IO.RLB The I/O request will be queued unless it is needed for a data block already in the process of being received. The RSX-11M Communications Driver Page 7 IO.RLB packets which do not have this subfunction bit will terminate with an error status unless they do pertain to a pending data block, awaiting a receiver buffer. ------------------------------------------------------------------------------- 4.2 IO.SPA - Set Packet Type Code Affinity This I/O function is used to declare which type of messages a task wishes to receive or to be notified of the arrival of. When a task successfully issues an IO.SPA function for a packet type code it establishes an "affinity" for messages with this PTC, for a particular CD unit number. This affinity or ownership of a particular PTC then ensures that all messages arriving over the link with this PTC destination identifier, are passed to the owning task. A task may not issue an IO.RLB QIO function for a particular PTC, without first having established an affinity for that PTC. The IO.SPA function call must specify the address of an AST routine as the second parameter. This AST routine will be entered whenever a signal for the specified PTC arrives, or whenever a sender on the other machine wishes to write a data block with this PTC, to the link, but no IO.RLB function has been issued and queued for this PTC. A task may issue the IO.SPA function for an arbitrary number of packet type codes. Any number of IO.SPA function calls may have the same AST address specified. The task can distinguish between different PTC's from the parameters passed to the AST on the stack. Each successful issuance of an IO.SPA function leads to the creation of a seven word in-pool data structure. Once a task has established a packet type code affinity for a particular PTC, on a particular CD device unit number, IO.SPA functions for that same PTC issued by other tasks will terminate with an error status. The IO.SPA QIO function terminates immediately leaving the task awaiting incoming messages, but without pending I/O, so therefore potentially checkpointable. This function is handled even if the physical link is not "up". 4.2.1 Pending Message AST Routine - On entry to the AST routine the stack contains several parameters, which must be removed before exiting the AST. The stack contents are: SP+6 Physical unit number of DR11-W with pending incoming message. SP+4 If positive is the Word Count of the pending incoming data block, sender is asking to send. If negative the low byte of this word is a signal value SP+2 Packet type code of pending incoming message SP+0 Stack displacement to be added to SP on exit to remove all parameters from stack The RSX-11M Communications Driver Page 8 The incoming message may be either a signal or a data block. The receiver does not need to issue a QIO to receive the signal since it has already been passed as a parameter on the stack. If the AST has been entered to notify the task that a sender is trying to write a data block there can be several possible outcomes. The data block to be sent is already 'pending' when the AST routine is entered, which means that the link is busy and no further messages can be transferred over the link, in either direction, until this particular transfer terminates. The ways in which it may terminate are: 1. Task may issue IO.RLB QIO function to receive the full data block. 2. Task may issue IO.RLB QIO function with smaller word count than that passed as a parameter on the stack. Truncated data block transfer will take place. 3. Task may issue IO.REJ QIO function to indicate that it does not wish to receive this message, at this time. 4. Task may take no action. After approximately 2 seconds the pending data block transfer will terminate with a time-out error status. NOTE: during this 2 seconds the link will not be able to be used for other transfers, so this is not a recommended course of action. 5. Other error condition (see table of errors in Section ). 4.3 IO.RPA - Remove Packet Type Code Affinity The IO.RPA function removes a previously declared ownership (affinity) of a particular packet type code. If IO.RLB QIO functions have been issued and queued for this particular PTC then the IO.RPA function will terminate with an error status. 4.4 IO.RLB - Read Logical Block The IO.RLB function is used to read a logical block of data from a link (either a DR11-W interprocessor link, or the internal intraprocessor link). If the SF.RDQ subfunction bit is not set then this function will succesfully read a block of data only if it is issued to read a pending data block, by the task owning the packet type code of that data block. If the SF.RDQ subfunction bit is set then this function will successfully read a block of data whenever a data block for that packet type code is next sent over the link. (This may be immediately if there is actually a pending data block when the QIO is issued). The "size" parameter on the IO.RLB QIO specifies the maximum block size that may be read. If this is smaller than the size specified by the sender of a data block (e.g. on the IO.WLB QIO ) then only "size" bytes of data will be transferred from the sender's buffer to the The RSX-11M Communications Driver Page 9 receiver's buffer. The IO.RLB QIO function will terminate with a Data overrun error status. See table of error statuses in Section for this and other possible error status returns. 4.5 IO.WLB - Write Logical Block The IO.WLB function is used to write a block of data to the link (either a DR11-W interprocessor link, or a intraprocessor link) Any legal packet type code may be specified to identify the destination of the block of data. There are several possible outcomes when a task issues an IO.WLB QIO function: 1. The packet type code specified is not owned by any task/program on the destination machine. An error status is returned from the QIO. 2. The full data block is read into a receiver's buffer. 3. Part of the data block is read into a receiver's buffer. A data overrun error status will be returned by the IO.WLB QIO. 4. The packet type code specified is owned by some task/program but the data block is not read from the link into a receiver's buffer (e.g. with a IO.RLB QIO function for an RSX-11M destination system) within the timeout period. The timeout period is approximately 2 seconds. 5. The packet type code specified is owned by some task/program but the data block is rejected by that owner (e.g. with an IO.REJ QIO function for an RSX-11M destination system). 6. Other error condition (see table of errors in Section ). 4.6 IO.SIG - Send Signal The IO.SIG function is used to send a one byte value (a Signal) to the owner of the specified packet type code. If the specified packet type code is not owned the IO.SIG function will return an error status. If the specified packet type code is owned the Signal will be successfully sent over the link to the receiving program. 4.7 IO.REJ - Reject Data Block The IO.REJ function may be used by a task when a sender wishes to write a data block with a packet type code owned by the task. A task when declaring a packet type code affinity implicitly states that it wishes to receive all messages with that packet type code. In normal The RSX-11M Communications Driver Page 10 operation, a task which is informed of a pending data block by the AST mechanism described above, will proceed to read the data block into a buffer. It may however instead choose to reject receipt of the data block, perhaps because of insufficient buffer space. The reject mechanism allows the pending data block transfer to be terminated immediately and the link thus freed for further messages. 4.8 IO.STU - Get Driver Status This function may be used to obtain the driver's current state. The state word returned is the same as Word 3 returned by the Get LUN information system directive, and described in Section 2. 4.9 IO.KIL - Cancel All Reads And Writes To Link The IO.KIL function will cause cancellation of all queued IO.RLB, IO.WLB and IO.SIG QIO functions, for the CD unit number corresponding to the LUN on which the IO.KIL is issued. The IO.KIL function does not affect an IO.RLB, IO.WLB or IO.SIG function which is actually currently being processed by the driver. This will terminate normally or timeout within the normal timeout period. 4.10 IO.CLN - Cancel All Packet Type Code Affinities The IO.CLN function will cancel all packet type code affinities for the CD unit number corresponding to the LUN on which the IO.CLN is issued. However the IO.CLN function will only successfully carry out this cancellation if there are no queued IO.RLB QIO functions. Normally the driver is called with this particular IO function only by the executive, during Task run-down, and after an IO.KIL has already been processed. 5.0 LINK HIBERNATION SERVICES 5.1 SF.SLP - Sleep Subfunction The CD driver will disconnect from the DR11W device interrupts, thus allowing a privileged task to connect to interrupt, on succesfull processing of a read or write logical block function which has the SF.SLP subfunction. In order to properly interlock the passing of control of the link to two privileged tasks, one in each machine, a proper protocol between the two tasks must exist, coordinating the use of "write block of data and sleep" QIO function with the use of "read block of data and sleep" function on the receiving end of the link. The RSX-11M Communications Driver Page 11 By this means control of the link hardware can be passed from the two device drivers to the two special link tasks with all other queued I/O functions remaining queued by both drivers to await return of the link control to the driver. The passing of control at both ends of the link is in fact accomplished within a single data block transfer. 5.2 IO.AWA - Awaken CD Driver When a privileged task has relinquished its connection to the DR11W interrupt vector the CD driver must be informed that it may regain control of the device, restart the link protocol and continue processing its queued I/O requests. The IO.AWA function is used for this purpose. If the device interrupt is still connected to a task when this function is issued then an error status return will be given. 6.0 PROGRAMMING HINTS 6.1 Vertical Parity Support And Data Validation The DR11W does not support vertical parity. In all our tests on transfers of blocks of data of varying sizes across a DR11-W to DR11-W 50 ft. link we have had no instances of errors in the data. 6.2 Retry Of Unsucessful Transfer The transfer of a signal or block of data from the sender to a receiver may fail for a number of reasons. For example there may be no suitable receiver, the receiver may fail to issue a read for the data within a timeout period or the DR11-W device itself may assert an error condition such as non-existant memory. The CD driver never tries to re-transmit a message whose transfer has failed, whatever the reason for the failure. The failure is reported as an error status to the sender of the block, and also to the receiver if the transfer had reached a stage where an actual IO.RLB QIO function was being processed. Certain types of error status returned to the sender of a message are such that the sender knows that the receiver has no information about this message, in fact there is no receiver. Other types of error status returned to the sender indicate that the receiver exists but has either failed to read the data or chosen to reject the data. The final type of error status involves both the sender and the receiver. Data transfer from the sender buffer to the receiver buffer is actually attempted, but the transfer fails in some way. This latter type of error is extremely rare. It is not an expected statistical feature of the hardware. Recovery from all such errors is handled by the CD driver. The RSX-11M Communications Driver Page 12 6.3 Speed And Space Considerations The driver may optionally be assembled with a debug trace feature. This takes up approximately 800 words for a driver with an actual DR11-W link. The trace feature even if present in the driver need not be enabled. There are about 3 milliseconds of additional overhead on each transfer when the trace option is enabled. Each declaration of a packet type code affinity causes a 7 word pool block to be allocated by the driver. These pool blocks are linked together and when a message arrives over the link the linked list of pool blocks is searched fo an appropriate packet type code. Obviously, use of many different packet type codes would use up a large amount of pool space and also affect the speed of data transfers marginally. 6.4 Full Duplex - Half Duplex Considerations Although the physical DR11-W link can only be used in one direction at a time, the CD driver allows the link to be considered as a full duplex device. A task may have any number of IO.RLB, IO.SIG and IO.WLB outstanding at one time. If the driver has a queue of IO.WLB or IO.SIG requests at the time it is terminating the read of a block of data from the link (IO.RLB function) then the link level protocol allows the driver to take ownership of the link to start a message transfer. This ensures fair bi-directional use of the link and is necessary because of differing processor speeds. 6.5 Redirection Of Device CD units are not redirectable 6.6 Unloading A Loadable Driver DO NOT unload a driver which supports physical DR11-W devices. System __ ___ one-shot timers may be active and a system crash could result. The next version of this driver will attempt to protect against this. 7.0 POWERFAIL The CD driver will attempt to re-start the link protocol on powerfail. However correct handling of an I/O packet which is being processed at time of powerfail is not assured. 8.0 SYSGEN OPTIONS REQUIRED The CD driver needs rotating data light support in the RSX-11M system. The idle counter is used as a random number source in the link startup protocol. The RSX-11M Communications Driver Page 13 For maximum speed task to task message transfer over the internal link the largest vector for $BLXIO should be specified 9.0 IO FUNCTION AND SUB-FUNCTION CODES Tables 3 and 4 give the values (in octal) for all the I/O functions and sub- functions used by the CD Driver. For convenience both standard I/O functions such as IO.RLB and IO.KIL and driver specific functions are listed in one table. The RSX-11M Communications Driver Page 14 Table 3 _____ _ CD Driver IO Function Code values __ ______ __ ________ ____ ______ ------------------------------------------------------------------------------- Code Word Equivalent Code (high byte) Meaning ------------------------------------------------------------------------------- IO.SPA 014400 31 (25.) Set packet type code affinity IO.RPA 015000 32 (26.) Remove packet type code affinity IO.RLB 001000 2 (2. ) Read logical block IO.WLB 000400 1 (1. ) Write logical block IO.SIG 017000 36 (30.) Send Signal IO.REJ 017400 37 (31.) Reject pending data block transfer IO.STU 014000 30 (24.) Get driver state IO.KIL 000012 0 subcode 12 Cancel all IO.RLB,IO.WLB and IO.SIG queued I/O requests IO.CLN 000007 0 subcode 7 Remove all packet type code affinities IO.AWA 016400 35 (29.) Restore driver ownership of DR11-W after sleep subfunction ------------------------------------------------------------------------------- Table 4 _____ _ CD Driver I/O sub-function values __ ______ ___ ____________ ______ ------------------------------------------------------------------------------- code value meaning ------------------------------------------------------------------------------- SF.SLP 1 Sleep i.e. disconnect from DR11-W interrupt vector SF.RSW 2 Resource wait SF.RDQ 4 Queue Read function ------------------------------------------------------------------------------- The RSX-11M Communications Driver Page 15 10.0 STATUS RETURNS The error and status conditions listed in Table 5 are returned by the communications driver. Values are given in decimal. Table 5 _____ _ CD Driver Status Returns __ ______ ______ _______ ------------------------------------------------------------------------------- Code Reason ------------------------------------------------------------------------------- IS.SUC 1 Successful completion The operation specified in the QIO directive was completed successfully. If the operation involved reading or writing of a data block, the second word of the I/O status block can be examined to determine the number of bytes transferred. IS.MAS 2 Link relinquished by driver with link master status After a Read or Write I/O function with the sub-function code SF.SLP has been successfully terminated this status is returned. The driver returning this status had the status of 'master' as defined in the link protocol. This means that the program who is gaining control of the link need not necessarily re-start the link protocol at this time. Truncated data transfers are also treated as successes and this status code is returned for them on a sleep sub-function. The second word of the I/O status block can be examined to determine the exact number of bytes transferred. IS.SLV 4 Link relinquished by driver with link slave status As for IS.MAS status except that the driver had the status of 'slave' as defined in the link protocol. IS.PND 0 I/O request pending The operation specified in the QIO directive has not yet been executed or completed. The I/O status block is filled with zeros. IE.IPT -112. Illegal packet type code value Valid packet type code values are between 0 and 255. IE.PTO -100. Packet type code owned The packet type code for which a set affinity or read function has been specified in the QIO directive is already owned, and in the case of a read function, by another task. For a set affinity function the packet type code may either be owned by another task or already owned by the issuing task. IE.DNE -103. Destination does not exist The packet type code on a write block or send signal type QIO function does not have an owner on the destination machine. The RSX-11M Communications Driver Page 16 IE.NRP -104. No receive of data block pending When a IO.RLB function is specified in the QIO directive, without the SF.RDQ subfunction code, this error status will be returned unless the IO.RLB function is the from the correct task and for the correct packet type code for a a block of data which is 'pending' awaiting a read from the link. IE.IOQ -95. Read I/O still queued on IO.CLN QIO directive One or more of the packet type code affinities of a task could not be removed because there was still pending Read I/O for that packet type code IE.SNA -93. Signal not acknowledged The receiver software has failed to acknowledge receipt of a signal. IE.NDS -89. Unit is not disconnected from CD driver When an IO.AWA QIO function was issued the CD driver had not in fact relinquished the DR11-W vector, so was not in the 'sleeping' state to be awakened. IE.NEX -102. Driver non-existant state This is a driver bug check and should never occur. On dispatch of the I/O function the driver's own dispatch table is found to contain an invalid code. IE.BUG -111. Driver Bug Check On an interrupt the driver is found to be in an invalid state. IE.LDN -101. Link Down The link protocol between the controlling pieces of software on either end of the link is not operational. This may occur because the other machine is down or not running link software. Unless the SF.RSW sub-function is specified read and write type QIO functions will terminate with this error condition when the link is down. A read or write type QIO function which is being processed may also terminate with this error condition if a link protocol failure occurs during the transactions involved in the Signal or data block transfer IE.EME -110. End of message error The receiver of a block of data detected an error condition on receiving the end-of-DMA interrupt from the DR11-W. The error condition indicated by the receiver in the end of message code can be found in the second I/O status word. IE.FHE -59. Fatal Hardware error The RSX-11M Communications Driver Page 17 On a IO.RLB or IO.WLB QIO function an error has been detected at the end of the DMA. Either the DR11-W itself has indicated an error condition, or the DMA word count register was found to have an incorrect final value. The DR11-W error register contents can be found in the second word of the I/O status block IE.DAO -13. Data overrun On an IO.RLB or IO.WLB function data was transferred from the sender's buffer to the receiver's buffer but not the full amount specified on the IO.WLB function. Both sender and receiver are notified of the truncated transfer. The actual number of bytes of data transferred can be found in the second I/O status word. IE.ABO -15. Request cancelled If an IO.KIL QIO function is executed, all queued I/O functions for that CD unit number, will be terminated with this status. IE.AST -80. Invalid AST address The AST address given on a set packet type code affinity QIO function is not a valid task address. IE.REJ -88. Data block rejected by receiver This status code is returned on an IO.WLB QIO function when the declared receiver of data blocks of this type rejects the message. IE.NOD -23. System dynamic memory exhausted IE.BAD -1. Bad parameters on QIO IE.SPC -6. Illegal user buffer Buffer for data transfer must in tasks address space, word aligned. IE.BYT -19. Odd byte count