Re: Making a program dynamic -- JAVA400-L

>I would like to try and make this
>program more dynamic to eliminate
>this need. Can this be done either
>via RPG or Java?

I assume here you actually want to automatically generate, compile, and run
useful code from some sort of template you generate.

Can you do a three step process:

1.  First, post-process some sort of file description for the new file (the
DSPFFD type description, fetchable for data base files (SQL Tables) under
JDBC meta data -- or, the equivalent spool file type information fetched
via some sort of system API I suppose or maybe Toolbox function -- I'm not
100 per cent sure what you need).  This would be dumped into some sort of
input file for step 2.  It would probably be in IFS and you'd arrange for
it to be trivial to parse (e.g. your fields separated by tabs, fixed
fields, or some such).

2.  Then you would have what is nowadays often called a "wizard" which
would produce a new subclass (in Java source code) of a generic class it
extends, based on the stylized input from step 1.  You would have to write
the wizard -- in fact, it would be most of the effort.  You would write the
wizard itself and, within it, the generic version of your application that
it knows how to generate and customize.

3.  You would now invoke "javac" (this can be done under the control of an
actual ordinary Java class IIRC, though I haven't had to do it -- JSP has
to do something like this) to produce the new, dynamically generated class
from your source code and then execute it.  If you can't invoke javac this
way, you can use the Toolbox classes to generate it some other way.

I'm assuming in all this that the task itself is fairly nominal, but needs
lots of on-the-fly, field level customization.  Or, conversely, if there is
complexity, the complexity is fairly generic, but needs to account here and
there for slightly different fields and data types that some subclassing
would reflect back to more generic code one way or another (either in a
parent class through virtual function calls supplied in the child or by
simply generating a slightly different version of the code in the child
class).

In terms of Java versus RPG (if you really need this much dynamism), I'm
all for Java as the final, target language as described above.  For one
thing, a common Java base class can contain all kinds of useful items and
you may need more than one of these in some useful hierarchy so that your
dynamic class can usefully inherit from different generic classes.  You do
talk about "very different" and I'm assuming this represents different
versions of even the generic code.

Now, if the process is a little less dynamic than this, than a more
ordinary "wizard" approach would work and step 3 would be an ordinary javac
as per normal, but turning your spool file info into some sort of pre-input
that is used to generate Java source that does all or 90 per cent of what
you want to do.  You can add a little bit of code by hand to finish the job
and lower the cost and complexity of your "wizard."  This I have recently
done in my most recent internal JDBC-based utility.  It is reasonable
enough to do, especially if the application is very well understood and any
by-hand customization well isolated.  If it is less dynamic still, then RPG
as a target for-the-wizard language becomes more and more plausible,
because an object hierarchy is less and less important.  I would still
favor writing the wizard itself (and the code for step 1) in Java.



Larry W. Loen  -   Senior Linux, Java, and iSeries Performance Analyst
                          Dept HP4, Rochester MN