MV community lawsuits

I'm not too proud to admit my mistakes...

You're right and I was wrong.

Mark

"Scott Ballinger" <scott.ballinger (AT) gmail (DOT) com> wrote

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.

Hi
It just shows how careful I am! They have fixed the DELETE foul up in
current versions of D3. My remarks were based on an inexperienced installer
following foolish instructions from an inexperienced supervisor and he
definitely managed to crucify a major file on several occasions.

I am baffled that anyone has trouble with prestored commands in ED as I have
always found them to be great. I am sure they were documented when I learnt
them. There again that was Reality 2.4d documentation 1976 which was quite
good, although I have never discovered an example of dependent attributes.
I do know defining one can cause chaos in the retrieval language so I have
avoided them like the plague.

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

I'm not too proud to admit my mistakes...

You're right and I was wrong.

Mark

"Scott Ballinger" <scott.ballinger (AT) gmail (DOT) com> wrote in message
news:1133554809.712623.125740 (AT) z14g2000cwz (DOT) googlegroups.com...
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.

Hi
RECOVER-FD was present in the earliest versions of Pick on Microdata
Reality. However with 32k of core,9k of which was used by the operating
system, the very act of breathing was probably sufficient to overwrite it. I
do remember the support chappie at AWA Melbourne (Basil I think) furiously
typing it in an advanced state of hyperventilation>
Peter McMurray
"Simon Verona" <nomail (AT) nomail (DOT) zzz> wrote

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 in message
news:1133541189.732904.313980 (AT) g43g2000cwa (DOT) googlegroups.com...

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

The amount of core/main memory had nothing to do with how long recover-fd
was available. As long as you didn't do anything subsequent to the FD, you
could be certain to recover the item. It would have been available in your
process workspace in virtual memory. And you could still do _some_ other
commands and be _pretty_ sure about recovering it.

It always felt like an adventure though... :-)

Ed

"Peter McMurray" <excalibur21 (AT) bigpond (DOT) com> wrote

Hi
RECOVER-FD was present in the earliest versions of Pick on Microdata
Reality. However with 32k of core,9k of which was used by the operating
system, the very act of breathing was probably sufficient to overwrite it.
I do remember the support chappie at AWA Melbourne (Basil I think)
furiously typing it in an advanced state of hyperventilation
Peter McMurray
"Simon Verona" <nomail (AT) nomail (DOT) zzz> wrote in message
news:4390b17d$0$18539$ed2619ec (AT) ptn-nntp-reader02 (DOT) plus.net...
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 in message
news:1133541189.732904.313980 (AT) g43g2000cwa (DOT) googlegroups.com...

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

Ultimate comes from your neck of the woods, right? Did you follow any
of those court cases? Was the mob involved? (Those are the type of
politically-incorrect questions this mid-westerner has).

Cheers! --dawn

Joisey isn't all about Tony Soprano, however...

Speaking (in another thread) of legal issues in Pick history, Ted Sabarese
was a colorful player.
Anyone with a story about Ted?

I found this link:
http://vls.law.vill.edu/locator/3d/Nov1995/95a1211p.txt

"Jeff Caspari" <FDFDFDFD (AT) sneakernet (DOT) com.invalid> wrote in
news:0pjkf.6015$a%.4841@trnddc05:

Ultimate comes from your neck of the woods, right? Did you follow
any of those court cases? Was the mob involved? (Those are the
type of politically-incorrect questions this mid-westerner has).

Cheers! --dawn

Joisey isn't all about Tony Soprano, however...
Speaking (in another thread) of legal issues in Pick history, Ted
Sabarese was a colorful player.
Anyone with a story about Ted?

I found this link:
http://vls.law.vill.edu/locator/3d/Nov1995/95a1211p.txt

No story per se, but I remember when I started working for Ultimate
years ago, the orientation included a tour of the building. The thing
I remember most was that Ted had his fish mounted all over the place.
In the hardware assembly room alone there were probably a dozen
sailfish and other varieties. He was quite the sportsman.

Regards,
Joe

Ed Sheehan wrote:

It always felt like an adventure though... :-)

The equivalent these days in windows would be recovering something from
the recycle bin - and just like plane travel, some of the thrill &
adventure has been lost

Simon Verona wrote:

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 in memory, per se, but in the user's virtual memory buffers. So
executing just about any command in between the FD and the RECOVER-FD
made it unrecoverable. It also didn't work if you were working in a PROC.

Luke

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

Regards
Simon
"dawn" <dawnwolthuis (AT) gmail (DOT) com> wrote in message
news:1133541189.732904.313980 (AT) g43g2000cwa (DOT) googlegroups.com...

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

Peter McMurray wrote:

Hi
RECOVER-FD was present in the earliest versions of Pick on Microdata
Reality. However with 32k of core,9k of which was used by the operating
system, the very act of breathing was probably sufficient to overwrite it. I
do remember the support chappie at AWA Melbourne (Basil I think) furiously
typing it in an advanced state of hyperventilation

The size of physical memory wasn't a problem, but yes, you're right.

Anybody ever think how stupid it was that FD and FS are only one key
away from each other on the keyboard?

Luke

On Mon, 05 Dec 2005 08:32:48 +1100, Luke Webber <luke (AT) webber (DOT) com.au>
wrote:

Peter McMurray wrote:
Hi
RECOVER-FD was present in the earliest versions of Pick on Microdata
Reality. However with 32k of core,9k of which was used by the operating
system, the very act of breathing was probably sufficient to overwrite it. I
do remember the support chappie at AWA Melbourne (Basil I think) furiously
typing it in an advanced state of hyperventilation

The size of physical memory wasn't a problem, but yes, you're right.

Anybody ever think how stupid it was that FD and FS are only one key
away from each other on the keyboard?

Yes. Emphatically. It was 2:35pm on Monday, 28th June, 1982.....at
121 High Street, Prahran, Melbourne..... on the first floor... and I
was wearing a charcoal suit with a pale blue shirt and black brogues.
After a luncheon at the Railway Hotel...

Luke
Regards,

Bruce Nichol
Talon Computer Services
ALBURY NSW Australia

http://www.taloncs.com.au

If it ain't broke, fix it until it is....