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.
