Re: Design shift of view

Buck,

A while back many request were made of the RPGIV developers that read this list 
to add features like EXIT subroutine and LIKE(File(field).  Those features 
would certainly reduce the time to develop a traditional application.  They do 
not enable a new class of application.

The RPGIV enhancement that has helped us move toward  a new class of 
applications is the much maligned pointer.  At this point the I think RPGIV 
supports components fairly well.  The next area that needs to be addressed is 
delegation.  This is very difficult in RPGIV without support for parameterized 
types.  Many would argue that is best left to interpreted languages.  I don't 
agree.  Another area that might help would be built in support for inheritance. 
 To me this is not nearly as useful and makes an application less adaptable, 
but should be supported.

I will probably be criticized for asking for these enhancements when they are 
available in JAVA or C++.  The only problem is that JAVA is not here yet, and 
C++ looks like the odd man out.  We also have spent two years building an 
application framework using RPGIV.  Even if we moved to JAVA today, the bulk of 
our applications could still benefit from these enhancements.

Another area that would help us would be the ability to create our own class of 
objects.  We maintain a repository that describes our database and 
applications.  Much of our information is a duplicate of what the system 
stores.  Even if we had to supply exit point programs, etc. to support those 
new objects, it would probably be worth it.

>>> Buck Calabro <mcalabro@commsoft.net> 07/23 9:08 AM >>>

... stuff cut out

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

You can't start out saying we want nirvana, but it has to encompass our 
existing systems.  You need a clean break.  Define your objectives.  Once you 
have your objectives defined, design a framework that supports that design.  If 
support for existing objects is required, include bridges in your framework 
that support the old interfaces.  This is an iterative process.  One of 
objectives was that file changes must not require compiling more than one 
object.  That ruled out DDS for display files.

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

You make a good points.  We seem to like to argue that which we know.  There is 
a risk involved when you discuss a subject that you do not completely 
understand.    Many people are afraid to go out on that limb.

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

We have a checklist of that includes many of those criteria.  Our checklist 
lumps several of your criteria under program standards compliance.  This is was 
difficult to enforce so we ended up creating a program to try to measure 
compliance.  Things like no code block over 50 lines, proper use of mnemonic 
names.

As far as documentation, we build our systems from a single repository that 
defines all of our application components.  These include system objects, 
source, help HTML, file relationships, fields, edits, messages, 
program/procedure/module relationships, etc.  We use this information to create 
and define our application.  No definition - no application.  The repository 
supports creation of any object and will check out or move those objects to 
production.

>Buck Calabro
>Commsoft, Albany, NY
>mailto:mcalabro@commsoft.net 

David Morris

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