|
When we delete spool file entries, this creates disk space. How soon is that disk space recovered? If recovered too soon, it makes for inefficiency the next time another report needs more disk space. I do not remember how QRCLSPLRTG manages this, but it is one of the reasons we use GO POWER to do some shutdowns in wee hours of weekends when no one using the system.
How much disk space is allocated, not for the reports themselves, but for the associated jobs that created those reports? DSPJOBTBL
We have never yet hit our maximum spooled files QMAXSPLF, but we found it necessary to modify some places in BPCS where some programs, such as CST270 inside CST900, habitually exceed the allowed size of a single report. We recently created a variant of INV260.
When we run INV260 for one facility, it typically creates 10,000 pages.The variant is only a few hundred pages, because it only lists those items for which we actually have inventory that has a cost variance. I believe there is a design flaw with INV260 in that it gets item class from IIM rather than CIC.
We also have individuals who use the spool file as a filing cabinet. I am one of them.I have added many drawers to this filing cabinet system to help organize the reports into various categories. e.g. QSCRAP contains statistical analysis reports associated with our scrap, so we can compare stories over several weeks or months.
My main concerns have been:* I would prefer that people are aware of how often we do backups, and they not delete what is necessary to recover to the last backup if that is ever needed. * Some people delete spool file reports before they know what they will need, when there is no way to reconstruct the data in those reports, without going through enormous effort. * Our current backup strategy only saves data files and software, not spool file contents, but we have stuff sitting in spool file from MONTHS ago. * End Fiscal Reports that we do not print, to save paper ... we just extract the total pages. If we were to have a disaster, we could potentially lose a lot of end fiscal data.
I have reminded the senior management of those individuals, that what came with OS/400 does not provide for backup of contents of spool files, that third party software is available to do so, and that we could also experiment with moving critical reports to PC based collections, such as a CD Rom containing all critical reports for each end-fiscal period.
If I had my choice of what third party software to get to better manage our resources, it would be ROBOT from www.helpsystems.com Help Systems, such as Robot/Reports, but I also recognize that there are several enhancements to BPCS that would serve the company better than doing something about our thousands of reports that cannot be backed up.
Software can also be written to do some of the spool file management, using such commands as CHGSPLFA in which I would love it there was more flexibility in DLTSPLF to say kill all reports older than some cut-off date that have certain other characteristics in common.
GO CLEANUP does not cleanup some stuff fast enough to our liking.On our backup menu, we have an option to purge unwanted system logs, there as a reminder to run regularly.
Al Macintyre Global Wire
Under the "GO CLEANUP" there are options to clear job logs, messages , system spool files. I don't know of one for all spool files. We have individuals that use the spool file for a filing cabinet. Roger Henady Thorco Industries "Dan Sweeney" <dsweeney@xxxxxxxxxxxxxxxx> Subject [BPCS-L]- AS/400 system value for retention of spool files I am trying to locate a system value for the global retention of spool file entries. Is there a system value available? Dan Sweeney Senior Technical Consultant PHOENIX Business Consulting Matching What's New With What Already Works !!! Main Office: P.O. Box 237, Greensburg PA 15601 Phones 724.836.4446 Fax 425.988.7102 Local Office: Manchester CT. Office Voice mail 724-836-4446 X7 E-fax 832-550-5144 Home office 860-432-9881 Cell 860.490.6712 http://www.phoenixbcinc.com All outgoing messages and attachments are scanned by Norton AntiVirus.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
