On 13-Oct-2015 03:11 -0600, Jevgeni Astanovski wrote:
It should be very simple, but looks like I am missing something
fundamental..
When I need to generate printed output from my C program, I write
something like:
....
FILE *LogFile ;
char szTemp[133] ;
LogFile = fopen("*LIBL/EQRPT", "w") ; // EQRPT - generic PRTF
sprintf(szTemp, "Printed output\n") ;
fwrite (szTemp, strlen(szTemp), 1, LogFile) ;
fclose(LogFile) ;
....
works fine in batch and interactive programs. Produces a spool file
in an output queue as expected.
The function interactive jobs apparently are started for a user for
which the Initial Library List (INLLIBL) includes a library in which the
Printer File (PRTF) named EQRPT exists.? And either similarly for the
batch jobs whereby the INLLIBL is resolved from that attribute of the
Job Description (JOBD) of that User (USER) for the submitted request, or
the Submit Job (SBMJOB) request suggests to refer to the *CURRENT value
of the submitter to establish the batch INLLIBL.?
However, when I place the same code in a program that runs in QUSRWRK
(job QZRCSRVS - a remote program call),
LogFile is *NULL after fopen and errno is 3025: "No such path or
directory" produces strerror. <ed: stderror ??>
I run the job under debugger using STRSRVJOB to check if EQRPT is
indeed in the path - I see that it is.
Can someone explain what am I doing wrong?
Not sure how the /path/ was verified for the QZSCSRVS job [while in
debug; which should be moot, as Work With Job (WRKJOB) for OPTION(*LIBL)
issued against the other job should be sufficient even without service
or debug being active], but the default Work Management (WM) setup for
that job, a Prestart Job Entry (PJE) in the Subsystem Description (SBSD)
QUSRWRK is to use the Job Description (JOBD) named QZBSJOBD in QSYS, and
that JOBD is setup with Initial Library List (INLLIBL) of *NONE [i.e.
INLLIBL(*NONE)].
The native path specification of *LIBL in the program [i.e. the
special-value *LIBL meaning {Search The} Library List] is unlikely to be
fruitful without first having established that native path. That path
would need to match what is used in the typical interactive job [where
noted, the function is as expected], for which the JOBD() specification
of the User Profile used to sign-on gets used to start the Job [i.e. the
WM established for that job].
AFaIK the QZSCSRVS does not effect implicitly establishing the *LIBL
upon initiation of the Current User for the job in the same way that is
done for WM setup of an interactive job; i.e. the JOBD of the current
user is not referenced for the INLLIBL [nor perhaps for CURLIB]. If so,
then the "generic PRTF" would have to reside in the System-portion of
the Library List (SYSLIBL), or the Library List of the job would need to
be managed\modified to allow use of that printer file from *LIBL.
Thus, I infer likely the issue is that the QZSCSRVS servicing the
request, does not have a run-time LIBL established that is compatible
with the program's assumptions about what will be in the *LIBL. If that
is an improper inference, and in fact the /path/ that was verified was
the *LIBL of the QZSCSRVS job servicing the request, then none of the
following is of interest. Regardless, FWiW:
Often a Command being invoked establishes a Product Library (PRDLIB)
for the feature being invoked, so as to eliminate dependencies on
establishing a specific library list within the program; i.e. the CMD
object ensures\performs the setup of the *LIBL, so the program can refer
to the *LIBL as path and function properly. When the application is
invoked from an interface other than the command, then the program
either needs to act differently, or the onus is on the caller to setup
the proper environment for the invoked program.
As I recall, some people have resolved similar issues [though I do
not recall if specifically for the QZSCSRVS job] with a Command (CMD)
and a Command Processing Program (CPP) for that Command, that
effectively replaces the current library list with the one extracted
from the JOBD associated with the Current User (CURUSER) of the job;
e.g. Retrieve User Profile (RTVUSRPRF) to get the JOBD, then the
Retrieve Job Description Information (QWDRJOBD) API to get the INLLIBL
details, and then the Change Library List (QLICHGLL) API to set\replace
the Library List (LIBL) specification for the User Portion of the *LIBL
[or to more fully mimic interactive, also the Current Library (CURLIB)
portion of the LIBL].
midrange.com
