print job gets different job number ?

Use this board to ask questions or have discussions with other Rich Displays users.
Post Reply
amc
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:

print job gets different job number ?

Post by amc »

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
User avatar
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 ?

Post by David »

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.
amc
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 ?

Post by amc »

Thanks David, I can confirm that SPLFOWN(*JOB) solved the problem
hbi
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 ?

Post by hbi »

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
User avatar
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 ?

Post by David »

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?
Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest