What are flavors of PICK Basic?

[LaurelC]

I am trying to hire someone for a contract programming. My
advertisement said that I needed someone with PICK Basic or UniData
Basic experience. (I run UniData basic on a Unix platform).

I am getting responses to my ad, but the individuals talk about Flavors
of Pick. The application software we use was written in PICK Basic
20+ years ago. I have only used PICK Basic and UniData Basic so I
don't know the "flavors" - sheltered life!

What are the flavors of Pick that I might be interested in?

Thanks in advance.

[Tracy Raines]

Flavors is just a general term for a particular vendors version of a
multivalue database.

Unidata would be a flavor, as would D3, Universe or QM.

[dawn]

Post by LaurelC
I am trying to hire someone for a contract programming. My
advertisement said that I needed someone with PICK Basic or UniData
Basic experience. (I run UniData basic on a Unix platform).
I am getting responses to my ad, but the individuals talk about Flavors
of Pick. The application software we use was written in PICK Basic
20+ years ago. I have only used PICK Basic and UniData Basic so I
don't know the "flavors" - sheltered life!
What are the flavors of Pick that I might be interested in?
Thanks in advance.

I have a list of a bunch of different names for the BASIC product
somewhere, but it would be quicker to point you to my poster that shows
the companies that have/had flavors of BASIC. at

http://www.tincat-group.com/mv/familytree.html

Each of hte companies in the column on the right hand side has a
current version. These names are often Pick BASIC or DataBASIC, but
UniData is UniBASIC, for example. If you know the company/product,
that is what is often referred to as the flavor.

Best wishes. --dawn

[Tony Gravagno]

Post by LaurelC
I am trying to hire someone for a contract programming. My
advertisement said that I needed someone with PICK Basic or UniData
Basic experience. (I run UniData basic on a Unix platform).
I am getting responses to my ad, but the individuals talk about Flavors
of Pick. The application software we use was written in PICK Basic
20+ years ago. I have only used PICK Basic and UniData Basic so I
don't know the "flavors" - sheltered life!
What are the flavors of Pick that I might be interested in?
Thanks in advance.

There are actually two notions of the word 'flavor'.

The first has been described as above, where there are different
Pick-based companies that each have their own subtle nuances or
dialects of Pick BASIC, the command line, query processor, etc.

For Universe and UniData, the word 'flavor' has a very specific
meaning. These U2 platforms have an emulation setting which
determines what commands are available, and how various command-line
and BASIC statements behave. The PICK flavor, for example, will make
the environment more friendly toward someone familiar with other
products that derive from the various Pick flavors of the DBMS (see
the nuance?). The PRIME flavor may seem very alien to Pick people, as
might the IDEAL or UNIDATA flavors.

The other MV DBMS platforms also have some notion of flavoring to
various extents. These cross-platform options were all added for
competitive purposes, to facilitate migrations. For example, D3
supports BASIC syntax from U2, Microdata, GA, Ultimate, and other
platforms. But all D3 accounts support the same commands and behave
in the same way, unlike U2 flavors. The exception is when someone
puts D3 in R83 emulation via the R83.SETUP command (don't try it folks
if could mess up your system). This was a crutch to help people to
migrate from the old R83 platform, but anyone who is still using it is
insisting on running a VW Bug engine in their BMW of a DBMS.

Back to U2, if you are using PRIME, PIOPEN, IDEAL, or UNIDATA flavors
then someone who has worked exclusively with the PICK flavor may not
hit the ground running as fast as someone who is familiar with the
others. There will be a lot of "I know that's valid syntax so why
didn't that blankin thing work?" - and this will go on for months
until the learning curve levels out a little. Some people will tell
you the differences aren't that great. YMMV.

So the first thing for you to do is find out which flavor(s) you are
running. Try this command:
CT VOC RELLEVEL
(That might only work on Universe, I blew my Unidata away recently
sorry.)

<digression>
Nothing is better than first-hand research to understand someone
else's pain. Find out how to create an account and specify the
flavor. Use a flavor that is NOT what you're used to. Then login to
that account, try some TCL/ECL commands, create a file, try a couple
queries, write a couple little programs... You'll quickly feel like a
fish out of water.
</>

The next thing is, when people apply for the position, ask them what
specific flavors they have used in UniData ! If they can tell you
which ones, and they can name a few, they are far better candidates
than someone who just says "I dunno, I use Unidata". That's not a bad
thing in the least, but knowing such nuances does indicate the
candidate is a bit more well rounded.

HTH
Tony
TG@ strawberrybananaNebula-Rnd.com

