Output to LAT devices from DS3100 program: Help!

john gerard jmg at cernvax.cern.ch
Mon Feb 5 21:37:39 AEST 1990


The story so far: I run a 3270 emulation on behalf of users sitting on
terminals on DECservers. These users can move to different sessions, so
that output then gets hung up. However, I do not want the emulation to
hang on output calls (fwrite, fputs, fputc or whatever), since the IBM
may at any time send messages. I think I understand the normal idea behind
a tty character device, though LAT is clearly a bit special.

Now read on:

I can clearly channel all output through my own routine(s), rather than
through fwrite, fputs or whatever. However, my observation is that the
select routine is not good enough for me because it may tell me that
output can be done and yet the actual output may cause the program to
be hung because it goes over the high water mark. Note that this applies
to block or line buffered output: if I use unblocked output then select
can work, but the overhead of unblocked output is too high for this to
be a practical solution.

Thus, how to know when the next output, even of a single character, would
cause a blocking because of going over the high water mark? How, also, to
know when output can again be accepted? Simple question, but no-one here
seems to have an answer. It might depend on the way that output to a LAT
device is handled: I know that the DECServer periodically asks for output
and (maybe) gets a number of characters depending (I think) on the line
speed of the terminal. However, what buffering, if any, is done for
creating these LAT output packets is an unknown factor. Certainly, the
code for creating these packets is hidden from me.

One observation that I have is that a signal interrupt may cause some of
these LAT output packets to get lost. I know that when I was testing using
ITIMER_PROF and ITIMER_REAL I sometimes lost three or four of these packets.
The DECserver kept asking at 70ms intervals for output, but suddenly some
LAT output packets were completely skipped. Of course, the setitimer manual
says that the routine handling the timer should be prepared to restart
interrupted system calls, but what this means in the case of LAT output
is hard to understand.

Another funny about LAT! I have two DECstations offering the same LAT
service: one for about 10 users, one for over 100 users. The 10-user
one gets completely filled before the 100-user one gets any user. I
thought that the LAT protocol had some better algorithm than that!

Ultrix gurus, over to you!



More information about the Comp.unix.ultrix mailing list