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