[murthi]

Probably most important is an awareness of the differences in syntax,
functionality and even existence of instructions in different "flavors". On
uv eg, you can set an account to be Prime flavor, which among other things
makes LOCATE work differently. On many other platforms - Unidata, jbase, QM,
flavors are settable sometimes down to the instruction level
(pick-format-locate eg) as well as on a program level.
Cross-Pick-programmers should be aware of these and be able to deal with any
specific setup

Chandru Murthi

Post by LaurelC
I am trying to hire someone for a contract programming. My
advertisement said that I needed someone with PICK Basic or UniData
Basic experience. (I run UniData basic on a Unix platform).
I am getting responses to my ad, but the individuals talk about Flavors
of Pick. The application software we use was written in PICK Basic
20+ years ago. I have only used PICK Basic and UniData Basic so I
don't know the "flavors" - sheltered life!
What are the flavors of Pick that I might be interested in?
Thanks in advance.

[Tom Rauschenbach]

Post by LaurelC
What are the flavors of Pick that I might be interested in?

I have no way of discovering if this is still true, but at one time it was
possible to define one's own Flavors in uniVerse. The size of the table
used to hold them was set at 31 or 33, I forget which. There was an
Easter Egg in there if one tried to define more Flavors than that.

[[e-mail]]

Yes, you can pick which "flavor" you want to use in UniVerse.

For instance, the last company I worked for used the "Prime
Information" flavor, which I much prefer.

My current company uses the "Pick" flavor.

Although why they can't all be incorporated into one is beyond me. Most
commands already have 3 valid syntax choices, it seems like it would be
fairly simple to allow them all. Why should I be forced to type
ID-SUPP on one version, when I learned "ID.SUP" as a "child"? Why
should I be forced to use <1> in a locate statement on one version and
not on another? Sheesh!

And why doesn't UniData have a DICT.DICT, and why don't they have field
names in their dictionaries by default?

And why does one version allow three-dot "..." wildcard expressions and
another require square brackets? Isn't the world all about inclusion
these days?

Sometimes I am just flabbergasted, and often dismayed.

-- Louie Bergsagel, 2006 President, Seattle Area Pick User's Group
(SAPUG)

[(latimerp)]

With Nathan Rector is charge of International Spectrum perhaps a new
and expanded SMA spec is in order. I hear he has some new things in
mind. Just a thought.

Patrick <;=)

P.S. No offense to Gus intended, he's been a warrior.

Post by ***@yahoo.com
Yes, you can pick which "flavor" you want to use in UniVerse.
For instance, the last company I worked for used the "Prime
Information" flavor, which I much prefer.
My current company uses the "Pick" flavor.
Although why they can't all be incorporated into one is beyond me. Most
commands already have 3 valid syntax choices, it seems like it would be
fairly simple to allow them all. Why should I be forced to type
ID-SUPP on one version, when I learned "ID.SUP" as a "child"? Why
should I be forced to use <1> in a locate statement on one version and
not on another? Sheesh!
And why doesn't UniData have a DICT.DICT, and why don't they have field
names in their dictionaries by default?
And why does one version allow three-dot "..." wildcard expressions and
another require square brackets? Isn't the world all about inclusion
these days?
Sometimes I am just flabbergasted, and often dismayed.
-- Louie Bergsagel, 2006 President, Seattle Area Pick User's Group
(SAPUG)

[dawn]

Post by ***@yahoo.com
Yes, you can pick which "flavor" you want to use in UniVerse.
For instance, the last company I worked for used the "Prime
Information" flavor, which I much prefer.
My current company uses the "Pick" flavor.
Although why they can't all be incorporated into one is beyond me. Most
commands already have 3 valid syntax choices, it seems like it would be
fairly simple to allow them all. Why should I be forced to type
ID-SUPP on one version, when I learned "ID.SUP" as a "child"? Why
should I be forced to use <1> in a locate statement on one version and
not on another? Sheesh!
And why doesn't UniData have a DICT.DICT, and why don't they have field
names in their dictionaries by default?
And why does one version allow three-dot "..." wildcard expressions and
another require square brackets? Isn't the world all about inclusion
these days?
Sometimes I am just flabbergasted, and often dismayed.

Hi Louie --
Does a concern for law suits explain the differences? Or were there
other reasons for the Devcom, Prime Information folks and others to opt
for so many changes? I'm guessing sometimes they just thought "hey,
this would be better" and simply were not concerned about compatibility
for the developer. Additionally, as we move forward, there seems to be
very little concern for compatibility at all. IBM certainly doesn't
think about whether they are implementing client/server connectivity
like D3, for example. OpenQM isn't concerned if they implement objects
when such code could not migrate to any other MV platform. I'm
guessing Cache doesn't care about that either.

