BPCS AS/SET Programming -- BPCS-L

Hi all

Anyone interested in teaching me ASSET programming over the Web/Email. I
done alot of programming in other languages, including introduction to
RPGILE.
I am prepared to pay.

Rgds

Ronald.

-----Original Message-----
From: bpcs-l-bounces+ronald=techdata.com.au@xxxxxxxxxxxx
[mailto:bpcs-l-bounces+ronald=techdata.com.au@xxxxxxxxxxxx]On Behalf Of
Clare Holtham
Sent: Friday, April 15, 2005 5:42 PM
To: SSA's BPCS ERP System
Subject: Re: [BPCS-L] ** Pick Release has poor response time **...


Hi Genyphyr, Sandy,

The workfile cleanup gives some benefit, but not nearly as much as the
database tuning using indexes. As Dave Trevino pointed out and IBM will
confirm, SQL indexes are much better than logicals....
And the purge programs are just that. Whereas the Archiving (Locksmith) will
allow old records to be removed to another database in an ordered manner,
avoiding 'orphaned' data, and allowing users to still look at the old data
if they want to.
Sometimes it is not the obvious files that are causing slowdown problems.
Files like the ZPD and CMF are accessed constantly, and don't forget that
SQL will read all the 'deleted' records every time too.
It is worth using DSPFD *Mbr to list the files that have high increments and
high numbers of 'deleted' records, and fixing them with CHGPF and RGZPFM.
I would recommend a combination of this housekeeping plus the database
tuning and archiving, and of course the workfile cleanup is an essential
part of that, and should probably be incorporated in overnight processing.
We and others (e.g. Unbeaten Path) offer this service, not including the
Archiving,  as a one or two day exercise which should be considered as
Preventive Maintenance on an annual basis. There's nothing like having happy
users!

cheers,

Clare

Clare Holtham
Director, Small Blue Ltd - Archiving for BPCS
Web: www.smallblue.co.uk
IBM Certified iSeries Systems Professional
Email: Clare.Holtham@xxxxxxxxxxxxxxx


----- Original Message -----
From: "Genyphyr Novak" <Genyphyr.Novak@xxxxxxxxxxxxx>
To: <bpcs-l@xxxxxxxxxxxx>
Sent: Thursday, April 14, 2005 7:58 PM
Subject: RE: [BPCS-L] ** Pick Release has poor response time **...


>
>
> 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
>
> --
> 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: Clare.Holtham@xxxxxxxxxxxxxx
>


--
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: ronald@xxxxxxxxxxxxxxx