|
from Al Macintyre Great advice from Steve ... I am going to adjust my stuff based on his tips. However, before implementing Bill's suggestion, I would check with the MAPICS_L list to find out if there are any files on your version of MAPICS that ought not go through any IBM reorg. We never left MAPICS I but were seriously considering MAPICS II before we switched to BPCS. We were in touch with other neighbor factories on other versions of MAPICS & BPCS. There was a problem with the Bill of Materials file at an earlier version of MAPICS. If you used the IBM reorg to get rid of the deleted records, you ended up with a file that did not work right on MAPICS ... it was neccessary to use the MAPICS reorg on that file, which took longer, for good reason. We have a problem with certain BPCS files if we use the IBM reorg on them to get rid of deleted records, because the sequence numbering is not reset in the IBM reorg ... basically you have some files that are accessed within some item customer operation etc. index record-1 record-2 record-3 etc. & suppose record-2 is deleted ... there are ERP programs reading record 1 2 3 etc. that if they cannot find record-2 they quit right then & not get to record 3. Some MAPICS files were accessed using relative record numbers, not any index of item customer etc. so if you reorganize those files by some technique other than the MAPICS reorg, you have just corrupted how MAPICS can access them. Basically some file would get at something else using relative record number of that other file & MAPICS did this a lot ... I think they were called CHAIN FILES. I know MAPICS has been re-written several times since this reality. This may no longer be a factor. This is why you have to ask the MAPICS-L or someone who knows the version of MAPICS that you are on. PRTDSKINF more informative for the overall picture like which libraries are eating how much space, but I find the *OUTFILE to be essential for analysis of our very heavily used production files. I guess we are using this for different functions. > From: ERHARDT@BaldwinHQ.com (Bill Erhardt) > When was the last time you did a RGZPFM to reclaim deleted records? > > > -----Original Message----- > > From: Steve Richter > > > > Rebecca, > > > > To get answers now, if at all possible, instead of waiting for RTVDSKINF > > to run later, you should run Dspobjd *all/*all *all to an outfile as > > suggested in an earlier reply. > > > > Use WRKQRY to create two queries, one by object size descending, > > the other a library summary with an object size total. > > The guilty parties then show themselves: > > too many objects in qrplobj ( need to ipl ), library qspl has a > > lot of space used ( too many spooled files, need to rplsplstg ), > > save files > > have not been cleared ( need to get tough and break some arms ), .... > > > > Dspobjd may run for a while ( 30 minutes ). You should run it in batch as > > qsecofr. Also the outfile might reach its default capacity. I get around > > that by running DSPOBJD to an outfile on a single object. > > Call the outfile "qgpl/dspobjd". > > After running the dspobjd on the single object, CHGPF > > QGPL/DSPOBJD Size(*NoMax). > > > > Good luck, > > > > Steve Richter MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac) BPCS 405 CD Manager / Programmer @ Global Wire Technologies Incorporated http://www.globalwiretechnologies.com = new name same quality wire engineering company: fax # 812-424-6838
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.