MV community lawsuits

I always remember that the SYSTEM account pointers had a security level
SYS1/SYS2/SYS3 etc... Some verbs would only work at certain levels.
Whilst this was generally poorly implemented in most MV variants, it could
have been used to give users read-only access at TCL level if it had been
expanded..

I would have liked a user-overrideable attribute in the MD definition that
defined a "minimum" level for the verb to run - expand the SYS1-3 to
SYS1-100 and allow program defnition pointers in the MD and procs to also
have the same security... Hey presto, usable security at tcl! Controlled by
the user account name.

Sadly, unless somebody knows differently.. the account secuity was pretty
much useless - not granular enough.

Another 2 cents into the money box!

Regards
Simon
"Excalibur" <excalibur21 (AT) bigpond (DOT) com> wrote

Hi Dawn
One of the really greate things about English/AQL/whatever is the fact
that
it cannot update. This allows it to be used safely by even the most
useless
operator.
In fact the worst thing that was ever done to Pick was the introduction of
the DELETE verb, effectively an AQL command. Only a unix revhead could
have
dreamed up this disaster. It races off with nary a check in the world.
If
the user forgot to call his select list then bingo it erases the entire
file. We had an excellent way of deleting items in the ED prestored
command
until somebody added "did you really want to do this" and failed to allow
the question to be overridden by the prestore. I say excellent because
only
people who knew what they were doing could use it.
Imagine if English could update the whole method of programming Pick would
have to be thrown out. Business rules would have to be held at the file
level. Dictionaries would have to be barred from users as they would
become
THE FILE DEFINITION and lose their flexibility etc etc.
Please do not even think about it again.
Regards
Peter McMurray

"Jim" <wildcat66 (AT) hotmail (DOT) com> wrote in message
news:2GQjf.3011$nA2.1657 (AT) newssvr22 (DOT) news.prodigy.net...
With regards to the first part of your question, the orginal 'english'
written by Chandru Murti (Chandru you can correect this if incorrect -
know
you are lurking out there somewhere) - who was with Dick in the original
Microdata days, and according to an orginal 'English 'Binder' English HAd
Update capabilities, but as I remember the story , it did not work well
at
the time and resourses were concentrated on merely the RETREIVAL'
capability - Chandru eventually worked ona project for Ultimate where the
'UPDATE Processor' was originally implemented and later part of Advanced
Pick, and to a certain extent D3 todaye

Oldies may have additional information on this as welkl
"dawn" <dawnwolthuis (AT) gmail (DOT) com> wrote in message
news:1133441835.891237.156050 (AT) z14g2000cwz (DOT) googlegroups.com...
I started to research the history of the MultiValue query language
because I was trying to figure out why it was so much easier to use
than SQL. I was curious why it didn't evolve into an update language.
I was/am looking into the future of data models and related languages
for query and update. When I embarked on this in 2001, I found the
stories behind the technology fascinating. One area I did not delve
into much is the area of lawsuits. There have been a flood of lawsuits
in the MultiValue world. A couple of them are:

Pick vs TRW from whom he, uh, obtained the original code
Pick vs Microdata (Pick married the secretary and former girlfriend of
Don Fuller, the President of Microdata)

and the more recent UniData lawsuits with Pacific UniData, with final
settlements during the acquisition of Informix by IBM IIRC.

I have read bits and pieces about many others such as Pick vs just
about everyone.

Since I was supposedly interested in tracing the movement of the
languages and data model, I didn't take many notes on these. Seeing
how many, uh, *seasoned* professionals there on this list, I thought
I'd ask what lawsuits anyone recalls among Pick and Pick-a-like
vendors. It seems like a history worth recording.

I really have no plans for use of this information -- just curious
right now. What lawsuits does anyone know about or recall? Thanks in
advance. --dawn

"Mark Brown" <mbrown (AT) drexelmgt (DOT) com> wrote

