Re: Design shift of view

David Morris wrote:

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

David,

That's my point entirely.  To stay with DDS means some work arounds.  Get away 
from DDS and "cleaner" solutions become possible.  That's my first vote.

You are correct in that the solution lies in separating what you want from how 
it gets done.  As I mentioned in replacing the CHAIN opcode, the programmers 
objective is to retrieve or send populated variables.  Even now, we do this 
without needing to concern ourselves with how the OS does a READ/WRITE to the 
underlying layer.

As in your case, you solved the limitations ... by design.  At that gets to the 
heart of this whole thread ..... doing it by design.

OK, here's another work around solution for DDS users that does not require you 
to have your users sign off/on or modify their library list:

Since a WORKSTN file can have a data queue attached to it,  after you have 
created the new display file and recompiled all programs involved, send a 
message to that data queue which instructs the program to shut down and call 
it's replacement.

This would happen without the user being aware of it.  Changes happen, design 
it in to handle it.

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