Re: Seeking inspiration ...

Jack,

Not quite the same, but the article at
http://www.mcpressonline.com/cl/the-cl-corner-overriding-commands-and-their-parameter-values.html
does
show modifying the command string associated with the ENDJOB command by
conditionally adding the string 'OPTION(*IMMED)'. Making a similar change
to SIGNOFF should be straightforward enough. And in case you are not aware
of it, the Control Job Log Output (QMHCTLJL) API documented at
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/QMHCTLJL.htmmight
be useful (independent of the Command Analyzer Change exit..

Bruce Vining
On Thu, Aug 2, 2012 at 8:33 PM, Jack Callahan <jjcllhn@xxxxxxxxx> wrote:

@Bruce

Thanks for sharing. Very slick- didn't realize a command could be
re-written before execution, but I don't usually go poking about exit
points without due cause. Could potentially solve a totally different
problem we've been brainstorming about recently (dumping the job log for
select users when they log off the system)

Would love to see an article detailing this exit program example. The
Command Analyzer Change exit point documentation you cited is a bit thin
for something that could cripple the platform if implemented incorrectly.


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

--
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.