Newsgroups: bit.listserv.jes2-l
Date:         Thu, 12 Nov 1992 16:27:00 CST
From:         Dave Ulrick <A01DGU1@NIU.BITNET>
Subject:      Re: JOBCARD standards enforcement

On Thu, 12 Nov 1992 16:24:29 EST Arthur Gutowski <AGUTOWS@WAYNEST1.BITNET> said:
>At our shop we are considering enforcing some sort of standards
>for jobs submitted into JES2.  We want to make sure that certain
>fields in the JOBCARD are present, and if not, we want to pull
>them in.  We would like to be able to get this information from
>the userid that the job is submitted under.  JES2 Exit 3 seems to
>be the ideal place to accomplish this goal.

You might want to consider Exit 6 (internal text scan).  See below...

>We are running ACF2, and already maintain some of the needed fields
>in the LIDREC.  We would have to add a couple more.  It doesn't seem
>like it would be that difficult to place an ACF2 call to get the
>LIDREC for fhe submitting userid and fill in the blanks from there.

This is more or less what we do in Exit 6.  In fact, we read the
entire LIDREC and add it to the JCT.  Note that Exit 6 runs in
the JES2 subtask environment, whereas Exit 3 runs in the JES2 main
task.  I would not recommend making an ACF2 call from Exit 3, since
any MVS WAIT incurred during the ACF2 call will cause the *entire*
JES2 main task to wait.  All of your printing, NJE, and RJE
functions will wait along with it.  If you *really* want to call
ACF2 at Exit 3 time, set up a subtask to do the actual call,
and $POST (I believe) the subtask from Exit 3.  Exit 3 would then
issue $WAIT, only to be posted by the subtask when the ACF2 call
is complete.  I have never had the opportunity or need to create
a JES2 subtask, so it's hard for me to estimate the difficulty of
doing so.  Using Exit 6 has the advantage and disadvantage of
working with the JOB card's internal text.

>Other approaches I've considered are using ACF2's exit facilities in
>the JES2 interface it has, but 1) their docs seem to recommend against
>modifying those exits which would be useful, and 2) there is a
>possibility we will be moving to RACF, and rather than reinvent the
>wheel, it would be easier to modify a JES2 exit already in-place to
>make the appropriate call to RACF.  Besides, it's a JES2 kind of
>function I'm doing, it would be best placed in the JES2 environment.

We maintain at least one small mod to ACFJ2ITF, so I can affirm that
modifying the ACF2 JES2 exits is not the best practice.  I would
confirm that a JES2 exit is the way to go.

>I've also considered writing a SUBMIT exit or Rexx front-end to SUBMIT
>that would pull the desired info from, say, a user profile dataset.
>That doesn't cover STCs and TSUs, though.  We already have an EXEC
>in place on VM that is used when submitting jobs from VM to JES2 via
>RSCS, but it seems to me that a JES2 exit would replace the need for
>that.  One program maintained at the point of entry into the system
>seems like a much better idea.

That would cover jobs submitted from TSO, but what about, say,
jobs submitted from another job via an internal reader?  Would you
want the JOB card for such a job to escape scrutiny?  You may also
want to consider the fact that an automatic job scheduler may be
in your future.  Thus, JES2, not TSO, should be considered as your
point of entry.

>Anyone got any comments or suggestions as to whether I'm on the
>right track or barking up the wrong tree?
>
>Thanks for any help,
>Art

Dave