Re: QZDASOINIT Job Spool File Question/Problem

The spool files created with SPLFOWN(*CURUSRPRF) in a job running under a switched user will be assigned to the QPRTJOB of current user profile, in order to establish the requested ownership. So although a properly scoped OVRPRTF SPLFOWN(*JOB) in effect prior to the spooling or having ensured CHGPRTF SPLFOWN(*JOB) prior to running would likely enable the existing program to function as coded [i.e. unchanged], it would be best IMO to change the CLP to use the "retrieve last spooled file information" API.

From another message for a similar inquiry:

http://groups.google.it/group/it.comp.as400/msg/6a7d93137d87f324

There is an API to "retrieve last spooled file in a job" or
something similar. The SPLF information retrieved by the API is
irrespective of, to which user\job the file is assigned ownership;
i.e. regardless of SPLFOWN() established for the spool file.

Having stated that... I took the next step....

Using the "API Finder" on InfoCenter
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apifinder/finder.htm
searching on description [for whatever reason titled "Find by name"]
with the tokens RETRIEVE LAST SPOOLED, or reviewing a listing of
APIs under the "Find by category" of PRINT, I found the API QSPRILSP
which "returns the complete spooled file identity of the last
spooled file created for the current job or thread."
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/QSPRILSP.htm

Regards, Chuck

Mike wrote:

I have a process I am working on where a stored procedure runs a CL program with several steps. A few of those steps generate a
spool file of which I want to convert to a PDF. The problem I am
having is that the converting program can't find the spool file.
The problem I am having is that the spool file has the following
job information:

File
File Nbr Job User Number
GAME11 13 QPRTJOB USER 677358

The running job however is using this job information: Error
converting spooled file GAME11 677426/QUSER/QZDASOINIT
Number ....

Everything is run in one CL under (at least I assumed) one job.

Any ideas as to why this would work this way or how I work around
it?