Is there one particular question that appears to hold the record for the most frequently answered?
(Thread taken directly from CDP, with original formatting preserved.)
========
Newsgroups: comp.databases.pick
Subject: Pick on old GA box?
From: Michael Hayworth <73233.2014@CompuServe.COM>
Date: 9 Feb 1996 04:26:02 GMT

I've been asked to evaluate an IS shop that's currently running
Pick and is wanting to buy a new system. They are running a
General Automation box utilizing Pick for all their development.
They told me they're running Pick R91, but they weren't sure
whether that referred to the version of PICK, the GA box, or the
total package. The system is five or six years old now.

They're looking to move to another GA box, which is essentially a
relabeled IBM machine running dual PowerPC processors and again
utilizing PICK. They're looking at spending a wad of cash on
this, and I hesitate to concur with spending $150K on this system
simply to avoid rewriting all their legacy code. In fairness,
there is a slew of legacy code and they do manage a lot of
data--everything is in a single 15GB customer/prospect database
and the machine runs constantly producing mailing lists, calling
lists, prospect lists for salespeople, telemarketed leads for the
field sales force, on and on. (I do think they'd benefit from
moving this huge database to three separate databases, one for
each of their three major customer and prospect types.)

I am skeptical, but want to keep an open mind. Can someone help
me equate the processing power of what they have to one of todays
Intel or RISC boxes? And can someone help me understand what they
love so much about PICK?

--
Michael Hayworth
Technology Director
Innovative Marketing
Fort Worth, Texas

========
Newsgroups: comp.databases.pick
Subject: Re: Pick on old GA box?
From: Gulraj Rijhwani 
Date: Fri, 09 Feb 96 12:03:24 GMT

In article <4feicq$pp2$1@mhafn.production.compuserve.com>
           73233.2014@CompuServe.COM "Michael Hayworth" writes:

> I've been asked to evaluate an IS shop that's currently running
[repost cut by ed.]

R91 is the version of the the o/s, which GA first released (surprisingly
enough) in mid 1991.  It implies that their hardware is one of the
"Advantage" series machines, A200, A400... you get the idea, although
being 15Gb one assumes it's one of the larger members of the series
.  However, without specific model number and configuration
information, it's impossible to make any useful comments about the absolute
performance figures.  By comparison with the proposed hardware it's
probably a lumbering dinosaur, though.