(This part is hear-say. I wasn't there, but I was around when a lot
of
substances were consumed)
Jim Whelen (whelan?) and Denny Brown sold Honeywell mainframes when
the got
a great idea. They told a prespective buyer that they didn't really
need to
buy a new computer, they just needed to buy TIME on one. Then they
went to
an old customer and said, you're only using your computer 10 hours a
day.
We'll pay you $1K/mo for the 14 hours you're not using. Then they'd
sell
that time to customer B for $5K/mo. Honeywell found out and
transfered them
to Alaska, so they quit and started a "facility management service"
where
they'd charge you to manage your DP department. They'd take over
the lease,
hire your people and give you a monthly bill.

The following is early computer history, not Pick history.

IBM had a clock built into their early 'computers', circa 1950s-1960s.
And your monthly IBM bill was based on when the computer was powered
up. This is pre-360. And even back then, coldstarting the tube
machines could be an adventure. <Pop, crackle & Snap> Eventually,
operation staffs realized they'd get less 'down' time if the computer
was left on 24x7. And then they started creating all kinds of nasty
overnight runs that interrupted many a night's sleep.


Roger

Excalibur wrote:

Hi Dawn
One of the really greate things about English/AQL/whatever is the fact that
it cannot update. This allows it to be used safely by even the most useless
operator.

