× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: GXR & GLH
  • From: "David Shea" <dshea@xxxxxxxxxxxx>
  • Date: Tue, 16 May 2000 15:40:10 -0400

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 thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.