I don't know, but I suspect there was relatively little cross-over from
Pick shops and developers to the Prime Information stream of the
extended family (or the other direction) until IBM bought U2. Was
there much discussion about crossing platforms in the 90's? Were there
many third parties that tried to be MV-platform independent?

I split out the languages into three streams that I named R83 Pick,
uData Reality, and PI -> U2 but these are definitely not clean lines.
I dropped my post here and just came back to it, so I haven't a clue
what my (unlikely) brilliant point was going to be.

I suspect that the issues with client-server connectivity are as
problematic for third-party vendors as differences in dictionaries and
syntax, but I definitely understand the frustration.

On a related, but not exactly the same, note -- ODBC (and written
standards) helped with SQL DBMS's, whose flavors of SQL often differ
from each other more than the languages with different flavors of Pick.
Is there any chance we could get at least a standard means of
specifying an MV data source to products out there that will be able to
work with XML data sources? (Does that question make sense to others,
given the way I asked it? I haven't been able to get this point
through to someone I tried to chat with about it). I recognize that
there is a lot more than just a standard means of specifying a data
source that each vendor would have to do in order to take requests and
return result sets (bags, to be precise). They would not have to
collaborate with each other for that, however.

Cheers! --dawn

[Tony Gravagno]

Post by dawn
Is there any chance we could get at least a standard means of
specifying an MV data source to products out there that will be able to
work with XML data sources?

Once again the answer to your question is .NET, which is heavily built
around XML, and the ideal tool to facilitate the process for most MV
DBMS environments on any OS is mv.NET:
- You can import MV data into an ADO.NET dataset and generate an XML
schema for use by other products.
- You can import XML Data into an ADO.NET dataset using a provided
schema. From there you can exchange data directly with MV.

What we lack, which some lucky entrepreneur will one day surely
provide, is a product/application which magically does this, so that
people focus on the XML and not the .NET or connectivity tools.

I keep tellin ya Dawn - the answers are there, you just need to grab
the brass ring to win your prize.

T

[Peter McMurray]

Post by Tony Gravagno

Post by dawn
Is there any chance we could get at least a standard means of
specifying an MV data source to products out there that will be able to
work with XML data sources?

Once again the answer to your question is .NET, which is heavily built
around XML, and the ideal tool to facilitate the process for most MV
- You can import MV data into an ADO.NET dataset and generate an XML
schema for use by other products.
- You can import XML Data into an ADO.NET dataset using a provided
schema. From there you can exchange data directly with MV.
What we lack, which some lucky entrepreneur will one day surely
provide, is a product/application which magically does this, so that
people focus on the XML and not the .NET or connectivity tools.
I keep tellin ya Dawn - the answers are there, you just need to grab
the brass ring to win your prize.
T

What about BRIZ I am only testinfg the waters but it seems to be a lot
further down the track that any others,
Peter McMurray

[Mark Brown]

Post by ***@yahoo.com
Yes, you can pick which "flavor" you want to use in UniVerse.
For instance, the last company I worked for used the "Prime
Information" flavor, which I much prefer.
My current company uses the "Pick" flavor.
Although why they can't all be incorporated into one is beyond me. Most
commands already have 3 valid syntax choices, it seems like it would be
fairly simple to allow them all. Why should I be forced to type
ID-SUPP on one version, when I learned "ID.SUP" as a "child"? Why
should I be forced to use <1> in a locate statement on one version and
not on another? Sheesh!
And why doesn't UniData have a DICT.DICT, and why don't they have field
names in their dictionaries by default?
And why does one version allow three-dot "..." wildcard expressions and
another require square brackets? Isn't the world all about inclusion
these days?
Sometimes I am just flabbergasted, and often dismayed.
-- Louie Bergsagel, 2006 President, Seattle Area Pick User's Group
(SAPUG)

In a word: competition. Why would you ever buy one version of anything over
another? Why Ford or Chevy or Dodge?

Once they were all the same, when there was just Pick. But each new vendor
had to add something to make it unique and make you want their version.

Instead of decrying diversity, we should be embrassing it.

Mark Brown

[Peter McMurray]

Post by Mark Brown

