Yes, that's not a bad point, surviving machines in case of a crash...
provided the software on the 386's is designed not to necessarily send
everything immediately to the main dbase...
... but also PROVIDED there is no need to consult the main dbase,
which is much
Nicola Bernardell writes:
I think nobody would think about replicating data on each of the 386's!
Don't. Have them build an LRU cache. Query the server first: if it
responds use its data and update the cache. If the server doesn't respond,
use the cache.
I mean, what scares me is all that
On Sun, 14 Sep 1997, A. Paul Heely Jr. wrote:
What ports are these devices connected to?
These all connect through device, I don't know exactly what it is,
that is itself connected to a serial port.
One device only... the Wyse's have _two_ serial ports, but maybe to just
switch from one
One device only... the Wyse's have _two_ serial ports, but maybe to just
switch from one host to another, don't know whether or not the second port
can just be used as auxiliary input... but why not keybord emulation as
done by most barcode scanners I saw? Do credit card scanners have
Why did you move to networked 386's? What's running on them?
The system that we use is provided to us by True Value.
The backroom system is a SCO 3.2V4.2 box. The registers are
simple 386's, 4M ram, 10Mb hard drives, simple ethernet cards.
They run some old version of DOS, and a custom
Why did you move to networked 386's? What's running on them?
The system that we use is provided to us by True Value. The backroom
system is a SCO 3.2V4.2 box. There where a couple of reasons for
getting rid of the WYSE terminals. There were emulation problems
with the terminals, SCO uses
On 12 Sep 1997, TENCC01.LEWIS01 wrote:
It probably doesn't work the way you want. Usually the terminal keyboard
is
locked until the print is finished. Making the terminal useful for input
at the
same time is generally not possible. It would require a very clever
terminal
On 12 Sep 1997, TENCC01.LEWIS01 wrote:
It probably doesn't work the way you want. Usually the terminal keyboard is
locked until the print is finished. Making the terminal useful for input at
the
same time is generally not possible. It would require a very clever terminal
and an extremely
On Fri, 12 Sep 1997, RHS Linux User wrote:
I don't know how big a problem having the keyboard locked
during printing would actually be. My part-time job is in a
hardware store that uses a POS system similar to the one
you are describing. All of our registers are 386's networked to
a
:-) I put my hands on some SCO systems at some customers' and I think
Linux is quite _another_planet_ (and among every distribution Debian, also
used Yggdrasil, Slackware and RedHat).
Could not agree more. I don't think SCO, even Open Server, is in
the same solar system :).
Yes
On Sat, 13 Sep 1997, A. Paul Heely Jr. wrote:
Why did you move to networked 386's? What's running on them?
The system that we use is provided to us by True Value. The backroom
system is a SCO 3.2V4.2 box. There where a couple of reasons for
getting rid of the WYSE terminals. There
On Sun, 14 Sep 1997, A. Paul Heely Jr. wrote:
The backroom system has never gone down from a hardware failure. It has
crashed/locked up for who knows what reason. I know that it
should not happen but it can. The registers also have
been known to lock up, more so than the backroom. If a
Printing to the aux port of a terminal has been done before. SCO Xenix used to
do it (about 10 years ago) with Wyse terminals. I have heard about printing
through vt type terminals off dec vax machines. I once wrote a program to do it
through hp terminals (with rte-a, not unix).
It probably
Printing to the aux port of a terminal has been done before. SCO Xenix used to
do it (about 10 years ago) with Wyse terminals. I have heard about printing
through vt type terminals off dec vax machines. I once wrote a program to do it
through hp terminals (with rte-a, not unix).
It probably
14 matches
Mail list logo