Porting onto the new kit shouldn't present too many problems, having
been involved in performing a very similar operation last summer.  R91
system transferred onto Motorola PowerStack, AIX and AP.  Your most
likely problems will come from data-entry and phantom routines, and
B-tree indexes (if they're used) will have to be re-built.  Provided
you and your client plan sensibly for teething problems and downtime
during the first couple of days, and iron out the worst wrinkles in one
or two dry runs it should go smoothly enough.

And what do they love about Pick?  Ask them.  It's a system designed
with flexibility in mind.  If for no other reason, ACCESS (the reporting
language inherent in the system) which even the least technical of
people can get to grips with if they have the inclination.  And of course
familiarity.  They know it, they've used it for several (at least 5)
years.  Better the devil you know...  Turn it around.  What are your
concerns about them staying with a system they know and like?  What would
be the benefits of migration elsewhere?  Particularly if the application
would have to be re-written?

No-one can comment on your advice that they should separate the database
without having been party to the analysis phase.  Perhaps they require
total, overall, combined reporting.  Is there shared, common data?  Do
they migrate prospects/clients between what you consider to be the three
discrete sections?  How would they benefit?  Too many questions.

Purely from the performance point of view, if the current design is
carried on, Pick is more than adequate to the task on the grounds that
it handles it now.  Sloppy, but true.
--
Gulraj Rijhwani           |  Courtfields Limited, Chessington, Surrey, UK
gdr@courtfld.demon.co.uk  |  Tel:    0181 255 4667  Fax: 0181 287 8381
Enquiries welcome         |  Mobile: 0374 921179
- Specialist in Pick, Unidata, data communications and general connectivity -
All material copyright Gulraj Rijhwani and Courtfields.  ALL RIGHTS RETAINED.

========
Newsgroups: comp.databases.pick
Subject: Re: Pick on old GA box?
From: Michael Hayworth <73233.2014@CompuServe.COM>
Date: 13 Feb 1996 04:56:13 GMT

The system is an A600. Can you comment on the processing power of
that system, in relation to something in the Intel or RISC
world?

Also, I understand what you're saying about the advantages of
PICK and why people like it. One of the things touted as an
advantage, though, seems to me more a detriment in this
situation. Perhaps you can clear up my questions.

The standard objection against variable length records is that it
makes the system have to do much more processing in selecting
records, which is the primary thing this shop does. Of course,
the main fields will be indexed,  but in many cases, I have to
add ad hoc criteria to my SELECT statement (to put it in SQL
terminology) to choose only records where non-indexed field X
equals ZZZ. In this case, a variable-length system can easily
select a group of records that meet any criteria I've indexed on,
but then it has to actually read each character in those records
to find field X and check its value, because it doesn't know for
sure that field X begins at offset Y in the record, as a SQL
database would.

Does PICK have some nifty way around this problem?

Thanks.

--
Michael Hayworth
Technology Director
Innovative Marketing
Fort Worth, Texas

========
Newsgroups: comp.databases.pick
Subject: Re: Pick on old GA box?
From: doug@modsoft.com (Doug Dumitru)
Date: 13 Feb 1996 00:12:01 -0700

Michael Hayworth <73233.2014@CompuServe.COM> wrote:

>The system is an A600. Can you comment on the processing power of
>that system, in relation to something in the Intel or RISC
>world?

This system is probably based on a Motorola 68040 running at 80MHz.
From a purely CPU point of view this is about 486DX4-100 land with
decent memory ,disk, and terminal subsystems.

>Also, I understand what you're saying about the advantages of
>PICK and why people like it. One of the things touted as an
>advantage, though, seems to me more a detriment in this
>situation. Perhaps you can clear up my questions.

>The standard objection against variable length records is that it
>makes the system have to do much more processing in selecting
>records, which is the primary thing this shop does. Of course,
>the main fields will be indexed,  but in many cases, I have to
>add ad hoc criteria to my SELECT statement (to put it in SQL
>terminology) to choose only records where non-indexed field X
>equals ZZZ. In this case, a variable-length system can easily
>select a group of records that meet any criteria I've indexed on,
>but then it has to actually read each character in those records
>to find field X and check its value, because it doesn't know for
>sure that field X begins at offset Y in the record, as a SQL
>database would.

This type of analysis is valid when considering CPU requirements for
processing records, but it ignores I/O issues.  In a Pick database,
the records will be packed into a fewer number of disk sectors leading
to fewer disk operations in total where in a flat-file database, the
data is physically spread out further.  Even though Pick may need more
time to scan through delimiters, this is one of the most heavily
optimized operations in any Pick implementation.  The tradeoff of less
disk I/O far outweighs this problem.

This is not to imply that Pick beats flat-file databases in
performance in all types of operations.  Flat-file databases often
outperform Pick in some entire-file select type operations because the
flat-file databases arrange for the I/O to be performed in a more
orderly fashion.  As soon as the entire file is not involved, Pick
again becomes more efficient because of the direct-hit hashed file
structure that typically involved only a single disk operation per
record even with truely randomly distributed records in a data file
that is much larger than memory.

I have not performed extensive tests on the A600, but if memory serves
me correctly (and I did not write these numbers down), on the Power PC
box that the customer is contemplating, I believe it traverses data
during a select at better than 4 Megabytes a second off of a single
non-striped disk.  This is not far from theoretical disk bandwidth.

>Does PICK have some nifty way around this problem?

Pick's way around this problem is to very very very carefully
implement an instruction called SICD (Scan Incrementing Counting
Delimiters).  The efficiency of this one virtual machine instruction
is the reason that Pick works at all.

Doug Dumitru
Modular Software Corporation

ps:  Your comment that the main fields will be indexed is probably
using GA's BTREE indexes, which I wrote.


========
Newsgroups: comp.databases.pick
Subject: Re: Pick on old GA box?
From: heggers@netcom.com (Henry Eggers)
Date: Wed, 14 Feb 1996 19:03:25 GMT

Doug Dumitru (doug@modsoft.com) wrote:
: Michael Hayworth <73233.2014@CompuServe.COM> wrote:

: >Does PICK have some nifty way around this problem?

: Pick's way around this problem is to very very very carefully
: implement an instruction called SICD (Scan Incrementing Counting
: Delimiters).  The efficiency of this one virtual machine instruction
: is the reason that Pick works at all.

I wouldn't put the focus on the SICD, because that is a new instruction
for 3.0/R77 (Sorry, Michael, this is very archane), and the function of
Pick and Microdata versions is significantly different.  I would place
the focus on the MIID/SID pairs.

(As an asside, I note that SICD Rx,X'xx' in its conventional use, has
roughtly the function Label SIC X'E0'; BDHZ CTR,Label, except that
the BD set and the -H- comparitor are also both 3.0/R77, so the
actual code was label SIC X'E0'; DEC CTR; BNZ CTR,Label.  Thus
spake the runes of the flowcharts.)

It also ignores the question of how versions written without the
traditional machine definition language come to have 'the same'
performance in 'the same' environment.  Fundamentally, I think, it
derives from a view that 'data' comes only as ascii strings.  This
avoids all sorts of conditional code at runtime.  Consider, for
instance, the difference between the implementation of extended
character sets as escaped sequences versus making everything 16 bit.
By eschuing the blandishments of local optimization, and keeping
one's eye on the general intent and principle, one builds a better
machine.  Albeit I've not seen that observed upon in the canon
of computer science (implicit request for counter-examples).

So, what the traditional machine ended up with was a pair of very RISC
instruction sets, one for the 'data', which was all and only strings,
and the other for the 'control data', which was all binary, fixed-field.

One of the benefits of the complete separation of datatypes is that
an 'item' can be passed to any processor as-is, without any transformation
(and historically was looked at 'in place' in the file, on the disk,
rather than moved to a buffer for the application -- yeah, yeah, I know,
more impossible magic -- next we'll be that disk io is done in the
middle of the instructions, below the instruction set, at a level
lower than the lowest level of the logical machine...).

Every time I look at this thing, I find a collection of weird and
ridiculous decisions, which just happen to fit rather well together
with the contiguous weird and ridiculous decisions.  So, how does
one come up with a general and theoretic description and discussion
of a machine, about which one finds oneself per force saying, in the
presence of the well-turned out computer scientist, things like, "Well,
I know this is wrong, but...;"  "Well, I know this seems hard to believe,
but...;"  "Yes, I know we can prove that it won't work, but..."  I am
forever reminded of the bumblebee;  but bumblebees don't have consciousness,
or at least don't read scientfic tracts on flying, so they are not encumbered
by an awarness that they shouldn't be doing that.  We are.

Which still leaves us with the apparant conclusion that a pick engine can
be implemented in anything, in any way a 'reasonable man' would implement
(and a number of exceptions have done fairly well, too), with the same
apparant performance, albeit, with no 'software' component in common,
and that this tends to cost about an order of magnitude base ten less
for an arbitrary application.

Anyone want to venture an observation as to what the fundaments are?

Regards, hve.

========
Newsgroups: comp.databases.pick
Subject: Re: Pick on old GA box?
From: heggers@netcom.com (Henry Eggers)
Date: Tue, 13 Feb 1996 21:21:02 GMT

Michael Hayworth (73233.2014@CompuServe.COM) wrote:

The question in this generic thread is always, where to starrt.

: The system is an A600. Can you comment on the processing power of
: that system, in relation to something in the Intel or RISC
: world?

Well, it's half a dozen years old, so it probably goes between .1 and
.3 of a 'current' machine.  Dual 604's will be on the order of 300x, for
those who remember 'x'.  Think of them as faster than the prior ones, and
slower than then next ones.

: Also, I understand what you're saying about the advantages of
: PICK and why people like it. One of the things touted as an
: advantage, though, seems to me more a detriment in this
: situation. Perhaps you can clear up my questions.

The fundamental problem appears to be that the 'pick machine' can not
usefully be described in computer science terminology.  That's an
unnecessarily broad statement, which I'll not attempt to defend here;
I ask, or suggest, your forebearance:  Think of the pick machine as being
'alien', something which functions on unknown axioms.  No?  Too outrageous?
Yeah, I know.  It's a problem.

: The standard objection against variable length records is that it
: makes the system have to do much more processing in selecting
: records, which is the primary thing this shop does. Of course,
: the main fields will be indexed,  but in many cases, I have to
: add ad hoc criteria to my SELECT statement (to put it in SQL
: terminology) to choose only records where non-indexed field X
: equals ZZZ. In this case, a variable-length system can easily
: select a group of records that meet any criteria I've indexed on,
: but then it has to actually read each character in those records
: to find field X and check its value, because it doesn't know for
: sure that field X begins at offset Y in the record, as a SQL
: database would.

First, let me note that there are local optimizations which, viewed
from the point of view of the SQL model, work better in SQL.  Unfortunately,
that is the case, pairwise, for all pairs, so that observing on it is
neither a credit nor a criticsm.

Second, the observation that variable-length records are too inefficient
is true of a lot of parts of pick machines:  There are a lot of
characteristics which would have been 'pruned' at the outset, if the
people implementing it had 'known anything about computers', not the
least of which being that it has traditionally been an emulation.  The
GA machine is a macro expansion of the original flow chart notation code.

Third, I note that the machine scans to the attribute in question, and
then does the comparison as you note.  Not only that, but, historically,
pick machines did not have indexing (which is why Doug can observe that
GA has his, a third-party product).   Skipping a long, tortuous
argument, which is more a speculation on why the machine appears to be
performant, than a specification, it probably works out that most
'items' (don't get these confused with either records or files) aren't
particularly big, and that 'the machine' (which has essentially nothing to
do with hardware) concerns itself with string handling.  What this means is
that most of the time is taken getting the data into memory, rather than
doing the searching,.  Unless you keep all of your data in 15GB of ram, which
is possible, but in that case I expect that the data will expand...

So what really happens is that SQL optimizes the easy part, finding
the field, by making the hard part, data size, harder.

: Does PICK have some nifty way around this problem?

I'm not sure we should call it nifty.  What pick appears to do is
redefine what the problem is.  This always bothers me, because it was part
of Dick's charm that he would ignore that which was inconvenient.
But the problem remains that pick is deeply counter-intuitive, if you
know about computers.  And it's obvious if you don't.  Fundamentally,
the topology of the data is not just isomorphic to its real-world
instantiation, but essentially identical.  There is no abstraction
between the two forms.  The result is that pick is 'proveably wrong'
from almost RDB/SQL criteria.  One or another of our associates might
take this opportunity to remind us of the details.  On the other hand,
this doesn't seem to bother the tens of thousands of businesses which
run on the thing.

This state of affaires has been stable for so long that I'm inclined to
put my social scientist hat on and go out there and find out what's
happening.  Well, not really.  But there appear to be issues salient to
the users of machines which are orthogonal to things on the minds of
well turned out computer scientists.

There is one other, ahhhh, matter:  The question of the 10k$ worth
of SQL to replace a well bedded in Pick application.  This one might
be different, but...  I'm torn between a contract involving debtor's prison
if it doesn't get done, and some gentle advice, the former because
this is not the first suggestion of this flavor.  I simply mention my
favorite reportation, which was flushed after 500 man years.

The problem,  going with the gentle advice, is that it is so easy to add
bits of implementation to a pick machine.  Normally, a lot of this has been
done.  It turns out that basic and English are as concise, in their way,
as the representation of the data.  So, while it may be possible to
replicate an SQL implement, presuming one can figure out what it's doing,
on a pick machine for 10k$, the converse is more problematical -- if for
no reason than that it's probably even harder to figure out what _it's_
doing.

In the immortal words of John Timmons, the only thing harder that getting
an application onto Pick, is getting it off.  The only problem with
that is, that getting it onto pick is blindingly simple.  Typically
by people who knew their business, and nothing about the computer, who
'worked out' an application and then went on to sell it...

In the most simple terms, a reason which one might educe for why people
like their pick machine, is that they can get more application and function
out of it for less money -- typically an order of magnitude base ten -- and
faster than anything else (of the shared database, minicomputer sort).

Then there's the matter of the data base.  It isn't a database, it's a file
system, a blindingly fast direct-access file system.  It's not hierarchal;
it's not relational;  it's not post-relational;  it's not object;  it's not
the next buzzword, either.  Indiginees around these parts will recognize
shadows of past palaver in a Platonic way.  But it has been called each
of these things, and kind of  acts like each of these things, if you
view it that way.  I keep expecting database technology to catch up, vainly.
All of which is wildly eliptical.

In order to understand pick:  I'm not, ahhh, particularly convinced by the
extant documentation,   which is said with the greatest of esteme for
our associates who have bent their attention to the description of the
elephant.  Rather, I'm inclined to see it as unspeakable.  :-)  It seems
to me that one has to 'forget' what one knows about computers and 'flow
with it'.  The term 'weedware' has been bruited about.  Unfortunately,
I seem to be participating in a sudy eintitled "The net will be the primary
cause of mayhem in the 21st century," and have about a three minute telnet
echo, I must away, and appologize for the vagueries of text above therefrom.

Regards, hve.



========
Newsgroups: comp.databases.pick
Subject: Re: Pick on old GA box?
From: murraya@enternet.co.nz (Murray Archer)
Date: Sun, 18 Feb 96 11:16:43 GMT

In article <4fp5ld$7ej$1@mhafc.production.compuserve.com>,
   Michael Hayworth <73233.2014@CompuServe.COM> wrote:
>The system is an A600. Can you comment on the processing power of
>that system, in relation to something in the Intel or RISC
>world?
>

From what I recall, the A600 is a 50 MHz 68030 machine.
You should be able to find some specs that compare theoretical CPU
throughput.

We upgraded from a GA 7820 (25 MHz 68020) to the A600.
There was a big improvement in performance, tho most of that
was due to faster fixed disks.
(usual caveat that machine performance is more related to
disks, bus speed, cache...not just CPU speed)

We were able to run 60 concurrent users with subsecond response
time, no problems (except if we started tape ops...)

My guess would be that it would rate about the same as a Sun SPARC 1

[snip]

>the main fields will be indexed,  but in many cases, I have to
>add ad hoc criteria to my SELECT statement (to put it in SQL
>terminology) to choose only records where non-indexed field X
>equals ZZZ. In this case, a variable-length system can easily
>select a group of records that meet any criteria I've indexed on,
>but then it has to actually read each character in those records
>to find field X and check its value, because it doesn't know for
>sure that field X begins at offset Y in the record, as a SQL
>database would.
>

IMHO you overestimate this as a problem
Once the disk record has been located and read into RAM, then
CPU time spent to scan through a few 100 or 1000 chars in a string,
to locate a field, is negligable

Especially compared to the many many other overheads imposed
by a SQL RDBMS
Do you suppose we could run Oracle on a 68030 and support 60 users?
Dream on  ;-)



========
Newsgroups: comp.databases.pick
Subject: Re: Pick on old GA box?
From: bcohn@aol.com (BCohn)
Date: 9 Feb 1996 09:44:51 -0500

They love Pick (you say) but they're looking to move off it? Or is that
your idea? Perhaps if it's your idea you *should* keep an open mind and
enlist some Pick people in the area to educate you. It's a bit dangerous
for a non-Pick person to redesign a Pick system...

========
Newsgroups: comp.databases.pick
Subject: Re: Pick on old GA box?
From: Michael Hayworth <73233.2014@CompuServe.COM>
Date: 9 Feb 1996 21:16:13 GMT

>>They love Pick (you say) but they're looking to move off it? Or
is that your idea? Perhaps if it's your idea you *should* keep an
open mind and enlist some Pick people in the area to educate you.
It's a bit dangerous for a non-Pick person to redesign a Pick
system... <<

Moving off it is my idea. And I think keeping an open mind and
enlisting some Pick people to educate me was the purpose of my
post.

Their idea is that they need to spend $150-200K on a new PICK
system to meet their processing needs. It's going to take a lot
to convince me that that needs to happen. My general feeling is
that we can accomplish everything we need to accomplish with
about $50K of new hardware and $10-20K of contractor's time to
rewrite their systems in SQL, leaving us spending a lot less
money and having a system in place with a lot more future. That's
why I'm trying to get an idea of the processing power of what
they really have in place now.

MH

--
Michael Hayworth
Technology Director
Innovative Marketing
Fort Worth, Texas

========
Newsgroups: comp.databases.pick
Subject: Re: Pick on old GA box?
From: "Geoffrey D. Genz" 
Date: Fri, 09 Feb 1996 15:13:31 -0700

Michael Hayworth wrote:

> Their idea is that they need to spend $150-200K on a new PICK
> system to meet their processing needs.

It strikes me that there must be ways to migrate the PICK system for
something much less than that.  PICK hardware is certainly no more expensive
generally than anything else, and in fact, usually is "anything else" if you
choose one of the Pick on Unix variants.

I migrated an admittedly much smaller system from GA R83 to Universe on a Sun
SPARC for less than $25k, total.

> That's why I'm trying to get an idea of the processing power of what
> they really have in place now.

It might help if you could find out a little more about the GA box.  They
have had several, most of which would make a 486 look like a Cray.

And if nobody's said it yet, R91 refers to the version of the PICK operating
system.  It should port without too much effort to anything current.

Personally, I have no love of GA.  I think there's a good reason they're
pushing IBM boxes.

Geoffrey

========
Newsgroups: comp.databases.pick
Subject: Re: Pick on old GA box?
From: Michael Hayworth <73233.2014@CompuServe.COM>
Date: 13 Feb 1996 05:01:50 GMT

Do you know anything about the GA A600? That's the machine they
have, but they can't really tell me much about what's inside it
except that they think, but wouldn't bet beer money on it, that
it's based on a Motorola 68040.

MH

--
Michael Hayworth
Technology Director
Innovative Marketing
Fort Worth, Texas

========
Newsgroups: comp.databases.pick
Subject: Re: Pick on old GA box?
From: dahnf@openix.com (Dahn Finard)
Date: Sun, 11 Feb 1996 05:46:28 GMT

Michael Hayworth <73233.2014@CompuServe.COM> wrote:

>>>They love Pick (you say) but they're looking to move off it? Or
>is that your idea? Perhaps if it's your idea you *should* keep an
>open mind and enlist some Pick people in the area to educate you.
>It's a bit dangerous for a non-Pick person to redesign a Pick
>system... <<

>Moving off it is my idea. And I think keeping an open mind and
>enlisting some Pick people to educate me was the purpose of my
>post.

>Their idea is that they need to spend $150-200K on a new PICK
>system to meet their processing needs. It's going to take a lot
>to convince me that that needs to happen. My general feeling is
>that we can accomplish everything we need to accomplish with
>about $50K of new hardware and $10-20K of contractor's time

I have seen this kind of arrogance before. How about I give you odds 2
to 1 that you will end up spending a multiple of the 20K contractors
time to rewrite the system and still not satisfy the user.
	The hardware is not the issue. Pick is more efficient than most
database systems. If you buy a Unix box you can run Oracle or whatever
database you think might be superior.  Then if you want to for the
sake of some dogma or you personal comfort with the software you can
attempt you rewrite.


========
Newsgroups: comp.databases.pick
Subject: Re: Pick on old GA box?
From: heggers@netcom.com (Henry Eggers)
Date: Thu, 15 Feb 1996 20:21:54 GMT

Stephen Rathkopf (srathkop@ix.netcom.com) wrote:
: In <4fla9c$2lb@spasmolytic.openix.com> dahnf@openix.com (Dahn Finard)
: writes:
: >Michael Hayworth <73233.2014@CompuServe.COM> wrote:
: >
: ***********************************************************************

: We keep talking about how little we are understood in the 'mainstream'.
: We keep talking about how we need to educate our non-pick colleagues.

Yes, and we've been talking about it for decades.  That we've been
talking about it for decades should be a hint that it is hard to do.
Pick is not a better <>, where <> is whatever is in vogue.  That pick
machines have been shipped commercially in ever-increasing
numbers for more than 20 years, unique in itself in the computer business,
has given time for a lot of <>'s to have been in vogue.  In each case,
the <> probably solved the problem it was trying to solve in some sense
better than pick solved it. But that's true pairwise of almost everything.

So, it appears that pick is talking _about_ something else than its
'competition'.  Trying yet another verbal fling, let's say that the
pick system is technically egoless, and simply acts as neutral -- nutral? --
fluid in which business solutions arise.  It's been bought, essentially,
by people with a business problem and not the least interest in computers,
by entrepreneurs who wanted to win in their market segment.  The ability
of the pick machine to give them an advantage in application flexiblity,
application timeliness, and, really better information faster than
their competitors, allowed a lot of them to do inordinately well in
their markets.

As an aside, I note that people observe that 'pick is for businesses, not
corporations.'  It's not because corporations are too big.  I think it's
because corporations are too lazy:  If the decision falls to the IT manager,
there is the line, "No one ever got fired for buying IBM."  'Course  now
it's Oracle.

As another aside, I note that pick has always been the haggis of computer
systems:  Cheaper than anything else.  The real effect of this is that
the manufacurers have been permanently starved.  Hummm.. Maybe that's why
it's lived so long...

This leads to the conclusion that pick is 'useful' because it is
incommensurable with computer science.  That also suggests that
computer science is not particularly useful.  Well, ok, after
fourty years of trying, a few interesting results are beginning to
creep into view.  This is not particularly unique in the interaction
between analysis and real things.  Annand and Row observe that, "Until
recently, there were many aspects in which theory could give little
guidance, and indeed quite a few areas remain in which theoretical
models are vague and clumsy.  It is this complexity which gives it its
continuing fascination."  It also turns out that those bits about which
something apparantly coherent can be said become the major focus of the
field.  It is always wise to stand back from scientists at work, to
look at the whole canvas, to be aware of what they're not talking about
because they've not marketable ideas.  It's also good to remember that
science is a highly entrepreneurial business, not an act of altruistic
monastic contemplation.

So I would suggest that pick is essentially outside of the model of
computer science, even though it does certain practical things fairly
well.  If one knows the internals, one is amazed at what a small
part of what it could do naturally it really does do, and the orders
of extention it calls for out of itself. Heidigger touches on this
in 'The Question Concerning Technology' ('Der Ursprung des Kunstwerkes'),
but this takes us a bit off the track.

: Here is an opportunity to enlighten someone who seems sincere, but
: lacks the pick expertise and vocabulary to talk-the-talk.

I remember coming to pick,  being told that it had files and items and
attributes.  Of course, I attempted to map this onto what I knew,
which was OS360 files and records.  So I figured that 'attributes'
were fields, and asked why they weren't called that...  Now I find
people coming from Dos/Unix and finding that files are directories and
that items are files, and attributes?...  Each of these descriptions
tends to be a complete, absolute description of 'what a computer is',
and of course none is.  Each is a description of an arbitrary and
capricious convention with which one may be able to do some things,
after enough work.

So, to say that pick used to be viewed as an OS, and as a database,
and then as a relational database, and then as a post-relational
database, and possibly as an application definition or execution
environment, and exists in various instances as various subsets of
what one has come to  'expect', is to describe very little about
the actual machine, but to describe alot about pick in the 'general'
context.

: Some of us have made attempts to help, others talk of his arrogance.

I don't think that anyone was speaking of the founder of this thread;
I do think, however, that we've all been told, time and again, by
the carriers of one tecnical theology after another, that we were
mad as hatters, completely irrelevant, had missed the boat, were
bad, et cetera.  I particularly remember being upbraided in the late
'70s about not using Pascal, and then C, of being a worse OS than
Unix, of not having communications, not whatever the flavor of the
month was.  Essentially all of those cavails were red herrings.

[And in this particular instance, we've seen the effect of the hubris
of the uninitiated.  Pick does so much with so little that people
think it's simple in the terms of their conventional machine.]

: We need to take the high road with him, and any others.

Of course.  But it's hard to sound like one is taking the high road
if one has, per force, to start with the observation, "This thing doesn't
match your understanding of what a computer is."  I assert that it can
not be usefully described in terms of the model of RDB/SQL, other
than to discover its insufficienies, or in terms of Unix, Dos, et
cetera.  So that leave us with some genlte hand-waving, which I think
Doug did best in his paragraph, "... them's fighting words...", and some
gentle recommendations to reevaluate the magnitude of the problem,
which came with the term, "..severely underestimated...".  Which itself
is a pretty severe understatement.  I think the 'estimate' was about
two orders of magnitude base ten low, but I can't explain why, and
not being able to explain why is deeply unexceptable in the current
context.

The citation from Annand and Roe is, _Gas_Flow_in_the_Internal_Combustion_
_Engine_, at page 9, Haessner, 1974.

Regards, hve.

========
Newsgroups: comp.databases.pick
Subject: Re: Pick on old GA box?
From: dessoft@main.com (gary valmain)
Date: 11 Feb 1996 20:25:15 GMT

In article <4fgdit$94h$1@mhadg.production.compuserve.com>, dated 9 Feb 1996
21:16:13 GMT, Michael Hayworth posits...
>
>>>They love Pick (you say) but they're looking to move off it? Or
>is that your idea? Perhaps if it's your idea you *should* keep an
>open mind and enlist some Pick people in the area to educate you.
>It's a bit dangerous for a non-Pick person to redesign a Pick
>system... <<
>
>Moving off it is my idea. And I think keeping an open mind and
>enlisting some Pick people to educate me was the purpose of my
>post.

Aahhhhaa.

>
>Their idea is that they need to spend $150-200K on a new PICK
>system to meet their processing needs. It's going to take a lot
>to convince me that that needs to happen.

Did they ASK you for an opinion as to whether to move from Pick?
Your postings state they did not.  Therefore, you are not providing
the service you were contracted to provide.  However, IF they did
ask you to consider the possibility of moving off Pick, okay.

What you are suggesting sounds like you wanting to put more dollars
into your pocket, at their risk.  And, the risk is very substantial.  You
obviously (as stated) don't know anything about Pick.  Therefore
you are completely oblivious to the downside to porting to a non-Pick
environment.  YOU will make a LOT of money.  YOU may put the
customer out of business.

 My general feeling is
>that we can accomplish everything we need to accomplish with
>about $50K of new hardware and $10-20K of contractor's time to
>rewrite their systems in SQL, leaving us spending a lot less
>money and having a system in place with a lot more future. That's
>why I'm trying to get an idea of the processing power of what
>they really have in place now.
>
Your dollar estimates are severly underestimated.  There are major
differences in the database/OS technologies which WILL have
significant impact on performance.  These differences will cause
the expenditure of massive amounts of dollars to add additional
hardware to compensate for the poor relative performance of the
new system.

Take my suggestion from my first response:  At least acquire the
magazine and read the article on the subject.  Preferably, do a lot
of research on Pick AND, as others have suggested,  bring in
someone you knows Pick to assist you.

Remember, you have only your reputation at risk.  Your customer
has their business life at risk

>MH
>
>--
>Michael Hayworth
>Technology Director
>Innovative Marketing
>Fort Worth, Texas

Proceed carefully.

gary valmain
_______________________|____independent pick applications programmer____
designed software, inc____|_ladies home companion__wars fought_whiskey_coins
voice_____713.367.8765__|_revolutions started_governments run_bars emptied
fax_______713.367.4316__|_uprisings quelled_burglars alarmed__tigers tamed
email dessoft@main.com__|_country gentleman_orgies organized_coffins_nails
compuserve__72203,2372__|_computers verified___used cars___land___manure
_______________________|_country gentleman___all round really nice guy


========
Newsgroups: comp.databases.pick
Subject: Re: Pick on old GA box?
From: pluck@cnj.digex.net (Rick Poleshuck)
Date: 10 Feb 1996 01:23:02 GMT

Michael Hayworth (73233.2014@CompuServe.COM) wrote:
:
: They're looking to move to another GA box, which is essentially a
: relabeled IBM machine running dual PowerPC processors and again
: utilizing PICK. They're looking at spending a wad of cash on
: this, and I hesitate to concur with spending $150K on this system
: simply to avoid rewriting all their legacy code. In fairness,
: there is a slew of legacy code and they do manage a lot of
: data--everything is in a single 15GB customer/prospect database
: and the machine runs constantly producing mailing lists, calling
: lists, prospect lists for salespeople, telemarketed leads for the
: field sales force, on and on. (I do think they'd benefit from
: moving this huge database to three separate databases, one for
: each of their three major customer and prospect types.)
:
You haven't filled us in with all the details, i.e. how many users,
but it seems to me $150k for a system supporting a 15GB database is
relatively cheap. $150k is less than 2 man/years of programmer time.
Unless you can find a canned application already tested and in use that
will fulfill their needs, you would make yourself look very foolish to
suggest anything else.

I would however consider choosing one of the top 3 Pick providers
rather than GA. I wouldn't think a port to AP would be difficult from
GA. GA service is good, and there is benefit in having software and
hardware support from one vendor.

TTFN
--
                | Email - pluck@cnj.digex.net
Rick Poleshuck  | Voice - (908) 245-1177
                | Mail  - Rick Poleshuck & Associates
                |       - 308 Elizabeth Avenue, Cranford, New Jersey  07016


========
Newsgroups: comp.databases.pick
Subject: Re: Pick on old GA box?
From: doug@modsoft.com (Doug Dumitru)
Date: 9 Feb 1996 19:14:01 -0700

Michael Hayworth <73233.2014@CompuServe.COM> wrote:

>I've been asked to evaluate an IS shop that's currently running
>Pick and is wanting to buy a new system. They are running a
>General Automation box utilizing Pick for all their development.
>They told me they're running Pick R91, but they weren't sure
>whether that referred to the version of PICK, the GA box, or the
>total package. The system is five or six years old now.

>They're looking to move to another GA box, which is essentially a
>relabeled IBM machine running dual PowerPC processors and again
>utilizing PICK. They're looking at spending a wad of cash on
>this, and I hesitate to concur with spending $150K on this system
>simply to avoid rewriting all their legacy code. In fairness,
>there is a slew of legacy code and they do manage a lot of
>data--everything is in a single 15GB customer/prospect database
>and the machine runs constantly producing mailing lists, calling
>lists, prospect lists for salespeople, telemarketed leads for the
>field sales force, on and on. (I do think they'd benefit from
>moving this huge database to three separate databases, one for
>each of their three major customer and prospect types.)

Depending on the scale of their operation, I would take exception to
claiming that $150K is a "wad of cash".  15GB of anything is not
trivial and is definately beyond the scope of anything that you buy at
the local computer store.  The GA box they are looking for is running
the same O/S virtual source code as the R91 system they are coming
from.  This means that the port should be very close to painless and
should be a re-compile of BASIC (frame sizes on the Power-PC
R91/Power-95 port are 4K as opposed to 2K on the 68K R91 port)

>I am skeptical, but want to keep an open mind. Can someone help
>me equate the processing power of what they have to one of todays
>Intel or RISC boxes? And can someone help me understand what they
>love so much about PICK?

There current system, assuming that it is the fasted non-PowerPC GA
box is an 80MHz 68040 single CPU system with 16 to 64 Megabytes of RAM
and a single SCSI disk channel running 5400 RPM SCSI-II peripherals.
The proposed system is about 6x in CPU performance, probably has more
memory, and has fast-wide SCSI-II disks at 7400 RPM for about 2.5x raw
disk performance.  Comparing to INTEL boxes, the Power PC boxes are
about equivelent to 200 MHz P6 processors (roughly), but remember that
there are two of them and Power PCs tend to multi-process slightly
better than Pentiums (admittedly open for arguement here!).

Regarding "what they love so much about Pick", them's "fightin words".
Pick is a particular data model that is heavily optimized for business
data processing operations.  It is often self-administered, makes very
frugal use of computing resources, and has a natural means of
developing applications that allow many end-users to maintain and
implement large-scale business applications will little or no formal
training (this can be a double-edged sword).  I will leave it to other
to expound on this.

Doug Dumitru
Modular Software Corporation

ps:  I do not work for GA, but I am somewhat biased as GA systems
account for a good amount of my companies business and our BTREE code
is licensed to GA.


========
Newsgroups: comp.databases.pick
Subject: Re: Pick on old GA box?
From: Mary Wadsworth 
Date: Tue, 13 Feb 1996 17:06:53 +0000

Doug Dumitru wrote:
>
> Michael Hayworth <73233.2014@CompuServe.COM> wrote:
>
> >I've been asked to evaluate .... The system is five or six years old now.
>
> >They're looking to move to another GA box ....
>
> Depending on the scale of their operation, I would take exception to
> claiming that $150K is a "wad of cash".  15GB of anything is not
> trivial and is definately beyond the scope of anything that you buy at
> the local computer store....
>
> ..........
>
> Doug Dumitru
> Modular Software Corporation
>
> ....

I am partial to the INTEL platforms (UNIX or NT) because the R&D investment in
operating system/software/system software continues to far exceed that of any other
platform.  INTEL has moved up the "food chain", and has started manufacturing
multi-CPU mother boards (i.e. they've figured out how to do symmetric
multiprocessing).  This is expected to be the new commodity (rather than a chip).

Regarding the Pick or Pick-like platform...I would look into the popularity and
success of the various vendors that are selling these products AND the support
mechanism/staff.

AND, I have to agree with Doug Dumitru -- $150K is a small wad of
cash for the size of the database...especially if this is 'mission-critical' data that
is necessary for the business.  How much $$ will they lose if they lose the data?

Mary Wadsworth
Data General Corporation

========
Newsgroups: comp.databases.pick
Subject: Re: Pick on old GA box?
From: riddle@interlog.com (Steve Riddle)
Date: 14 Feb 1996 10:46:45 -0500

In article <3120C52D.3128@atlanta.dg.com>,
Mary Wadsworth   wrote:
>Doug Dumitru wrote:
>>
>> Depending on the scale of their operation, I would take exception to
>> claiming that $150K is a "wad of cash".  15GB of anything is not
>> trivial and is definately beyond the scope of anything that you buy at
>> the local computer store....
>>
>> Doug Dumitru
>> Modular Software Corporation
>>
....
>AND, I have to agree with Doug Dumitru -- $150K is a small wad of
>cash for the size of the database...especially if this is 'mission-critical'
>data that is necessary for the business.  How much $$ will they lose
>if they lose the data?
>
>Mary Wadsworth
>Data General Corporation

Maybe I've just missed the relevant posting, but I don't think he has
given enough information about the system to guess whether that is a fair
price (there is more to it than size of the disk).  If we are talking
about 8 users accessing a big database, it is way too much money.  If it
is a 500 user system, then it is a real bargain.
I suspect the answer lies somewhere in the middle, resulting in this
being a not-unreasonable (but not great) price for a new system.
(It is also quite likely that the MIS department is looking at their first
chance in years to spend ANY money, and knows that it will be years before
they get another chance - so if there is anything else they might need, now
is the time to pad it in to the quote.)
Also, with regard to splitting the files into 3... isn't this just a simple
implementation of an index?  Instead of including a WITH statement to specify
which records to select, the user has to logon to the appropriate account (or
choose the appropriate menu option).  A significant learning curve for the
users, and it might not be a good fit for the business, but it certainly
would improve performance.
Steve Riddle
riddle@interlog.com


========
Newsgroups: comp.databases.pick
Subject: Re: Pick on old GA box?
From: dessoft@main.com (gary valmain)
Date: 10 Feb 1996 21:57:04 GMT

In article <4feicq$pp2$1@mhafn.production.compuserve.com>, dated 9 Feb 1996
04:26:02 GMT, Michael Hayworth posits...
>
[snipped]
>
>They're looking to move to another GA box, which is essentially a
>relabeled IBM machine running dual PowerPC processors and again
>utilizing PICK. They're looking at spending a wad of cash on
>this, and I hesitate to concur with spending $150K on this system
>simply to avoid rewriting all their legacy code. In fairness,

What would you have them do, spending $500K on a replacement system?  What other
system (hardware/software) will handle their current and future requirements, and NOT
require rewriting their legacy code??

Based on what you posted, you have been asked to assist in determining WHICH PICK
based hardware/OS combination is best for them.  Yet, your statements seem to imply
that you think they should move from Pick.

I, for one cannot comment on the dollars you stated, since you did not provide any solid
basis (hardware configuration) for the dollar range.  However, if they have 15GB of data
online, providing everything they ask for at this time, the $150K just might be cheap.  They
may be able to move to a Pentium based system running AP/SCO (Advanced Pick on
Santa Cruz Operations' Unix) for less money.  Or, an IBM RS6000, running AP on AIX.
Or, how about Hewlett/Packard's Unix running AP?  Data General?  There are others.

I will point out to you that the cost of replacing the software (even if done in Pick) could
dwarf the cost of replacing the hardware.  Not to speak of the potential lost revenue,
should problems arise during a conversion of the data, or they cannot get the required
reports, list, whatever, as quickly as they can at this time.  And, from experience, I can
also tell you that if you DO port the data to a non-Pick platform, you'll be looking at roughly
3 times the disk space that Pick uses, just to hold the converted data.


>I am skeptical, but want to keep an open mind. Can someone help
>me equate the processing power of what they have to one of todays
>Intel or RISC boxes? And can someone help me understand what they
>love so much about PICK?

How many users online at one time?  How many printers going at one time?  How large
are the primary file(s)?  How important is speed?  How frequently do they produce these
lists and how large are they?

You listed several functions they are currently processing.  Could you put together a
system (hardware, OS and software) which can give them what they now have, as
inexpensively as the current, or replacement, Pick system?

Since it is possible to do much more with much less (speaking of hardware), I suggest
you learn _much_ more about PICK before you make any recommendations, or restrict
your recommendations to strictly Pick vs Pick hardware/OS combinations.

You should obtain a copy of the current _INTERNATIONAL SPECTRUM_ magzine.  It
contains an article concerning several companies which attempted to migrate to other
database platforms, and why most of them returned to the orginal Pick based platforms.

International Spectrum Magazine
10675 Treena Street # 103
San Diego, Ca  92131
619-578-3152

Pick Systems
1691 Browning
Irvine, Ca  92949
800-FOR-PICK
www.picksys.com

Unfortunately, I don't have contact information for General Automation at hand, but they
are in southern California, I do believe.
>
>--
>Michael Hayworth
>Technology Director
>Innovative Marketing
>Fort Worth, Texas

gary valmain
_______________________|____independent pick applications programmer____
designed software, inc____|_ladies home companion__wars fought_whiskey_coins
voice_____713.367.8765__|_revolutions started_governments run_bars emptied
fax_______713.367.4316__|_uprisings quelled_burglars alarmed__tigers tamed
email dessoft@main.com__|_country gentleman_orgies organized_coffins_nails
compuserve__72203,2372__|_computers verified___used cars___land___manure
_______________________|_country gentleman___all round really nice guy


========
Newsgroups: comp.databases.pick
Subject: Re: Pick on old GA box?
From: clive@jac.co.uk (Clive Ketteridge)
Date: Mon, 12 Feb 1996 11:54:14 GMT

In article <4feicq$pp2$1@mhafn.production.compuserve.com>,
Michael Hayworth  <73233.2014@CompuServe.COM> wrote:
>I've been asked to evaluate an IS shop that's currently running
>Pick and is wanting to buy a new system. They are running a
>General Automation box utilizing Pick for all their development.
>They told me they're running Pick R91, but they weren't sure
>whether that referred to the version of PICK, the GA box, or the
>total package. The system is five or six years old now.
>
>They're looking to move to another GA box, which is essentially a
>relabeled IBM machine running dual PowerPC processors and again
>utilizing PICK. They're looking at spending a wad of cash on
>this, and I hesitate to concur with spending $150K on this system
>simply to avoid rewriting all their legacy code. In fairness,
>there is a slew of legacy code and they do manage a lot of
>data--everything is in a single 15GB customer/prospect database
>and the machine runs constantly producing mailing lists, calling
>lists, prospect lists for salespeople, telemarketed leads for the
>field sales force, on and on. (I do think they'd benefit from
>moving this huge database to three separate databases, one for
>each of their three major customer and prospect types.)
>
>I am skeptical, but want to keep an open mind. Can someone help
>me equate the processing power of what they have to one of todays
>Intel or RISC boxes? And can someone help me understand what they
>love so much about PICK?
>
>--
>Michael Hayworth
>Technology Director
>Innovative Marketing
>Fort Worth, Texas

Call or e-mail Paul or Rob Bootes, They have just gone through
the exact process you describe, they evaluated ALL alternatives :-)

rob@koorong.com.au  or paul@koorong.com.au

Koorong Books Pty Ltd., Sydney - 61 2 857 4477

bfn, clive k

--
       |                                http://www.jac.com/~jimi
     --|--------- Clive A Ketteridge  - email clive@jac.co.uk
       | J A C    Tel. +44 (0) 1442 235-515 -- Fax. +44 (0) 1442 233-515
_______|          2,Sovereign Park,Cleveland Way,Hempstead,Herts,HP2 7DA,UK

========
Newsgroups: comp.databases.pick
Subject: Re: Pick on old GA box?
From: dessoft@main.com (gary valmain)
Date: 12 Feb 1996 21:20:27 GMT

In article , dated Sat, 10 Feb 1996 13:05:13
GMT, Alex Levitsky posits...
>
>Michael Hayworth (73233.2014@CompuServe.COM) wrote:

[snipped]

>users.  And, of course, they've been brainwashed the leaders of
>the PICK cult 8-).                                  ^^^^^^^^^^^^        ^^^^^^^

Alex,

This is a politically incorrect term.  Please, use educated and facilitators instead.


>==========================================================
>===    Alex Levitsky    bi362@freenet.toronto.on.ca    ===
>==========================================================

thank you in advance for your co-operation.

gary valmain
_______________________|____independent pick applications programmer____
designed software, inc____|_ladies home companion__wars fought_whiskey_coins
voice_____713.367.8765__|_revolutions started_governments run_bars emptied
fax_______713.367.4316__|_uprisings quelled_burglars alarmed__tigers tamed
email dessoft@main.com__|_country gentleman_orgies organized_coffins_nails
compuserve__72203,2372__|_computers verified___used cars___land___manure
_______________________|_country gentleman___all round really nice guy


========
Newsgroups: comp.databases.pick
Subject: Re: Pick on old GA box?
From: cwnoah@aol.com (CWNoah)
Date: 13 Feb 1996 17:24:26 -0500

I'll probably get blasted for this one, but I use an ancient 
technology quite often for this, and it works quite well. It's called
inverted file cross referencing.  If you build a record (or multiple
records in the case of a large database), with the value to select as ID,
and the IDs as multivalues or attributes (depending on need), then SELECT
or QSELECT the record(s) - you have an instant select list (well, almost
instant).  If you need to sort from there, you can do an SSELECT on the
subset, or build sorting into the xref (a pain sometimes).  It may not
work for you, but it's another example of the flexibility available.
Regards,
Charlie Noah   cwnoah@aol.com

========
Newsgroups: comp.databases.pick
Subject: Re: Pick on old GA box?
From: edt@world.std.com (Eugene D Tyler)
Date: Wed, 14 Feb 1996 03:06:45 GMT

You may be missing the other side of the fixed/variable length record
tradeoff: disk I/O. In most systems I've done detailed performance
studies (a limited set, of course), the primary area was fetching data
rapidly enough to keep the processor busy. Thus, on those systems,
the time spent looking for the nth field of a record was unimportant
compared to the time spent actually retrieving the records from
disk.

A better argument might be if you could somehow arrange to dedicate
the a disk to a particular set of data and then deliver that data to
the processor. The variable length records might be under some
disadvantage in this case. I would think that this scenario would
be hard to implement in the real world. Note: In case it is not
clear, the purpose for a dedicated disk is to prevent *any* seeking
other than that required at cylinder boundaries. Once you have
multi-user access to the data set, this becomes impossible.

I hope this was useful.

Best Regards,
Dale Tyler

========
Newsgroups: comp.databases.pick
Subject: Re: Pick on old GA box?
From: heggers@netcom.com (Henry Eggers)
Date: Wed, 14 Feb 1996 19:29:01 GMT

Eugene D Tyler (edt@world.std.com) wrote:

: A better argument might be if you could somehow arrange to dedicate
: the a disk to a particular set of data and then deliver that data to
: the processor. The variable length records might be under some
: disadvantage in this case. I would think that this scenario would
: be hard to implement in the real world. Note: In case it is not
: clear, the purpose for a dedicated disk is to prevent *any* seeking
: other than that required at cylinder boundaries. Once you have
: multi-user access to the data set, this becomes impossible.

A fascinating proposal.  Several reflections:  Before there were
relational databases to talk about, most of the content of books
on databases was how to optimize the location of things on the disk,
so that the processing took just a little less than the disk
latency. From this, RDBs were a step up.  Just.  I particularly note
the discussion it 3 Knuth at 361ff, 5.4.9 Disks and Drums.  :-)

