Ref: 03250454 Title: IVECS and PVCs; Useful Information Date: 4/15/88 Copyright 3Com Corporation, 1991. All rights reserved. QUESTIONS: Back in Aug '87, you wrote in "CONNECTIONS" about IVECS installs. I have been having problems with PVC's off IVECS on both XNS and TCP/IP systems. I'm confused about the UDTR parameter you discuss in the article. Are you referring to UDTR on the IVECS or the server port connected to the printer, or both? When you say that if UDTR=IGNORE, then incoming data is ignored, does that refer also to flow control characters? Basically I need to know what the config for PVC's should be to support printers. Should the PVC be established on the server with the printer or on the IVECS? On the server/printer and IVECS, what should UDTR be? What should the modem no-modem param on the VAX be set as? A customer with XNS IVECS has a situation where he can start a print job to a printer, flow control it off (by opening cover or via online button), and listen the port out to break the connection. At that point the print job on the VAX spills into the bit bucket. Would any of the above params have anything to do with that? They send print jobs to remote locations via GS/1-X.25 and if connections are inadvertently dropped, there is no way to be sure whether a complete print job was sent or not because the VAX indicates success even when it's not successful! ANSWERS: 1) The UseDtr parameter to which I referred was the one on the IVECS card. This can only be changed by remoting to the IVECS. 2) Characters that arrive at the VAX (inbound) when DTR is un- asserted are eventually dropped into the bit bucket. As to flow control characters, IVECS SHOULD NEVER RECEIVE FLOW CONTROL CHARACTERS from a connected device. This prompts a short explanation of flow control of async devices over Ethernet. Async devices typically use a hardware handshake, or XON/XOFF characters, to perform flow control. Ethernet devices (at least XNS, TCP, and OSI based) use a data-transparent flow control built into the protocol. These Ethernet devices have no use for XON/XOFF, or DTR flow control. Our CS/1 product line has long recognized the XON/XOFF or hardware handshake, and translated it into the network flow control state. This flow control condition will propogate over the Ethernet, and the other attached CS/1 will re-generate the XON/XOFF or hardware flow control. Notice that the flow control need not be the same on each device, and that neither serial device knows what type of flow control the other end is using. In fact the other end (in the case of a UNIX host) may not have either type of flow control if an ASCII line is not involved. Notice also that if the user sets flow control on both ends (CS/ 1's) to none and both attached devices (host, terminal) to XON/ XOFF, flow control sort of works. The terminal generates XOFF, and the CS/1 passes it as data across Ethernet to the other end. Finally the HOST gets the XOFF and stops sending data. However, there are probably several packets in transition on the network, so the data will not stop for several lines of data. Many ASCII devices cannot accept that many characters after they flow control, in which case the flow control does not work at all. If the device can accept that many characters, the flow control works but very inefficiently. You probably know all of the above, but maybe don't realize that an IVECS is very much like a CS/1 front ending a DMF32. The flow control works in a similar way except that the serial line between the virtual DMF32 and the CS/1 has a very high bandwidth! This causes certain complications but first--the "basics." Take the case of a host VAX (A) with an IVECS (B) attached to an Ethernet (C), attached to a CS/1 (D), attached to a serial printer (E). The VAX and the IVECS use XON/XOFF flow control between THEMSELVES. The IVECS and the CS/1 use XNS or TCP flow control between themselves. The CS/1 and the serial printer use XON/XOFF or hardware handshake flow control between themselves. It is very important that the CS/1 handle the flow control with the printer, and that the IVECS does not receive any XON/XOFF characters. This is because the IVECS uses XON/XOFF flow control to throttle data between the VAX and the IVECS. The IVECS does not want to search all incoming data for XON/XOFF characters (for performance reasons), and so, if any come in, they are passed to the VAX, which may confuse the IVECS/VAX flow control. I am getting a little carried away with the details so I'll try to get back to your questions. There are multiple ways to get a PVC to work, but I will suggest the one I believe is most likely to provide success. 1) The printer/server should be set up to provide flow control between themselves, typically via XON/XOFF. 2) The IVECS and server will flow control via XNS or TCP. Don't worry about this. 3) The IVECS and the VAX must use XON/XOFF flow control between themselves, with the possible exception of UNIX running on the VAX. In any case XON/XOFF will always work. The IVECS should be set up for XON/XOFF flow control in both directions. 4) On the subject of PVC's specifically, I have the following suggestions: a) It should not matter which end sets up the PVC, but if the VAX might be shut down more often than the printer's server, then it is more convenient to have the PVC on the VAX. I believe that this will stop numerous Audit trail messages from appearing when the VAX is powered off, for service. b) The VAX should ALWAYS be set for MODEM control. This allows the IVECS to notify the VAX (via Carrier Detect) when a connection is dropped. The vax can then stop its printer queue until a system manager restarts it. If MODEM is not set, the VAX does not see the connection drop and will continue to send data. This probably causes the data loss mentioned later. c) The IVECS should be set to "UseDtr = ignore". This is because when some VAXen boot, they take so long to start the printer queue that an unwanted interaction starts taking place. The IVECS starts the PVC, and the VAX thinks the PVC is actually a user trying to log on. After 30 seconds the VAX times out the logon attempt and drops DTR, forcing the IVECS to drops the connection. 30 seconds later IVECS reissues the connection, and the process repeats every 60 seconds. If the VAX tries to start the printer queue when the connection is invalid, the queue manager stops the queue and waits for a system manager to restart the queue. The Audit trail fills up, and the user cannnot get the printer to work. The solution is to set UseDtr = Ignore. This means that the IVECS will not drop the PVC when the VAX "hangs up" the user, and the PVC will be there when the printer queue starts. While this does mean that data coming from the printer will be lost if the VAX is not up and running, I have not found any cases where this is actually a problem. I alerted the field to this data loss possibility in case there was in fact a problem with it, and I have not found one in the past year. d) As to the bit bucket, this may or may not be avoidable. First it is worth noting that data can come out of the VAX when it is not expected. This includes data coming out just after/ during a disconnection that in turn causes a logout procedure. It also may include data generated by a "reply /all" (broadcast) command, executed by the system manager. In these cases where the IVECS gets data and has no place to send it, the data must be dropped on the floor. In the case of a logout, it is certainly not appropriate to save the data for the next user! The IVECS software does not attempt to recognize a PVC port as being special in that it will most likely connect with whomever it disconnected from. Therefore, when a PVC connection is lost, the IVECS becomes a data sink, dropping all data sent as fast as it is sent. This is mostly unavoidable. The only safety is in the host recognizing that the connection is down. If the host is set to "MODEM" and the IVECS is set to "UseDCD = OnConnection", when the connection is dropped, IVECS will drop DCD (Carrier Dectect), and the Vax will suspend whatever process was outputting data. This may or may not save the day. I am not sure how the printer queue handles this situation. It may: (1) Stop Output and restart from where it left off when a restart queue command is entered. (2) Abandon the print job and restart from the beginning when the restart queue command is entered. (3) Complete the current print job (drop the data), and continue with the next job when a restart queue command is entered. If the printer queue software does #1, some data will be lost, since the data sent by the VAX is unlikely to all have been delivered when the network disconnection occurred. (Some data is always in transit in the IVECS/network/CS). If the queue does #2, life is good unless the print jobs are very large. If the queue program does #3, then is no way to recover from the disconnection (currently). I am sorry that I do not know enough about the queue software to tell you which it does. This information should be available from DEC as this is no different from a printer attached to a VAX through a modem. Make sure to take care of the IVECS configuration though so that the VMS system has a chance of handling the down line correctly.