RE: ILE Conversion

Richard et al,

For some strange reason, I seem to recognise the product to which you are
referring.

DISCLAIMER: I work on the development team for said product.

It does work in a similar way to that which you describe. You can get away
with adding fields and deleting fields in the middle of the format, and even
changing some characteristics of existing fields with only regenerating and
recompiling the "file server" program. The application programs, unless
directly affected will not need recompiling. The application programs
request fields from the "file server" program by name, type, length and
decimals as at the point in time that the application program was compiled.
If the field no longer exists then it does not attempt to get it. If the
field characteristics have changed then an attempt is made to map the field
from its "new" characteristics to its "old" characteristics.

On the AS/400 the "file server" program is generated in RPG.

I could go on.  

HTH,

Kevin Wright.


> -----Original Message-----
> From: Richard Jackson [mailto:richardjackson@richardjackson.net]
> Sent: Wednesday, 5 July 2000 1:56
> To: RPG400-L@midrange.com
> Subject: 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
> +---
> 
+---
| 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
+---