Hi Chuck
That was it. It turns out that Macro4 isn't used on the test box but the
libraries, etc, had been restored as part of the setup from live. As it
wasn't being used it hadn't been configured so a masking job was trying to
set the library list by adding individual libraries that didn't exist to the
QUSRLIBL default library list.
The result was that only QGPL and QTEMP appeared in the final library list.
We've changed the SBMJOB command to use the IBM CPP and everything is now
working fine.
Thanks again for the suggestion, and thanks to everyone for their help.
All the best
Jonathan
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jonathan Mason
Sent: 01 July 2010 08:24
To: 'Midrange Systems Technical Discussion'
Subject: RE: SBMJOB and INLLIBL Acting Strangely
Hi Chuck
Looks like you could be on to something. The CPP associated with the SBMJOB
command is a Macro4 AutoJob program, SBMJOBC.
I've just tried re-submitting from the command line and specifying the exact
same job name as submitted from the interactive program and the library list
is changed to only contain QGPL and QTEMP. I don't know much about Macro4,
but I'm suspecting there's a masking job that changes the library list based
on the job name.
Thanks for the help
All the best
Jonathan
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: 30 June 2010 20:03
To: midrange-l@xxxxxxxxxxxx
Subject: Re: SBMJOB and INLLIBL Acting Strangely
On 30-Jun-2010 05:52, Jonathan Mason wrote:
We're experiencing a strange thing with the SBMJOB command and
the INLLIBL for the job.
We have a program that was generated using Synon/2e and this
submits a job to run in batch. The command to be submitted is
stored in amessage file as:
SBMJOB CMD(CALL PGM(PCEOXFR) PARM('' '&1')) JOB(&2)
LOG(4 0 *MSG) LOGCLPGM(*YES)
The job appears to run instantly, but when I check the joblog
it shows an error "CPD0170 Program PCEOXFR in library *LIBL not
found." The INLLIBL for the job shows in the joblog as
"INLLIBL(QGPL QTEMP)".
The defaults on the SBMJOB command for JOBD and INLLIBL are
JOBD(*USRPRF) and INLLIBL(*CURRENT). The JOBD associated with
the user profile is QGPL/QDFTJOBD and this has an INLLIBL value
of *SYSVAL.
The QUSRLIBL system value has QGPL and QTEMP specified only.
The library list for the "current" signed-on job contains the
complete application library list.
This setup is the same on a number of machines and everything
works fine, but in this case the library list being assigned to
the submitted job is incorrect. If I replace the &1 and &2
values in the SBMJOB command above and key it in directly from
QCMD the program runs correctly and in turn submits another job.
The second job then falls over with the same issue, i.e. a
program not found because the INLLIBL only contains QGPL and
QTEMP.
The system is at v5r4m5 with Cumulative PTF TC09321 applied.
I'm sure I'm missing something obvious, but can't for the life
of me see what it is. Any ideas?
When running the application, does the CPI1125 in the submitted
job show the "submitted ... from job" being that same interactive
job which invoked the application? For the invocation which saw the
program being found and thus "runs correctly" because the
like-SBMJOB request was issued from the QCMD command line, the
CPI1125 would show that interactive job as having initiated the
SBMJOB. So does the normal invocation of the application [by
whatever means that is, which apparently is not by the SBMJOB
command string directly] similarly show the interactive job in the
CPI1125 as having initiated the SBMJOB?
If not, perhaps the request is being initiated from another job
with its library list established unrelated to the interactive job
which invoked the application [unlike how, when the SBMJOB is issued
directly]. For example, the submit job request may be invoked
*indirectly* via a message on a queue [in a file, msgq, dtaq, or
etc.] that is being serviced by a server job which then performs the
SBMJOB, versus being placed directly as a job onto a job queue by
the system work management per SBMJOB having been issued directly
in\by the interactive job which invokes the application. In such a
case, review the system library list for the job which issued the
SBMJOB, to see if the *LIBL/SBMJOB came from somewhere other than
QSYS, or was explicitly SomeLib/SBMJOB, and then review the
parameter default for the INLIBL of that SBMJOB command.
Also possible I suppose... Is there an exit registered for a
"replace command" on the SBMJOB command, which perhaps changes the
effect of the INLLIBL parameter?
Regards, Chuck
midrange.com
