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



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

Replies:

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.