|
For starters, you should consider _archiving_ these records instead of just _purging_ (or deleting) them. If you archive the data properly, you can always just copy it back into the live system if you find that it was a mistake. Then, you can re-group and try again. My company sells an add-on product for BPCS that can assist in your purging and archiving needs, especially with respect to these files. You can find more information at http://www.arctools.com or email me privately and I will contact you. It can help you keep your files trimmed by allowing you to archive these files on a regular basis. Now... away from the 'product' and on to some functional suggestions. You definitely should clean out these (and possibly other) files. You should at least consider getting the old static data out of the live environment and into an archive library. Trimming the size of your files in the live database obviously speeds up everything, including nightly processing, backups, etc. You can leave the archived data on disk if you like - it won't affect performance if it's not being accessed often, and as long as it's not driving your disk utilization too high. If you find that you need the older data in certain programs, it is possible to build it back in to just those few areas that it's really needed. Many shops don't even consider purging and archiving because the users won't let them. But - perhaps you can... My favorite example is the company that doesn't purge because the VP of Sales wants to see 20 years of history for his big customers. The problem is, that 20 years of history (which only gets looked at once a quarter) is slowing down everyone, including the customer service reps taking orders over the phone. Archive 18 years of history to another library, then find the two or three programs (one inquiry and two reports) that the VP _really_ needs and do a little tinkering to build the static, archived data back into the reports. This can typically be done by modifying the logical file used for the report, then making a few relatively simple changes to the report program. Now, everyone is running faster, and you don't need to go from a P20 to a P30 any more, and the boss still sees his 20 years history on the reports. I've seen sites reduce their batch windows by over 65%, with corresponding improvements in on line response time. Good luck. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Purge and Archive your AS/400 Data Without Programming with ARCTOOLS (tm) DCSoftware, Inc. (508) 435-8243 (508) 435-4498 (fax) http://www.arctools.com mailto:info@arctools.com +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ----- Original Message ----- From: "Paul Holstein" <holstein13@excite.com> To: <BPCS-L@midrange.com> Sent: Friday, May 12, 2000 9:28 AM Subject: Re: GXR & GLH > Mark, > > Let's take the two files one at a time. > > First, the GXR file. This is the Subsystem Cross Reference file and you may > or may not need its content. This file helps you link back to the subystem > for any individual subsystem G/L entry. This can be very helpful to help > you reconcile accounts or inquire into the G/L. On the face of it, this > file would seam critical but the information in it may actually be > redundant. With 6.04 macros, you can actually have all the information you > need to link to the subsystem written direcly to the GLH or GLA files. > Therefore, if you are using the proper macros in your models, you probably > can purge the GXR file carefully and selectively. > > Note: I think you are better off getting more disk space than deleting this > data. > > Now on to the GLH file. This file is central to your general ledger. It is > the General Ledger line detail. You definately need all the data in this > file for the current year and probably for the previous year. However, > there are tho things you can do to save room. First, you could post in > summary. I don't like this approach because, you will lose the ability to > reconcile your accounts easily if you don't have the detail. However, some > clients reconcile daily and have no need to go back to the detail. > > Secondly, you could purge old history from this file. Many companies do not > need to report results from over two years ago. If this is the case, you > could selectively and carefully delete old info from the GLH, GHH, GLA, GSX, > GXR and GSB files for the old data. > > Again, I would be very careful before I did any purging. Of course you > should back everything up to tape or a separate server before doing anything > like this. Consider data warehousing. > > --Paul Holstein > iWork Software, L.L.C > > > On Fri, 12 May 2000 09:13:40 +0100, BPCS-L@midrange.com wrote: > > > 6.0.04 HP-UX / Informix > > > > Folks, > > > > About 1/3rd of my total dB space (i.e. 6Gb of 18Gb) is taken up by two > > tables, GXR & GLH and I have been informed by SSA that there are no purge > > programs with BPCS for these tables. > > > > We have been running for around 13 months on 6.0.04 and whilst I can > still > > accommodate these tables I need to put into place a long term strategy to > > ensure that these tables do not just continue to grow. > > > > Has anyone out there had similar problems with these tables ? If so did > you > > get a solution out of SSA or write your own SQL to purge data from them ? > > > > Any help or assistance would be much appreciated. > > > > Regards > > Mark Curtis > > IT Director > > Hafele U.K. Limited > > Office : +44 (0)1788 542020 > > Direct : +44 (0)1788 548557 > > Fax : +44 (0)1788 548599 > > Mobile : +44 (0)973 121135 > > email : mailto:mark.curtis@hafele.co.uk > > Web : http://www.hafele.co.uk > > > > > > > > +--- > > | This is the BPCS Users Mailing List! > > | To submit a new message, send your mail to BPCS-L@midrange.com. > > | To subscribe to this list send email to BPCS-L-SUB@midrange.com. > > | To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com. > > | Questions should be directed to the list owner: dasmussen@aol.com > > +--- > > > > > > _______________________________________________________ > Get 100% FREE Internet Access powered by Excite > Visit http://freelane.excite.com/freeisp > > +--- > | This is the BPCS Users Mailing List! > | To submit a new message, send your mail to BPCS-L@midrange.com. > | To subscribe to this list send email to BPCS-L-SUB@midrange.com. > | To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com. > | Questions should be directed to the list owner: dasmussen@aol.com > +--- > +--- | This is the BPCS Users Mailing List! | To submit a new message, send your mail to BPCS-L@midrange.com. | To subscribe to this list send email to BPCS-L-SUB@midrange.com. | To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com. | Questions should be directed to the list owner: dasmussen@aol.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.