Conference bulova::decw_jan-89_to_nov-90

1532.0. "What to do about DECW-E-CNXABORT and XLIB-F-IOERROR" by STAR::VATNE (Peter Vatne, VMS Development) Wed Oct 04 1989 23:44

This subject has come up a number of times, so I thought I would
answer this in one place.  (Also, I doubt I could find all the
instances of this question in order to post specific replies.)

These frustrating errors can occur at any time, and are very hard
to diagnose, mainly because the underlying error status causing
the I/O error is not reported.  The connection is aborted because
the rule is to tear down a connection when any fatal error occurs.

The underlying problem is most likely not a true device I/O error,
but an overflow of the DECwindows transport's I/O buffers.  This
most frequently happens when the application cannot keep up with
events generated by the server.  One common example is running
DECW$PAINT on a very slow system or network, and then generating
lots of mouse movement events by moving the mouse around quickly.
Also, poorly designed applications (ones which do not process
events as quickly as possible) can exhibit this problem.

These problems can occur on VMS V5.1 and V5.2, and their variants,
which contain DECwindows V1.0 (plus some bug fixes).

DECwindows V2.0, now in field test with VMS V5.3, greatly alleviates
these problems.  The new DECwindows transport makes much better use
of its buffers, so buffer overflow hardly ever occurs any more (it can
still happen if an application stops reading events altogether).  In
addition, the transport now reports back the underlying error status,
so you can get a better idea of what is going wrong.

Therefore, I heartily recommend that if you are seeing these problems
that you upgrade to VMS V5.3 FT.  In fact, any QARs submitted on VMS
V5.1 or V5.2 will be answered with this recommendation.