× 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: RGZPFM & RCLSTG
  • From: MacWheel99@xxxxxxx
  • Date: Tue, 19 Dec 2000 16:49:37 EST

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


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.