PRINTQUEUE File on iSeries.

[bukoskynr]

Does anyone have an issue where their printqueue file on the iseries gets full? There is a limitation of the system that will only allow 32700 some records, well we frequently fill this up and all jobs halt. We do run the purge job to keep only three days of a certan user set of User IDs (Robot Jobs) Then five days of others.

Wondering if anyone has had any experiece with this limitation and what you did to get past it.

 

[Bill Dotson]

We have run into the same limitation and we get around it by purging print jobs weekly. In our case, it's sufficient to purge anything over 14 days old, but if you run a lot of UBEs you may need to use a lower value, or purge more frequently.

 

[jstooge]

I think you'll find that most get around it by doing the same are you are doing, running frequent purges, or using offloading to copy it off then purge.

Another concept I've seen used if there is budget for it, is to offload some of the UBE processing to a cheap W2K application server. Ok, so cheap is relative, but compare it to the cost of the iSeries and you get my point. User jobs could be sent to the W2K and the scheduled and Robot jobs could run on the iSeries.

You'd still have to purge and manage, but the time intervals would hopefully become longer.

Regards,

 

[jennifer_qiu]

Is there a UBE in Xe to do the printqueue file purge? Thanks, Jennifer

 

[b_gilmore]

You could upgrade to 8.10. Peoplesoft stores the PDFs in the IFS starting at
8.9.

You also might do some checking via sql to locate any orphan PRINTQUEUE
members that do not have corresponding F986110 records.

 

[bukoskynr]

R9861101 I think is the report name.

 

[jennifer_qiu]

Thanks for the info. We had contractors developed RPGLE program to first
archive the PDF files and corresponding F986110 records then purge both of
them. The information is written to an index file so if needed, people can
look at the index file to find out the archived PDF files. But the programs
are developed in RPGLE and is for B7321. I wonder if R9861101 has the
archive + purge function or just purge function.

Thank you,
Jennifer Qiu




bukoskynr
<bukosknr@hotmail To: [email protected]
.com> cc:
Sent by: Subject: Re: PRINTQUEUE File on iSeries.
jdelist-bounces@j
delist.com


10/08/2004 11:47
AM
Please respond to
"PeopleSoft®
EnterpriseOne"






R9861101 I think is the report name.


Nick Bukosky XE SP22_W1 iSeries V5R1 Citrix Metaframe XP FR3

 

[DBohner-(db)]

Just Purge - and it's All or nuthin.

You need to consider duplicating the R9861101 process. If memory
serves correctly - R9861101 does an override to a seperate library
(the corrected printqueue) - then calls R9861102. When R9861102 is
completed R9861101 then retracts the override, closing cleanly.

What you want to do is create a list of jobs that you want spared from
the delete - and omit them from the purge - or just include those you
desire to be purged.

If you need more detail - I should be able to provide some examples.

(db)




--

 

[dlk1999]

Hi,
Might be you can find the oti-01-0112 document on the KG.
...DLK

 

[jolly]

Dan is right. R9661101 does the business. However it's not much help if your users still need to access the old PDFs as R9861101 blows them away.

I've written a UBE that moves the PDF's to a windows share, but I'm having trouble writing a server C bsfn to remove the PrintQueue member. If anyone know's how to do that I'd love to hear about it.

BTW, I want to avoid using system() to invoke an AS400 command to remove the member for efficiency reasons. I expect something like
unlink("B7333SYS/PRINTQUEUE(F324564)");
to do it, but I suspect unlink does something else on AS400's, rather than the standard C library file-remove function.

 

[DBohner-(db)]

Consider copying the R98 process - but, in the second program... copy the member to a file with .pdf extension to the IFS. Based on how folders are maintained in the IFS - users may be able to map directly to a shared IFS folder.

I use fuzzy words - only because I haven't done it before. I'd like to build the monster, but... thus far, I haven't been to a client that desired to bring the process to reality. Maybe some of the SOX stuff will change all that.

(db)

 

[jolly]

Oh, I should have mentioned: I initially used the jde DeletePrinterFile API to delete the member. That works, but it also deletes the F986110 record :-( I need that record to stay. That APUI sends a JDENET message to the server to do it's work so I have no idea what the code looks like.

I've resorted to just using a
system("RMVM FILE(B7333SYS/PRINTQUEUE) MBR(F123456)");

type approach. I've mapped this BSFN to the server, and call it from a test client. However there is something wrong: the BSFN call never returns. If I type in the same command on a green screen it works fine.

No operator messages, nothing in any logs. I'm confused.

 

[jolly]

Ok, I got it going. What I didn't realise is that I needed to reference the file in the IFS context, i.e. /QSYS.LIB/B7333SYS.LIB/PRINTQUEUE.FILE/F323843.MBR

I can unlink() that with the only issue being it is slow when the PrintQueue file has 30,000 members.

However the whole application now works great: I have a UBE that runs over F986110 and archives the PDF's and CSV's to a windows share, and updates the Job status to 'A'rchived. I've changed the View row exits in P986110B to automagically view the archived PDF when the status is A.It also displays the archived records in blue, like the sales order screens do.

This pretty much solves our issue for now. It dodn't require a whole lot of coding so if anyone is having PrintQueue capacity issues I'd recommend this approach.

JohnO

 

[sashton]

Hi Jolly,

Can you share with us what UBE you have that runs over the F986110 and archives the PDFs and CSVs into a Windows share. Thanks.

 

[Ben O'Malley]

Hey guys and girls,
Has Jolly posted any more information about what changes can be made to archive these members from printqueue on B7333sys? If so can you tell me where they would be?

 

[jolly]

Sorry Steve and Ben - I never noticed your posts!

I can post the code here - but am just about finished rewriting the whole thing as a DB2 stored procedure which has some advantages over the client-only UBE I wrote earlier. If anyone's still interested I'll post the DB2 code when it's completed.

 

[manish400]

Let me know if you still need to solution ,I am running it sucessfully.

 

[jolly]

Here's the DB2 Stored Procedure based code attached.

Notes:
- I take advantage of the /QNTC filesystem to write the PDF and CDV files to an archive in a windows share. This means that the UserId/Password of the AS400 session (i.e. the ODBC DataSource) must match a Win32 domain UserID and Password that has access to write to the Archive share.
- Instead of using stored procedure, the 'MoveMember' could easily be embedded into a UBE by assembling the CL commands into a string and then invoking them with the System() command.
- I have also made a customisation to P986110B (Work with Server) so that if the user uses the View PDF/CSV row exit, it seamlessly retrieves from the Archive share.
- You need to add a UDC to 98|JS for the A "Archived" status.
- None of this is necessary from 8.10 onwards. You only need this nonsense of you are on OneWorld, Xe or ERP8.
- Use this at your own risk - I take no responsibility for it!
- Do not redistribute this in code for sale, or free code used to promote or schill other products
- If you use this code, please acknowledge the author
- udf_Date2OWJulian code courtesy of Chris Wenslick, Slik Software, developer of the superb Slik application.

Cheers,
JohnO

 

[TAV]

Just an FYI I did not see mentioned.

The PRINTQUEUE file is over your machine so if you have DV?PY/PD on the same box sharing the same resources you will fill it with pdf output from these environments as well. Especially if ROBOT is running the same jobs in test. One place I remember moved development off the same box and saved a bunch. Just another thing to keep in mind so you can keep as much as possible in the file for PD.

 

[jolly]

True. Plus you generally aren't too emotionally attached to non PD PDF so can data select your R9861101 purge job to ditch them more aggressively where they are not PD.