Comparison of Pick and Pick/Unix requested

Comparison of Pick and Pick/Unix requested

Post by Dale E. Hig » Wed, 29 Sep 1993 04:49:39



Hello.  Right now our division is trying to consolidate two companies'
Information Systems Departments.  One company runs Pick on a Honeywell
Ultimate, the other runs Information on a Prime.  The first company is
arguing that we need to go to a Pick Operating System.  The second is
arguing that we need to go to Pick/Unix.  This is where I need as much help
as I can get.  There is an existing ethernet LAN/WAN in the division.

What are the advantages of Pick OS over Pick/Unix?
What are the advantages of Pick/Unix over Pick OS?
What are the disadvantages of Pick OS?
What are the disadvantages of Pick/Unix?
What can I do in Pick OS that I cannot in Pick/Unix?
What can I do in Pick/Unix that I cannot in Pick OS?
Is one substantially easier to use than the other?
Does one have a longer future than the other?
Will one conversion be easier than the other (for both companies)?
Are there any compelling reasons to _NOT_ go with one or the other?

You get the idea.


Thank-you in advance.

--
 ____________________________________________________________________________

|     "When he sneezes, he looks like a party favor."       !uupsi!rrc!deh  |

 
 
 

Comparison of Pick and Pick/Unix requested

Post by Toni van de Wi » Thu, 30 Sep 1993 18:13:37



>What are the advantages of Pick OS over Pick/Unix?
>What are ...


I would rather see the responses posted to this group, as there are many
sites with the same 'problems'.
Also, many sites (like us) will eventually have to move from Prime Information
to another platform and (we for sure) would like to hear how other users
did it and on what bases they made their choices.

Please share you horror (and success?) stories with us!

Regards,
++Toni;

--
Toni van de Wiel       phone: +31 35 258411       Intomart BV


 
 
 

Comparison of Pick and Pick/Unix requested

Post by Mark Dela » Sat, 02 Oct 1993 00:28:01



>Hello.  Right now our division is trying to consolidate two companies'
>Information Systems Departments.  One company runs Pick on a Honeywell
>Ultimate, the other runs Information on a Prime.  The first company is
>arguing that we need to go to a Pick Operating System.  The second is
>arguing that we need to go to Pick/Unix.  This is where I need as much help
>as I can get.  There is an existing ethernet LAN/WAN in the division.
>What are the advantages of Pick OS over Pick/Unix?
>What are the advantages of Pick/Unix over Pick OS?
>What are the disadvantages of Pick OS?
>What are the disadvantages of Pick/Unix?
>What can I do in Pick OS that I cannot in Pick/Unix?
>What can I do in Pick/Unix that I cannot in Pick OS?
>Is one substantially easier to use than the other?
>Does one have a longer future than the other?
>Will one conversion be easier than the other (for both companies)?
>Are there any compelling reasons to _NOT_ go with one or the other?


And if we do your job for you, what will you do?

M.

 
 
 

Comparison of Pick and Pick/Unix requested

Post by Nick Pembert » Fri, 01 Oct 1993 22:35:07



Quote:>as I can get.  There is an existing ethernet LAN/WAN in the division.

[In itself worth considering - Pick/Unix is more likely able to use that then
Pick/Native - although this is not always the case]

You are considering one of the biggest problems facing anyone who has
a large investment in one hardware platform/software solution moving to
another. As far as I can tell, there is no simple answer, but there are a
number of factors to consider, some of which might be:

o Which of your current systems would be more difficult to convert? Ie,
  which one has the more challenging code to convert, or has more?
o have you taken advantage of any particular feature of one system not
  commonly found in others?
o Do you (ACK, phht) have any custom user modes?
o Lost any source code?

Now, a more general question: Do you have any real need to stick to
native pick? Native Pick does tend to be slighlty faster then Unix on the
same hardware, because it is simpler. Remember this is a generalization,
but in my experiance it is true.

I'll try and list some of the answers I have to your questions below, but
ahead of time I'll tell you that given one Prime Information set of apps, and
another native (ultimate) set, you'de probably find it relatively easy to
fit into uniVerse, and there are some very powerfull uniVerse boxes out there.