That's what drums were for -- no seeking.

That's why sinusoidal seeks did just about nothing for performance.
The problem was whether another user/process had moved the head for
its own purposes.  Which deeply obviates keeping a b-tree of overflow,
since having the new storage 'close' is useless.

So that leads to track and cylinder caching and RAIDs, all of which
have the effect of increasing the apparant size of a 'sector' at
a performance level, without decreasing the granularity of addressability.
Which leads to another issue:  How much scanning and comparing is
required in order to find the 'named' target, and whether that happens
in an RDB and how, which we can take up some other time.

So 'close' means at least in the same cylinder, but only counts in
the case of cylinder caching.  Otherwise we're not playing horseshoes
or handgrenades.

In either case, this leads us to the use of memory _instead_ of disk,
and that leads us to Mary Wadsworth's 5-Pentium, 2GB machine, which
is said to scream, to use an old colloquialism.

Stepping back from the technotrivia a bit, Dale's suggestion brings
us face to face with the problem of multi-user machines, and the
fact that the only reason for 'databases' per se is to have common
data, which means concurrent access.  What one could do is declare
database access to be through the database engine only, so that
the diskios were 'uninterruptable' in the relevant sense.  One could
then bind the processor to the disk subsystem, seen as a logical
access engine.  For monolithic, very large, high demand, high value
databases, this might make sense.  But contemplate what it would cost
to get the flexibility of a pick machine out of such a database...

