Re: BPCS 405 CD & Re-Use Deleted Records

from Al Macintyre

Summary
=======
Check out SYS12* series of BPCS programs - whose documentation is found in SSA
document SSARUN92
Check out IBM's RGZPFM parameters
Check out MC forum on AS/400 Packages - specifically replies to my BPCS war
stories (URL given in BPCS_L thread "New to this Listing")
Our 11 Gig disk space was 85% consumed at the beginning of February - now it
is 72%.  The savings have come from cleaning up BPCS files whose deleted
records were building to infinity, getting approval to eliminate an unused
environment, and downsizing our Machine/36.

I have learned a lot of info from a lot of sources on this topic in the last
month & have been applying it & here is an update, which might also be of
interest to the thread "BPCS Documentation for Dummies."  I had passed onto
SSA a lot more gory details than I posted on the forums & also cited the
recent News/400 articles on the topic, and some advice I had received from
other quarters.

My questions - many have been answered
==========

Are there BPCS reorg functions that get rid of deleted records without
clearing active contents?  How often should they be run?

Are there BPCS files for which SSA has made no provision for reclaiming disk
space for which we have to resolve?

Do you reccommend that we use IBM's RGZPFM for files whose # of deleted
records reach some threshhold and/or CHGPF to REUSEDLT (reuse deleted space)
automatically?

After I had called these questions into SSA Help Line, I learned that RGZPFM
can resequence physical to agree with some logical to improve Query
performance.  Thus I also need to follow-up ... what might such an action do
to BPCS performance & what happens to any good records not contained within
the logical used?

A related concern is that many records are coded inactive by BPCS, but not yet
deleted.  What is the mechanism by which filled order requirements (quantity
shipped equal or exceeds quantity ordered) are purged from the BPCS system ...
is it a combination of SYS800 parameters & other ECL lines open on same ECH
order?   Does BIL900 or some other program look at the data that is there &
the SYS800 story to determine what to purge?

We happen to have a couple of hassles for which this is not an academic
question.

Traditionally at end-fiscal, we crank our order numbers back to ONE - less
keying, and we also started them at ONE in the mid-year Y2K conversion to BPCS
405 CD.  Well come to find out that history on "purged records" works
differently in 405 CD than BPCS/36.  If we had an order say 1234 last October
& it was filled & completed & shipped & closed, now we have same order number
1234 for different item different facility different everything, except SFC300
is showing history on both 1234's all intermingled.

On BPCS/36 the detail data in SFC300 was from FOD & FMA which went away with
CST900 order purge, and history was in FLT controlled by SYS800 parameters.
Silly us assumed BPCS 405 CD would use similar logic, even though JIT is in
the picture.

Then there is another problem due to inadequate training on the differences
with RESUPPLY ORDERS.  We were accustomed to using PO's for inter-company, and
a bunch of people have been processing inter-company according to the logic of
PO's while other people have been doing the RO logic.  This has resulted in
duplicate requirements that need to be cleaned up.  

Our Y2k consultants basically said to use a quickie fix to force quantity
shipped to read the same as quantity ordered for those inter-company customer
orders that were involved in this big OOPS, which I have it on good authority
is still being compounded.  So, I am very interested in knowing what is the
mechanism that causes BPCS to realize that a customer order needs to be purged
when ECL has been faked but ECH still thinks there are requirements.

Well I did not go into all of this in my call to SSA regarding the RGZPFM
adventure - I have collegues calling them regarding the BBL adventure & other
related topics.

SSA Answers
==========
Running IBM RGZPFM and changing REUSDLT default are not a problem.

I had been running RGZPFM several times a week, and decided to leave REUSDLT
alone when I learned about the I/O performance issue.

For how often to run a specific 900 program, call SSA help line & speak
directly with someone who specializes in the department of that program.

They brought my attention to SYS120 & SYS122, which I had seen, but been
afraid to touch since the apparent help (menu) was so vague.  Prerequisites to
deleting data via these programs include:

Read help text & follow the recommended precautions & have a restorable backup
tape on hand.  These programs may take a large amount of time to run so SSA
reccommends we run them over a weekend or 3 day holiday.  Since I had been
doing 20-30 RGZPFM's per nite & finding that most files took less than a
minute & rarely did one take as much as 5 minutes, I took my chances.

Before backup I run my XDSPFDEL which places all the candidates in *OUTFILE
Query as suggested by Debbie, then by the time backup is finished I have
marked which ones I will do tonite.  SYS120 is much faster to run than RGZPFM
when we are doing a bunch of files, because of the amount of keying I had, but
RGZPFM is faster if it is only 1-2 files, because SYS120 has to build a list
of physicals.  Also the SYS120 list is incomplete.  One nite I thought I would
do ZMO because it has 800 deleted records (1261 good records), but SYS120 only
goes thru YTH file.

I need to be aware of file interdependencies.  Well I don't see where this
applies to SYS120 if I limit my selection to the elimination of records
already coded as deleted.

DO NOT physically delete records from SSA files using IBM commands, except for
records in history files (e.g. ITH) due to record dependencies needed for BPCS
to work right.  That is good advice.

I knew that, but I have got co-workers 2nd guessing me in the aftermath of SSA
Help Support walking them through BPCS Security Back Doors.  All I approved
was to use DFU to look at what was in some records before & after vanilla
updates, so we could try to reverse-engineer what all those fields were used
for to help us create some queries, in the absense of SSA documentation
explaining all that.  I have people who know enough to be truely dangerous,
and fortunately my boss agrees "You screw it up, you fix it."

My further digging
=============
Where is the help text?  I want to read the help text on job-X without
actually running job-X.  Panel groups (QPNLSRC) source code for UIM is where
we find help text without actually running the BPCS job.  SSARUN92 document is
also invaluable on this topic.  I have a new question after wading through all
this - is there value in reorganizaing all BPCS files (that SYS120 will allow)
irrespective of this deleted space concept?  I suspect so, but my AS/400 know-
how is not yet up to that.

SYS122, which I have not tried out yet, clears data from selected BPCS data
base members.  We have some baggage from recent bombs in shipping & billing
for which we may need to clear data that BPCS can't get at any more.
Fortunately my dangerous partners have learned from the episode when I was
screaming "Hold up your right hand ... Repeat after me ... I will not ... use
DFU to change BPCS stuff ... except explicitly where SSA help line says ... to
fix a precisely defined scenario." because I now have 2 files where I have
been told SSA said to those users that MIS will need to clear out the good
records, because that is a work file that should not contain any permanent
records.

SYS124 deletes selected members.  When we were in the Y2K conversion, the work
station ids were 95% pass-thru from M/36, but now they are on-line renamed due
to what we learned about BPCS substring work areas using part of a work
station identification, which means we have tons of members all over creation
with obsolete names.  We also have files that came from SSA with strange names
of unused members.  I will be interested to see how much disk space is
occuplied by empty members since we have thousands of them.

This saga will continue

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