Quote:

>What are the advantages of Pick OS over Pick/Unix?

Mostly speed - it can get more out of the hardware then Pick/Unix. However,
its often simpler to install and maintain then Pick/Unix - this may be a
consideration if you don't have CS staff.

Quote:>What are the advantages of Pick/Unix over Pick OS?

There are two obvious points: It has fantastic communications abilities (at
least some of them do - Advanced Pick for Unix is appalling at I/O, even over
TCP/IP, due to its internal buffering (Can you tell I've run into this
one?) ) - uniVerse and unidata are both very good at I/O, and ADDS' M.O.E. isn't
bad.

The second point is the open nature of it: You can choose a wide range of
hardware and O/S vendors for uniVerse and unidata, AP/Unix is a bit more
limited, and M.O.E. runs only on the NCR 3000 line (which are nice boxes,
if not a bit pricey...)

From the software point of view, you get all the development tools of Unix
as well as the Pick implementation - this can be a very productive boost.
Remember what a pain it was to launch phantom tasks in PICK - its trivial
under Unix...

Quote:>What are the disadvantages of Pick OS?

My biggest beef with Native PICK is that it isn't really growing any more -
there's not much more any vendor is going to do to it (like adding TCP/IP to
it, or Fax Cards, or CD-Roms, etc, etc).

As a platform its stable, relatively cheap, and does what its intended to
do. Its just very limited these days.

Quote:>What are the disadvantages of Pick/Unix?

Can be very complicated to install, administer and learn. But its worth it.
It takes quite a long time to boot on many platforms, and if you've ever
seen a Unix filesystem get truely hosed, you know what a pain that can
be to rebuild.

Quote:>What can I do in Pick OS that I cannot in Pick/Unix?

Totally ignore security at all levels :-) Seriously, you can create D-Pointers
just about anywhere, have totally hidden files, move about the system
freely, without risking too much damage (hell you can delete a D-Pointer,
leave it deleted for days, use the editor to put it back, and not loose
anything - not for the faint of heart - but its a great way to hide
something!)

Write in PICK Assembler. This can be a pro or a con though...

Fix GFE's using the system de* (yuck some say, but its been known
to save lives)

Quote:>What can I do in Pick/Unix that I cannot in Pick OS?

Well, much better security, if that matters.

Use many more devices. Both quantity, and types.

Much better communications, as above.

Better use of the hardware (can be a DOS network server as well as
being a PICK machine)

Quote:>Is one substantially easier to use than the other?

Again, depends on your background. Because I come from Native PICK, and
worked in it for years, I think its easier (certainly its simpler).

But if you are a die hard unix nut, you'de hate native PICK.

Due to the nature of our business, we have a lot of machines and types
here: Native in a few flavours, uniVerse, unidata, M.O.E., and a few
others. I definately prefer Unix implementations, and they all have merit.
Our uniVerse and M.O.E. boxes are used regularly. Our native boxes only
get started now when we have to test our product on them.

There is no correct answer to this one.

Quote:>Does one have a longer future than the other?

