Old Debate, New Day - MVDB vs. Other DBs

#31

Mark Brown wrote:

Quote:

"frosty" <frostyj (AT) bogus (DOT) tld> wrote in message
ISTC X'C0' means stop at SM. The uppermost bit says "match"
or "no match." Geez, I heard Howie Mandel's voice when I
wrote that. =`8^0 And weren't they SC0, SC1 and SC2?

Jeeze,

Just how much detail do they need, anyway? Dick's probably rolling over in
his grave that I gave away THAT much!!

Ah well, I must admit that I tend to agree that that stuff needed to be
kept /somewhat restricted. It didn't sit well with me when, for example,
I discovered that a seriously mentally ill client of mine flourished his
assembler manual, legally purchased from our parent company, Ultimate
Corp. OTOH, I always hated being told by my previous employer that that
stuff was company proprietary, and I had no need to know. The hell with
that. <g>

Luke

#32

Quote:

frosty wrote:

ISTC X'C0' means stop at SM. The uppermost bit says "match"
or "no match." Geez, I heard Howie Mandel's voice when I
wrote that. =`8^0 And weren't they SC0, SC1 and SC2?

Mark Brown wrote:

Quote:

Jeeze,

Just how much detail do they need, anyway? Dick's probably rolling over
in his grave that I gave away THAT much!!

