Printqueue file maxed out

Can anyone help with the problem of the printqueue file on an AS/400 enterprise server filling up with 32,767 members. When this happens UBEs will not run. We have looked into archiving then removing the members from the AS/400 side this seems to work but what about reports that people need to access after we archive the members? Any suggestions will be greatly appriciated.

Look at reports R9861101 and and R9861102. It is documented on the KG on OTI-01-0112.

By varying versions etc you will be able to control what jobs are purged from the system. I have set this up a number of times.

On the whole though this implementation of one member per job is terrible, I have two clients who are filling this up every day...

We have ran into the same problem. We made a rule at our work that we will
delete any print job on the 400 that is older than 3 weeks. If a user has a
print out that is needed they can print it out or just open it and it will
be stored in the printqueue file on the server (if user is using Citrix)

Hope this helps...

I didn't know about those two UBE's, thanks. However, if you are using an AS/400 enterprise server and would like for this to run as a scheduled job, I've created a CL that can delete the PRINTQUEUE members.

Thanks, thats a useful program...

Thanks Jean. We are nowhere near this problem (only 1400 mbrs) but I will be reviewing this problem so we can stop it before it hurts us. Hope you don't mind if we utilize your code - of course your name will appear in the author section still

This CL program doesnot delete the corresponding F986110 records.

Do you leave the table alone or is some type of maintenance done on it?

that file hasn't given me any problems so I have not worried about it.



Jean Driscoll
AS/400 Co-existent Xe 17.1, Update 4/A73Cum12

you can leave my name out of it. hope it works for you



Jean Driscoll
AS/400 Co-existent Xe 17.1, Update 4/A73Cum12

Gee, isn't the AS/400 PrintQueue issue great? (NOT!)

We have been doing some extensive review regarding this issue - I'll fill a
few of you needful folk in, on the issues.

Both the Work with Submitted Jobs/Job Control Master(interactive) and the
Job Control Master (R9861101/R9861102) use the F986110 DS OVERRIDE function
(OVERRIDE DATABASE FILE) to point to a specific library for the F986110
table (usually, one that is shared across the LPAR).

The PDFs/CSVs/whatevers are stored in PrintQueue Library as Members. Each
Member's name is based on a naming convention using a letter prefix and the
JobNumber of the submitted job (D#####, F#####). The architecture of the
AS/400 only allows for 32K members (technically not files). BSFNs retrieve
the member (basically a saved object) based on type and jobnumber.

The Work With Submitted Jobs will allow you to QBE by the first characters
of a UBE (R42565*) to select all of the UBE's by a report name.

The Batch Application will allow you to delete based on days old, only
(everything more than ## days old will go away). You cannot target a
specific UBE using the R986110# Batch Process.

We copied the R9861101/02 (R5598611/2) and added ER to delete specific UBEs
within a shortened time frame. Basically we do the following inside our Do
Section (R55986112):
* Parse the 'Foundation Future Use 2' field for the first underscore (this
returns the Submitted UBE's Name')
* Check to see if the UBE Name is on our discard list (if parsed name =
R42##, R####, R###...)
* Check to see how old the record is (test for retention)
* Delete using the DeletePrinterFile Function (based on above criteria)

Identifying the UBEs that can be quickly deleted is the most difficult
aspect of the issue...

Good luck in your adventures!

Daniel Bohner
[email protected]
www.existinglight.net

AS/400 SP 18 XE




Daniel Bohner
[email protected]
www.existinglight.net
JDE - XE, SP 18 & AS/400 V4R5.0
JDE - B7331 & MS SQL 7x