I'd say PICK/Unix most definately has a longer future. After all, Native
PICK is just an O/S hacked together to support a great database at a time
when there was no other solution (boy I'll get flamed for this one...) -
Unix (and - gasp - even NT) is better then PICK as an O/S. Why keep native
PICK? Keep the data model, sure, but native is eventually going to
disappear

Quote:>Will one conversion be easier than the other (for both companies)?

Need a lot more detail to answer that. As I mentioned, uniVerse can be
configured in one account to behave like Prime (and when they complete
the merger of PI/Open and uniVerse, it'll be ever better), and you can
configure another to look like native PICK.

What does your code look like? Anything non-standard?



Replying via email and news, since it'll be an interesting debate.

Nick
--

Amaron Canada         uunet.ca!amaron!nick          Fax: (416) 690-0840

 
 
 

Comparison of Pick and Pick/Unix requested

Post by Lance Anders » Sat, 02 Oct 1993 21:09:02


Dale,

You don't specify which flavor of ultimate (ultimate+, ultix, etc...) so I
will give you generalities...

I have done many ports to PI, PI/open and uniVerse during my tenure at Prime
from 'classic' Pick so here are some of my thoughts...

Moving from Prime INFORMATION (PI) to an R83 like implementation of PICK
would be extremely difficult as there many pieces of functionality that
PI, PI/open, uniVerse, UniData provide that are not available.  Same is
true for some of the AP implementations that I have seen.  Here are a list
of some of the missing functionality and porting issues:

        * Transfer of Data will be a hassle as you will have to either
          T-dump using the SMA mode or write/buy a utility to transfer
          data similar to how SAVE.ACCOUNT/RESTORE.ACCOUNT work...

        * Itypes will need to be converted to correlatives (yuk !!!)

        * No Distributed or Multi-volume files

        * No Paragraphs

        * No true GCI (though AP allows this but I have never used it)

        * No ICI

        * No user written functions

        * Dictionary types/structures are different

        * Does not support many of the conversion codes that PI does

        * If you are using PIM or PI/NR forget it

        * Many  INFO/BASIC statements are missing or act differently

        * No Dynamic files and file sizing on non-PI like implementations
          is much more work

        * All VOC entries would have to be converted to MD style entries

        * PICK is the database and the OS

        * The de* is less sophisticated

        * All INFORM queries would require re-writing unless you are using
          SMA accounts on PI and even then some would still need re-working

        * Many commands are different

        * Spooler is totally different

        * No batch support (ala primos)

        * no command stack editor


          easily replaced.        

I could go on, but you get the idea.

Now going from PICK (non-AP) to PI is fairly easy, going to PI/open
(or uniVerse) is even easier. Porting to UniData isn't bad but not as easy
as PI/open or uniVerse in my opinion.

Porting to PI et al:

                 *  Utilities are provided to read file-save and account-save
                    tapes as well as t-dumps

                 *  Full Pick style dictionary entries are supported (On PI
                    you have to go through a conversion tool to convert to
                    PI style entries).  Not a problem for PI/open or uniVerse

                 *  Most of the popular user exits are provided or can be
                    easily written in INFO/BASIC or the language of choice

                 *  PQ and PQN proc support provided

                 *  Support for the 'classic' pick and reality correlative
                    stack differences an a per-account basis. (not in PI,
                    reality style correlatives might need some mods, not an
                    issue for PI/open)

                 *  Support for PICK style spooler is provided.

                 *  Support for Q-pointers are provided in PI/open and uniVerse
                    These will need conversion on PI

                 *  Various compiler options to handle differences between
                    PICK and PI, PI/open and uniVerse.  PI/open and uniVerse
                    can handle just about all nuances.  PI would require more
                    direct changes to the code


                    'classic' PICK to PI on a per application basis without
                    application modification

These are not complete lists but you should be able to get an idea of your
obstacles.

I would certainly reccommend migrating from Ultimate to PI/open or uniVerse.
I believe Vmark has a better product set and a brighter future than Ultimate
or 'classic' PICK.  

Migrating to an implementation which sits on top of the OS like PI will not
lock you in to a vendor as the OS wars are heating up between Solaris, NT
and unixware your hardware choices will be many.

Other issues to look at when deciding who to go with;

    *  Support quality and responsiveness

    *  Delivery of promised futures

    *  stability of the vendor

Some of the 'classic' Pick players are looking into incorporating a PI flavor
but PI offers so much more functionality that it will take time to catch-up.

Good luck!

Lance
===============================================================================

Sybase Technical Support            
77 South Bedford Street
Burlington, MA 01803                      
Phone:(617) 238-6336                    Fax: (617) 238-6148

The Dark Knight Returns!!!              Let's Go Penguins!!!
===============================================================================

 
 
 

Comparison of Pick and Pick/Unix requested

Post by Dale E. Hig » Sun, 03 Oct 1993 06:47:52



> Subject: Re: Comparison of Pick and Pick/Unix requested
> Date:    1 Oct 1993 01:28:01 +1000

[clip]
Previous posting with questions about Pick and Pick/Unix deleted.

Quote:

> And if we do your job for you, what will you do?

> M.

Hopefully what I was hired to do.  That being: Provide technical software,
hardware and m*support for 400+ users spread over the state using such
applications as Manufacturing, Inventory control, Contract Administration,
Capacity Requirements Planning, Costing, Material Requirements Planning,
Computer Aided Design/Manufacturing/Engineering, TCP/IP and Appletalk network
Administration and support, SUN Workstation configuration/maintenance/
programming/handholding, same for personal computers, answer the telephone
every five minutes, act as a repository of information about every subject
the boss can think of, and try to retain my sanity.  In other words, what any
IS staff member is expected to do.  Oh.  I forgot system administration.

Regards,

Dale E. Higgs
Programmer/Analyst
Olin Rocket Research Company

(:) :) :)) (for the smiley-impaired)

 
 
 

