Re: Design shift of view

James,

In a message dated 98-07-22 22:32:13 EDT, you write:

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

Amen to _THAT_!

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

As long as that "older copy" isn't an in-house API that performs a RETRN
rather than setting on *INLR ;-)!

<<snip>>

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

_EXCELLENT_ point!  Our only down time is an eight hour window on Sunday.
Even with a CMS installed, the calibre of people running forms on Sunday is
suspect at best.  When a problem comes up (say, someone came in and was using
the program in Production when they shouldn't have been, thus having the
display file locked) the weekend folks (when they call at all) usually don't
call until it's going to be another week before the form can be promoted.
Taking our plant off-line for mission-critical applications is _CONSIDERABLY
MORE_ than $10K per hour -- most shop floor reporting happens through over 100
terminals and touch screens via a mere _TWO_ programs.  Change either of the
latter, and you've got a mess on your hands (especially if the change ends up
needing to be backed out).  We've tried for as long as _FOUR WEEKS_ to get a
change into Production on our shop floor transaction processing programs --
meanwhile paying someone _big_ bucks and taking _big_ chances with data damage
to manually fix the problems caused by the malfunctioning program...

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

Yeah, they've _HAD_ this with menus since at least V2R3, except that it
doesn't go far enough.  I usually get elected to change the menu that we all
sign on to because I nearly always work late.  Once everyone else is signed
off, I hit the F-Key to go to the AS/400 main menu and can compile the initial
menu with impunity -- even though a simple <F12> will send me back to the
newly-modified menu.  Why can't this work with _ALL_ display files, without
having to go somewhere else?

>  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!"?

Today, hang your head...

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

Errrrrrr!  I'd declare SOAPBOX MODE(*ON) here, but I've already been there!
DDS for DSPF's remains what it was back when IBM machines first got two-digit
system designations -- a "graphical" (HA!) representation of punched cards.
Much like the 5250 data stream, DSPF structure should have been re-written for
the /400 -- I've never seen either an MFCU _OR_ a 5250 actually _SOLD_ with a
new AS/400.  The only buffers I want are "BUFFERINs" when I start thinking
about why this ancient DDS technology was grafted into an otherwise forward-
thinking system.

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

Amen, again!

Dean Asmussen
Enterprise Systems Consulting, Inc.
Fuquay-Varina, NC  USA
E-Mail:  DAsmussen@aol.com

"A lot is two words.  ALOT is _NOT_ a word at all." -- My 10th Grade English
Teacher
+---
| 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
+---