× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.