Stepping further back, the question becomes, "How do we identify the
right questions to ask?"  It is clear that the problem has been out there
for at least 30 years that I know of, and that the solutions come very
slowly, and not that much as a matter of extentions in technology.

Consider the case of a database of photographs of the earth, taken
at, say, 50 feet, at 100 foot intervals, so that I can ride my
exercise bicyle anywhere I want, or I can emulate Bosnian boundaries
in Dayton.  That's about at petabyte:  10**9th 10**6th objects.
It should be easy to access, given a reasonable addressing.  All that's
happened is that the objects are slightly bigger, and their
cardinality is perhaps an order of magnitude bigger than the largest
pick database (Anecdotal evidence?).  The problem arises if you want to
find all the birds.  This leads to indexing, which is alright, if
all 'things' for which you are indexing are palpably in the things
you are indexing.  This leads to the act of indexing 'everything',
per Altavista, for instance.  Never mind that that takes considerably
more space and processing power than the underlying data.  It is, on
occasion, the right thing to do.

But consider the case of indexing all the unanticipated inqeries against
a file, given that the inquirer can instantiate an arbitrary F-correlative
and then select against it.  Heh.

One of the nastier realities of the pick file system is that it comes with
'dictionaries', which are different that other people's dictionaries, in
that they do not 'define' the contents of file as a database.  Rather,
they allow the data to be 'seen as' in any way that the (fairly broad)
class of transformations available (named 'F-correlatives') can act,
including 'foreign file' access to data in 'other databases' (if the
idea of database made any sense in a pick machine) anywhere in the
world, with no assurance that it will be there now or tomorrow.

