Re: Design shift of view -- MIDRANGE-L



Pete Hall wrote:

> Actually, it's not absolutely required. If you create a temporary version of 
>the *DSPF (different name), and compile the program to use it, you can wait 
>until the permanent display is no longer allocated, then compile it and 
>recompile the program with the correct file name. It's a bit of a hassle, but 
>nobody gets kicked off the system and the job does get done...
>

That's what we do also where it fits.  It's a work around.  For a given display 
file we'll have multiple programs using it. (sharing and all that) so we have 
to compile all programs, wait for shift change, change all the programs again, 
recompile, wait for next shift change ... well, you get the picture.

I take it that you are speaking of the majority environment where you compile 
directly into the production library.  This is just a gut feel from looking at 
the statistics of single machine installations and number of unit sales of CMS 
and have concluded that, well I wouldn't be surprised at 70%, of the shops 
compile to live.

The idea of a "shift of view" is to create a clean method that reduces the work 
around busy work that eats talent without producing benefit.  We all live in 
the real world and work arounds have become the norm. Or should I say numb. <g> 
 They're both four letter words!

You can request that all users sign off, then sign back on.  I've asked. Then 
you spend more CPU and man hours copying back the display file to the name it's 
supposed to be, changing all programs, submitting compiles and during this 
whole process no -real- progress in made.  But you get the naming convention 
back to where it's supposed to be. Whew!

There has got to be a better way.

Ok, let's say you're stuck with DDS and straight RPG/400.  When a program 
change is made and that program is in use, it gets moved to QRPLOBJ and the 
user keeps on running it.  What if, during that move, a flag was set.  When the 
user job made it's next resolved call, that flag triggered a new resolution 
like a first call?  It's a start.

Now we can wait for the OS/compiler to do this, or we can design it in.  How 
you ask. When a call is made and it returns without LR on it stays in the PAG.  
This speeds up the next call.  That's a good thing.  What if, just what if, 
that program was made aware of it's replacement?  Could it seton LR and 
initiate a recall?  Of course it can. We're clever little
buggers and we can do this. <g> (Venu, I'm going to twist this whole thing 
around by bringing in data queues as an alternative to CALL/PARM next time out)

Now that works for programs, but not for files of any flavor. Display, physical 
or logical.  I've understood the concept behind the "file" labeling of 
displays.  Programs have I/O to files.  Well they do have I/O to more than just 
files, but files are what appear in the "F" specs.  Now here's a wild idea, a 
new spec type for display files.  Well we can't use "D",
already taken, maybe "P" for panel or maybe "U" for user interface?  That could 
have the QRPLOBJ behavior of a program?

Well let's take a look at the characteristics of a "file". A physical file has 
a single format.   (let's not quibble over the S/36 concession to multi format 
logicals and the format selector that comes along as additional baggage) A 
display file does have multiple formats by design.  A physical contains 
persistent data. A display file contains transient data.  Other
than the arbitrary labeling of "file", physical files and display files don't 
have a lot in common other than they are a buffer to variable mapping 
mechanisms. So why do we have display "files". Well how about looking at a 
display "file" as a collection of data structures. Now don't get me wrong, I 
love the evolution that WORKSTN files have gone through.
Unfortunately the label of "file" has put shackles on an I/O parsing object 
that should be as dynamically replaceable as a program object.  They are both 
transients.

Ok, here's the rub.  Since every new solution creates a new problem, how do you 
sync a change in a display file to trigger a recompile of a program to avoid 
level checks?  How about stop treating files and programs as separate objects.  
If the two have to dance together, why not capitalize on the ability of knowing 
"where used" to trigger an auto sync commit type
wholesale replacement?

Dare I say that display files are not "files", but program components and 
should behave accordingly?   If we can perform an update with commitment 
control to multiple files, why couldn't a compiler perform the same "unit of 
work" commitment control to program components?

Wow! I'll leave this on a note where applications are more capable then the 
tool!  That's a twist! <vbg>

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