Re: Design shift of view

Buck Calabro wrote:

> <<snip>>
>
> May I suggest that a broadened viewpoint is valuable in and of itself, and
> that a better class of solutions will come about *without* the absolute
> necessity of a radical change in philosophy.  All too often, people hear
> about a new paradigm, etc., and see such things as the "flavour of the
> month."  Rather than focus on the differences between existing design
> concepts and newer ones, perhaps we should focus on the similarities.  The
> sale would sure be easier...
>

Point taken.  How about "broadened" viewpoint instead of "radical"?  It's not
that much of a step to praise for what has been in the past, then ask where to
next?  Oh, darn, I just got the horse to do what I want and now you want to talk
to me about a car?! ;-)

Unfortunately, it's the differences that must be pointed out to prevent 
"business
as usual" solutions.

One small example:  On the AS/400 I can not change a display file while it is in
use, but I can change a program although any active users continue to use the
older copy.  I'm sure there are a myriad of reasons for this situation, but with
a "broadened" solutions viewpoint a web page can be changed while it is use and
the user automatically receives the new page upon next display.

Now this does require that the browser be set to verify the page upon each
display instead of per session, and does have a negative performance impact, but
it does permit changes during operations and it does introduce the possibility 
of
having dynamic pages (screens) created on the fly.

The point to ponder would be how much logistical resources are consumed in 
timing
the implementation of a modification?  Between shifts? If your shop is 24/7 it
would mean worker down time.  I don't know about the rest of you, but I've been
told by my clients that amounts to about $10k/hr. to have idle staff.  As Rob
pointed out, a real-time enabled environment would make a big difference on the
ability to "deliver" solutions.

Who knows, maybe V5 of OS/400 will not treat display files like physical files
and permit a shift to QRPLOBJ, like programs do, while it's still on a user
screen and upon next display/call the OS will check date/time and bring in the
newer copy automatically.

Now we've all been there, we need a new variable on a screen, x gazillion people
are logged onto the program that uses that screen, they're on the phone to
customers, paying customers, and the big guy does not want disruption of 
business
but he realllly wants the new variable.  What are you going to do? Hang your 
head
or stand proud and declare "Can do!"?

OK, I didn't intend to get into it this deep, but......

DDS is a buffer to variable mapping facility.  Your program receives input from 
a
WORKSTN file which does buffer to variable parsing to your program.  As long as
you do not change the buffer position of a variable (or length which bumps all
others) you do not have a level check and all is good.   But DDS is compiled and
fixed at a point in time.  Now let's say that, from a design viewpoint, you
declared ALL variables as variable length.  If, and it's a big IF, what if DDS
could do variable length input like a <FORM> type text HTML page could do?  How
long is the customer name? Who cares!

Now the purpose of fixed length variables and fixed length records has
(historically) been speed.  That song sold then but hey!, drives are faster now.
Not only that, they're cheaper too!

Till later,
James W. Kilgore
qappdsn@ibm.net



+---
| 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
+---