RE: Design shift of view

On Wednesday, July 22, 1998 9:47 PM, James W. Kilgore 
[SMTP:qappdsn@ibm.net] 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?! ;-)

That's exactly the kind of opposition I see.  Besides, I have all these 
horseshoes...

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

That's quite right, too.

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

Rather than delve into the details behind this restriction, let's run with 
your broadened viewpoint.  You're exactly right that a DSPF is a major 
hassle when you need to send a new version into production.

-snip about the cost of quiescing production to promote a new version-

The current mind-set doesn't take into account the costs involved with 
promoting 24x7 applications into production (i.e. if I want to promote a 
DSPF to production, I have to kick the production users out of it.)  There 
was no conscious decision made to look at alternatives to display files; 
rather, we simply live within the restrictions because "we've always done 
it that way."  But there *are* alternatives to using DDS for "fixed 
format" display files and there always have been.  You pointed out one way 
to dynamically build screens: HTML/Java.  One can also write user defined 
datastreams on the fly.  One can use dynamic screen manager APIs as well 
as UIM.  Any of these takes more work to use than DDS, but that's not the 
point; they were never *considered* for the job.  When the ability to 
promote over currently executing software is paramount, it pays to keep an 
open mind...

It's a trait of many programmers that the minutiae of the problem absorb 
us more than the "big picture."  That's how debates over Z-ADD vs. MOVEL 
remain with us from one generation to the next.  It's that trait that 
keeps us "in the box."

Here's an interesting practical question: Does anybody here have to get 
their work formally signed off against a list of criteria that define the 
"acceptability" of the software?  Things like built-in error recovery 
after a disk crash (OK, water damage!), auditing (legal), performance (n 
transactions/minute), maintainability (ability to make changes without 
breaking something else), documentation (user and system), flexibility 
(modularity), ease of installation, etc.  I don't.  I do the best I can, 
but I certainly don't have any hard targets to try to hit.

Buck Calabro
Commsoft, Albany, NY
mailto:mcalabro@commsoft.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
+---