Ooops, sorry... didn't want to give away too much about the
PVA architecture, which, incidentally, was a "Virtuous Memory"
system which used drum, not core, by way of 13 Virtuous Registers,
R17--R29, with R17 pointing to the "Control Protocol Block,"
or CPB, and had a large number of twine-handling instructions,
such as MBBD, "Move Bumping Bumping to Delimiter," which could
copy a twine of any length from one part of drum to another,
crossing cell boundaries. =`:^> Yeah, that's the ticket.

--
frosty

#33

Might I be permitted to leap in here at this late stage and offer:

On Sun, 16 Jul 2006 20:48:23 -0700, Tony Gravagno
<g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote:

Quote:

Dawn, I think what he's saying is that the MV DBMS is hailed proudly
for its support of values and subvalues but none of the MV
implementations seem to regard values or subvalues as first class data
elements. We define values in Dict definitions using awkward syntax,
controlling and dependent relationships are defined just as awkwardly,
and using BY-EXP doesn't always work the way one would hope or expect
without playing some games. Subvalues, if they can be defined at all,
aren't even recognized in the AQL process of most MV platforms.

A short note from Ladybridge regarding OpenQM, QMQuery and SVMs:

My question to Martin regarding QMQuery and SVM's:

" Simply, the ability to SORT BY.EXP on subvalues and report,
via QMQuery, with BREAK.ONs etc applying to subvalues
equally as it applies to values - the next higher level......"

And his (almost immediate) reply:

"Forgive me if I'm wrong, but I think this already works. Would you
like to check and let me know if you disagree?"

Quote:

I'd say, maybe in agreement with the OP, that this could be an
embarrassing sore spot, that the MV DBMS doesn't truly support MV.

Except for .......... ???? <grin>

Quote:

(Yes I'm taking a broad brush to the matter as some SQL-biased person
might). Using BASIC, we do have full control over the entire
environment. Unfortunately, since that original effort by Ken Simms,
MV BASIC really hasn't progressed much at all - outside of uniqueness
in ARev/OI BASIC+ and now with QM.

Undoubtedly people are going to respond "but PlatformX does support
_blank_ ...the BASIC in PlatformX has evolved... ProductX makes using
values and subvalues as easy as attributes...".

Tony, evidently, not only the "BASIC".....,

Quote:

There are many
anecdotes to show that values or subvalues are supported to varying
extents in product-specific ways, but I'll still maintain that the MV
DBMS model in general still only supports a few dimensions - and
questionably.

Methinks, mehopes, the world has changed..... for the better, at
least in this instance....

Regards,

Bruce Nichol
Talon Computer Services
ALBURY NSW Australia

http://www.taloncs.com.au

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

#34

IBM was the first with the concept of nested values and that was before
computers. The first punched card of a group - called group indicate if you
printed from it - had the top level. The subsequent cards were unpunched in
the fields that were not to be summed with the lower values - unit price,
for instance. The date shipped might be the next level with the batch or
serial number, quantity and price at the third level. Just as with mv and
sv, the levels got very difficult to keep track of when they went deeper
than three but sometimes it was needed. The reproducer ganged the upper
levels into the cards usually with one pass for each level with the lower
cards having been merged into the deck with a collator. Finally, a
tabulator - 405 or 402 or newer - was used to print the report with proper
totals. Sometimes there were multiple passes through a calculator/gang
punch in order to get percentages on the total lines. Full circle?
Just idle memories. Since that was more than fifty years ago the memories
may not be correct in detail. But there are some young whipper snappers on
this group who remember some of that.
BobJ
"Bruce Nichol" <reverse_ecurb (AT) taloncs (DOT) com.au> wrote

Quote:

Might I be permitted to leap in here at this late stage and offer:

On Sun, 16 Jul 2006 20:48:23 -0700, Tony Gravagno
g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote:

Dawn, I think what he's saying is that the MV DBMS is hailed proudly
for its support of values and subvalues but none of the MV
implementations seem to regard values or subvalues as first class data
elements. We define values in Dict definitions using awkward syntax,
controlling and dependent relationships are defined just as awkwardly,
and using BY-EXP doesn't always work the way one would hope or expect
without playing some games. Subvalues, if they can be defined at all,
aren't even recognized in the AQL process of most MV platforms.

A short note from Ladybridge regarding OpenQM, QMQuery and SVMs:

My question to Martin regarding QMQuery and SVM's:

" Simply, the ability to SORT BY.EXP on subvalues and report,
via QMQuery, with BREAK.ONs etc applying to subvalues
equally as it applies to values - the next higher level......"

And his (almost immediate) reply:

"Forgive me if I'm wrong, but I think this already works. Would you
like to check and let me know if you disagree?"

I'd say, maybe in agreement with the OP, that this could be an
embarrassing sore spot, that the MV DBMS doesn't truly support MV.

Except for .......... ???? <grin

(Yes I'm taking a broad brush to the matter as some SQL-biased person
might). Using BASIC, we do have full control over the entire
environment. Unfortunately, since that original effort by Ken Simms,
MV BASIC really hasn't progressed much at all - outside of uniqueness
in ARev/OI BASIC+ and now with QM.

Undoubtedly people are going to respond "but PlatformX does support
_blank_ ...the BASIC in PlatformX has evolved... ProductX makes using
values and subvalues as easy as attributes...".

Tony, evidently, not only the "BASIC".....,

There are many
anecdotes to show that values or subvalues are supported to varying
extents in product-specific ways, but I'll still maintain that the MV
DBMS model in general still only supports a few dimensions - and
questionably.

Methinks, mehopes, the world has changed..... for the better, at
least in this instance....

Regards,

Bruce Nichol
Talon Computer Services
ALBURY NSW Australia

http://www.taloncs.com.au

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

#35

Hi
Wasn't if FUN when you dropped the deck? As for one mispunch in the middle
of a program deck! Now that did take some finding.
Peter McMurray
"BobJ" <bob (AT) wildblue (DOT) net> wrote

Quote:

IBM was the first with the concept of nested values and that was before
computers. The first punched card of a group - called group indicate if
you
printed from it - had the top level. The subsequent cards were unpunched
in
the fields that were not to be summed with the lower values - unit price,
for instance. The date shipped might be the next level with the batch or
serial number, quantity and price at the third level. Just as with mv and
sv, the levels got very difficult to keep track of when they went deeper
than three but sometimes it was needed. The reproducer ganged the upper
levels into the cards usually with one pass for each level with the lower
cards having been merged into the deck with a collator. Finally, a
tabulator - 405 or 402 or newer - was used to print the report with proper
totals. Sometimes there were multiple passes through a calculator/gang
punch in order to get percentages on the total lines. Full circle?
Just idle memories. Since that was more than fifty years ago the memories
may not be correct in detail. But there are some young whipper snappers on
this group who remember some of that.
BobJ
"Bruce Nichol" <reverse_ecurb (AT) taloncs (DOT) com.au> wrote in message
news:0doqb2l5pbo2icilue195otpejje19cci0 (AT) 4ax (DOT) com...
Might I be permitted to leap in here at this late stage and offer:

On Sun, 16 Jul 2006 20:48:23 -0700, Tony Gravagno
g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote:

Dawn, I think what he's saying is that the MV DBMS is hailed proudly
for its support of values and subvalues but none of the MV
implementations seem to regard values or subvalues as first class data
elements. We define values in Dict definitions using awkward syntax,
controlling and dependent relationships are defined just as awkwardly,
and using BY-EXP doesn't always work the way one would hope or expect
without playing some games. Subvalues, if they can be defined at all,
aren't even recognized in the AQL process of most MV platforms.

A short note from Ladybridge regarding OpenQM, QMQuery and SVMs:

My question to Martin regarding QMQuery and SVM's:

" Simply, the ability to SORT BY.EXP on subvalues and report,
via QMQuery, with BREAK.ONs etc applying to subvalues
equally as it applies to values - the next higher level......"

And his (almost immediate) reply:

"Forgive me if I'm wrong, but I think this already works. Would you
like to check and let me know if you disagree?"

I'd say, maybe in agreement with the OP, that this could be an
embarrassing sore spot, that the MV DBMS doesn't truly support MV.

Except for .......... ???? <grin

(Yes I'm taking a broad brush to the matter as some SQL-biased person
might). Using BASIC, we do have full control over the entire
environment. Unfortunately, since that original effort by Ken Simms,
MV BASIC really hasn't progressed much at all - outside of uniqueness
in ARev/OI BASIC+ and now with QM.

Undoubtedly people are going to respond "but PlatformX does support
_blank_ ...the BASIC in PlatformX has evolved... ProductX makes using
values and subvalues as easy as attributes...".

Tony, evidently, not only the "BASIC".....,

There are many
anecdotes to show that values or subvalues are supported to varying
extents in product-specific ways, but I'll still maintain that the MV
DBMS model in general still only supports a few dimensions - and
questionably.

Methinks, mehopes, the world has changed..... for the better, at
least in this instance....

Regards,

Bruce Nichol
Talon Computer Services
ALBURY NSW Australia

http://www.taloncs.com.au

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

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Old Debate, New Day - MVDB vs. Other DBs

comp.databases.pick comp.databases.pick

Re: Old Debate, New Day - MVDB vs. Other DBs - 07-17-2006 , 08:16 PM

Re: Old Debate, New Day - MVDB vs. Other DBs - 07-18-2006 , 11:32 AM

Re: Old Debate, New Day - MVDB vs. Other DBs - 07-18-2006 , 05:45 PM

Re: Old Debate, New Day - MVDB vs. Other DBs - 07-18-2006 , 07:22 PM

Re: Old Debate, New Day - MVDB vs. Other DBs - 07-19-2006 , 05:53 PM