WY-60 display problem
Jerad Stoops
OSR5.0.5
Stallion Easy Connection Serial Boards (ISA internal card)
WY-60 Dumb Terminals
FoxBASE+ 2.1.2 Application
We have ran this setup for about two years. Many of the terminals have
two sessions enabled on the stallion board. The user switches sessions
using ctrl+e and ctrl+o on the dumb terminal keyboard.
When the user logs in it automatically starts our FoxBASE+ application.
Each users .profile is setup for wy-60 terminals.
At seemingly random times, when a user switches sessions (let's say
from session A to session B), screen B gets completely munged. At first
sight it would appear that parts of session A are inter-mixed with
parts of session B. But when comparing what is displayed on session B
with session A, there is extra stuff getting mixed in that is neither
from session A nor B. Usually it is part of another one of the screens
from our FoxBASE+ application. And this extra stuff on the screen
becomes the active part of the terminal, that's where the users
keystrokes get directed to, not what was supposed to be session B. The
terminal does not display garbage characters, it just has parts of two
screens from the FoxBASE+ application inter-mixed with each other, in
discernable patches on the terminal.
Usually just logging out and back in again allows the user to continue
with no problem.
Some terminals seem to be worse than others with this problem, but I
can't find any differences with the setup on the terminals, they look
to be setup identically. We also have a couple of Link MC-5's running
with wy-60 emulation that experience similar problems. The serial port
speeds are at 9600bps and the terminals are setup at the same speed.
If it was just the two sessions getting mixed with each other I would
figure that it was a problem redrawing with the terminals. But the fact
that it is getting the other stuff mixed on the screen really has me
stumped. At times it looked like what had just been displayed on
another users terminal became the extra stuff mixed in, but it is
usually pretty difficult to discern if that is the case. The users do
not share a single user account, each user has their own account.
However they do usually use the same account to login on both sessions
on their terminal.
One other thing occurs very rarely. Some times when a user logs out and
FoxBASE+ displays the line: "FoxBASE+ normal shutdown." this line gets
output to the printer attached to the parallel port on the OSR5.0.5
box. I don't know if this is related, but it does show that output that
was meant for a certain terminal got directed to the wrong place. I've
never seen any more than just that one line directed to the printer.
Sorry for the lengthy post but I wanted to make sure that this problem,
that has throughly confused me, got described in an understandable
manner with as much hopefully relevant information as I can think of.
Thank You,
Jerad Stoops
Bela Lubkin
Thanks for the lengthy post. You included the crucial, seemingly
unrelated clue about the printer.
Your serial terminals and parallel printers use different device
drivers, but they are all "terminal" device drivers. These use a shared
pool of memory buffers in the kernel, called "clists".
If output meant for one device shows up on another, it is probably a
device driver bug. When you describe problems that occur only on
terminals, I would guess that the bug is _somewhere_ in the device
driver for the serial ports (i.e. for your "Stallion Easy Connection
Serial Boards (ISA internal card)"). The added clue about the printers
strongly suggests that there's a bug in that device driver, and the bug
is in its clist handling.
I would recommend first making sure you have the newest device driver
for your Stallion card(s); then, if the problem persists, talking to
Stallion about it.
>Bela<
Bill Vermillion - alt account
>OSR5.0.5
>Stallion Easy Connection Serial Boards (ISA internal card)
>WY-60 Dumb Terminals
>FoxBASE+ 2.1.2 Application
>We have ran this setup for about two years. Many of the terminals have
>two sessions enabled on the stallion board. The user switches sessions
>using ctrl+e and ctrl+o on the dumb terminal keyboard.
While not using this particular combination I have used things like
this in the past. The one thing you didn't describe [or if you did
I missed it] was what are you using for flow-control. I always
used hw-flow. If you are using x-on/x-off that might be part of
the problem.
I did have user problems at times, so I made the systems to
automatically log the users off if they powered off their terminal.
I took pin 20 [DTR] and crossed it to pin 8 [CD] as the computer
side and ran all the terminal as if they were modems. It cut down
over 90% of the support calls to the people at that site with "I
can't do anything and I powered my terminal off and now all I have
is a blank screen". Making the terminals act like modems meant the
session was logged off when the power to the terminal was turned
off.
If you are using HW control ignore this message. If not try it and
see if it helps.
Bill
Karel Adams
"Jerad Stoops" <j...@sofnet.com> schreef in bericht news:tun172...@corp.supernews.com...
> System Info:
>
> OSR5.0.5
> Stallion Easy Connection Serial Boards (ISA internal card)
> WY-60 Dumb Terminals
> FoxBASE+ 2.1.2 Application
>
> We have ran this setup for about two years. Many of the terminals have
> two sessions enabled on the stallion board. The user switches sessions
> using ctrl+e and ctrl+o on the dumb terminal keyboard.
>
> One other thing occurs very rarely. Some times when a user logs out and
> FoxBASE+ displays the line: "FoxBASE+ normal shutdown." this line gets
> output to the printer attached to the parallel port on the OSR5.0.5
> box. I don't know if this is related, but it does show that output that
> was meant for a certain terminal got directed to the wrong place. I've
> never seen any more than just that one line directed to the printer.
Can't be sure but it sounds to me like noise on the RS232-line.
Don't you also suffer from the accidental garbled character?
My suspicion is the escape sequences that do the switching
between sessions nd/or the printer port get garbled as well.
If so: check out by lowering the baud-rate, maybe on one
terminal only. If this confirms: check your cabling, particularly
the shielding, and proper grounding of all equipment.
KA
Bill Vermillion
>(snip)
That rings a bell. I recall that some implementations of
the terminal printing, where the lines was toggled from key-input
to printer-output weren't really ruggedized. They did something
like xx character from terminal - then output to terminal.
At least one vendor got caught in this because they were only
checking character counts - while another vendor was checking to
see if the last character it was going to receive was part of an
escape sequence and then continued so as not to disrupt that
sequence.
This goes back a very long time ago and at that time I >think< the
probelmatic vendor was Computone before we switched at that site to
Anvil and then later Specialix. The latter two never had any
significant problems. The only one I recall at all was liniking in
the drivers in Xenix where it put the kernel past the 640K boundary
and would fail. A quick change in the linking script so that the
rest of the kernel fell above the 1MB boundary fixed that. Boy
were things primitive then. I don't even know what part of you
post triggered those long forgotten details - but it makes me
appreicated today's world even more.
Jerad Stoops
> System Info:
>
> OSR5.0.5
> Stallion Easy Connection Serial Boards (ISA internal card)
> WY-60 Dumb Terminals
> FoxBASE+ 2.1.2 Application
>
> We have ran this setup for about two years. Many of the terminals have
> two sessions enabled on the stallion board. The user switches sessions
> using ctrl+e and ctrl+o on the dumb terminal keyboard.
>
> When the user logs in it automatically starts our FoxBASE+
> application. Each users .profile is setup for wy-60 terminals.
>
> At seemingly random times, when a user switches sessions (let's say
> from session A to session B), screen B gets completely munged....
<snip details>
Well, I called Stallion to see if they had seen this problem before.
They hadn't. But during the conversation mention was made about how the
terminal escape sequences were setup on the stallion board for
switching sessions. I checked them and the only escape sequences
present were only for switching the sessions, not to redraw the session
after it had been switched.
I sat down and tested swapping sessions with this idea in mind and
found that I could consistently reproduce the following results.
What was happening is that when the user would switch sessions the
terminal would actually make the switch from session A to session B,
but it would not redraw the screen to display session B. Without
realizing what they were really doing the user would press the enter
key which did two things; first it had the side effect of redrawing the
screen and displaying session B, and second it acted on the FoxBASE+
application which was hidden from them before the redraw. If the
"hidden" session had a screen running in the FoxBASE+ application and
it had something like a menu or a selection grid going, in which the
enter key would take them to another FoxBASE+ screen, it would appear
that they were getting information displayed on the terminal from some
unknown source, but really wasn't, it was just session B. Sometimes the
terminal wouldn't redraw correctly because it didn't have the proper
escape sequences sent to it and would display parts of session A and B
inter-mixed on the screen.
I'm sure glad to get to the bottom of this. But it still leaves the
curious problem about the line of text getting sent to the printer. Oh
well... one thing at a time :-)
Thanks for the posts
Jerad
Simon Hobson
(in message <tv3ng19...@corp.supernews.com>):
> Well, I called Stallion to see if they had seen this problem before.
> They hadn't. But during the conversation mention was made about how the
> terminal escape sequences were setup on the stallion board for
> switching sessions. I checked them and the only escape sequences
> present were only for switching the sessions, not to redraw the session
> after it had been switched.
You should not have to redraw screens !
The Wyse 60 supports MINIMUM of 2 screen memories which it can switch by
escape codes. So all you have to do is get the right codes sent to the
terminal every time the session is switched and the terminal will already
have the right screen in memory. If you set the columns to econ-80 instead of
80, then the terminal has enough memory for 3 screens.
A persusal of the documentation for mscreen may be useful to you (mscreen is
SCOs standard offering to do this sort of thing independently of the serial
ports used). The config file for mscreen has the codes for many terminals !
Simon
Michael Spicyn
Users do learn that they can enter keystrokes "ahead" of computer and
eventually computer would "catch up". Normally such behavior is OK. We
all do it to lesser or greater extend.
But... WY60 is very _slow_ terminal. While it does the switching, the
users are left free to poke at the keyboard (and those that believe that
computer will eventually catch up, do so rapidly) and such keystrokes
are sent to application while redrawing is not finished. The application
sends new content to the screen while screen is being redrawn. Depending
on the FIRMWARE version of WY60, the results are different and
unpredictable.
My solution was to expand "switch screen" escape sequence to include:
1. disable keyboard - user's keystrokes are not accepted
2. switch screen.
3. enable keyboard - user's keystrokes are accepted again.
I do not thing that sending a "redraw escape sequence" is necessary: it
supposed to happened automatically, unless applications running on each
screen are different _and_ they set their own stty setting
BTW - same thing applies for printing to printers attached to WY60. You
must disable keyboard so that users input will not create application
output which will be intermingled into a print stream.