That leaves one back at the search engine.  You are going to have to look
to see.

Regards, hve.

========
Newsgroups: comp.databases.pick
Subject: Re: Pick on old GA box?
From: bcohn@aol.com (BCohn)
Date: 14 Feb 1996 08:34:28 -0500

Michael wrote and has received replies from some kooks and from some
gurus. His integrity was questioned at least once, and he objects to that
in principle, since we don't actually know him.
True, Michael.
But all of us who have been in Pick for any length of time, and especially
in management, have had the experience of being second guessed by a
consultant, often from a big accounting firm (where they recommend the IBM
machine of the year by definition) and/or where the personal
compensation/integrity *is* in question. Sometimes the consultant is an
employee's husband, sometimes just someone with the ear of the president,
or whatever. Sometimes it's a person you thought was allied, until he
recommends removing your current machine, which you just bought, and
moving to a different Pick platform. (This probably cost the involved
person their job.) Have you ever had to argue rationally with a person who
believes you should change your word processing people (ie typists) to a
system on which literally you enter each character with a mouse?????
People who know me will know whom I'm referring to, probably. No harm
meant.

Anyway, *that's* why you get such defensive reactions; because we've all
had to defend Pick personally, against folks blinded by something which
sounds persuasive (did I mix my metaphors?) and enamoured by the latest
gadget from PC Magazine...

