======== 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 valmainwrites >>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