|
We found out through earlier discussion on BPCS-L about the importance of running various BPCS file reorganizations and purges which are supposed to remove old completed records. Then we have Query/400 to list records coded to go away, that did not go away in purges & end-fiscal runs, then try to analyze how come. Literally millions or records go away in our regular cycle of BPCS file reorganizations..
For example, shop orders purge if the final operation is reported as having made all that is needed, and all the materials needed to make the product were in fact consumed. We can then resolve anomalies in our reporting, and get our inventory more accurate, and these old orders go away through normal cycle of regular shop order purges.
We learned on customer orders that all sorts of other files interlink by line # in original order, so an order should not have its line #s resequenced to remove completed lines. Also some BPCS programs read through orders line by line, and if hit a missing line, they just quit, not go to next available line. Thus if any line of an order is needed, all lines of the order must be kept.
So, I have program that reads all lines of all orders to find orders where 100% of the lines have been fulfilled, and the last activity was more than 2 years ago (the cut-off that my people decreed), then for that order, delete the ECH. Then I run the BPCS reorg that removes records coded for deletion, then I run the BPCS reorg that remove lines for which the header is gone.
We have had some facilities close, combined. We got help moving engineering records across facilities, since our # systems are facility-dependent. With CMF, you can zero selected combinations, but that does not remove the records, just zeros stuff. Well we can use BPCS to populate some other cost set facility combination, then SQL to remove records where their costs are all zero. But then we also have to remove the corresponding CIC records.
Al Mac Tom wrote
midrange.com
We are on V6.04. Some time ago we had problems, not so much with disk
usage as the fact that, if left to it's own devices, BPCS builds up data
at a staggering rate of knots and standard tasks begin to take ages to
complete as programs plough their way through millions of records.
To alleviate this and before I knew what archiving tools were available,
I wrote some programs of my own to take data off live BPCS files and put
them onto archive files that could still be accessed by in-house
enquiries and reports and retrieved back to the Live system in case of
problems. From there it would be a short step to actually deleting data
to make disk space.
I archive the following data :
Customer Orders : ECH, ECL, ECS and ESN
Shop Orders : FSO, FMA, FOD, FLT and ESN
Purchase Orders : HPH, HPO and ESN
Pick List Pribt File : IPP
Print Detail Work File : ZPD
Material Requirements File : KMR
Inventory Transaction History File : ITH
Promotions & Deaks Master File : PDM
Special Prices File : ESP
Cost Master File : CMF
You need to carefully determine your criteria to make sure you don't
archive/delete anything you need.
After consultation with our Accounts Department, we also archived some
old years off the G/L files - eg GLH, GHH, GSB - that were completed and
this took off millions of records.
So, if you can find software that does the job for you - great. But if
not, there are ways of doing it yourself.
Tom Molyneux
-----Original Message-----
From:Al Mac
Subject: Re: [BPCS-L] Data Purging
I wanted LOCKSMITH, because it works for ALL files, then we could
decide
what to purge from there, but company profit margin too low to
support
add-on software I thought we needed for improving productivity (not
just
LOCKSMITH), so I had to develop a series of programs to
* Identify BOM & Routings for parts we have not needed in X years
* How old is data in various files, then programs to get rid of
stuff
older than something people can agree to ... like 2 years ...
stick
in the scheduler to send reminder message to me every 3-4 months
that
it is about time to kill the oldest data in whatever file set,
and
remind me name of program to do that ... documentation in that
program
includes what the checks & balances are to make sure it goes
right
* When we close a facility, what data in it do we need to keep.
* Some files you gotta be careful with ... such as customer orders
use
line #s to navigate ... you can't just get rid of lines that are
dead,
and be able to access rest of the order.
* As i developed the KILLIT software, I started with files that
either
were most bulky in disk consumption, or were giving humans
conniptions
of the run-out-of-#s kind
You might also look at software duplicated when new releases BMRs
etc.
come in ... for example, how many execution & source members do you
have
of ORD500 & how big are they? Can you identify oldest & is it Ok to
kill
oldest, only keeping most current versions?
Letting this topic get to 90% is in my opinion a very serious
disaster for
your company computer system. During a BPCS conversion we went over
100%
& we had data lost & corrupted. I have seen IBM guidance saying.
* At 90% it is time to shut the computer system down entirely
awaiting a
hardware solution.
* At 80% you order whatever fix ... software solution and/or
hardware
solution & get it installed before you hit 90%
* At 70% you figure out what you gonna do & get it implemented so
you
not get to 80% ... we currently struggling at just over 70%
because
the work load on me means I not have as much time for this as
Iought
to spend on it, and I have not been able to convince higher
authorities of certain solutions I think we need.
Hi,
We r using BPCS 6.04 on AS400.
Server Hard Disk is filled upto 90%.
I want to purge data for specific period. (i.e. from 01-04-1999 to
31-
03-2003.
can anyone tell me how to purge this data.
Vitthal Kulkarni.
Sys Admin
Matsushita Washing Machine I pvt Ltd.
India.
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.
