|
From Al Mac with BPCS 405 CD on AS/400 V4R3 Hopefully several of my tips help with Oludare situation & also perhaps Rob Stagis take a look at SYS120 on the SYS reorg menu. If you have emergency running out of disk space ... check out BPCS LITE from UPI. http://www.unbeatenpathintl.com/services.html How often do you do a full IPL? ... we do one about once a month ... that picks up RCLSTG & typically increases our disk space by about 3% for a few days. DSPSYSSTS tells us summary disk space story. I usually try to do re-IPL a few days before fiscal end month, so as to optimize performance when system is about to get a massive work out. DSPJOBTBL can supply some useful information for overall performance planning vs. disk space trade offs. GO CLEANUP can do some settings for how long you want to keep storage tied up due to large reports, how long old messages stay on line & such like. BPCS has SYS120 (SYS menu then option 23 to reorg menu then option 21 is where it is on 405 CD but we copied the reorgs we use all the time to our general FXS (fixes) menu) which goes through the BPCS data base & identifies files that are SOFT CODED for deletion & eliminates those records & reorganizes those files from both a soft coded and hard coded perspective & is BPCS-friendly. IBM RGZPFM is only going to catch holes in the file due to records that are HARD CODED for deletion ... ie. GONE & no longer accessible. I do not know why, but BPCS SYS120 does NOT do all the BPCS files & of course weuns might have added some files to the collection. Thus we use RGZPFM for the few odd BPCS files that SYS120 misses. You better not have anyone else doing anything on these files during SYS120, RGZPFM or various other serious programs like INV900. There are some BPCS files I would NEVER run through RGZPFM because of pitfalls in how some BPCS programs access records in those files, such as Bill of Materials & Customer Orders. This may be version sensitive, but a collegue at another company using BPCS told me a horror story about how they used IBM reorg on their MBM file & messed it up so bad they had to restore earlier backup. I have also created horror story here by deleting individual customer order lines that were finished, on customer orders that were running out of individual lines available - yes we have blanket customer orders that span multiple years. I have not studied how ALL BPCS programs access ALL BPCS files but I have studied enough to know that they do NOT all function in a consistent manner. If you are going to RGZPFM over ANY BPCS file you had better know how ALL programs access that file & make sure that NONE of them are going to be messed up by this. I have not seen any BPCS files accessed by RRN ... MAPICS did that a lot. Generally they are accessed by compound keys involving a sequence number in which the software expects all the numbers in the sequence to be there consecutively, and different programs use different logicals. We run a job that sends DSPFD info to *OUTFILE to identify volume of records coded for deletion times record size to get number of bytes that can be saved & use it as a guide to how often to run SYS120. Invariably General Ledger Work is the #1 file needing SYS120 attention & there are a bunch of Shop Order work files tied for #2 place. SYS120 gets them all except some of the JIT files (V* range). Normally we run SYS120 about once a week, but this week I have been running it almost every nite, because we are doing more frequent CST900 since there is a physical inventory next week & I want to purge shop orders more often than usual on its eve. I have found that CST900 takes 5 hours to execute if it has been a week since the last SYS120 ran & 2 hours to execute if SYS120 has run within the last 24 hours. Since SYS120 takes 45 minutes, it is a no brainer to run it first when CST900 is imminent. CST900 gives a work out to FSO FMA FOD so I usually try to run SYS120 soon after CST900, and also soon after fiscal month end. I asked BPCS tech support about REUSE when I first found out that we had millions of records coded for deletion & their answer was basically that we should be running SYS120 regularly. Apparently there is a performance hit if you REUSE deleted records, so we decided NOT to have a performance hit, or to second guess SSA on this performance issue, then do all this clean up stuff regularly. The performance hit has to do with the software taking extra time to find if there is a space to write something then have to add a record if needed. On those files with very heavy user access this can make a big difference. > From: oludare@ix.netcom.com (oludare) > > Guys, > > What are the Pros and Cons of performing RGZPFM & RCLSTG monthly. > For BPCS: Are there any pitfalls performing RGZPFM ? > > Oludare > From: stagis@fansteelvrwesson.com (Rob Stagis) > > I can't speak for the rclstg, but RGZPFM is one of my regular maintenance > tasks. Depending on the version, the files'll be different, but on V4.05CD > one of the chief offenders (for instance) is GJW. Tons of stuff gets fed in > there, then sucked out by the G/L journal-entry generation programs, leaving > hugemongous holes in the file. A DSPFD on it will typically show 700 > records, with 35,000 deleted! > > If you're running CST close or shop-order close, the FSO file, FOD file. > ITH! If your system is purging records this is a good one. There's others, > too...I've found 'em mostly by curiousity. BBH, BBL, um, ESN, ESR.... Carlos wrote > Basically you don't need to perform rgzpfm in any file if you reuse the > deleted records. This is set at file level at the REUSEDLT parameter. If > this is set to *YES the system reuses deleted records and it is not > necessary to do the RGZPFM command. I'm not sure if this is a default > value retrieved from the system or not. If your files are not reusing > deleted records you could change the parameter via CHGPF command. > > Carlos > From: (Carl Galgano) > > Oludare: > It has been quite a while since I have worked with BPCS, but it seems like I > remember something that processed a file by RRN. If this is the case, the > RGZPFM will probably cause you a problem. This may have changed over the > years. > cjg MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac) AS/400 Data Manager & Programmer for BPCS 405 CD Rel-02 mixed mode (twinax interactive & batch) @ http://www.cen-elec.com Central Industries of Indiana--->Quality manufacturer of wire harnesses and electrical sub-assemblies - fax # 812-424-6838 +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
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.