[luau] NEWS: Sherwin-Williams to use Linux Cash Registers

[R. Scott Belford]

On Thursday, May 23, 2002, at 06:19 PM, Warren Togami wrote:

> On Thu, 2002-05-23 at 17:20, MonMotha wrote:
>> Yes, but SCO != Linux :)
>>
>
> Because SCO was/is a x86 Unix, most SCO binaries run with little or no
> modification on Linux when you have the right libraries and Unix
> compatibility kernel modules installed.  Scott can post more about this.

Yeh, from what I have learned about this program called Counterpoint 
that runs on Linux is that it does so through a "hack" of sorts.  If you 
are using Redhat's 6.2, then you must insmod iBCS in your rc.local file 
to be sure that the program runs.  In Red Hat's 7.2 distro, you must

insmod abi -machdep
insmod abi -svr4
insmod abi -cxenix
insmod abi -sco
insmod abi -ibcs
insmod abi uw7
insmod binfmt_coff
insmod binfmt_xout

I really don't know what it is doing, but it allows one to execute the 
POS application once they ssh in from a remote client.  I think some 
dealers use Slackware, and I suppose it would run on Caldera's flavor of 
SCO.  I never got it to work with debian or mandrake.


Our registers access this application through a private network.  A 
"register" is simply a pc in this case.  They connect to the remote POS 
application, Counterpoint, with a windows based telnet client.  We use 
Vandyke's, www.vandyke.com , CRT program.  Each register has a keyboard 
and scanner for input.    In to the keyboard port plug the keyboard and 
scanner.  They share this port with a wedge or y-adaptor.  Keyboards 
have a credit card reader which is hardware programmed.  The scanner is 
also hardware programmed.  The telnet program doesn't care where the 
data comes from it just takes it from the port.  The POS application 
doesn't care what OS is used to access it and trade data.

Also attached to the pc are a monitor and parallel receipt printer.  The 
pole display, that thing on a pole that displays the price, works in 
pass-through mode on the parallel port.  It can also be plugged in to a 
serial port.

So, there you are at the counter and you want to buy some gum.  The 
cashier positions the cursor in the customer screen, asks your zip code, 
and then uses the keyboard to enter a stream of data matching your 5 
numbers.  The cursor is now positioned in the item entry screen.  The 
gum is passed over the scanner where its barcode is read.  This stream 
of numbers travels through the network, is compared to an inventory 
file, and a stream of data returns displaying big read for .25 on the 
cashiers screen.  At the same time, the price of gum has appeared on the 
pole display.  She scrolls down to the payment entry area, selects 
credit card, and swipes your card.  That stream of data is read from 
your magnetic strip and is passed through the network to the POS 
application.  Counterpoint engages one of the server's many modems and 
dials our processor for approval.  The approval is displayed on the 
cashiers screen a few seconds later, and the magic begins.

On the server end, peripheral devices can be defined.  That pole display 
showing the gum, let's say it was a serial port pole.  On the server 
end, a remote printer is defined where the pole is located.  In our 
case, because our register pc's run windows, that pole display is known 
to windows as a generic text serial printer.  It is shared.  We setup 
this remote windows printer on the server, usually name the queue with 
that register's number, and when the application gets your gum data 
stream, it knows to print the price data to the user defined printer.  
In this case it is a remotely shared windows printer.  It can easily be 
any printer.

This, so far, may not be too hard to replicate on a thin-client linux 
register.  Something else happens, though.  CRT, the windows telnet 
program,  is set up to pass through printing to lpt1.  When the cashier 
got your approval for the gum, she finished the transaction by printing 
a receipt.  When she printed that receipt, the printer was not defined 
the same way as the pole.  The printer in this case is a device defined 
in Counterpoint called local.  Local is a file in the top level of the 
Counterpoint, with 777 permissions but root ownership and root group.  
In the file are the following magical lines

echo -ne "\\033\133\065\151"
cat $*
echo -ne "\\033\133\064\151"

So, this setup tells the telnet application to print to the local 
printer port, it appears.  That's how your receipt comes out.  Receipt 
printers, as opposed to some poles, are not defined print queues.  Some 
poles are also not defined queues.  I mentioned earlier that some poles 
are pass through.  They plug in to the parallel port with the receipt 
printer.  They too are defined as "local"  In Counterpoint certain codes 
are defined for this type of pole display that insert themselves in the 
lpt stream and send the right data to the pole and the rest to the 
printer.  It is this pass through and local file configuration that I am 
not certain about, yet, with a pure linux register.  I know it is 
doable, but I have not tried, period.

If you made it this far, let me share a vision.  Next time you are 
shopping, realize how many small business are out there struggling to 
get by.  Many lack any computer integration save for a cash register.  
Many use windows pos applications.  They, these small businesses, are 
generally said to comprise 90% of all businesses.  These people need a 
linux POS application, and they need YOU to help them do it.  I am going 
to do all I can to make Pricebusters completely open sourced as I 
possibly can, starting with the registers.  I will have obstacles, and 
there will be problems.  When I am done they will serve as a gleaming 
example of the benefits of open source.  We are a locally owned company 
facing formidable mainland competition, so any competitive edge we can 
get, we go for.  I think that linux is it for us.  If you can help in 
any way, this project is for you.  It is for you because when it is done 
you will always have a linux reference.  When you are selling that small 
hardware company on your service and the reliability of this linux POS 
application you have found and are representing, you will have them call 
me to attest for the quality and reliability of your endeavor.

scott