[luau] The open-sourcing of Pricebusters

[R. Scott Belford]

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.

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, ;-)

from ray:

Hi Scott.

> echo -ne "\\033\133\065\151"
> cat $*
> echo -ne "\\033\133\064\151"
Okay, I looked these escape sequences up at vt100.net and they do
exactly what you say they do.  The first one says, "terminal, please
redirect everything I tell you to your printer instead of your screen"
and the last one says, "stop redirecting to the printer and go back to
directing to the screen".  I played around with xterm and .Xdefaults a
bit and got it to work.
The X resourses that are needed are:

xterm*printerCommand: lpr
xterm*printerAutoClose: true 

where lpr is the printing program.  Since these output devices are
basically just line printers we could probably construct our own custom
lpr program if needed.

  Are your linux register boxen going to be running X?  I checked
whatever version of the kernel source I have laying aroudn on my
hard-drive (console.c) and the kernel's console vt's don't appear to
support those particular escape sequences.  I don't think it would be
too terribly hard to add that feature to the kernel tho (it's all
grouped in a pretty easy to follow set of switch() statements). There
may already be a patch on the net somewhere, or it may already be in the
kernel in a non-obvious [for me] spot.  I'll do more investigating if
you like.

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?

> 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.  
Interesting.  What are those codes?  When I looked in the vt102 user
manual, I didn't see anything to support printer selection (probably
because real vt102's and the like only had at most one printer per
terminal).

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.

> It is this pass through and local file configuration that I am 
> not certain about, yet, with a pure linux register.
Me neither.  If the sequence that specifies which output it's going to
comes after the print sequence then we can just have our lpr scan for
that sequence and choose accordingly.  If it happens before the print
sequence, then we'll probably have to patch xterm to support it.  If X
isn't an option at all, then we'll have to patch console.c in the
kernel.  

okay

> I know it is doable, but I have not tried, period.
Yea I think we'll be able to get it to work.  Although, I'll admit that
I've never done anything like this before.

It will be interesting.  Thanks for the great input ray.

scott



The overview:

 
> 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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freesoftwarehawaii.org/pipermail/luau-freesoftwarehawaii.org/attachments/20020524/e66bbfe4/attachment-0001.htm>