<<From a vendor's point of view, this means that the more someone is
going to use the product, the more they should pay for it.  Perhaps
software should be priced based upon the number of times it runs, a CPU
should be priced on the number of bits that run through it, a database
should be priced on the number of records stored.>>

Good point. In fact, I've thought several times that maybe MPE/IMAGE
should have a "per concurrent DBOPEN" pricing option of some kind. Since
most HP3000s are probably running IMAGE as a primary function, a
"database-user" based scheme has several advantages over both "size of
box" and "user count" pricing:
1) If you want a high-powered box, you buy it; the hardware price
reflects the horsepower you're putting behind those DBOPENs, but you
don't pay extra for the same number of DBOPENs on the larger box.
2) If you have a lot of users, but don't need tremendous horsepower
(probably not too likely, but possible), you can buy a smaller box to
offset the increased cost of the access.
3) You can buy a development machine, with the bottom-of-the-list DBOPEN
limit, based on how much hardware horsepower you want.
4) If you want a lot of users, but don't want to pay a lot for them, you
can reduce your costs by writing server software that allows you to
multiplex several clients into a single DBOPEN. Of course, creating,
testing, and maintaining such software costs money too.

Steve Dirickson         WestWin Consulting
(360) 598-6111  [log in to unmask]