RE: ILE Conversion

Hans :

I agree with the thrust of what you are saying.  I believe that I have
recovered from my experiences performing this kind of work so I would like
to toss in a few "things to watch out for" and give Mark some things to
think about.

Suppose that we decide to externalize the database interface.

An external database UI can and should have more rigor than that provided by
the underlying database.  This note is not about externalizing the user
interface.  In my opinion, user interfaces have less rigor than databases
and demonstrate a much larger range of creative elements.  I think that it
would be cool if the user interface would support HTML, forms, Java, and
other such cool stuff.

Imagine that your concept is:  Each physical file will have a corresponding
"file server" program.  The file server program will be written in OPM RPG
and will have one subroutine for each logical file.  Each subroutine will
support almost all RPG IO operations for its file - open, close, setll,
reade, chain, read, updat, delet, readp, and so forth.  The file server
"user interface" consists of three parameters: control and status,
operation, and data.  When the chain operation is executed, values are
required to indicate which LF (this defines which key list to use), number
of key fields, and values for the key fields.  "Which LF" is passed in the
"control and status" parameter.  The operation (in this case, chain) and the
number of keys is passed in the "operation" parameter.  The key values are
passed in their field names in the "data" parameter.  The file server
program parses the data in the parameters, assembles the key list, then
executes the chain.  A "success" or "fail" status flag is set in the
"control and status" parameter.  If successful, the data is returned in the
"data" parameter.

Okay, what is wrong with this design?  Lots of things!

Why write the file server in OPM RPG?  Because most of your customers
haven't upgraded to ILE machines and you don't want to force them to - its
bad for business to force customers to do things.

Since the file server program is written in OPM RPG and RPG doesn't support
variables for the file name or record format name, somewhere in the program
you will find every possible combination of key list, physical/logical file
name, and operations code.  If the file has a lot of fields and a lot of
logicals, there will be too many variables to compile using the OPM RPG.  It
is annoying to have one file server program for most files but two in a few
cases.

What is the solution to this problem?  Should you use ILE RPG to avoid the
name space issue?  NO!  A code generator can be created that reads the DSPFD
and DSPFFD information and creates a C program.  The generated C program
will be around 300 lines of code with a corresponding .h file of about (40
plus (number of fields times 1.3)) lines.

Should the operation be expressed as CHAIN, READ, READP, and so forth?  no,
it shouldn't.  These verbs offend the C programmers that come along later
because they think that RPG is a dead language that isn't quite dead enough
because here is the evidence.  Use some non-language-specific words for
operation codes or (maybe best) use ENUMs and let the developers assign
their own words.  You are probably doomed to exposing some RPG semantics
through this interface but try very hard to make them vanish.  It is worth
it.

Using three parameters will be fine but passing the key data in the same
structure that you return the record in is a bad idea.  The caller has to
know how the file server program works to decide what the input arguments
were.  It would be better to avoid parameters that have one meaning before
the call and another meaning after the return.

The format of parameter 3 should not be the same as the physical file
format.  In other words, the user should be able to specify different return
formats for read operations.  On the other hand, only the physical file
format should be supported for write/insert operations.

Before explaining the next issue, I have to create an example.

Imagine that your GL account number structure is composed of a company
master, cost center master, account master, and account detail file.
Suppose that you implement something called cost center security where users
may be excluded from one or more cost centers or allowed access to one or
more cost centers.

Now, here is the issue.

Others on this list have suggested that you should embed the cost center
security logic into your file server program.  I say that is a bad idea.
The file server program described above should do file serving and nothing
else.  You should be able to throw out the existing file server source and
object, regenerate it and the new one should work just like the old one.  If
you can't regenerate the file server program, I think you lose.

How should the cost center security be implemented so that it encapsulates
the cost center file server?  Build the file server, then build the cost
center security module so that it includes the file server.  Do not expose
the file server to the outside world, it is only a component of the security
module.

There are more problems but these are at the top of my list.

In case you hadn't spotted it yet, this is the voice of experience that you
are hearing.  Based on the descriptions, some of you may recognize the
product.

Potential Conclusion

If you externalize your database interface, you can change the database
without having to change the applications.  That is good.  If you build your
applications so that business logic uses the database interface you built,
for the same reason they are also partially protected from database changes.
If you build your applications using frameworks where the framework puts up
screens then calls the business logic you can have a framework for an
interactive app and another framework for a batch app and not have to
rewrite anything.  If you reach that point, you can add support for web
activities and EDI activities very rapidly and with very low cost.

In the previous paragraph please note that your applications are largely
independent of the external user interface and that all of the value in your
solution is in three places: the framework, the business logic, and the
database schema - with most of it in the last two.  That is where it belongs
and, in my opinion, that fact justifies the both direction and the effort to
reach the goal.


Richard Jackson
mailto:richardjackson@richardjackson.net
www.richardjacksonltd.com
Voice: 1 (303) 808-8058
Fax:   1 (303) 663-4325

-----Original Message-----
From: owner-rpg400-l@midrange.com [mailto:owner-rpg400-l@midrange.com]On
Behalf Of boldt@ca.ibm.com
Sent: Tuesday, July 04, 2000 7:13 AM
To: RPG400-L@midrange.com
Subject: Re: ILE Conversion




Mark wrote:
>I have been assigned the task of converting a HUGE monolith of a program
>into more manageable pieces. I have been working with RPG IV now for about
>4 years and have been creating small ILE programs utilizing
sub-procedures,
>service programs, and the rest of that good stuff for about a year. This
is
>the first very large project I will be attempting and I have a few
>questions.
>
>Regarding screen handling: The current program maintains 10 screens in one
>display file. Would it be advantageous to place each display format in
it's
>own display file or to continue to place all of the screens in one display
>file and just maintain each format in it's own module.
>...

Screen handling is a tricky subject.  Like many others here, you too
may someday have to deal with the issue of "web-enabling" your
application.  Web applications have a much different user interface
model than your typical monolithic AS/400 application.  In particular,
web apps are driven by the web server, and not by the application
itself.  If you've done any CICS programming or S/36 MRT programming,
you should be comfortable with web programming concepts.

When restructuring your app, anything dealing with the user interface
should be separated out into separate modules.  The business logic
preferably should be restructured into a set of procedures that can
be called in "batch" mode with no global data within the procedures.

There's more to it than that, obviously, but hopefully you'll start
thinking about UI-logic separation when restructuring your code.

(Note that web-based programming is a major focus for us in the
Toronto Lab, and hopefully in the future you'll see some easier ways
to web-enable your apps.)

Cheers!  Hans

Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com


+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---