|Subject:||Re: POS System|
|Date:||Dec 9, 1999 10:44:27 pm|
John Sanders wrote:
Well, this system is pretty in depth...it does run on TCP/IP over a 10BaseT Ethernet LAN. The system uses IP's 126.96.36.199 - 188.8.131.52 (MFS1 = 184.108.40.206, MFS2 = 220.127.116.11, LFS3 = 18.104.22.168, LFS10 = 22.214.171.124, POS1 = 126.96.36.199, POS254 = 188.8.131.52) with MFS1 being the Primary file server, MFS2 being the Backup file server, LFS3 - 10 being workstations (difference between workstations and servers in this system is, the workstations cannot do parameter maintenance). POS1-254 are registers 1 - 254
Well, talking to the POS, provided we have the custom protocol, is no problem since FreeBSD/Unix is king of TCP/IP. 243 POS clients aren't much either, how fast can the checkout girls scan? Are these smart POS terminals? As in, do they add up everything themselves once the backend provides them with prices for product codes? How about credit cards? Who talks to the bank, POS or backend?
The database system is something i've never seen anywhere outside this system, it is called "Quick-Dex" or "QDex" for short. Basically it consists of roughly 120 files, each performing its own little function, for example, "transact.qdx" is the transaction file, storing all sales, all signon/sign offs, order suspends/retrieves, etc. you have 3 or 4 PLU (UPC) files, that store of course, PLU information, and indexes. (The index files can rebuild all of its "children" files on a reboot & reload of the database into memory, if the file dosent match the index, it rebuilds them). Files that handle cashier accountability, POS accountability, departmental sales, etc. It's quite extensive.
This is were it gets complicated. It's not just an OS issue, but a backend database, accounting and business model issue as well.
Best thing would be to release the specs and gather people for an open source Client/Server POS/accounting system. Not impossible, but would take coordination. If you have the specs, why not upload them on a web page for everyone to inspect. It's the first step.
I don't see anyone writing something from scratch at this point in the ISS 45's lifespan, as it will soon become outdated in its capabilities. Which is why i was wondering about a system being written previously to handle this. If you would like file layouts, that is not a problem.
The bottom layer should be universal for any POS, on top, we could write intermediate layers to facilitate different POS terminals.
Sorry to all on the list if they feel this is irrelevant.
-----Original Message----- From: stephen <scha...@geocities.com> To: John Sanders <moo...@ebicom.net> Cc: dkwi...@hagenhomes.com <dkwi...@hagenhomes.com>; Langa Kentane <evab...@earthling.net>; linu...@vger.rutgers.edu <linu...@vger.rutgers.edu>; free...@FreeBSD.ORG <free...@FreeBSD.ORG> Date: Thursday, December 09, 1999 5:40 PM Subject: Re: POS System
John Sanders wrote:
I would also be interested in the same, if anyone comes up with something. I would love to see a POS back end system more than anything, that interfaces to the ICL/Fujitsu ISS 45 system. I for one work for an ICL/Fujitsu Retail partner (we sell their retail software/hardware), but i'm sick and tired of our current system constantly becoming corrupted and the system going down under serious loads (it runs on NT 4.0). It was written by ICL, so you'd think it would be more stable eh? At any rate sorry for the rambling, but if anyone turns up anything I would <really> like to know, simply because I'm positive FreeBSD could handle any load placed on it by one of our sites.
To start we need specs, protocol and backend DB tables.
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message