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
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.