RE: Making a program dynamic

Okay, so lets take this through one spool file. Please correct anything I
have wrong.

I have spool file information and based on the spool file name (?) I grab
the correct set of routines for that spool file. I read the file and see I
have to run the GENIFSNAME routine. I run the routine and pass the filename
back. Now I read the file and see I execute CNVPDF. I run that routine and
return to the program. On and on...

How do I execute those routines?
How do I create them?


-----Original Message-----
From: Joe Pluta [mailto:joepluta@PlutaBrothers.com]
Sent: Monday, April 01, 2002 6:53 PM
To: rpg400-l@midrange.com
Subject: RE: Making a program dynamic


> From: Wills, Mike N. (TC)
>
> I am looking at ways to make a program more dynamic. I have a program that
> will monitor outqs for spool files through a dataq and kick off a
> processing
> program. The processing program then runs hard-coded processes
> based on the
> spool file information. Several processes could be the same or
> similar, but
> they could also be very different. So every time I need to add
> another spool
> file, I need to modify this program, recompile and test it. I
> would like to
> try and make this program more dynamic to eliminate this need. Can this be
> done either via RPG or Java?

You're asking a very broad question here, Mike, but the answer is yes, and
not only that, you can most everything in RPG.

The idea is to build your own "step" processor.  What this does is
automatically run an object (such as a spool file) through a series of
steps.  These different work entities take on different names depending on
who is designing the system, but one good set of names is Job, Task, and
Activity.

A Job is a number of Tasks.  Each Task is a number of Activities.  You have
a hierarchy like this:

The Job file has an ID and a description.
The Task file has an ID and a description.
The Activity file has an ID, a description, and a program to call.

There is cross-reference file that consists of a parent, a child, a sequence
and a relationship code.  For example, let's say a job is made up of three
tasks.  The XREF file might look like this:

PARENT    TYPE  SEQ  CHILD
FTPJOB    JT    1    PREPARE
FTPJOB    JT    2    CNVPDF
FTPJOB    JT    3    FTPLIST

Now we cross-reference the tasks to their activities.  The GENIFSNAME
activity is a generic activity that takes the spooled file name and creates
a temporary IFS file name.  CNVPDF converts a file to PDF.  FPTLIST is a
little more complex - it builds a list of recipients, then invokes the FTP
send activity, and fnially, when all is said and done, sends a completion
message.

PREPARE   TA    1    GENIFSNAME

CNVPDF    TA    1    CNVPDF

FTPLIST   TA    1    BLDFTPLIST
FTPLIST   TA    2    FTP
FTPLIST   TA    3    COMPLETION

Finally, the master records:

JOB1       Send spooled file as PDF

GENIFSNAME Generate an IFS name
CNVPDF     Convert file as needed

PREPARE    Prepare Spool File          PRP001
CNVPDF     Convert Spool File to PDF   CPYSPLFPDF
BLDFTPLIST Build list of recipients    FTP001
FTP        Send file to recipient(s)   FTP002
COMPLETION Utility step - completion   UTLMSG01


I know this is a lot in one small email, but the idea is that you can easily
design and build the small modules, then plug them into your tzask processor
as you need them.  Some are generic, and can be used over and over, while
some are specific to a single task.

You'll need to set up a common data structure that you'll use to pass the
parameter around from task to task.  You can use a data structure, or the
LDA, or a user space, or a data area in QTEMP, whatever you're comfortable
with.  For example, the spooled file information would always be in once
spot, and the IFS file name would always be in one spot.  If things get
really complex, I usually have a little common module I call that I can use
to set and retrieve parameters throughout the life of the job.  It stores
them in an array or a file; it's irrelevant to the caller.

My point is that you can do something like this.  It takes a bit of upfront
work - probably a week or so to get all the pieces just the way you want
them.  But once you've done it, it's a wonderfully extensible design that
can then be expanded for not only your original needs, but for whatever
sorts of batch processing jobs you might have in the future.

Joe

_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
or email: RPG400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.