Re: Printing from ILE/C program running in QUSRWRK

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].

-- 
Regards, Chuck

-- 
This is the Bare Metal Programming IBM i (AS/400 and iSeries) (C400-L) mailing list
To post a message email: C400-L-Zwy7GipZuJhWk0Htik3J/[email protected]
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request-Zwy7GipZuJhWk0Htik3J/[email protected]
Before posting, please take a moment to review the archives
at http://archive.midrange.com/c400-l.