Comparison of Pick and Pick/Unix requested

Post by Tony Dard » Tue, 05 Oct 1993 20:27:58


Nick Pemberton invites comment, as follows, in a discussion of the
merits of Pick/Unix and Native Pick

Quote:> I'd say PICK/Unix most definately has a longer future. After all, Native
> PICK is just an O/S hacked together to support a great database at a time
> when there was no other solution (boy I'll get flamed for this one...) -
> Unix (and - gasp - even NT) is better then PICK as an O/S. Why keep native
> PICK? Keep the data model, sure, but native is eventually going to
> disappear

What still strikes me as a virtue of Native Pick (as far back as the
Microdata Reality implementations) is the memory model:  for most
purposes there simply is no distinction between certain kinds of
mass storage (i.e., disk memory) and working storage (i.e., "main
memory").  This lack of distinction has relatively little to do with
the fact that the O/S supports a data base, in that one can well
develop other sorts of applications on the O/S.  That said, there
clearly are applications for which such a distinction is essential,
so it is a vice of Pick that it does not offer the distinction when
it is needed.

I still see new PC software published with the warning that only entities
up to a certain size will be handled, and that the authors are working
on memory management.  That seems to me to be a problem not worth
having.

Tony Dardis
Hofstra University

 
 
 

Comparison of Pick and Pick/Unix requested

Post by Mark Dela » Tue, 05 Oct 1993 22:13:34



Quote:>I have done many ports to PI, PI/open and uniVerse during my tenure at Prime
>from 'classic' Pick so here are some of my thoughts...

And some good thoughts too.

Here's another thought that applies to people who are looking in the
medium-term to migrate off of pick/PI/Universe altogether.

Namely that it *may* make sense to move to one of the Unix based
Pick-like (eg, UniVerse, PI/Open, Unidata) products now, then move to
your preferred Database later on.

The biggest advantage of this is that you make the change in two
smaller steps rather than one large step. I have seen/heard of too
many people who take both steps at once and take a long time to get
fully functional again.

Quote:>The Dark Knight Returns!!!              Let's Go Penguins!!!
>=============================================================================

Yes. I agree. Let go of the Penguins. It's probably illegal anyway.

M.

 
 
 

Comparison of Pick and Pick/Unix requested

Post by Dale E. Hig » Wed, 06 Oct 1993 08:47:59


One more reply forwarded to the list.

__________________________________________________________________________

Date: Fri, 1 Oct 93 08:09:22 EDT


Content-Length: 5130
Status: OR

Dale,

You don't specify which flavor of ultimate (ultimate+, ultix, etc...) so I
will give you generalities...

I have done many ports to PI, PI/open and uniVerse during my tenure at Prime
from 'classic' Pick so here are some of my thoughts...

Moving from Prime INFORMATION (PI) to an R83 like implementation of PICK
would be extremely difficult as there many pieces of functionality that
PI, PI/open, uniVerse, UniData provide that are not available.  Same is
true for some of the AP implementations that I have seen.  Here are a list
of some of the missing functionality and porting issues:

        * Transfer of Data will be a hassle as you will have to either
          T-dump using the SMA mode or write/buy a utility to transfer
          data similar to how SAVE.ACCOUNT/RESTORE.ACCOUNT work...

        * Itypes will need to be converted to correlatives (yuk !!!)

        * No Distributed or Multi-volume files

        * No Paragraphs

        * No true GCI (though AP allows this but I have never used it)

        * No ICI

        * No user written functions

        * Dictionary types/structures are different

        * Does not support many of the conversion codes that PI does

        * If you are using PIM or PI/NR forget it

        * Many  INFO/BASIC statements are missing or act differently

        * No Dynamic files and file sizing on non-PI like implementations
          is much more work

        * All VOC entries would have to be converted to MD style entries

        * PICK is the database and the OS

        * The de* is less sophisticated

        * All INFORM queries would require re-writing unless you are using
          SMA accounts on PI and even then some would still need re-working

        * Many commands are different

        * Spooler is totally different

        * No batch support (ala primos)

        * no command stack editor


          easily replaced.        

I could go on, but you get the idea.

Now going from PICK (non-AP) to PI is fairly easy, going to PI/open
(or uniVerse) is even easier. Porting to UniData isn't bad but not as easy
as PI/open or uniVerse in my opinion.

Porting to PI et al:

                 *  Utilities are provided to read file-save and account-save
                    tapes as well as t-dumps

                 *  Full Pick style dictionary entries are supported (On PI
                    you have to go through a conversion tool to convert to
                    PI style entries).  Not a problem for PI/open or uniVerse

                 *  Most of the popular user exits are provided or can be
                    easily written in INFO/BASIC or the language of choice

                 *  PQ and PQN proc support provided

                 *  Support for the 'classic' pick and reality correlative
                    stack differences an a per-account basis. (not in PI,
                    reality style correlatives might need some mods, not an
                    issue for PI/open)

                 *  Support for PICK style spooler is provided.

                 *  Support for Q-pointers are provided in PI/open and uniVerse
                    These will need conversion on PI

                 *  Various compiler options to handle differences between
                    PICK and PI, PI/open and uniVerse.  PI/open and uniVerse
                    can handle just about all nuances.  PI would require more
                    direct changes to the code


                    'classic' PICK to PI on a per application basis without
                    application modification

These are not complete lists but you should be able to get an idea of your
obstacles.

I would certainly reccommend migrating from Ultimate to PI/open or uniVerse.
I believe Vmark has a better product set and a brighter future than Ultimate
or 'classic' PICK.  

Migrating to an implementation which sits on top of the OS like PI will not
lock you in to a vendor as the OS wars are heating up between Solaris, NT
and unixware your hardware choices will be many.

Other issues to look at when deciding who to go with;

    *  Support quality and responsiveness

    *  Delivery of promised futures

    *  stability of the vendor

Some of the 'classic' Pick players are looking into incorporating a PI flavor
but PI offers so much more functionality that it will take time to catch-up.

Good luck!

Lance
===============================================================================

Sybase Technical Support            
77 South Bedford Street
Burlington, MA 01803                      
Phone:(617) 238-6336                    Fax: (617) 238-6148

The Dark Knight Returns!!!              Let's Go Penguins!!!
===============================================================================

 
 
 

1. Which PICK, PICK-UNIX did you choose?

Seeing the bandwidth has been a bit quiet, hopefully, this will cause
some interesting discussions.

I would be interested to know if your company moved or is planning on moving
to a new system (or dbms)  which flavor of PICK/PICK like dbms and platform
did you  choose and why?

Regards,

Lance
===============================================================================

Sybase Technical Support            
77 South Bedford Street
Burlington, MA 01803                      
Phone:(617) 238-6336                    Fax: (617) 238-6148

The Dark Knight Returns!!!              Let's Go Penguins!!!
===============================================================================

2. Arcobaleno Hardware Factory

3. PICK, UniVerse, Unix and what-have you (info request)

4. Delete Rules

5. Pick on NT Comparison

6. Escaping strings for inclusion into SQL queriesh

7. PICK on NT comparison

8. dates In SQL

9. Comparison Oracle vs Pick H/Ware Requirements

10. Pick and Pick-like windows for dumb terminals

11. PICK to PICK transfers

12. New PICK and PICK Flavours Mailing List.