|
This is a topic which has had traffic in the archives, although not
recently.
There are some gotchas to be aware of.
Third party places have developed software to cleanup BPCS for us, where
they have thought of everything that SSA forgot, and can be a royal pain
for us to figure out. If you interested in this, start with the archiving
packages, which can include getting rid of garbage records for you, and
still be accessible to trouble shoot.
This is an area in which the cleanup guidelines are extremely BPCS version
specific ... what works for one version will bomb for another ... is your
plant in Germany on the same BPCS version as you are?
We are on 405 CD, so anything I say, you need to ask people on V6 for what
if anything different.
Some things that can get messed up in BPCS are not easy to see or stumble
over (e.g. costs not add up to bucket zero), so it generally pays to have
sets of reorg run at regular times, when it is safe to do so, and have
some queries that look for specific problems (like negative costs) ... I
have a bunch that I run every nite ... if query empty, great I kill it,
but when there's a problem ... text on top of the query reminds me what it
is we do to fix this or that recurring problem.
BPCS documentation exists, but the quality varies greatly.
Generally you need to run these reorg tasks in an extremely constrained
sequence to get best value out of them.
There are a LOT more than those you listed.
Most of them are on the SYS/23 menu.
The SYS/23 menu has options that are safe to run any old time right next
to options that are high impact high risk, so we have moved to our menus
in several categories
* do this to fix problems on the fly
* do this on weekends when no one else on BPCS
* do this during end fiscal, at one particular step in the process
Let's suppose you have users in programs that use the files involved in
the cleanup. This can corrupt the cleanup. Jobs run very slowly. Some
stuff can bomb. You need to be running the cleanup on a system in which
no one else is in BPCS at the same time.
SYS120 not only ought to be run weekly, when no one on the system, but if
it is done before a shop order purge, the purge runs much faster ... in
our case the SYS120 takes like 45 minutes, then shaves 2 hours off CST900
run time. There may be other periodic jobs with similar impact, purge is
the only one I noticed this on so far.
Note that SYS120 gets at a LOT of files, but NOT all that need reorg to
eliminate soft coded for deletion records. You need to search out the
exceptions and write your own cleanup support, and likewise only be doing
that on a system when no one else in BPCS.
On weekends when no one else on the system, I do
SFC990
ORD990
SYS990
INV971
INV972
ACR970
ACR972
MRP990
in that sequence
For these, no harm done if get out of sequence, just not get full benefit.
Note there is an ORD991 report that I give to customer service
Note that before running this stuff, I have a report on what will get
wiped, so if it got wiped because it got corrupted, we have the data to
re-enter it
I also have a report on what customer orders got deleted since the last
time I ran that report
I also have a report on order changes that violated lead times
Some reorg clears data associated with month-to-date, and should only be
done at a particular point in the end month process ... we do ours right
after INV900 backup.
Some tasks take HOURS to run, especially if you have never done them
before. We have check list of stuff to do, with estimate of normal run
time as part of the list. When something runs in wildly off normal time,
that is clue something may be wrong.
Some reorg is flawed, and you need to write your own. Examples of flaws:
* delete control record associated with some detail file ... BPCS now
ignores the detail records, even in the purging
* a shop order purge needs access to inventory transactions and labor
transactions associated with that order ... flawed purges can wipe out
such transactions on old orders still in existence
* some reorgs write to backup media what got purged, using the identical
name as the last time, not based on FILE.YYMM for example.
* code records for soft deletion but they never really go away
and don't forget those pesky members, data areas etc. that are named after
work station addresses. If yours, like ours, are somewhat volatile, then
every work station naming you ever had, probably has a score of those
things hanging on some place.
Hi,
I have a question on BPCS V6.0.04 Re-Organization Programs.
We recently had an issue with incorrect customer allocation on items.
On advice from our plant in Germany we ran INV971 for resetting customer
allocations which seemed to address the problem.
Since we have started to run this program we have been advised run the
following programs in the order listed below
SFC990 - Cleanup FMA & FOD Files
ORD990 - Cleanup ECL & ECS Files
INV971 - Reset On Order Allocated
SYS990 - Cleanup Allocations
My questions are as follows
(a) in running INV971 on it's own are we causing any potential problems,
ie data out of sych
(b) is it advisable to run all programs above together ?
(c) can the programs above cause any potential problems that we need to
be
aware of ?
Kind regards,
Yvonne Nugent
--
This is the SSA's BPCS ERP System (BPCS-L) mailing list
To post a message email: BPCS-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/bpcs-l
or email: BPCS-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/bpcs-l.
Delivered-To: macwheel99@xxxxxxxxxxx
-
Al Macintyre
http://en.wikipedia.org/wiki/User:AlMac
http://www.ryze.com/go/Al9Mac
BPCS/400 Computer Janitor ... see
http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.