RE: Making a program dynamic

First, decide how you are going to pass parameters.  In your case, I think a
simple data structure might be enough.  Create an externally described data
structure with the right fields:

R SPLPARMS
  SPJOB         10
  SPUSER        10
  SPJNBR         6
  SPNAME        10
  SPSNBR         6
  SPIFS        128

Okay, now you have a parm that you can pass.  Your initial program fills in
the first five fields, then calls the driver program.  It passes in two
parameters, the job ID (FTPJOB) and the spool parameters.  The driver
program then uses the job ID to run through the cross-reference file,
calling each program and passing it the spool parameter data structure.  The
job of each called program is to either fill in another parameter, or do
some work.  GENIFSNAME, for instance, would look at the SPLPARMS and format
the IFS name, and then fill in the SPIFS parameter.  CNVPDF would use the
spool file information and the IFS name to execute the conversion command.
The FTP step would use the IFS name.

If you need other parameters for the job stream, you need to add them to the
SPLPARMS.  If the parameters change often, you may want a more flexible way
to define them than using a data structure - that's the called program I
mentioned in the previous email.

Hope this makes some sense.

Joe


> -----Original Message-----
> From: rpg400-l-admin@midrange.com [mailto:rpg400-l-admin@midrange.com]On
> Behalf Of Wills, Mike N. (TC)
> Sent: Tuesday, April 02, 2002 11:56 AM
> To: 'rpg400-l@midrange.com'
> Subject: 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.
> _______________________________________________
> 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.