Enough? Well, I'd actually like to get more philosophical discussions
going in this group. Any interest? Any philosophers among you? Any
oldtimers? (an oldtimer is defined as a person who remembers at least 3
Spectrum parties in detail when the men didn't wear SUITS and maybe who
remembers our dear departed Aussie crony, Peter Rechnitzer.)

Sincerely, Betsy Cohn

========
Newsgroups: comp.databases.pick
Subject: Re: Pick on old GA box?
From: dessoft@main.com (gary valmain)
Date: 16 Feb 1996 19:53:57 GMT

In article <4fsod4$sko@newsbf02.news.aol.com>, dated 14 Feb 1996
08:34:28 -0500, BCohn posits...
>
[explanatory stuff stuffed into bit bucket]

>Enough? Well, I'd actually like to get more philosophical discussions
>going in this group. Any interest?

Interested.  Subject?

Any philosophers among you?

May be philosophically challenged, but game(y).  Being challenged
has not stopped me.... yet.

Any
>oldtimers? (an oldtimer is defined as a person who remembers at least 3
>Spectrum parties in detail when the men didn't wear SUITS and maybe who
>remembers our dear departed Aussie crony, Peter Rechnitzer.)

Been doing Pick for 20 something years.  Didn't make _any_
Spectrum parties (suits or not) and unfortunately didn't know Peter.
By process of elimination, I don't fit the definition of oldtimer.
Now my day looks better!!

