RE: GXR & GLH

["George Sagen" <gsagen@xxxxxxxxxxxxxxxxxxx>]

Mark,

The GLH contains your journal lines. Your philosophy for archiving the
records in this file will be tied to your accounting departments needs for
having detail on line. Some ramifications of clearing GLH records are:

1. Though you will still have account balances, which are stored in the GSB,
you will lose the individual journal lines from which the balances were
built.
2. You must never run CEA971 against a period for which the GLH records were
purged, or it will change your historical balances in the GSB.
3. If you archive GLH you should archive the related GHH record which are
the journal headers, the GXR's for those GHH's, and related GLA records
which contain journal line analysis data.
4. Be aware that archiving GLH may interfere with some methods of account
reconciliation. For example, the accounting department may reconcile the
Accrued Purchases Liability by macroing the PO and PO line # into analysis
fields on the inventory receipt model and A/P invoice model. They then write
a report, grouping the journal lines against that account by PO and PO Line
# then totaling the debits and credits. This would allow them to see POs
lines where the amount accrued doesn't match amount costed. They then
compare that report to the subsytem unmatched receipts report and reconcile.
If you delete records up to a certain point, then items received prior to
that point and costed afterwards will never come off the report. So by
removing records you may mess up a reconciliation reports effectiveness.
5. Try grouping and counting GLH records by reason code. Look at the
distribution. Find the reason codes with the most records and ask accounting
if any of them are candidates for summarization.

Additionally for GXR's you may consider that the [Subsystem] button in
account inquiry will not work on any journal line for which the GXR was
purged.

This will only work with Informix. If you don't mind closely monitoring the
file, you could unload the table, then reload it setting the initial extent
size to the current size of the file and the first new extent to a smaller
number. This will cause it to gobble up your disk in smaller pieces as it
allocates additional extents when the file grows. Just be careful as the
number of extents allocated to the file approaches 200 you will need to
unload, reset the extent sizes, then reload. It could get ugly if the DB
engine could not allocate any more extents to the table. There is an onstat
command that will tell you the current size of the file and how many extents
it is using. When you load the file it will create an extent the size of the
initial extent then put the current data into it. Then as you use the system
and records are added, it will add extents the size of the first new extent
setting. The first 16 extents created will be the size of the first new
extent size setting. The next 16 will be double the first, the next 16
double that, and so on until around 200 extents. The first new extent size
setting can have a powerful influence on how much disk space gets allocated
as you approach 200 extents. I think Informix recommends that the first new
extent size be set to 1/16 to 1/8 the initial size of the table.

Maybe if you reload the files using a smaller font they will take up less
space.


Geo.

+---
| 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
+---