Re: Design shift of view

James,

If you make the assumption for some reason that DDS is required for displays 
you have just locked yourself out of many potential solutions.  If what you 
need is 24/7 availability, you should start out making it a requirement that 
any application be able to be resettable.  We are not a 24/7 shop but we do 
like to reduce the time it takes to move something to production.  It is also 
possible, and I would recommend, creating a layer between your files and 
applications.  In this delegation layer you can do the required mapping to 
support a more flexible design.  As I mentioned before, support for variable 
data types is the thing that is lacking.  Passing pointers is OK, but it means 
you cannot verify that what you received matches your expectation.  This 
imposes a burden on the application that is not necessary.  I doubt that the 
compiler developer could create this delegation layer, just look at SQL.

We have found the dynamic screen APIs allow us to change a display when the 
program is active.  If you allow the display to changes while someone is in an 
application you do have to check the current attributes against the stored 
attributes.  If they change you have to re-allocate storage for the new 
attributes.  The overhead is negligible.

Changing your underlying database while a program is active is also possible.  
We did not go that far.  In our case the benefit did not justify the overhead.  
To do this you could monitor for a change to the definition and if one 
occurred, disconnect the data sever (close the files), recreate the file, 
rebuild the data, reallocate storage for the new definition, recreate the 
server, reconnect to the server, and continue.  If the time to rebuild the data 
is a problem you could create a new database while using the old and connect to 
a new server when the conversion is complete.

David Morris

>>> "James W. Kilgore" <qappdsn@ibm.net> 07/24 3:52 AM >>>

... Stuff cut out

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