khoho
Member
For those of you that hit the member limit of 32767 members in your printqueue file, or have been able to avoid it, how many days is your PDF retention and how do you purge the PDF's to keep this within limits?
Ritchie_
Well Known Member
We keep different pdf different times. All depends on some legal rules for it. Some need to stay there 7 years or so
Someone from JDE made us a custom program and ube based on what happens when you delete the pdfs through submitted reports screen.
works fine. But we're busy with a new archive programm which will also be used for non JDE things. So eventually also those 7 year things will move out of our printqueue making it smaller again
Someone from JDE made us a custom program and ube based on what happens when you delete the pdfs through submitted reports screen.
works fine. But we're busy with a new archive programm which will also be used for non JDE things. So eventually also those 7 year things will move out of our printqueue making it smaller again
Jack_Crouch
Well Known Member
I was told by JDE yesterday that "B9" will employ the IFS instead of a file called PRINTQUEUE.
Since we run about 7000 UBEs a day, this 32,000 limit is bad news. We have an agressive purge setup (run it every day).
I have attached a couple of CL programs R55PRGPRT and R55PRGPRT2 that does this purging.
I have also attached a CL program called R5507ARC that copys the members in PRINTQUEUE to the IFS using the CPYTOSTMF command. This goes into the IFS to a directory that users can then burn the payroll files off to CDROM with.
Since we run about 7000 UBEs a day, this 32,000 limit is bad news. We have an agressive purge setup (run it every day).
I have attached a couple of CL programs R55PRGPRT and R55PRGPRT2 that does this purging.
I have also attached a CL program called R5507ARC that copys the members in PRINTQUEUE to the IFS using the CPYTOSTMF command. This goes into the IFS to a directory that users can then burn the payroll files off to CDROM with.
DBohner-(db)
Legendary Poster
Did they bother to tell you if there were file limitations in the IFS? I am un-aware if there are any (our luck, there will be????)
We modified the the JDE UBE that clears the printqueue, also. We created a table of ubes that must be retained - and for how long. The UBE then works it way through Batch Versions and clears the queue - per the table.
Users, then are responsible for clearing out things that have 'extended' dates (retainment = forever)... Anything that isn't specifically placed int the table gets deleted after 15 days.... use it or loose it.
We, too, are looking at different retention methods - IFS does look a good situation... Are you renaming them for specific users/groups??? Have you thought of any security issues?
Daniel
We modified the the JDE UBE that clears the printqueue, also. We created a table of ubes that must be retained - and for how long. The UBE then works it way through Batch Versions and clears the queue - per the table.
Users, then are responsible for clearing out things that have 'extended' dates (retainment = forever)... Anything that isn't specifically placed int the table gets deleted after 15 days.... use it or loose it.
We, too, are looking at different retention methods - IFS does look a good situation... Are you renaming them for specific users/groups??? Have you thought of any security issues?
Daniel
Tom_Davidson
VIP Member
Jack,
We currently keep 6 days. Our goal is to keep ourselves under 29000 members on our production server in each instance. That way we have time to react if someone accidently submits a job such as statements, with no data selection we can react before we generate 32K members.
We have found that doing a DSPFD *MBRLIST locks the file for a significant amount of time (15 min), causing jobs to fail. Therefore we process the journal over the PRINTQUEUE for entries MD & RD, and write a record to a file. We then run our purge over this file, this also allows us to run the purge multiple times a day, we actually run it twice a day.
HTH
Tom
We currently keep 6 days. Our goal is to keep ourselves under 29000 members on our production server in each instance. That way we have time to react if someone accidently submits a job such as statements, with no data selection we can react before we generate 32K members.
We have found that doing a DSPFD *MBRLIST locks the file for a significant amount of time (15 min), causing jobs to fail. Therefore we process the journal over the PRINTQUEUE for entries MD & RD, and write a record to a file. We then run our purge over this file, this also allows us to run the purge multiple times a day, we actually run it twice a day.
HTH
Tom
tgore
Reputable Poster
I created a version of R9861101 that purges older than 60 days. I created a CL that calls the program using RUNUBE. We run ROBOT on our AS400 so once a month ROBOT runs the job for me.
