jdm1@eds1.UUCP (Jon McCown) (09/23/90)
I have been encountering more than the usual (low number) references to
PICK of late, and more specifically 'guest' environments (such as UniVerse)
which allow PICK to run as a guest under Unices.
Specifically my questions are:
1- How usable, stable, maintainable and scalable is PICK
(generally) and what (if anything) changes when a non-
native (such as Pick under Unix) implementation is used.
2- What vendors would you/would you not recommend for PICK
and (can be general) reasons for recommendation.
3- Where can a small (cheap?) Pick environment be gotten
for experimentation and testing? (Can be PC type for testing)
I have been reading Pick-World and a couple of texts on the system
(describing Pick in 'glowingly lovely detail'), but what I really want
to know is if you now use/maintain a Pick system-- would you do it over?
Mail responses are welcome, postings are fine as well. Vendors beware.
- Jon McCown
(if this turns into a mail deluge, I will summarize)
--
J.D. McCown - RCSG Director - Senate of Pennsylvania
psuvax1!eds1!jdm1 (this space intentionally "Your lupins or your life!"
jdm1@eds1.eds.com filled with this text) - Dennis Moorenick@aimed.UUCP (Nick Pemberton) (09/29/90)
In article <605@eds1.UUCP> jdm1@eds1.UUCP (Jon McCown) writes: > 1- How usable, stable, maintainable and scalable is PICK > (generally) and what (if anything) changes when a non- > native (such as Pick under Unix) implementation is used. Pick is probably one of the easiest O/S's to maintain. It is too simple to really run into the kinds of troubles you typically see when machines run out of disk space, out of power etc. The installation is equally simple (I recently set a machine up from scratch - new disk - it took one tape, a few easy questions, and 1 hour of whirring to do it). It is highly portable, if (like any OS) you stick to the vanilla stuff. I have moved code easily between ADDS, ULTIMATE, PICK SYSTEMS and PRIME with no trouble. Scalability really depends on the vendor. Some are and some aren't. The O/S certainly provides for it. It is extremely stable. Our development (!) machine has not been down in two years, except when we moved our office. Our client machines have even better records. When you move to a non native, like VMARK/UNIVERSE, there are naturally plenty of things that change. It is, after all, then just a guest O/S. That having been said, VMARK so far has caused me no grief, save certain UNIX restrictions (like files not being able to span devices). Again, if the PICK code is reasonably vanilla, it will have no trouble moving to a Non-native implementation. > > 2- What vendors would you/would you not recommend for PICK > and (can be general) reasons for recommendation. > Wow. Loaded question! We currently *highly* favour the ADDS/NCR line, they have what I consider one of the best Implementations, their machines are very stable (they are based on the NCR tower line), and their solution to UNIX/PICK is exactly how I believe the blend should be done. See my earlier posting for details... Incidently, since PICK is so much simpler then UNIX, it takes far less horsepower then UNIX. Thus a 7 Mips machine (like the NCR Tower 700 series) is a real screamer in PICK. We have 80 users hanging off one such machine, using good ol' Wyse 50 terminals, and they can't get ahead of the machine. The IBM RISC 6000 should be something to see - since there is I believe a native PICK for it. You'd have to check with PICK systems on that. We have in the past dealt with ULTIMATE and PRIME. Ultimate is a native implementation, PRIME is not (although I'd rather avoid that argument for the moment.) We are presently looking at the new BULL DPX series, running Vmark. We've yet to actually see one working, although we are told its RSN. > 3- Where can a small (cheap?) Pick environment be gotten > for experimentation and testing? (Can be PC type for testing) > You can get PICK for the PC. Your best bet is a 386 though, since a 286 can't handle the virtual memory scheme as well. ADDS and PICK Systems are the two offerings that I've used. PICK systems has the better price, ADDS has the better product. Contact PICK systems for a vendor near you, or ADDS. I can provide the numbers if you need them. >I have been reading Pick-World and a couple of texts on the system >(describing Pick in 'glowingly lovely detail'), but what I really want >to know is if you now use/maintain a Pick system-- would you do it over? No question. It is a wonderfull Database system, rugged, and reasonably full featured within its intended realm. Remember, PICK is not the answer to all things - It is targetted at data management for business, and is thus missing certain fundamentals - like decent communications. Thats what the PICK/UNIX combinations are meant to solve. -- Nick Pemberton uucp: !{lsuc, uunet!mnetor}!aimed!nick AIM, Inc bus: (416) 429-1085 Toronto, Ontario, Canada Home: (416) 690-0647
prc@erbe.se (Robert Claeson) (10/01/90)
In a recent article nick@aimed.UUCP (Nick Pemberton) writes: >When you move to a non native, like VMARK/UNIVERSE, there are naturally >plenty of things that change. It is, after all, then just a guest O/S. >That having been said, VMARK so far has caused me no grief, save certain >UNIX restrictions (like files not being able to span devices). Again, if >the PICK code is reasonably vanilla, it will have no trouble moving to >a Non-native implementation. We recently installed UniVerse on an Encore Multimax. A file can be up to 2 (4?) GB in size, since the system supports virtual partitions. Code was moved from another non-native system (Prime Information) as well as a native system (ADDS) to the new system without any problems at all. Performance was greatly increased (after all, no other Pick-like system, native or non-native, has outperformed the UniVerse/Multimax combination). >No question. It is a wonderfull Database system, rugged, and reasonably >full featured within its intended realm. Remember, PICK is not the answer >to all things - It is targetted at data management for business, and is >thus missing certain fundamentals - like decent communications. Thats >what the PICK/UNIX combinations are meant to solve. Ah, that was one of the reasons to move to UniVerse on the Multimax. UniVerse/Net makes it possible to run Pick applications in a client/ server environment, just like any other /Net database. -- Robert Claeson |Reasonable mailers: rclaeson@erbe.se ERBE DATA AB | Dumb mailers: rclaeson%erbe.se@sunet.se | Perverse mailers: rclaeson%erbe.se@encore.com These opinions reflect my personal views and not those of my employer.
rag@yarra.oz.au (Robyn A Grunberg) (10/04/90)
In article <8505@aimed.UUCP> nick@aimed.UUCP (Nick Pemberton) writes: >When you move to a non native, like VMARK/UNIVERSE, there are naturally >plenty of things that change. It is, after all, then just a guest O/S. >That having been said, VMARK so far has caused me no grief, save certain >UNIX restrictions (like files not being able to span devices). As one other person has already pointed out, this is only a restriction on any Unix machine that does not handle virtual file systems. I believe the Encore Multimax was cited, but you can also add Pyramid to this list. Experience with various customers has shown that striped disk can be a real advantage should you do any heavy disk I/O, typically in long-running batch runs such as end of month routines. Robyn Grunberg rag@yarra.oz.au #include <disclaimer.h>