Re: Seeking inspiration ...

In a similar, though not identical (in my case I was propagating adopted
authorities to the submitted job) situation, I wrote two programs
to insulate the applications. One program was an exit program using the
Command Analyzer Change exit documented at
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/xcachg.htm.
The
exit program examined the job to be submitted and, if it met certain
criteria, would modify the CMD string of the original SBMJOB to call my
second program passing two parameters -- some control information and the
original CMD string. The changed command string was then returned to the
exit point to be run.

The second program would be called as the initial program of the submitted
job, set the appropriate environment for the job to run in, and then call
the application program that the user wanted to run (using the second
passed parameter).

I have not been following this thread very closely, but one could certainly
do what ever data gathering is necessary in the exit program (it runs in
the job performing the SBMJOB), if necessary (due to size) store the data
under some arbitrary key passed in the first parameter (or just make the
data into a parameter), and then have the initial program of the submitted
job perform whatever is necessary to recreate the environment. Assuming
that the submitted job would run OK in the initial job if directly CALLed
(which is what I'm not sure of when skimming this thread), then the
submitted applications would/should require no change.

This would require no change to the defaults of the IBM SBMJOB command
itself, require no duplication of the SBMJOB command and subsequent playing
with the library list, and as an added benefit enable one to do a whole lot
of "other things" while in the exit program.

Bruce Vining

On Thu, Aug 2, 2012 at 9:10 AM, <darren@xxxxxxxxx> wrote:

The issue is that you need to define a place for a submitted job to look,
and it has to know where that place is, without being told. My suggestion
would be to submit the job on hold. You can do this with the SBMJOB
command, or by making sure it goes to a jobq that is always held or not
attached to a subsystem. Then you read your current job's message queue to
see what job you just submitted, and you create a keyed DTAQ entry based on
the qualified job name of the job that was just submitted. Release the
submitted job and it has the data in the place it expects to find it,
without being told where that place is.

Cleanup is the remaining issue in a system like this. What happens if the
batch job didn't run, or it failed. A secondary process can be called to
sweep through the DTAQ to eliminate any items deemed expired.





From: Jon Paris <jon.paris@xxxxxxxxxxxxxx>
To: Rpg400 Rpg400-L <rpg400-l@xxxxxxxxxxxx>,
Date: 07/29/2012 08:08 PM
Subject: Seeking inspiration ...
Sent by: rpg400-l-bounces@xxxxxxxxxxxx



I have a series of programs that need to be able to share some basic
information.

Solution must have similar characteristics to the LDA in as much as it must
be available to any batch job submitted from code running in interactive or
web mode,

BUT there are some limitations:

1) Adding additional parameter(s) is not an option

2) Using the LDA is not an option (other software thinks it "owns" it)

3) Does not involve the use of a file if at all possible.

Everything I have thought of so far falls apart somewhere along the path -
so I'm hoping someone else here has dealt with a similar issue and can stop
me from going round in circles with this one.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com <http://www.systemideveloper.com/>




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



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