RE: RGZPFM & RCLSTG

Sorry all... hit the wrong button.

Barry M. Blackwell
Kimberly-Clark China
bblackwe@kcc.com
Tel: 8610-6561-6688 ext 2609
Fax: 8610-6561-4280


-----Original Message-----
From: Genyphyr Novak [mailto:novakg@ssax.com]
Sent: Thursday, December 21, 2000 2:23 AM
To: BPCS-L@midrange.com
Subject: Re: RGZPFM & RCLSTG


Hi,

There is a BPCS Clean up document available on OGS Online in the performance
section that explains regular file clean up for V6 releases and when and why
you would want to use the RGZPFM command. It doesn't cover a RCLSTG. There
are times you want to reorganize files, even though BPCS V6 is shipped with
database setting of reuse deleted records turned on. Mainly this is when
files have a high percentage of deleted records on them, and you are
unlikely to reach the point of reusing those records in the near future. I/O
efficiency improves if the file is reorganized at that point.

Thanks

Genyphyr Novak
SSA GT


----- Original Message -----
From: "Rob Stagis" <stagis@fansteelvrwesson.com>
To: <BPCS-L@midrange.com>
Sent: Wednesday, December 20, 2000 6:53 AM
Subject: RE: RGZPFM & RCLSTG


> *grin* Every time I go in there, I get nervous.....I trust to my own
> devices.....lol.  Thanks, Mac.
>
> -----Original Message-----
> From: owner-bpcs-l@midrange.com [mailto:owner-bpcs-l@midrange.com]On
> Behalf Of MacWheel99@aol.com
> Sent: Tuesday, December 19, 2000 4:50 PM
> To: BPCS-L@midrange.com; MIDRANGE-L@midrange.com
> Subject: Re: RGZPFM & RCLSTG
>
>
> >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 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
> +---
>

+---
| 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 e-mail is intended for the use of the addressee(s) only and may contain 
privileged, confidential, or proprietary information that is exempt from 
disclosure under law.  If you have received this message in error, please 
inform us promptly by reply e-mail, then delete the e-mail and destroy any 
printed copy.   Thank you.

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