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

Thu May 23 20:22:00 PDT 2002

I actually have some of this hardware that I can use to test things on 
(a pole display on serial and a keyboard/barcode scanner wedge). 
However, I'm not really a UI programmer, but I can get the basic OS base 
down for you fairly quickly should you want me to.

--MonMotha

R. Scott Belford wrote:
> 
> 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
> 
> _______________________________________________
> LUAU mailing list
> LUAU at videl.ics.hawaii.edu
> http://videl.ics.hawaii.edu/mailman/listinfo/luau
> 