On 13-Nov-2013 12:20 -0800, Steinmetz, Paul wrote:
This is mainly for the programmers' convenience, so they don't have
to type a job name when SBMJOB and testing.
I personally have never had any issue with specifying the job name.
In fact, I use it often to give WRKJOB more direct access to the job
solely by job-name; i.e. no need to get there via WRKSBMJOB, nor by
copying\pasting the job name from the completion message, nor by the
/Select Job/ list of WRKJOB OPTION(*SELECT). If I SBMJOB CMD(...)
JOB(DOIT), I can simply issue WRKJOB DOIT after the submit request, and
given I had picked an effectively unique name, then that one job is
displayed. And if I am concerned that I will get the /Select Job/
effect per OPTION(*SELECT) because someone else also used JOB(DOIT),
then I might preemptively request WRKJOB MYUSER/DOIT to ensure only my
user's job(s) named DOIT will be found or listed.
Would a routing entry work <<SNIP>>
The change-command exit would be a much better choice. Yet...
A routing entry could enable setting a job name, but only indirectly;
i.e. at the effective cost of two jobs for each affected job. That is
because the original job already has its name established, by the time
the job routing starts. Hardly a desirable effect, two jobs for one,
even if the resubmit activity were most properly effected using the
special value *CURRENT everywhere available, and the extracted
equivalent of *CURRENT where not available, along with the "Submitted
for (SBMFOR)" job of the original submitter. For example, any
automation like parsing the replacement data for the message CPC1221, to
act on the job that was just submitted, would prove unfruitful :-(
Even so, a big issue would remain. That is the Routing Data (RTGDTA)
that would need to be effected for these SBMJOB requests. If they would
not want to name the JOB(), then they probably also would not want to
specify the RTGDTA().
The default could be changed to RTGDTA(*RQSDTA), but that could be at
least somewhat dangerous, unless the JOBQ() is also\already defaulted to
avoid the processing of the routing by whatever unexpected Subsystem
could receive the job. For example some setup such as just the first of
the following, or perhaps other variants [like those that follow]:
ADDRTGE SBSD(The_SbsD) SEQNBR(33) CMPVAL('CALL ' 1) PGM("ReSbm_as")
ADDRGTE ... CMPVAL('QSYS/CALL ' 1) PGM("ReSbm_as")
ADDRTGE ... CMPVAL('*LIBL/CALL ' 1) PGM("ReSbm_as")
The default could, if currently the IBM-supplied default of 'QCMDB'
remains in effect, change to RTGDTA('CALL'), even if only for the
unqualified SBMJOB requests, i.e. the effective *LIBL/SBMJOB requests,
issued by these programmers. Then the subsystem routing as established
via their default Job Queue could be static. The /resubmit as/ routing
program would parse the request to decide, if a CL 'CALL' is being used
and given a /program-name/ was found, then issue the "SBMJOB CMD(&rqs)
JOB(&pgm_name) SBMFORM(&SbmByJbNr/&SbmByUser/&SbmByJbNm) ...", *else*
just issue the TFRCTL QCMD to let the standard request processor deal
with it. Thus the one static additional routing for the subsystem(s):
ADDRTGE SBSD(The_SbsD) SEQNBR(33) CMPVAL('CALL ' 1) PGM("ReSbm_as")
Note: I do not recall, but the trailing space possibly is not honored
in the comparison. The Option-7=Routing Entries should show if the
space was trimmed by the Add Routing Entry (ADDRTGE) request.
midrange.com