Post by ***@yahoo.com
Yes, you can pick which "flavor" you want to use in UniVerse.
For instance, the last company I worked for used the "Prime
Information" flavor, which I much prefer.
My current company uses the "Pick" flavor.
Although why they can't all be incorporated into one is beyond me. Most
commands already have 3 valid syntax choices, it seems like it would be
fairly simple to allow them all. Why should I be forced to type
ID-SUPP on one version, when I learned "ID.SUP" as a "child"? Why
should I be forced to use <1> in a locate statement on one version and
not on another? Sheesh!
And why doesn't UniData have a DICT.DICT, and why don't they have field
names in their dictionaries by default?
And why does one version allow three-dot "..." wildcard expressions and
another require square brackets? Isn't the world all about inclusion
these days?
Sometimes I am just flabbergasted, and often dismayed.
-- Louie Bergsagel, 2006 President, Seattle Area Pick User's Group
(SAPUG)

In a word: competition. Why would you ever buy one version of anything
over another? Why Ford or Chevy or Dodge?
Once they were all the same, when there was just Pick. But each new
vendor had to add something to make it unique and make you want their
version.
Instead of decrying diversity, we should be embrassing it.
Mark Brown

Are the wonders of the English Language when misspelt. Was that
"embarassing" or "embracing" it? :).
Peter Mcmurray

[Simon Verona]

Mark

Agreed about embracing the standards and then extending...

but.. surely if UniVerse has compatibility with other flavours, surely it
would be simple for them to support both flavours at the same time unless
there is a conflict between their syntax. This means that two people who
both use UniVerse are actually using different systems! Surely this
fragments the UniVerse marketplace up and makes employment of new staff to
run with UniVerse more difficult ? This can't be in IBM's best
interest!!!!

Regards
Simon
--
================================
Simon Verona
Dealer Management Service Ltd
Stewart House
Centurion Business Park
Julian Way
Sheffield
S9 1GD

Tel: [phone]
Fax: [phone]

Post by Mark Brown

Post by ***@yahoo.com
Yes, you can pick which "flavor" you want to use in UniVerse.
For instance, the last company I worked for used the "Prime
Information" flavor, which I much prefer.
My current company uses the "Pick" flavor.
Although why they can't all be incorporated into one is beyond me. Most
commands already have 3 valid syntax choices, it seems like it would be
fairly simple to allow them all. Why should I be forced to type
ID-SUPP on one version, when I learned "ID.SUP" as a "child"? Why
should I be forced to use <1> in a locate statement on one version and
not on another? Sheesh!
And why doesn't UniData have a DICT.DICT, and why don't they have field
names in their dictionaries by default?
And why does one version allow three-dot "..." wildcard expressions and
another require square brackets? Isn't the world all about inclusion
these days?
Sometimes I am just flabbergasted, and often dismayed.
-- Louie Bergsagel, 2006 President, Seattle Area Pick User's Group
(SAPUG)

In a word: competition. Why would you ever buy one version of anything
over another? Why Ford or Chevy or Dodge?
Once they were all the same, when there was just Pick. But each new
vendor had to add something to make it unique and make you want their
version.
Instead of decrying diversity, we should be embrassing it.
Mark Brown

[Tom Rauschenbach]

Post by ***@yahoo.com
Yes, you can pick which "flavor" you want to use in UniVerse.
For instance, the last company I worked for used the "Prime
Information" flavor, which I much prefer.
My current company uses the "Pick" flavor.
Although why they can't all be incorporated into one is beyond me. Most
commands already have 3 valid syntax choices, it seems like it would be
fairly simple to allow them all. Why should I be forced to type
ID-SUPP on one version, when I learned "ID.SUP" as a "child"? Why
should I be forced to use <1> in a locate statement on one version and
not on another? Sheesh!

Way back when, when VMark was creating the notion of Flavors within
uniVerse, the goal was better compatibility. We couldn't just accept
every syntax we knew about. Stuff that wasn't supposed to work had to
fail in the expected way.

The idea of user defined flavors was intended to let people select from
all of the different behavior options available if that's what they
wanted. Flavors affected the compiler, but I don't recall anything in the
run-machine (that's what we called the interpreter) that was flavor aware.

And of course you could put whatever you wanted in the VOC file.

[[e-mail]]

Many competing companies follow standards.
There is no reason why there can't be a multivalue (syntax) standard.
Compete with features, not different spellings of the same functon.

-- Louie

[t***@gmail.com]

On the Universe and Unidata flavor options, lets not also forget the
compilation $OPTIONS which allows you to set the BASIC flavor for
compilation even though the account flavor, this negates
incompatibility issues because you can always code in the flavor of
your choice.