Interesting observation. Given the VOC or MD as almost the only
security strategy in Pick, it really does help a lot that there is no
chance that the query language would alter the data. That is likely
why I opted to stick to using it as a manager, mitigating the risk of
my meeting-riddled schedule (and ensuring I wasn't on a pager perhaps,
per rog's post).

In fact the worst thing that was ever done to Pick was the introduction of
the DELETE verb, effectively an AQL command. Only a unix revhead could have
dreamed up this disaster. It races off with nary a check in the world. If
the user forgot to call his select list then bingo it erases the entire
file. We had an excellent way of deleting items in the ED prestored command
until somebody added "did you really want to do this" and failed to allow
the question to be overridden by the prestore. I say excellent because only
people who knew what they were doing could use it.

An unreliable, but largely effective, security approach.

Imagine if English could update the whole method of programming Pick would
have to be thrown out. Business rules would have to be held at the file
level. Dictionaries would have to be barred from users as they would become
THE FILE DEFINITION and lose their flexibility etc etc.
Please do not even think about it again.

Point taken. Someone should tell those XQuery folks who released the
XQuery update standard this year. Hmmmm. Cheers! --dawn

Regards
Peter McMurray

"Jim" <wildcat66 (AT) hotmail (DOT) com> wrote in message
news:2GQjf.3011$nA2.1657 (AT) newssvr22 (DOT) news.prodigy.net...
With regards to the first part of your question, the orginal 'english'
written by Chandru Murti (Chandru you can correect this if incorrect -
know
you are lurking out there somewhere) - who was with Dick in the original
Microdata days, and according to an orginal 'English 'Binder' English HAd
Update capabilities, but as I remember the story , it did not work well at
the time and resourses were concentrated on merely the RETREIVAL'
capability - Chandru eventually worked ona project for Ultimate where the
'UPDATE Processor' was originally implemented and later part of Advanced
Pick, and to a certain extent D3 todaye

Oldies may have additional information on this as welkl
"dawn" <dawnwolthuis (AT) gmail (DOT) com> wrote in message
news:1133441835.891237.156050 (AT) z14g2000cwz (DOT) googlegroups.com...
I started to research the history of the MultiValue query language
because I was trying to figure out why it was so much easier to use
than SQL. I was curious why it didn't evolve into an update language.
I was/am looking into the future of data models and related languages
for query and update. When I embarked on this in 2001, I found the
stories behind the technology fascinating. One area I did not delve
into much is the area of lawsuits. There have been a flood of lawsuits
in the MultiValue world. A couple of them are:

Pick vs TRW from whom he, uh, obtained the original code
Pick vs Microdata (Pick married the secretary and former girlfriend of
Don Fuller, the President of Microdata)

and the more recent UniData lawsuits with Pacific UniData, with final
settlements during the acquisition of Informix by IBM IIRC.

I have read bits and pieces about many others such as Pick vs just
about everyone.

Since I was supposedly interested in tracing the movement of the
languages and data model, I didn't take many notes on these. Seeing
how many, uh, *seasoned* professionals there on this list, I thought
I'd ask what lawsuits anyone recalls among Pick and Pick-a-like
vendors. It seems like a history worth recording.

I really have no plans for use of this information -- just curious
right now. What lawsuits does anyone know about or recall? Thanks in
advance. --dawn

Excalibur wrote:

In fact the worst thing that was ever done to Pick was the introduction of
the DELETE verb, effectively an AQL command. Only a unix revhead could have
dreamed up this disaster. It races off with nary a check in the world. If
the user forgot to call his select list then bingo it erases the entire
file. We had an excellent way of deleting items in the ED prestored command
until somebody added "did you really want to do this" and failed to allow
the question to be overridden by the prestore. I say excellent because only
people who knew what they were doing could use it.

<pavlovian mode = on>
I don't know whether you are joking or not. To say that using an obscure
and poorly documented feature of ED (which is in itself a relic that
unfortunately persists to this day) to replace a command that is
essentially required for *every application ever written* is absurd.
Would DOS or Unix be usable without DEL/rm? I think not. If DELETE
didn't already exist it would be the first program everyone learned to
write. Plus, on what platform does "DELETE MYFILE" do anything but
return "[203] item name?" ? Not R83 > OA > AP > D3, Adds Mentor or
MVBASE, UniVerse, or GA, to my recollection.
</pavlovian>

Always willing to snap at the obvious troll,
/Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006

Can't take credit for AQL, sorry.

The original GIM/GIRLS specification contained a comprehensive and complete
updating specification. Not surprisingly, the AQL verbs were ADD, DELETE and
CHANGE. It was a precursor of the SQL in its capabilities. This was
implemented by the original Pick group (Pick, Earl, and 2 others whose names
I forget) at TRW, "inherited" by Pick Systems on the qt (actually it was,
and still is, all in the public domain, courtesy of the US Army since it was
taxpayer funded).

When I joined Pick, the updating facility was the 2nd thing I worked
on.Though meticulously flowcharted and documented by Don Nelson, the
original architect, it was full of problems. You can imagine the complexity,
as it was designed for full internal join capability down to smv->smv or any
combination thereof (the infamous original "bridge correlative"). After
working with it for a few months, Dick decided to delay implementation till
later, a day which never came.

Dawn, anybody: does anyone have any of the original Nelson flowcharts? If
so, I would love to have a copy of one to frame!

Excalibur's fears about an Update language are unfounded if it's implemented
properly (after all, you can do this in SQL). Dictionary words used for
updating can be unique , and can be verified for consistency, ensuring
business rules are coherent. It'd be easy to limit their use based on user,
security level, etc, just as you would limit use of a data-entry screen.
Mainly, the update AQL could have ensured a level of data integrity via
Dict definitions. Their use would, I imagine, be indirect, via calls from
data-entry collector screens.

Minor comment: DELETE with no ids does nothing, not delete all items in
file. REFORMAT is the killer, since a null entry to file name reformats
into the same file!
Another comment: Why can't verbs like DELETE, CLEARFILE always have a
confirmation unless being executed from a proc or basic? Wouldn't that be a
clever thing to do?

Chandru Murthi

"Excalibur" <excalibur21 (AT) bigpond (DOT) com> wrote

Hi Dawn
One of the really greate things about English/AQL/whatever is the fact
that
it cannot update. This allows it to be used safely by even the most
useless
operator.
In fact the worst thing that was ever done to Pick was the introduction of
the DELETE verb, effectively an AQL command. Only a unix revhead could
have
dreamed up this disaster. It races off with nary a check in the world.
If
the user forgot to call his select list then bingo it erases the entire
file. We had an excellent way of deleting items in the ED prestored
command
until somebody added "did you really want to do this" and failed to allow
the question to be overridden by the prestore. I say excellent because
only
people who knew what they were doing could use it.
Imagine if English could update the whole method of programming Pick would
have to be thrown out. Business rules would have to be held at the file
level. Dictionaries would have to be barred from users as they would
become
THE FILE DEFINITION and lose their flexibility etc etc.
Please do not even think about it again.
Regards
Peter McMurray

"Jim" <wildcat66 (AT) hotmail (DOT) com> wrote in message
news:2GQjf.3011$nA2.1657 (AT) newssvr22 (DOT) news.prodigy.net...
With regards to the first part of your question, the orginal 'english'
written by Chandru Murti (Chandru you can correect this if incorrect -
know
you are lurking out there somewhere) - who was with Dick in the original
Microdata days, and according to an orginal 'English 'Binder' English HAd
Update capabilities, but as I remember the story , it did not work well
at
the time and resourses were concentrated on merely the RETREIVAL'
capability - Chandru eventually worked ona project for Ultimate where the
'UPDATE Processor' was originally implemented and later part of Advanced
Pick, and to a certain extent D3 todaye

Oldies may have additional information on this as welkl
"dawn" <dawnwolthuis (AT) gmail (DOT) com> wrote in message
news:1133441835.891237.156050 (AT) z14g2000cwz (DOT) googlegroups.com...
I started to research the history of the MultiValue query language
because I was trying to figure out why it was so much easier to use
than SQL. I was curious why it didn't evolve into an update language.
I was/am looking into the future of data models and related languages
for query and update. When I embarked on this in 2001, I found the
stories behind the technology fascinating. One area I did not delve
into much is the area of lawsuits. There have been a flood of lawsuits
in the MultiValue world. A couple of them are:

Pick vs TRW from whom he, uh, obtained the original code
Pick vs Microdata (Pick married the secretary and former girlfriend of
Don Fuller, the President of Microdata)

and the more recent UniData lawsuits with Pacific UniData, with final
settlements during the acquisition of Informix by IBM IIRC.

I have read bits and pieces about many others such as Pick vs just
about everyone.

Since I was supposedly interested in tracing the movement of the
languages and data model, I didn't take many notes on these. Seeing
how many, uh, *seasoned* professionals there on this list, I thought
I'd ask what lawsuits anyone recalls among Pick and Pick-a-like
vendors. It seems like a history worth recording.

I really have no plans for use of this information -- just curious
right now. What lawsuits does anyone know about or recall? Thanks in
advance. --dawn

"murthi" <c_xyz_murthi (AT) seeing_xyz_green (DOT) net> wrote

<snip>

Another comment: Why can't verbs like DELETE, CLEARFILE always have a
confirmation unless being executed from a proc or basic? Wouldn't that be
a clever thing to do?

Chandru Murthi

Would this clever thing resemble the

"Are you sure (Y/N)"

response from DOS when someone typed DEL *.* ?????

I hope it would be smarter and more informative than that!

Larry Hazel

murthi wrote:

Can't take credit for AQL, sorry.

The original GIM/GIRLS specification contained a comprehensive and complete
updating specification. Not surprisingly, the AQL verbs were ADD, DELETE and
CHANGE. It was a precursor of the SQL in its capabilities. This was
implemented by the original Pick group (Pick, Earl, and 2 others whose names
I forget) at TRW, "inherited" by Pick Systems on the qt (actually it was,
and still is, all in the public domain, courtesy of the US Army since it was
taxpayer funded).

Somehow I don't think that all software written by any company today
for the US Army or any other government entity is automatically in the
public domain. Software laws have perhaps changed slightly in the past
four decades?

When I joined Pick, the updating facility was the 2nd thing I worked
on.Though meticulously flowcharted and documented by Don Nelson, the
original architect, it was full of problems. You can imagine the complexity,
as it was designed for full internal join capability down to smv->smv or any
combination thereof (the infamous original "bridge correlative"). After
working with it for a few months, Dick decided to delay implementation till
later, a day which never came.

Dawn, anybody: does anyone have any of the original Nelson flowcharts? If
so, I would love to have a copy of one to frame!

Since you brought it up, I'll tell you that I used this as a "quest for
the holy grail" effort a few years ago. I don't have your e-mail in my
current address book, but if you or anyone else wants to know where my
quest took me, shoot me an e-mail to dwolt at tincat-group dot com
before Sunday of this week and I'll let those who e-mail me know the
status on that.

Excalibur's fears about an Update language are unfounded if it's implemented
properly (after all, you can do this in SQL).

SQL has a different approach to security, but I agree that this issue
can be successfully mitigated.

Dictionary words used for
updating can be unique , and can be verified for consistency, ensuring
business rules are coherent. It'd be easy to limit their use based on user,
security level, etc, just as you would limit use of a data-entry screen.
Mainly, the update AQL could have ensured a level of data integrity via
Dict definitions. Their use would, I imagine, be indirect, via calls from
data-entry collector screens.


Minor comment: DELETE with no ids does nothing, not delete all items in
file. REFORMAT is the killer, since a null entry to file name reformats
into the same file!

DELETE.FILE is another issue. Have you ever intended to remove only a
DICT and ...?

Another comment: Why can't verbs like DELETE, CLEARFILE always have a
confirmation unless being executed from a proc or basic? Wouldn't that be a
clever thing to do?

I don't like that design. You have to be careful with modal logic. I
would prefer the user specify FORCE or something. I also prefer not to
be asked every time if I really want to do something, but sure do like
that UNDO button. Cheers! --dawn

Chandru Murthi

"Excalibur" <excalibur21 (AT) bigpond (DOT) com> wrote in message
news:cORjf.8864$ea6.7649 (AT) news-server (DOT) bigpond.net.au...
Hi Dawn
One of the really greate things about English/AQL/whatever is the fact
that
it cannot update. This allows it to be used safely by even the most
useless
operator.
In fact the worst thing that was ever done to Pick was the introduction of
the DELETE verb, effectively an AQL command. Only a unix revhead could
have
dreamed up this disaster. It races off with nary a check in the world.
If
the user forgot to call his select list then bingo it erases the entire
file. We had an excellent way of deleting items in the ED prestored
command
until somebody added "did you really want to do this" and failed to allow
the question to be overridden by the prestore. I say excellent because
only
people who knew what they were doing could use it.
Imagine if English could update the whole method of programming Pick would
have to be thrown out. Business rules would have to be held at the file
level. Dictionaries would have to be barred from users as they would
become
THE FILE DEFINITION and lose their flexibility etc etc.
Please do not even think about it again.
Regards
Peter McMurray

"Jim" <wildcat66 (AT) hotmail (DOT) com> wrote in message
news:2GQjf.3011$nA2.1657 (AT) newssvr22 (DOT) news.prodigy.net...
With regards to the first part of your question, the orginal 'english'
written by Chandru Murti (Chandru you can correect this if incorrect -
know
you are lurking out there somewhere) - who was with Dick in the original
Microdata days, and according to an orginal 'English 'Binder' English HAd
Update capabilities, but as I remember the story , it did not work well
at
the time and resourses were concentrated on merely the RETREIVAL'
capability - Chandru eventually worked ona project for Ultimate where the
'UPDATE Processor' was originally implemented and later part of Advanced
Pick, and to a certain extent D3 todaye

Oldies may have additional information on this as welkl
"dawn" <dawnwolthuis (AT) gmail (DOT) com> wrote in message
news:1133441835.891237.156050 (AT) z14g2000cwz (DOT) googlegroups.com...
I started to research the history of the MultiValue query language
because I was trying to figure out why it was so much easier to use
than SQL. I was curious why it didn't evolve into an update language.
I was/am looking into the future of data models and related languages
for query and update. When I embarked on this in 2001, I found the
stories behind the technology fascinating. One area I did not delve
into much is the area of lawsuits. There have been a flood of lawsuits
in the MultiValue world. A couple of them are:

Pick vs TRW from whom he, uh, obtained the original code
Pick vs Microdata (Pick married the secretary and former girlfriend of
Don Fuller, the President of Microdata)

and the more recent UniData lawsuits with Pacific UniData, with final
settlements during the acquisition of Informix by IBM IIRC.

I have read bits and pieces about many others such as Pick vs just
about everyone.

Since I was supposedly interested in tracing the movement of the
languages and data model, I didn't take many notes on these. Seeing
how many, uh, *seasoned* professionals there on this list, I thought
I'd ask what lawsuits anyone recalls among Pick and Pick-a-like
vendors. It seems like a history worth recording.

I really have no plans for use of this information -- just curious
right now. What lawsuits does anyone know about or recall? Thanks in
advance. --dawn

Scott, try this sometime when you have a good backup.

SELECT filename WITH *A1 = "YADDA-YADDA"
DELETE filename

I've seen it too many times, on D3, especially since the English
pre-compiler came out in 7.0. Or my personal favorite:

DELETE-FILE USERS "BOB"

TCL was created to mirror JCL from mainframes. Most programmers protect
their users from ever getting to TCL because they know how dangerous a
little knowledge can be.

Mark Brown


"Scott Ballinger" <scott (AT) paretoTIRED-OF-SPAM (DOT) net> wrote

Excalibur wrote:
In fact the worst thing that was ever done to Pick was the introduction
of
the DELETE verb, effectively an AQL command. Only a unix revhead could
have
dreamed up this disaster. It races off with nary a check in the world.
If
the user forgot to call his select list then bingo it erases the entire
file. We had an excellent way of deleting items in the ED prestored
command
until somebody added "did you really want to do this" and failed to allow
the question to be overridden by the prestore. I say excellent because
only
people who knew what they were doing could use it.

pavlovian mode = on
I don't know whether you are joking or not. To say that using an obscure
and poorly documented feature of ED (which is in itself a relic that
unfortunately persists to this day) to replace a command that is
essentially required for *every application ever written* is absurd. Would
DOS or Unix be usable without DEL/rm? I think not. If DELETE didn't
already exist it would be the first program everyone learned to write.
Plus, on what platform does "DELETE MYFILE" do anything but return "[203]
item name?" ? Not R83 > OA > AP > D3, Adds Mentor or MVBASE, UniVerse, or
GA, to my recollection.
/pavlovian

Always willing to snap at the obvious troll,

Ok: (d3 7.4.0 rh9)

:select sb.temp with *a1 = "yada-yada"
[401] no items present.
:delete sb.temp
[203] item name?
:
And what's the deal with confusing DELETE and DELETE-FILE? I agree that
DELETE-FILE could use some "protection," like rm is aliased to "rm -i"
for root in linux.

I seem to recall that Mentor had a command called RECOVER-FD... which worked
from time to time when an item was deleted by mistake! IIRC it relied on the
frame still being in memory with the original (ie undeleted version) still
on disk, which could be read in and the item recovered..

Not sure if this adds to the debate, but it came to mind !

Regards
Simon
"dawn" <dawnwolthuis (AT) gmail (DOT) com> wrote

murthi wrote:
Can't take credit for AQL, sorry.

The original GIM/GIRLS specification contained a comprehensive and
complete
updating specification. Not surprisingly, the AQL verbs were ADD, DELETE
and
CHANGE. It was a precursor of the SQL in its capabilities. This was
implemented by the original Pick group (Pick, Earl, and 2 others whose
names
I forget) at TRW, "inherited" by Pick Systems on the qt (actually it was,
and still is, all in the public domain, courtesy of the US Army since it
was
taxpayer funded).

Somehow I don't think that all software written by any company today
for the US Army or any other government entity is automatically in the
public domain. Software laws have perhaps changed slightly in the past
four decades?


When I joined Pick, the updating facility was the 2nd thing I worked
on.Though meticulously flowcharted and documented by Don Nelson, the
original architect, it was full of problems. You can imagine the
complexity,
as it was designed for full internal join capability down to smv->smv or
any
combination thereof (the infamous original "bridge correlative"). After
working with it for a few months, Dick decided to delay implementation
till
later, a day which never came.

Dawn, anybody: does anyone have any of the original Nelson flowcharts? If
so, I would love to have a copy of one to frame!

Since you brought it up, I'll tell you that I used this as a "quest for
the holy grail" effort a few years ago. I don't have your e-mail in my
current address book, but if you or anyone else wants to know where my
quest took me, shoot me an e-mail to dwolt at tincat-group dot com
before Sunday of this week and I'll let those who e-mail me know the
status on that.


Excalibur's fears about an Update language are unfounded if it's
implemented
properly (after all, you can do this in SQL).

SQL has a different approach to security, but I agree that this issue
can be successfully mitigated.

Dictionary words used for
updating can be unique , and can be verified for consistency, ensuring
business rules are coherent. It'd be easy to limit their use based on
user,
security level, etc, just as you would limit use of a data-entry screen.
Mainly, the update AQL could have ensured a level of data integrity via
Dict definitions. Their use would, I imagine, be indirect, via calls from
data-entry collector screens.


Minor comment: DELETE with no ids does nothing, not delete all items in
file. REFORMAT is the killer, since a null entry to file name reformats
into the same file!

DELETE.FILE is another issue. Have you ever intended to remove only a
DICT and ...?

Another comment: Why can't verbs like DELETE, CLEARFILE always have a
confirmation unless being executed from a proc or basic? Wouldn't that be
a
clever thing to do?

I don't like that design. You have to be careful with modal logic. I
would prefer the user specify FORCE or something. I also prefer not to
be asked every time if I really want to do something, but sure do like
that UNDO button. Cheers! --dawn


Chandru Murthi

"Excalibur" <excalibur21 (AT) bigpond (DOT) com> wrote in message
news:cORjf.8864$ea6.7649 (AT) news-server (DOT) bigpond.net.au...
Hi Dawn
One of the really greate things about English/AQL/whatever is the fact
that
it cannot update. This allows it to be used safely by even the most
useless
operator.
In fact the worst thing that was ever done to Pick was the introduction
of
the DELETE verb, effectively an AQL command. Only a unix revhead could
have
dreamed up this disaster. It races off with nary a check in the world.
If
the user forgot to call his select list then bingo it erases the entire
file. We had an excellent way of deleting items in the ED prestored
command
until somebody added "did you really want to do this" and failed to
allow
the question to be overridden by the prestore. I say excellent because
only
people who knew what they were doing could use it.
Imagine if English could update the whole method of programming Pick
would
have to be thrown out. Business rules would have to be held at the
file
level. Dictionaries would have to be barred from users as they would
become
THE FILE DEFINITION and lose their flexibility etc etc.
Please do not even think about it again.
Regards
Peter McMurray

"Jim" <wildcat66 (AT) hotmail (DOT) com> wrote in message
news:2GQjf.3011$nA2.1657 (AT) newssvr22 (DOT) news.prodigy.net...
With regards to the first part of your question, the orginal 'english'
written by Chandru Murti (Chandru you can correect this if incorrect -
know
you are lurking out there somewhere) - who was with Dick in the
original
Microdata days, and according to an orginal 'English 'Binder' English
HAd
Update capabilities, but as I remember the story , it did not work
well
at
the time and resourses were concentrated on merely the RETREIVAL'
capability - Chandru eventually worked ona project for Ultimate where
the
'UPDATE Processor' was originally implemented and later part of
Advanced
Pick, and to a certain extent D3 todaye

Oldies may have additional information on this as welkl
"dawn" <dawnwolthuis (AT) gmail (DOT) com> wrote in message
news:1133441835.891237.156050 (AT) z14g2000cwz (DOT) googlegroups.com...
I started to research the history of the MultiValue query language
because I was trying to figure out why it was so much easier to use
than SQL. I was curious why it didn't evolve into an update
language.
I was/am looking into the future of data models and related
languages
for query and update. When I embarked on this in 2001, I found the
stories behind the technology fascinating. One area I did not delve
into much is the area of lawsuits. There have been a flood of
lawsuits
in the MultiValue world. A couple of them are:

Pick vs TRW from whom he, uh, obtained the original code
Pick vs Microdata (Pick married the secretary and former girlfriend
of
Don Fuller, the President of Microdata)

and the more recent UniData lawsuits with Pacific UniData, with
final
settlements during the acquisition of Informix by IBM IIRC.

I have read bits and pieces about many others such as Pick vs just
about everyone.

Since I was supposedly interested in tracing the movement of the
languages and data model, I didn't take many notes on these. Seeing
how many, uh, *seasoned* professionals there on this list, I thought
I'd ask what lawsuits anyone recalls among Pick and Pick-a-like
vendors. It seems like a history worth recording.

I really have no plans for use of this information -- just curious
right now. What lawsuits does anyone know about or recall? Thanks
in
advance. --dawn