Actually I don't remember have done anything for 20 years before.
Already sounding philosophical.  Weird.  Or, I don't remember
for 20 years doing anything?

>Sincerely, Betsy Cohn

gary valmain
____________________________independent pick applications programmer__
designed software, inc___|_ladies home companion_wars fought_whiskey
voice_____713.367.8765___|_revolutions started_governments run_coffins
fax_______713.367.4316___|_uprisings quelled_burglars alarmed_nails
dessoft@main.com_________|_orgies organized_used cars_tigers tamed
72203,2372@compuserve.com|_computers verified_manure_bars emptied_land
___________________________country gentleman_all round really nice guy


========
Newsgroups: comp.databases.pick
Subject: Re: Pick on old GA box?
From: Brig Campbell 
Date: Fri, 23 Feb 1996 10:46:15 -0800

An "old-timer" is not "Someone who can remember 3 spectrum parties
in detail", but someone who has been to 10 spectrum parties and
*can not* remember any details.

That was the charm of Pick and the people.  If you every had the
opportunity to see Tim Holland running around a party with his tie
on his head then you understand.  A "guru" such as tim, Henry, etc.
are human beings, interested in more than "macro expansion" and
BNF/aMETA optimization.

And likewise, Pick is more that a "compter science", it's interested
in solving people and business problems without bias for perception.
It just works and works well.  And if you can have a few
cocktails with people that feel the same way.  Then it's just that
much better.

-brig

Return to CDP FAQ Main Index