Is "Native" Pick going away?
(Thread taken directly from CDP, with original formatting preserved.)
========
Newsgroups: comp.databases.pick
Subject: No native PICK OS ???
From: dessoft@main.com (gary valmain)
Date: 15 Feb 1996 18:02:51 GMT
Yesterday, 14 February, I attended a seminar help by Pick Systems, in Houston.
There were many interesting things revealed during the seminar concerning D3
and it's future. Much of it positive and very interesting. I can see many good
things in the future for things Pick based.
It appears that Pick may be trying to get it's stuff together, in terms of systems
engineering and future product development. It also becomes very apparent
that Pick is attempting to become a "mainstream" product. There are pros and
cons.
In my opinion, in an attempt to become "mainstream", meaning to become
_acceptable_ to the mainstream market, Pick may become "just another
mainstream product". In other words, just another database product which runs
on top of massive hardware platforms. Relying on the massive hardware for it's
speed, rather than it's efficiency.
As has been noted at other times, Pick will support SQL, either now or in the
near future. At what cost?? Does this mean compromising the Pick model?
In the near future, Pick will run on WindowsNT as a WindowsNT application.
Note that I am NOT saying _attached as a database server_, but on NT in the
same manner as on Unix. Is this a good thing? In terms of opening up other
marketing avenues for the dealers and Pick, yes. Again, at what cost to the
Pick model?
I do not profess to be able to argue to points of the Pick model at the systems
level. I write applications.... only. But, can someone explain to me how the Pick
model can be ported to the NT platform, with all of it's distributed processing
capabilities, and still retain the performance of Pick on a single host?
I understand that the port can be done to basically any OS platform. That's one
of the features of the Pick model (machine). My concern is about the possibility
of having many files, scattered over several nodes, requiring random, frequent
updates. It appears to me, at first blush, that this will degrade respone time due
to the extra time required to retrieve data from all files.
This single point would seem to mean that if there were heavy user IO, the entire
database should then be located on a single node (server). Then we would
have a system similar in concept to a current AP/PRO / networked system. That
is, one node is functioning as a database server. All other nodes are clients.
This appears to me nothing other than using the network to handle all user IO.
Not necessarily a bad thing. Other than cost and performance.
Which brings me to another point. One which I consider significant. There was
some information which very strongly implied, if not explicitly stated, that by the
end of 1996, or possibly early 1997, there would no longer be a native version
of Pick. Repeat. ALL Pick implimentations would be database only. No
AP/PRO, AP/NAT, AP/DOS, R83, etc. Only D3.
My opinion is that this would significantly increase the cost threshold of the small
systems, small being 10 or fewer users. Due to the additional hardware cost of
networking and workstations vs dumb terminals the acquisition costs would be
higher. Due to the complexities of networking, the ongoing maintenance costs
would be higher. Thereby eliminating a segment of the market. How large is
that segment? How much of your business comes from this segment of the
market? For me, that's just over 50% of my customer base.
What about you? Is there not enough business in this market to justify retaining
it? Is this an indication of the new direction of Pick Systems? Walking away
from the small systems market?
Comments? Please, no pointy, barbed arrows. And remember, just because
you are paranoid does not mean they are not out to get you.
enjoy
gary valmain
--
____________________|_independent pick applications programmer____
designed software, inc__|_ladies home companion_wars fought_whiskey
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|coins_computers verified_used cars_land_manure
____________________country gentleman_all round really nice guy
========
Newsgroups: comp.databases.pick
Subject: Re: No native PICK OS ???
From: Mark Chapman
Date: Thu, 15 Feb 1996 20:42:18 +0000
In article <4fvsgb$jdk@spectre.star.harc.edu>, gary valmain
writes
>>There was some information which very strongly implied, if not
explicitly stated, that by the end of 1996, or possibly early 1997,
there would no longer be a native version of Pick. Repeat. ALL Pick
implimentations would be database only. No AP/PRO, AP/NAT, AP/DOS, R83,
etc. Only D3. <<
Great! Most of our support is stuff to do with the OS side of things -
Tape Streamers / inexplicable hangs etc.
>>My opinion is that this would significantly increase the cost
threshold of the small systems, small being 10 or fewer users. Due to
the additional hardware cost of networking and workstations vs dumb
terminals the acquisition costs would be higher. Due to the
complexities of networking, the ongoing maintenance costs would be
higher. Thereby eliminating a segment of the market. How large is that
segment? How much of your business comes from this segment of the
market? For me, that's just over 50% of my customer base. <<
Agreed, but compared with what they are _already_ doing to the small
user this is not so significant, surely. The one that gets almost all
my clients is the charges for upgrades and pickup contracts - small
money per user, with a huge minimum charge. Most of my sites are 2
users so I am having to go 'yes thats 20 pound per user makes 40 pound
but the minimum charge is 5 times that'. Its a bit embarassing.
If you cant find a way out of using Pick by the time you cant get hold
of AP/Native or AP/PRO I beleive there will be a D3 for Linux, which
should give better performance on a more stable platform with support
for peripherals (which you can add to if so inclined) at a reasonable
cost. This has to be the way forward for small dealers.
--
Mark Chapman
W.W.S. Limited
========
Newsgroups: comp.databases.pick
Subject: Re: No native PICK OS ???
From: dessoft@main.com (gary valmain)
Date: 19 Feb 1996 20:00:00 GMT
In article <7n2UUDAqq5IxEwof@wwsltd.demon.co.uk>,
dated Thu, 15 Feb 1996 20:42:18 +0000, Mark Chapman posits...
>
>In article <4fvsgb$jdk@spectre.star.harc.edu>, gary valmain
> writes
[snipped]
>If you cant find a way out of using Pick by the time you cant get hold
>of AP/Native or AP/PRO I beleive there will be a D3 for Linux, which
>should give better performance on a more stable platform with support
>for peripherals (which you can add to if so inclined) at a reasonable
>cost. This has to be the way forward for small dealers.
This is precisely what was being proposed.
enjoy
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: No native PICK OS ???
From: clive@jac.co.uk (Clive Ketteridge)
Date: Fri, 16 Feb 1996 10:30:54 GMT
In article <4fvsgb$jdk@spectre.star.harc.edu>,
gary valmain wrote:
>Yesterday, 14 February, I attended a seminar help by Pick Systems, in Houston.
>There were many interesting things revealed during the seminar concerning D3
>and it's future. Much of it positive and very interesting. I can see many good
>things in the future for things Pick based.
>
>It appears that Pick may be trying to get it's stuff together, in terms of systems
>engineering and future product development. It also becomes very apparent
>that Pick is attempting to become a "mainstream" product. There are pros and
>cons.
>
>In my opinion, in an attempt to become "mainstream", meaning to become
>_acceptable_ to the mainstream market, Pick may become "just another
>mainstream product". In other words, just another database product which runs
>on top of massive hardware platforms. Relying on the massive hardware for it's
>speed, rather than it's efficiency.
>
>As has been noted at other times, Pick will support SQL, either now or in the
>near future. At what cost?? Does this mean compromising the Pick model?
>
>In the near future, Pick will run on WindowsNT as a WindowsNT application.
>Note that I am NOT saying _attached as a database server_, but on NT in the
>same manner as on Unix. Is this a good thing? In terms of opening up other
>marketing avenues for the dealers and Pick, yes. Again, at what cost to the
>Pick model?
>
>I do not profess to be able to argue to points of the Pick model at the systems
>level. I write applications.... only. But, can someone explain to me how the Pick
>model can be ported to the NT platform, with all of it's distributed processing
>capabilities, and still retain the performance of Pick on a single host?
>
>I understand that the port can be done to basically any OS platform. That's one
>of the features of the Pick model (machine). My concern is about the possibility
>of having many files, scattered over several nodes, requiring random, frequent
>updates. It appears to me, at first blush, that this will degrade respone time due
>to the extra time required to retrieve data from all files.
>
>This single point would seem to mean that if there were heavy user IO, the entire
>database should then be located on a single node (server). Then we would
>have a system similar in concept to a current AP/PRO / networked system. That
>is, one node is functioning as a database server. All other nodes are clients.
>This appears to me nothing other than using the network to handle all user IO.
>Not necessarily a bad thing. Other than cost and performance.
>
>Which brings me to another point. One which I consider significant. There was
>some information which very strongly implied, if not explicitly stated, that by the
>end of 1996, or possibly early 1997, there would no longer be a native version
>of Pick. Repeat. ALL Pick implimentations would be database only. No
>AP/PRO, AP/NAT, AP/DOS, R83, etc. Only D3.
>
>My opinion is that this would significantly increase the cost threshold of the small
>systems, small being 10 or fewer users. Due to the additional hardware cost of
>networking and workstations vs dumb terminals the acquisition costs would be
>higher. Due to the complexities of networking, the ongoing maintenance costs
>would be higher. Thereby eliminating a segment of the market. How large is
>that segment? How much of your business comes from this segment of the
>market? For me, that's just over 50% of my customer base.
>
>What about you? Is there not enough business in this market to justify retaining
>it? Is this an indication of the new direction of Pick Systems? Walking away
>from the small systems market?
>
>Comments? Please, no pointy, barbed arrows. And remember, just because
>you are paranoid does not mean they are not out to get you.
>
>enjoy
>
>gary valmain
gary and all other application owners out there. What Pick Systems
have started doing today JAC (with jBASE) we shipped more than 2 years
ago.
The following has to have a bias because I work for JAC but it is
also factual and important to a lot of the readers of this
group. gary is saying "where's my future" i am telling him
of an option. No technical stuff here, stop reading now if
this concerns you.
JAC have been trying to explain that the applications and the owners
of those applications have a future. jBASE is one product that sees
to that. The small end of the market, ie. 1 user will be taken
care of by jBASE 4 Windows 95, (shipping very soon) or jBASE 4 Window NT
(shipping now). The 2000 user plus will be handled by Unix and NT
and 95 systems in a network environment.
What you want to retain is your skills in building your application
that uses a 3 D data model. That what this option gives you, except take
a look at the size of the Windows market, look at the 2 million
copies of VB our there (not including run-time's).
jBASE turns your application into a REAL windows app. Yes .EXE and .DLL
files, HHow the hell isa VB programmer going to beat your app !
Typical VB programmer wants to deliver a simple application
to a 5 user customer that keeps information about people.
He has to develop in something. OK VB
He needs a Database - OK ACCESS
Enquires - MS SQL
Thats 3 products the developer has to buy and 2 the customer
has to buy to run the thing. And this is VERY simplified.
What if this application is good enough for a 1000 user system,
no way hosay.
But with your application that is now a jBASE application no wories.
The language is BASIC
The database is the 3 D model (can be anything else
jBASE is DB Independent)
The enquires are jQL (ENGLISH like)
All in one product,id the customer or you want to use
ACCESS as the DB and MS SQL as the enquiry language thats
OK too.
The main advantage you have us that your application has
been out there for years and you have a ton of reference sites.
No Windows application tools need to be excluded from your
development options they all join seamlesly with your jBASE
compiled object (your BASIC code is compiled using the
MS Visual C++ compiler ! )
Oh and the code you maintain is backward compatable to
your existing customers.
If what i am pointing out here is true, you have rather a busy future
selling into the shrinkwrap market as well as the fortune 500
companies of the world.
I am not sure if Pick are right to ditch the generic product but
i do agree with the new direction, it takes a massive re-write
but they are going for it. I'm glad that bits over for us, we're on the
to next stage , NO i wont say what it is, suffice to say it's
aimed at making applications people powerful, people buy your
stuff not ours (mostly), so we'll see you have the tools to beat
the toy boy developers out there.
Flame me if you like guys but i think The Net is about knowing
whats available as well as how it works.
bfn, clive k. JAC
>
>--
>____________________|_independent pick applications programmer____
>designed software, inc__|_ladies home companion_wars fought_whiskey
>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|coins_computers verified_used cars_land_manure
>____________________country gentleman_all round really nice guy
>
--
| 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: No native PICK OS ???
From: bcohn@aol.com (BCohn)
Date: 16 Feb 1996 06:58:07 -0500
Seriously, no native Pick? A smallish company with a 386 and 3 crts ably
handling its business would only be able to run until something broke in
R83 (or whatever) irretrievably and then they would *have* to spend 5k on
networked pcs plus whatever else would be involved?
I think that would be a damn shame.
========
Newsgroups: comp.databases.pick
Subject: Re: No native PICK OS ???
From: dessoft@main.com (gary valmain)
Date: 19 Feb 1996 20:07:40 GMT
In article <4g1rgf$km4@newsbf02.news.aol.com>,
dated 16 Feb 1996 06:58:07 -0500, BCohn posits...
>
>Seriously, no native Pick? A smallish company with a 386 and 3 crts ably
>handling its business would only be able to run until something broke in
>R83 (or whatever) irretrievably and then they would *have* to spend 5k on
>networked pcs plus whatever else would be involved?
>I think that would be a damn shame.
As stated in the Pick Price Information guide (handed out at the seminar),
as of 1 June 1996 Pick will no longer support R83 or IBM RT. And, a hint
of things to come, AP/DOS and AP/NAT are "Final Release Versions".
enjoy
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: No native PICK OS ???
From: kasey@karlcara.microserve.com (Karl B. Carapellotti)
Date: Tue, 20 Feb 1996 02:03:15 GMT
On 19 Feb 1996 20:07:40 GMT, dessoft@main.com (gary valmain) wrote:
--->As stated in the Pick Price Information guide (handed out at the seminar),
--->as of 1 June 1996 Pick will no longer support R83 or IBM RT. And, a hint
--->of things to come, AP/DOS and AP/NAT are "Final Release Versions".
--->
--->enjoy
--->
--->gary valmain
========================================
How much would you like to bet that they'll still SELL R83 and IBM RT
(and at full list $$$, too), though?
Oh well, "if it ain't broke, then don't fix it" never did have a
strong following in the software industry.
Karl
========
Newsgroups: comp.databases.pick
Subject: Re: No native PICK OS ???
From: dessoft@main.com (gary valmain)
Date: 21 Feb 1996 17:56:26 GMT
In article <31292b32.3838049@news2.microserve.net>,
dated Tue, 20 Feb 1996 02:03:15 GMT, Karl B. Carapellotti posits...
>
>On 19 Feb 1996 20:07:40 GMT, dessoft@main.com (gary valmain) wrote:
>
[snip]
>How much would you like to bet that they'll still SELL R83 and IBM RT
>(and at full list $$$, too), though?
NO BET. That would probably be a sure bet..... for you.
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: No native PICK OS ???
From: dessoft@main.com (gary valmain)
Date: 19 Feb 1996 20:25:20 GMT
In article <4g1rgf$km4@newsbf02.news.aol.com>,
dated 16 Feb 1996 06:58:07 -0500, BCohn posits...
>
>Seriously, no native Pick? A smallish company with a 386 and 3 crts ably
>handling its business would only be able to run until something broke in
>R83 (or whatever) irretrievably and then they would *have* to spend 5k on
>networked pcs plus whatever else would be involved?
>I think that would be a damn shame.
This _could_ be a fair description of the situation as I see it.
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: No native PICK OS ???
From: mward@linkd.net
Date: 18 Feb 1996 14:24:58 GMT
> dessoft@main.com (gary valmain) writes:
> Yesterday, 14 February, I attended a seminar help by Pick Systems, in Houston.
> There were many interesting things revealed during the seminar concerning D3
> and it's future. Much of it positive and very interesting. I can see many good
> things in the future for things Pick based.
>
------ snip ----------
>
> Which brings me to another point. One which I consider significant. There was
> some information which very strongly implied, if not explicitly stated, that by the
> end of 1996, or possibly early 1997, there would no longer be a native version
> of Pick. Repeat. ALL Pick implimentations would be database only. No
> AP/PRO, AP/NAT, AP/DOS, R83, etc. Only D3.
>
> My opinion is that this would significantly increase the cost threshold of the small
> systems, small being 10 or fewer users. Due to the additional hardware cost of
> networking and workstations vs dumb terminals the acquisition costs would be
> higher. Due to the complexities of networking, the ongoing maintenance costs
> would be higher. Thereby eliminating a segment of the market. How large is
> that segment? How much of your business comes from this segment of the
> market? For me, that's just over 50% of my customer base.
------ snip ---------------
Good point, I have been getting similar impressions, and agree that this would present problems for us
and our low end users. Our customer base is, more than 80% native implementations, mostly AP/PRO
now. Of course, if you count by user not customer, then native implementations are less than 50%.
Maybe PICK believes if they move to exclusively non-native products, that all customers will
necessarily be larger. This may be true, but in my opinion there would be considerably fewer of them.
The D3 meeting in Toronto happens next week. We'll be there to see if our impressions are true.
Martin Ward
Thede Ward Systems Inc.
mward@linkd.net
519-659-2222
========
Newsgroups: comp.databases.pick
Subject: Re: No native PICK OS ???
From: heggers@netcom.com (Henry Eggers)
Date: Sat, 24 Feb 1996 21:56:45 GMT
gary valmain (dessoft@main.com) wrote:
: ... D3 and it's future...
The question of what to do to go forward with pick in the market has
been fundamental for at least two decades, and can be considered based
on what pick is, what the underlying substrate is, and what the 'marketing
inputs' are.
: Issue: ...in an attempt to become "mainstream", Pick may become "just
: another database product"....
It is not clear that Pick is 'useful' as 'another database product' if
the required model is either RDB or Object. Both of those have formal
definitional 'requirements' which would be fundamentally deletirious
to the existing pick model: To wit, that 'lists' break all rules of
concurency (and are as far as I can tell unique to pick -- possibly
for a reason :-) ), and that, while multivalues are not a 'problem'
for an SQL 'view', the fact that their _address_ can change is.
If, on the other hand, the pick model were 'straightened out' and
theoreticizes, it might compete for the role of 'post-object'
database. :-) The straightening out is the easier part. The machine
is fraught with gratuitious cul-de-sacs, about which something needs
to be done. Theoretization is a bit more difficult, since it requires
a 'definition' of pick, about which we have talked from time to time,
and it requires a congruence of vocabulary with the rest of the
world.
On the third hand -- well, I've a macro hand generator here -- it may
be that the 'database' does not stand on it's own, as Stas Lukaitis
(and my appologies for my spelling errors) pointed out to me. That
it is a file system which is able to store and return stuff, albeit
with rather less reliability than Paul Beardsdall would like (ibid on
the othography), is not particularly unique. To that I think you
need to add the prescription that all the applications use the same
meta data representation, and that you have the application dual
of english and basic operating within that prescription. And that
would appear to go well beyound a data base, to the rules of the
business language and report language. At least the user interface
language is a bit independent.
So, fundamentally, the machine is mainstreamable if one causes at
least some part of the 'mainstream' to adopt pick, rather than pick
simply becoming like 'everything else'.
IMHO.
: Issue: ...which runs on top of massive hardware platforms, relying on
: the massive hardware for it's speed, rather than it's efficiency.
Well, the current curves have price-performance improving by 3 orders
of magnitude base ten every 15 years. So that would suggest that one
gets about 10,000 as much processing per dollar now as when Pick was
first shipped. So, one has to ask oneself, how do we use this stuff?
because it isn't linear. Disks are cheaper but not _that_ much faster,
so we probably can't generate a 10**7 listing in the time we generated
a 10**3 listing in 1975. But we _can_ have databases 10**4 as big,
and arithmetic routines 10**4 as fast, and memory 10**4 as big.
Pick, in the words of Phil Kramer, is a 'haggis system'. Haggis is,
for the purposes of this comment, a 'poverty food', which has a
negative elastisty to income (wrong term, but the economics book
doesn't fall to hand). That means when people have more income,
they eat less of it. Pick was basically the cheapest way to get
a sophisticated application running -- and probably still is --,
but cheap is sooo cheap now that that isn't the factor which it
once was. But, just as I need to appologise to all Scots with
emotional attatchment to and a taste for haggis, one notes that
people develop the same for pick.
So the question has been, how do you extend the pick machine to take
advantage of the change in the substrate? (Mostly, I note, this has
been done by expanding the memory per user from 3k (R77) to about 2mb.
This is all about caching the disk in memory to reduce access times.)
Given that the traditional form is about as malignantly inextensible
and unmodifiable is it is possible to get and still run, short of
putting it on the die in the first place, and given that the marketing
cooperation between the players in the market was equally malignant,
extention hasn't been easy. Never mind that a lot of the 'standard'
features of computers are either irrelevant or orthogonal to pick, or
they are positively counter productive. (The latter has been a favorite
area for new feature lists.)
In other words, there's power to burn: Let's burn it. The question is,
what do we burn with it, not how do we stay 'as efficient': Why try
to run a business in 10$ worth of disk space?
: As has been noted at other times, Pick will support SQL, either now
: or in the near future. At what cost?? Does this mean compromising
: the Pick model?
If you want to build a 100% SQL correct access engine to a database
accessed as well by pick things, you need to put the pick access
through the SQL dictionary subsystem, because of it's assurance of
correctness. So, what you really build (or buy from Oracle) is an RDB
which you then 'see' as a pick database. I do not look forward to
using such a thing. On the other hand, if you want apparant SQL
visibility into a pick database, which has a pick 'security and
concurrency' profile, then you have the issue of the address of
multivalues, which you could solve as is done with BY-EXP, which is
to expect some invalid data in a dynamic environment. SQL people
probably don't look forward to using such a thing.
Looking at the marketing inputs, you probably build an SQL database;
but INSERT will necessarily _still_ disturb the addressing of the
multivalues, unless you keep two addressing schemes, one for SQL,
which is stable, and one for basic/english, which is dynamic. What
_that_ means is after the first insert the SQL view will be inconsistent
with that of english until after the next 'sync', which happens when
there are no SQL cursors in the file, or that part of the file, or
something unpleasant.
This brings us to a fundamental pick database issue: It is _designed_
to allow some amount of 'bad data' in a dynamic environment. I think
that the rest of the world is going to have to come to the same
conclusion, but I also think that there are a lot of people who
will fight to the death over the matter: Some people want a sure
thing: to be assured that _all_ of the data is _always_ correct.
I would suggest, snidely, and probably very unfairly, that their
mothers probably left them in the mall when they were little.
Naaaaah, I probably shouldn't say that. The real tension is over
a tollerance for ambiguity. The modern world is pretty ambiguous and
we all have a finite tollerance.
: In the near future, Pick will run on WindowsNT as a WindowsNT application.
: Note that I am NOT saying _attached as a database server_, but on NT in the
: same manner as on Unix. Is this a good thing?
There is no reason why 'it' should work differently on NT than Unix at
this level. I think what you are saying is that it is an 'embedded'
machine, rather than a hang-on ap. That has been the problem of pick
in its 'other' environment ever since Harold of Prime observed that
there would be no access to cobol data in the forseeable future. (Does
anyone remember his name? He was the marketing guy from Prime either
in '82 at Tahoe or '84 at Reno. He had an MBA, had joined Prime, and
had 'inherited' this orphan called information, about which he knew
nothing and wanted to know less -- I suspect that he was devoting his
days to getting a job with a respectable product, one his putative
brother-in-law had heard of -- when it turned out that the customers
were buying it in droves, and he turned into an instant hero, for
which he diligently tried to take credit. So amusing, eti cpomnenie.)
All the ported-to-os pick machines were sui generis, with a 'white
picket fence' around the pick garden of common metaformat, surrounded
by a jungle of exogenous .*** things with various 'associated
applications'. So, how do you operate on pick data from outside the
fence and on 'jungle data' from pick in a consistent, orderly and
regular manner? It would be nice. See Clive's comments, else
where in this thread, for a worked example.
: I do not profess to be able to argue to points of the Pick model
: at the systems level. I write applications.... only. But, can
: someone explain to me how the Pick model can be ported to the NT
: platform, with all of it's distributed processing capabilities, and
: still retain the performance of Pick on a single host?
That was easy. You can't but it tends not to matter. We did the
same thing at uData a half decade ago. It takes longer to list
data from a machine in England, than one across the room, than
from this machine. But not _that_ much longer. It lead to a number
of improvements: Reading all the item id's in the group; not
reading the item, unless the actuall data was called for, so that
sort only SM (system modes) went a _lot_ faster, since none of
the actual items were read from disk (indirect items, of course);
reading the item into a buffer not in the group, thereby leaving
the group unreadlocked a _lot_ more of the time. And, given a
10baseT ethernet, we achieved around 150k/second transfer rates, which
is _far_ more than the sector-at-a-time disk read rates of 15 or 30k/sec
for 500 or 1k frames on traditional machines. There is a 'client/server'
delay of around 4ms per item, if memory serves, so the limit was around
200 items/sec, instead of around 2k on a fast local machine.
So the relative performance of local vs remote data is a bit cloudy.
It also depends on relative resource load on each machine.
What's probably more important is that you don't have to put _everything_
on one machine, and that intermittant sharing is much easier if you
can use wires rather than sneakernet.
Deeper, it's part of the general consideration of 'client/server',
cooperative processing, peer load sharing, and how dynamically to
optimize the response of a complex system.
As Dick observed, "Two is ten times as hard as one."
: ...My concern is about the possibility of having many files, scattered
: over several nodes, requiring random, frequent updates. It appears to
: me, at first blush, that this will degrade respone time due to the extra
: time required to retrieve data from all files.
Yeah, but nothing like the fun to be had if these are SQL-compliant files
with full concurrency validity. So, file access in the real world is
getting worse anyway.
: ... would no longer be a native version of Pick.
Basically inevitable, because of all the collateral software which someone
might want to run. The marketing input is for an infinite amount of
software, so the result is to run in the 'open system', which is the
place where 'all software' runs, so we go put pick solely on Unix...
... At exactly that moment when the 'machine' is the net, and where
the only requirement is to have a working TCP/IP stack. [I note again,
in indignation, the clarity with which MD saw this, and therefore
refused to allow the shipment thereof.] What one does now is either
send the work to the machine where the software runs, or goes to the
machine were the software runs, and runs the 'appliation' there.
In that context, a native verson of pick with TCP access makes exactly
the sense, or more sense, of a pick-in-Unix version.
The next phase is, of course, 'platform neutrality', which means
a soft machine emulated everwhere. I note that Java is a bit
more sluggish than it might be, if we wondered where they next
quantum of power is going to go...
But _all_ that's necessary is a generally agreed cooperation protocol
in the net.
None of which makes any sense for someone with an R83 equivalent
application running on 1k$ of pc... The _problem_ is, how does the
software manufacturer make any money? If they don't make money,
they won't do it.
: My opinion is that this would significantly increase the cost threshold
: of the small systems, small being 10 or fewer users. Due to the
: additional hardware cost of networking and workstations vs dumb terminals
: the acquisition costs would be higher. Due to the complexities of
: networking, the ongoing maintenance costs would be higher. Thereby
: eliminating a segment of the market. How large is that segment? How
: much of your business comes from this segment of the market? For me,
: that's just over 50% of my customer base.
The question is 'unnecessarily' increase the cost. The problem is not
the customer's cost. It is the survivablity of the source of the
platform. Pick has always been 'too cheap' to the customers. It isn't
mainstream, because it doesn't finance the lifestyles of 'mainstream'
platform providers, except the historical example of MDISL, Microdata
UK, who charged 'mainstream' prices for applications running on
'don't ask' what. And got about a 90% gross profit out of it, I suspect,
thereby employing legions of bat-folk to tend to the least concerns
the customers might have. The applications were excellent, so far
as I can tell; but that was what was being sold, and that was what
the profit was from. So even there, the software platform was 'too
cheap' and under invested in. (Again noting that, when people tried
to invest in the platform, they usually came away thoroughtly snake-bit,
as has been noted before.)
So, again, how does a platform provider make enough money to stay in
business? Or, do we reactivate Garrett Hildebrand's suggestion of
'freepick', to run, I would presume, in linux? I suspect that our
jbase friends would counsel us, quite honestly, that it's rather a
lot of work. I would observe that there's a lot in the 50k lines
of executable code which made up R83 -- 51 or 52k if you count the
comments (he said with a very straight face and a sparkle in the eye).
: What about you? Is there not enough business in this market to
: justify retaining it? Is this an indication of the new direction of
: Pick Systems? Walking away from the small systems market?
I doubt that they'll walk away from the small systems market. I
suspect that they would continue to build a native machine if they
think that they can get the money which would go into the underlying
Unix platform. But, presuming Linux, they can get away with going
forwared _with_only_one_ machine. It is not easy to build a lot of
these things and keep then consistent. As much as I like thinking
that I know everything down to the silicon -- a problem which most
people don't have -- a version which can operate in Unix/NT, with
the condition that the latter don't get in the way, in the spirit
of the relevant quotation from Mash the film, is sufficient.
That leaves the question, so, what does one do with Pick now?
Regards, hve.
Return to CDP FAQ Main Index