FASTR Balance Auditor files?

[tpayne]

Files F8308/F8310 in the Common Library are 2gb and 12gb respectively.
Both are multi-member files and described as "FASTR Balance Auditor".
Can these be re-organised in any way?

I searched through the World forum and could not see any postings
related to this.

Thanks in advance.

 

[Neilwar]

Ouch! Do people actually use the balance auditor or are they just copying FASTRs that are producing files and not using them? (It's under "Override default information" then page down.

The Balance auditor should only be used where really necessary as it not only creates very large files (as you have found out) but also slows down the FASTRs

You might find that people don't even know they are creating them - if this is the case the FASTRs can be changed and the members deleted.

HTH

 

[Colin_Hugill]

Tony,



I see Neil Warrington has already given you some comment so nothing is
needed from me on the background stuff.



Also, I posted something several years ago about FASTR performance etc -
Neilwar can give you the JDEList reference in two secs. He has already
searched and found it (that's a hint Neil !!!!).



The balance auditor files are supposed to be purged automatically by JDE
about two days after they are created - but...!!?? Sally White might
have some more detailed knowledge of this.



Yes you can "reorganize" the balance auditor files but it would best be
done using IBM commands, firstly though you have to find the FASTR
versions that create/update these members and make some decisions
whether or not these should continue to do so.



My two cents worth is - very few (if any) reports should be creating
balance auditor files on a regular basis.



My suggested approach, which depends on your relationship with your
users and your site rules (i.e. adapt my approach to suit yourself):-



1. Make sure you have last night's backup just in case there is a user
who has been using the Balance Auditor files to store a "point in time"
report by account. Use CLRPFM to clear all the members in the balance
auditor files, and then run a RGZPFM. this will get back disk space
fast. Don't worry; they will get updated as needed next execution of
any FASTR with auditor turned on.

2. Use QRY etc to identify all FASTR definitions that have the Override
Default for balance auditor turned on (probably in F8303 but I can't
remember - a quick look at the file with QRY or SQL will help you find
out). List out the versions.

3. Have the users review all these versions on your list and have them
identify and justify those that are really necessary

4. While the users are about this task, use DSPFD to an "outfile" (you
need to check the parms 'coz you want details about each member) - use
this outfile to identify all the ones that have an "old" last
used/changed date. If there are a lot of old members then decide on a
nice cutoff date. Write a simple CL to read through the outfile and
execute RVMBR (sorry I can't remember the actual CMD spelling - but it
is remove member) for any file with a last change date before your
cutoff date and where the member is not the usual IBM default member
name. This will clear all the old stuff en masse and get some more
space back - but run your reorg again.

5. When the users get back to you with their list - use RVMBR to knock
off the rest of the problematic members, then, go into FASTR and change
the override defaults (or use WW in update mode).

 

[Neilwar]

Re: RE: FASTR Balance Auditor files?

I think Colin was dropping me a subtle hint

Colin's earlier post is at
http://www.jdelist.com/ubb/showflat.php?Cat=&Board=W&Number=24172&Forum=f2&Words=&Searchpage=0&Limit=25&Main=24088&Search=true&where=bodysub&Name=&daterange=1&newerval=1&newertype=w&olderval=&oldertype=&bodyprev=#Post24172

It makes very interesting reading for anyone using FASTRs

 

[SallyWhite]

Re: RE: FASTR Balance Auditor files?

Thanks, Colin, but I don't have experience with these two files. I like the idea of a CLP that does a DSPFD *MBRLIST to an *OUTFILE, and reading the outfile to check the last used date to issue a RMVM (remove mbr) or CLRPFM (clear PF mbr).

Your older post that Neil referenced is an excellent overview of FASTR performance. At my last job, we had a very large F0902 (~10 million records) and had the FASTRs restricted to a few savvy power users. We used % menus to set up a series of reports for month-end reporting. Someone had devised an alternate approach to your 2nd item in the old post, which was very effective and greatly reduced the time required to change general specs for a new fiscal year: Create one version to build a workfile that includes all the business units, ledger types, object accounts, and fiscal years required for all month-end reporting for the current fiscal year. All subsequent FASTR versions run off the workfile. The workfile build ran for approx 2 hours during non-peak times. Each subsequent report ran in under 2 minutes, despite the workfile having a large number of rows. All FASTRs ran in a separate pool.