<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 5.50.4915.500" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Having recently inherited a mess here at
Pricebusters, I have made it my goal to open source this organization and let it
serve as an example and as a knowledge resource for our community in hopes that
some of you will be inspired to devote your energies to helping our struggling
small businesses utilize linux in their Point of Sale technologies. For
many, their POS technology is a cash register. The POS industry is where
the rubber meets the road in the IT world. It needs YOU.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>This company uses windows based cash registers that
telnet to a linux POS server. My battle is two-pronged: convert the
registers to linux, a technical challenge, and convert the office staff, a
cultural and social "it doesn't look like Word" battle. First the
registers. Many of you may have seen my original overview in the Sherwin
Williams thread. I am placing it at the end of Ray's first response.
I hate to send it out again, but it will help consolidate the discussion into
this thread. Below is Ray's wise response with a few of my answers
followed by the overview. I look forward to any insights you may
have. Especially you, ;-)</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>from ray:</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV>Hi Scott.<BR><BR>> echo -ne "<A
href="file://\\033\133\065\151">\\033\133\065\151</A>"<BR>> cat $*<BR>>
echo -ne "<A href="file://\\033\133\064\151">\\033\133\064\151</A>"<BR>Okay, I
looked these escape sequences up at vt100.net and they do<BR>exactly what you
say they do. The first one says, "terminal, please<BR>redirect everything
I tell you to your printer instead of your screen"<BR>and the last one says,
"stop redirecting to the printer and go back to<BR>directing to the
screen". I played around with xterm and .Xdefaults a<BR>bit and got it to
work.<BR>The X resourses that are needed are:<BR><BR>xterm*printerCommand:
lpr<BR>xterm*printerAutoClose: true <BR><BR>where lpr is the printing
program. Since these output devices are<BR>basically just line printers we
could probably construct our own custom<BR>lpr program if needed.<BR><BR>
Are your linux register boxen going to be running X? I checked<BR>whatever
version of the kernel source I have laying aroudn on my<BR>hard-drive
(console.c) and the kernel's console vt's don't appear to<BR>support those
particular escape sequences. I don't think it would be<BR>too terribly
hard to add that feature to the kernel tho (it's all<BR>grouped in a pretty easy
to follow set of switch() statements). There<BR>may already be a patch on the
net somewhere, or it may already be in the<BR>kernel in a non-obvious [for me]
spot. I'll do more investigating if<BR>you like.</DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>Charles and Warren introduced me to the idea of
using a bootable flash disk for a lean thin client. The vision
has been not to use X. It is a changeable vision if X will allow
us to do what we can't do with the kernel's console. No commitment to
direction here, yet. Some investigating may be good. How can I
help?</FONT><BR><BR>> In Counterpoint certain codes are defined for this type
of pole display <BR>> that insert themselves in the lpt stream and send the
right data to <BR>> the pole and the rest to the printer.
<BR>Interesting. What are those codes? When I looked in the vt102
user<BR>manual, I didn't see anything to support printer selection
(probably<BR>because real vt102's and the like only had at most one printer
per<BR>terminal).</DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>These are some specific hex codes that are entered
in the Pole Display setup within the POS application. I'll have to get
them and share 'em. I don't think that these have to be accounted for in
the register's OS. Key word is think. The way this industry's
hardware is setup, once this stream of data makes it to the parallel port, the
printer and pole handle who prints what. Counterpoint's inserts the
appropriate codes in the stream to accomplish this.</FONT><BR><BR>> It is
this pass through and local file configuration that I am <BR>> not certain
about, yet, with a pure linux register.<BR>Me neither. If the sequence
that specifies which output it's going to<BR>comes after the print sequence then
we can just have our lpr scan for<BR>that sequence and choose accordingly.
If it happens before the print<BR>sequence, then we'll probably have to patch
xterm to support it. If X<BR>isn't an option at all, then we'll have to
patch console.c in the<BR>kernel. </DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>okay</FONT><BR><BR>> I know it is doable, but I
have not tried, period.<BR>Yea I think we'll be able to get it to work.
Although, I'll admit that<BR>I've never done anything like this before.</DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>It will be interesting. Thanks for the great
input ray.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>scott</FONT></DIV>
<DIV><BR> </DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>The overview:</FONT></DIV>
<DIV> </DIV>
<DIV> <BR>> Yeh, from what I have learned about this program called
Counterpoint <BR>> that runs on Linux is that it does so through a "hack" of
sorts. If you <BR>> are using Redhat's 6.2, then you must insmod iBCS
in your rc.local file <BR>> to be sure that the program runs. In Red
Hat's 7.2 distro, you must<BR>> <BR>> insmod abi -machdep<BR>> insmod
abi -svr4<BR>> insmod abi -cxenix<BR>> insmod abi -sco<BR>> insmod abi
-ibcs<BR>> insmod abi uw7<BR>> insmod binfmt_coff<BR>> insmod
binfmt_xout<BR>> <BR>> I really don't know what it is doing, but it allows
one to execute the <BR>> POS application once they ssh in from a remote
client. I think some <BR>> dealers use Slackware, and I suppose it
would run on Caldera's flavor of <BR>> SCO. I never got it to work with
debian or mandrake.<BR>> <BR>> <BR>> Our registers access this
application through a private network. A <BR>> "register" is simply a
pc in this case. They connect to the remote POS <BR>> application,
Counterpoint, with a windows based telnet client. We use <BR>>
Vandyke's, <A href="http://www.vandyke.com">www.vandyke.com</A> , CRT
program. Each register has a keyboard <BR>> and scanner for
input. In to the keyboard port plug the keyboard and <BR>>
scanner. They share this port with a wedge or y-adaptor. Keyboards
<BR>> have a credit card reader which is hardware programmed. The
scanner is <BR>> also hardware programmed. The telnet program doesn't
care where the <BR>> data comes from it just takes it from the port.
The POS application <BR>> doesn't care what OS is used to access it and trade
data.<BR>> <BR>> Also attached to the pc are a monitor and parallel
receipt printer. The <BR>> pole display, that thing on a pole that
displays the price, works in <BR>> pass-through mode on the parallel
port. It can also be plugged in to a <BR>> serial port.<BR>>
<BR>> So, there you are at the counter and you want to buy some gum.
The <BR>> cashier positions the cursor in the customer screen, asks your zip
code, <BR>> and then uses the keyboard to enter a stream of data matching
your 5 <BR>> numbers. The cursor is now positioned in the item entry
screen. The <BR>> gum is passed over the scanner where its barcode is
read. This stream <BR>> of numbers travels through the network, is
compared to an inventory <BR>> file, and a stream of data returns displaying
big read for .25 on the <BR>> cashiers screen. At the same time, the
price of gum has appeared on the <BR>> pole display. She scrolls down
to the payment entry area, selects <BR>> credit card, and swipes your
card. That stream of data is read from <BR>> your magnetic strip and is
passed through the network to the POS <BR>> application. Counterpoint
engages one of the server's many modems and <BR>> dials our processor for
approval. The approval is displayed on the <BR>> cashiers screen a few
seconds later, and the magic begins.<BR>> <BR>> On the server end,
peripheral devices can be defined. That pole display <BR>> showing the
gum, let's say it was a serial port pole. On the server <BR>> end, a
remote printer is defined where the pole is located. In our <BR>> case,
because our register pc's run windows, that pole display is known <BR>> to
windows as a generic text serial printer. It is shared. We setup
<BR>> this remote windows printer on the server, usually name the queue with
<BR>> that register's number, and when the application gets your gum data
<BR>> stream, it knows to print the price data to the user defined
printer. <BR>> In this case it is a remotely shared windows
printer. It can easily be <BR>> any printer.<BR>> <BR>> This, so
far, may not be too hard to replicate on a thin-client linux <BR>>
register. Something else happens, though. CRT, the windows telnet
<BR>> program, is set up to pass through printing to lpt1. When
the cashier <BR>> got your approval for the gum, she finished the transaction
by printing <BR>> a receipt. When she printed that receipt, the printer
was not defined <BR>> the same way as the pole. The printer in this
case is a device defined <BR>> in Counterpoint called local. Local is a
file in the top level of the <BR>> Counterpoint, with 777 permissions but
root ownership and root group. <BR>> In the file are the following
magical lines<BR>> <BR>> echo -ne "<A
href="file://\\033\133\065\151">\\033\133\065\151</A>"<BR>> cat $*<BR>>
echo -ne "<A href="file://\\033\133\064\151">\\033\133\064\151</A>"<BR>>
<BR>> So, this setup tells the telnet application to print to the local
<BR>> printer port, it appears. That's how your receipt comes
out. Receipt <BR>> printers, as opposed to some poles, are not defined
print queues. Some <BR>> poles are also not defined queues. I
mentioned earlier that some poles <BR>> are pass through. They plug in
to the parallel port with the receipt <BR>> printer. They too are
defined as "local" In Counterpoint certain codes <BR>> are defined for
this type of pole display that insert themselves in the <BR>> lpt stream and
send the right data to the pole and the rest to the <BR>> printer. It
is this pass through and local file configuration that I am <BR>> not certain
about, yet, with a pure linux register. I know it is <BR>> doable, but
I have not tried, period.<BR>> <BR>> If you made it this far, let me share
a vision. Next time you are <BR>> shopping, realize how many small
business are out there struggling to <BR>> get by. Many lack any
computer integration save for a cash register. <BR>> Many use windows
pos applications. They, these small businesses, are <BR>> generally
said to comprise 90% of all businesses. These people need a <BR>> linux
POS application, and they need YOU to help them do it. I am going <BR>>
to do all I can to make Pricebusters completely open sourced as I <BR>>
possibly can, starting with the registers. I will have obstacles, and
<BR>> there will be problems. When I am done they will serve as a
gleaming <BR>> example of the benefits of open source. We are a locally
owned company <BR>> facing formidable mainland competition, so any
competitive edge we can <BR>> get, we go for. I think that linux is it
for us. If you can help in <BR>> any way, this project is for
you. It is for you because when it is done <BR>> you will always have a
linux reference. When you are selling that small <BR>> hardware company
on your service and the reliability of this linux POS <BR>> application you
have found and are representing, you will have them call <BR>> me to attest
for the quality and reliability of your endeavor.<BR>> <BR>> scott<BR>>
<BR></DIV></BODY></HTML>