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

Version 6.1 should no longer create members on files.

You should also check the documents files for pickers and re-organize
that I know that it will help speed up processing.

Also, I know that when you ran the order purge you had problems, but, If
you are still on maintenance make sure that you have the latest BMR's
for the ORD900 suite of programs.

Otherwise you will be forced to create your own purge programs.

But you have to clean up the database and re-org the required files.


-----Original Message-----
From: bpcs-l-bounces+dsweeney=phoenixbcinc.com@xxxxxxxxxxxx
[mailto:bpcs-l-bounces+dsweeney=phoenixbcinc.com@xxxxxxxxxxxx] On Behalf
Of Al Mac
Sent: Wednesday, April 13, 2005 7:37 PM
To: SSA's BPCS ERP System
Subject: Re: [BPCS-L] ** Pick Release has poor response time **...

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.
-- 
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: dsweeney@xxxxxxxxxxxxxxxx