Hi Sandy, 

When there is a gradual slow down over time, you need to look at why
that could be happening. Work files getting full of junk records are a
prime suspect. 

If you are on OnePoint support there is a document you can get from the
support center called "BPCS Work File Cleanup.doc" which lists out all
the BPCS work files and how/when to clear them. That normally explains
this type of gradual slow-down over time. A lot of customers submit
weekly batch jobs to clean these out when users are not on the system
after backups have run. 

There are not many logicals built over those work files because the
number of records in them should be quite small and so under normal
conditions a logical file is not ever required by SQL to read those
records quickly. Records do sometimes get left in them as 'orphans' when
jobs end abnormally.

Also check with support center for any performance BMRs on that program
(which may just deliver a new logical file or a programming change).
However a programming issue normally would not explain the gradual slow
down.

Other suggestions previously made by people regarding cleaning unneeded
ZPD are also very good, and running the general cleanup programs that do
exist in the product (purge programs) will keep the number of records
down. In general I don't think the number of records in your physical
files are extreme. 

If something in a purge program ended in error before, a support center
call would normally be the way to resolve that. 

If you are not on OnePoint support, then I suggest hiring SSA
professional services to come out and do this analysis for you on a
one-time basis. 

Thanks,

Genyphyr Novak
Senior System Software Engineer
SSA Global R&D

message: 2
date: Wed, 13 Apr 2005 14:28:13 -0400
from: Lat - Sandy Sever <sandys@xxxxxxxxx>
subject: [BPCS-L] ** Pick Release has poor response time **...


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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 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.