Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!rsiatl!jgd
From: jgd@Dixie.Com (John G. DeArmond)
Newsgroups: comp.org.eff.talk
Subject: Re: Point of Sale
Message-ID: <6195@rsiatl.Dixie.Com>
Date: 29 Jan 91 03:21:19 GMT
References: <1991Jan28.204538.17471@bronze.ucs.indiana.edu>
Organization: Rapid Deployment Systems (making go-fast things and things that-go fast)
Lines: 97

jkonrath@silver.ucs.indiana.edu (jon) writes:

My department wasnt scanned (its hard to run a lawn tractor over
>one of those counters) but our database was similar. in our 'base, all
>it held was a 20some letter description, a big/small ticket toggle, and
>a price.
>the idea of the storage of these items is about ludicrous, and is totally
>irrelevant.  At a grocery store with an average of 2000 transactions a 
>day, and an average of 30 or so items (these are guestimates) it would
>take thousands of dollars of disk space to store the relatively useless
>data.  and the correlation: its like thinking your unix computer stores
>your phone number when you use chfn; you can tell your personal life to
>someone using the talk command; therefore the system automatically stores
>your personal life when you use talk.
>half the time, they cant even keep the damn database updated; you think
>theyd take the time to store what kind of dog food you buy?

A little bit of knowledge is a VERY dangerous thing.

As I noted in a previous article, I was until recently, the project manager
for a development team implementing one of these centralized data collection
schemes.  I can assure you that every important detail (price, UPC, quantity,
time bought, location bought and so on) IS recorded even on old and 
primitive POS systems.  The database you describe is the master inventory
database and is completely different from the transaction database that
collects POS details.

Let's look at the loading to see if it really would take "thousands of 
dollars of disk space" to store a day's worth of transaction detail.

Let's assume a record layout as follows:

UPC		       6 bytes (always shortened in the POS to save space)
Cust ID		   12 
price          7 
quantity       2  (if more than 99, then enter twice)
timestamp      8  (varies, typical)
-------------------
			   35 bytes/detail

Your assumption of an average of 30 items is close but for capacity planning,
we planned for 5000 transactions per day.  So a day's worth of storage equals

	35 X 30 X 5000 = 5,250,000 bytes.

At a dollar a megabyte or so today, we're talking maybe 8 dollars worth of
disk storage.  In reality, there is usually some more detail stored, such
as retail vs sell price, but this puts things in perspective.

The oldest POS system we looked at collecting data from was a DataChecker
that uses mid-70s logic in an architecture similiar to a PDP-11.  Even
this machine had 2 20 mb 12" spindles onboard.   More modern systems 
easily have hundreds of MB of storage.

Connected to each of these POS systems is a general purpose computer of 
some sort.  Some  vendors supply Unix systems, others use DOS or Oasys.  
The machine may or may not be in the store.  If a store already has a
VSAT or SNA link to the store, it makes sense to connect the POS
controller to a sync modem and have the computer elsewhere. In any event,
this system is designed to offload the data from the POS as quickly as
possible and to filter out error messages and the like and to hold it 
for polling by a regional or centralized computer.  

Our system design used either Telebits on dialup lines for smaller stores
or 64kb/s leased line SNA or VSAT for high volume stores.  And for POS
systems that are not amenable to detail collection, special hardware has
been built that will monitor and log the keystrokes on the POS systems. 
That this kind of money is being spent should show you how much some
people value this data.  

You are correct in saying that the individual stores do not store your
life history.  They don't need to.  All they need is your SSN, your check
cashing card number, your frequent buyer number or anything else they can
use to match the transaction data against your personal information
records on the mainframe.  The data agregators DO know this information
because they buy it from a  variety of sources including our favorite,
Equifax.  The stores then buy this filtered data back from the agregators
when needed. 

You may want to believe that "nice people" would not do these things or
that technology won't permit it but if you do, you are simply fooling
yourself.  These systems are already in place in many parts of the 
country.   Citibank is the leader; many others are scrambling for a 
piece of the pie.  The worst thing one can do is underestimate his
enemy, something you have gravely done.

John

PS:  The tricks used to get ethical programmers and managers to work 
	on such systems is the subject of a story of its own.  The lessons
	of Big Brother have been learned well.

-- 
John De Armond, WD4OQC        | "Purveyors of speed to the Trade"  (tm)
Rapid Deployment System, Inc. |  Home of the Nidgets (tm)
Marietta, Ga                  | 
{emory,uunet}!rsiatl!jgd      |"Politically InCorrect.. And damn proud of it