RE: Design shift of view -- MIDRANGE-L

This thread has taken an interesting academic twist. Let us all remember
that we work for companies that are in the business to make money
(non/not-for profit excluded). So, yes machines are faster, but still
not fast enough. Imagine presenting to your management that you want to
spend 100K on an AS/400 upgrade and your users won't see any performance
improvement. (AKA, selling V3Rx to a V2Rx company) All the company will
get from this upgrade is the ability to move programs/display/physicals
into production without any downtime. While some managers (very few)
might bite, the rest would laugh you out of the office. Or to put it
another way, how would you like B50 performance from your brand-spanking
new 620?

Now, I don't disagree that display/print files should be changeable with
a RPLOBJ option, just like programs, but to take the concept to the
database is going to far, IMHO. I'd love it, but the machine performance
isn't there yet. And remember, the RPLOBJ option on a program compile is
a happy side effect to the fact that once a name is resolved the program
is called again via its pointer, not via its name. So we tell the
program object that it is in QRPLOBJ now, not PRDPGMS and away we go. We
aren't actually moving the program, but counting on the fact that it
doesn't move.

-Walden

-----Original Message-----
From: James W. Kilgore [mailto:qappdsn@ibm.net]
Sent: Saturday, July 25, 1998 9:37 PM
To: MIDRANGE-L@midrange.com
Subject: Re: Design shift of view




boothm@ibm.net wrote:

> You mean... change the length of the punch card while some of the card
> trays are out of the filing cabinets?  Now there is a scary thought...
>

You're right, it is scary, so was fire! ;-)

Actually, I'm not talking about changing the length of a card, I'm
talking about
designing a program that could accept any size card.

With the introduction of variable length fields we have now (finally)
acheived
variable length cards.  But even at that we have a fixed number of
variables.
How do we acheive a variable number of variables?

Even allowing for null values for ommited entries we have a "fixed"
number of
pigeon holes.  This is where we (IS staff) spend time and talent to
implement
instead of solve. Also, the enterprise faces the possibility of
information flow
shut down during implementation. (regen a data base)

Have you ever noticed that in the program feedback area is a value for
number of
parameters?  Why is that there?  To remind you that you have x number of
parameters, or is it because there can be a variable number?  Well, if
we can
pass a variable number of parameters to a program, why couldn't a RDMS
pass a
variable number of variables?  If we can have a variable number if
variables, we
eliminate the "fixed" unit record (card) mentality of disk storage.  And
if the
RDMS can't handle it, how do we "design" it?

Scary! ;-)

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---