Date: Thu, 09 Dec 1999 22:44:49 -0800 From: stephen <schan_ca@geocities.com> To: John Sanders <moose@ebicom.net> Cc: dkwiebe@hagenhomes.com, Langa Kentane <evablunted@earthling.net>, linux-admin@vger.rutgers.edu, freebsd-questions@FreeBSD.ORG Subject: Re: POS System Message-ID: <3850A161.7F46FFA1@geocities.com> References: <00d901bf42bd$4ec9e690$0101a8c0@inferno.dissention.ebicom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello John: 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 129.103.2.1 - 129.103.2.254 (MFS1 = 129.103.2.1, > MFS2 = 129.103.2.2, LFS3 = 129.103.2.3, LFS10 = 129.103.2.10, POS1 = > 129.103.2.11, POS254 = 129.103.2.254) 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. > > John Sanders > ======================================================= > > -----Original Message----- > From: stephen <schan_ca@geocities.com> > To: John Sanders <moose@ebicom.net> > Cc: dkwiebe@hagenhomes.com <dkwiebe@hagenhomes.com>; Langa Kentane > <evablunted@earthling.net>; linux-admin@vger.rutgers.edu > <linux-admin@vger.rutgers.edu>; freebsd-questions@FreeBSD.ORG > <freebsd-questions@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. > > > >Stephen Chan > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3850A161.7F46FFA1>