Hi,
i have a CL job that copies an SCS print file of in invoice (created in the job) to a physical file with CPYSPLF using the CTLCHAR(*FCFC) option.
I then use OVRPRTF to override QSYSPRT using the DEVTYPE(*AFPDS) & FRONTOVL options.
I then use CPYF to copy the physical file to QSYSPRT.
This gives me an AFP invoice with the required overlay which is then converted to PDF format.
This CL program works 100% from the command line or in batch & has been working correctly for some time. When run that way, both the original SCS print file & the finished AFP file have the same job name/number/user.
When run via Profound UI however, the SCS file gets created with the correct job name/number/user but the AFP file gets created by job QPRTJOB with a different job number ? I have no idea how they get different job numbers when they are created by the same CL. This doesn't happen when run outside Profound UI.
The different job name/number means that the next section of code can't find the required spool file & therefore fails.
Any ideas how this can be overcome ?
Thanks
Tony C
print job gets different job number ?
-
- Profound User
- Posts: 67
- Joined: Thu Jul 29, 2010 1:25 am
- First Name: Tony
- Last Name: Cusack
- Company Name: Welding Industries
- City: Adelaide
- State / Province: Outside Canada/USA
- Zip / Postal Code: 5139
- Country: Australia
- Location: Adelaide, South Australia
- Contact:
- David
- Profound Logic Staff Member
- Posts: 690
- Joined: Fri Jan 04, 2008 12:11 pm
- First Name: David
- Last Name: Russo
- Company Name: Profound Logic Software
- Contact:
Re: print job gets different job number ?
See here for an explanation of the system's behavior with QPRTJOB:
http://publib.boulder.ibm.com/infocente ... prtjob.htm
It's using the separate QPRTJOB so that the spooled file owner will be the same user, because the HTTP server job is started as one user (QTMHHTP1) and then changed to another. All web server jobs will operate this way.
If you need to locate the spooled file using the current job information, try using an OVRPRTF command and specify SPLFOWN(*JOB). This should allow it to be assigned to the current job.
http://publib.boulder.ibm.com/infocente ... prtjob.htm
It's using the separate QPRTJOB so that the spooled file owner will be the same user, because the HTTP server job is started as one user (QTMHHTP1) and then changed to another. All web server jobs will operate this way.
If you need to locate the spooled file using the current job information, try using an OVRPRTF command and specify SPLFOWN(*JOB). This should allow it to be assigned to the current job.
-
- Profound User
- Posts: 67
- Joined: Thu Jul 29, 2010 1:25 am
- First Name: Tony
- Last Name: Cusack
- Company Name: Welding Industries
- City: Adelaide
- State / Province: Outside Canada/USA
- Zip / Postal Code: 5139
- Country: Australia
- Location: Adelaide, South Australia
- Contact:
Re: print job gets different job number ?
Thanks David, I can confirm that SPLFOWN(*JOB) solved the problem
-
- Profound User
- Posts: 24
- Joined: Sun Oct 30, 2011 1:04 pm
- First Name: Helge
- Last Name: Bichel
- Company Name: Helge Bichel
- Country: Denmark
- Contact:
Re: print job gets different job number ?
Ok, tried SPLFOWN(*JOB) and SPLFOWN(*CURUSRPRF).
Result:
TDL001AP 7 PROFOUNDUI QTMHHTTP 318285 <---SPLFOWN(*JOB)
TDL001AP 21 QPRTJOB DKHEBID 318178 <---SPLFOWN(*CURUSRPRF)
should be:
TDL001AP 7 PROFOUNDUI DKHEBID 318285
so neither SPLFOWN works for being able to do a CHGSPLFA with
JOB info from the SDS.
Houston, we have a problem.
Brgds
Helge
Result:
TDL001AP 7 PROFOUNDUI QTMHHTTP 318285 <---SPLFOWN(*JOB)
TDL001AP 21 QPRTJOB DKHEBID 318178 <---SPLFOWN(*CURUSRPRF)
should be:
TDL001AP 7 PROFOUNDUI DKHEBID 318285
so neither SPLFOWN works for being able to do a CHGSPLFA with
JOB info from the SDS.
Houston, we have a problem.
Brgds
Helge
- David
- Profound Logic Staff Member
- Posts: 690
- Joined: Fri Jan 04, 2008 12:11 pm
- First Name: David
- Last Name: Russo
- Company Name: Profound Logic Software
- Contact:
Re: print job gets different job number ?
The user profile assigned to the spooled file is the job start user, if SPLFOWN(*JOB) is used. The job start user of a PUI session job is always QTMHHTTP unless running in a 5250 interactive job through Genie.
SPLFOWN(*CURUSRPRF) ensures that the spooled file is assigned to the current user, but it accomplishes this by assigning the spooled file to a separate QPRTJOB as explained in the earlier mentioned article. So, this makes it impossible to locate the spooled file by SDS job values in the program.
SPLFOWN(*JOB) ensures that the spooled file is assigned to the current job, but the job start user profile (QTMHHTTP in this case) is assigned to it. So, you can reliably locate it later using the job name, job number, and job start user profile (not current user profile) from the SDS. This will work both on green-screen and in a PUI job.
In a 5250 interactive job, the job start user profile and current user profile are always the same thing, so none of this is a factor.
This does hold true for Genie, since in that case you are running in a 5250 interactive job.
Does this clear it up?
SPLFOWN(*CURUSRPRF) ensures that the spooled file is assigned to the current user, but it accomplishes this by assigning the spooled file to a separate QPRTJOB as explained in the earlier mentioned article. So, this makes it impossible to locate the spooled file by SDS job values in the program.
SPLFOWN(*JOB) ensures that the spooled file is assigned to the current job, but the job start user profile (QTMHHTTP in this case) is assigned to it. So, you can reliably locate it later using the job name, job number, and job start user profile (not current user profile) from the SDS. This will work both on green-screen and in a PUI job.
In a 5250 interactive job, the job start user profile and current user profile are always the same thing, so none of this is a factor.
This does hold true for Genie, since in that case you are running in a 5250 interactive job.
Does this clear it up?
Who is online
Users browsing this forum: No registered users and 1 guest