Re: ** Pick Release has poor response time **... -- BPCS-L

We also have been running the same programs for years. We basically add new reports that access the BPCS data base, and very occasionally add new logicals. I guess every other year or so we add a new file.

Our OS/400 at V5R1

AS/400 disk space about 70% consumed (it was 45% a very few years ago, and a few years before that we had a serious crisis when we found out about % above what IBM reccommends, so this growth is a concern ... the problem is much bigger than the files)

You can do an *OUTFILE list of BPCS files and look at statistics like which have excessive numbers of members ... also review the other kinds of BPCS objects that create members based on work station ids. Customer Order files are particularly sensitive to this, having empty members for work station names that not exist any more. This can screw up the logicals, as I found out when I tried to add a new logical to a physical file that had too many members.

GO CMDDSK ... you will need a high 400 security officer to mess with this 1. Retrieve Disk Statistics ... I have this on GO CMDSCDE to refresh in the wee hours of last calendar day of each month, since it takes a while to run. 2. Print reports of the statistics, and be careful to be selective ... e.g. libraries only, limiting to those with 1,000 bytes or more Or just go after BPCS files ... you will be surprised how much disk space is eaten by files with lots of logicals. I have not got rid of any, but if I was to do so, I would take a hard look at date of last usage, so as not to get rid of anything that might be needed in once a year stuff like end-year fiscal. Is there any old stuff you not need any more, such as from a conversion, or safety copies of repairs that are now history? Is there anything that has not been used in eons?

The archiving products, offered by Milt and others, can do wonders for performance, but you also need to consider disk space. How far back do you keep various kinds of history, for what reasons, and how far back do people normally need to access data in INV300 etc.? We keep our history for a time period of almost 2 years, but most people only need to see the last 2 weeks, thus with archiving product we could get massive performance improvement on the same 400 box, still keep access to the records for those odd occasions where we do need those ancient records, and the disk space hit is not significant. This also impacts how long INV900 runs in end-fiscal ... for us it is 3-5 hours without archiving.

We IPL weekly via GO POWER schedule (wee hours of weekend) We run a full spectrum of BPCS file reorgs weekly (approx a dozen programs) but know full well that is not enough. Some of the reorg programs do not work very well, and some are plain broken. We added to the collection.

You need to have a conversation with the person who told you not to run the reorg programs to get an understanding why.

Some of them are fiscal sensitive ... if you going to run them, do ONLY after certain steps of end-month processing, and if you got ample time ... some take MANY HOURS to reach a conclusion. Cleaning up ILI and IWI is like that. Do not be doing them in mid-month between fiscals. These take an eternity to reorg, but we make the effort to do so a month before a physical inventory because we do not want tags printed for locations that have been zero for months.

The vanilla menus have right next to each other options that are safe to run almost at any time, right next to options that are sheer disaster to run by accident. We copied to our own menu those options that are Ok to run in middle of month when no one else on BPCS (like right before or after a backup), and we placed them on the menu in the sequence in which they are to be run.

I wrote a CL to get *OUTFILE directory of BPCS files snapshot, to be compared with other periodic snapshots, to help identify which files seem to have unusual growth. I wrote an RPG that uses SQL to access files that are in that *OUTFILE to identify the oldest date by file. That program also does correlations ... this file has how many records on an item that does not exist any more, for example. This helps me prioritize what to clean up, when time permits, and deletion approval exists.

We have about 80,000 items Our largest file is ITH with 2 million records ... you do know that the "B" transaction gets posted there through the shipping process? Our second largest file is CMF with about 1.4 million records Routings third with just over 1 million records I get so I am familiar with the top statistics, then WOW notice when something changes dramatically.

BPCS has its strengths and weaknesses, at least with us at 405 CD.

One of its weaknesses is that it is great at adding records but a sorry excuse for a software package when it comes to getting rid of stuff we not need any more ... it lets us close orders, and customers, but keep ESN notes for situations that not exist any more. it lets us delete items, then keep history on those items to infinity, then if the item # is reassigned to some other purpose, its history is corrupted for the first month.

When you do a shipment, it populates file ESH and ESL, and there is NOTHING in vanilla BPCS to clean out old shipment records ... you have to setup something to clean them out yourself ... get a consensus what's needed ... like the last 2 years worth.

When we first found out about BPCS reorgs, we had over 100 million General Ledger records coded for deletion and just sitting there.

When an order line is completed, we can't get rid of it, without corrupting access to the other lines on the same order. Try doing a count of how many order lines you have that are no longer needed relative to the number of lines you do need to keep ... in our case the ratio is over 10 to 1.

I recently been trying to modify ORD550, and my efforts failed, so I love to see this kind of discussion to help me do a better job of comprehending what is going on.

- Al Macintyre http://www.ryze.com/go/Al9Mac Find BPCS Documentation Suppliers http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html BPCS/400 Computer Janitor

this is off the top of my head, but i think there was a discussion about
this several months ago. many people replied that you should purge the
IPP but there is no 'canned' BPCS program to do this.

>>> sandys@xxxxxxxxx 04/13/05 11:28AM >>>

Hello All,

BPCS Version: 6.01.01
AS/400 Operating System: V4R4
% system ASP used: 47
IPL: 2 times a month

When we run the program for Pick Release ORD550, the processing
keeps getting slower and slower.  We have been running the same
programs for several years.  No updates to BPCS or operating system.
The response time was acceptable a year ago.  We only select one
order at a time.

My only guess is that our databases have been growing and growing,
but I don't know which one(s) would cause this to happen.  How
big of a database is to big?

I've been told not to run the reorg. programs, so I have not done
this.  Should I do this manually?  Which ones?

The order purge program was run a couple years ago. Though ending
in errors, so I haven't ran it since.

Here are some record counts if that helps:
ECL  158,000
ECH   72,000
ESN  130,000
IPP  102,000
ZPD  449,000
LLL   74,000
ELA    1,000
IIM  105,000
ILM      100
ILI  307,000


Any helpful direction would be greatly appreciated, since I'm getting
beat up by the users...

Thanks,
Sandy

Hydro Carbide, Inc.
Latrobe, PA  15650
Voice 724-539-9701
Fax    724-539-0326


-
Before posting, please take a moment to review the archives
at http://archive.midrange.com/bpcs-l.