|
I agree with Peter as well. Work files should never require logicals, and any DBMON showing this is only pointing out that your work files were left with excess records due to some sort of program crashes or other strangeness, and that they should be cleared up. This is a clear example of why it is important to not only understand what DBMON recommends, but to also understand BPCS files and how the applications use them. Knowing that work files are meant to be sparsely populated, and thus not require logicals is an important concept. Building logicals over work files speeds up the processing, but not as much as clearing the files will. It also encourages unnecessary database bloat and overhead in maintaining truly unneeded data paths. SSA R&D does not recommend a certain set of logicals be built for all customers for any of the BPCS applications. If that was the case, R&D would deliver them. When it is found that a new logical should be delivered because it will benefit the most common code path used by clients, R&D will add that logical to the ADK repository and deliver it in a BMR fix or a new release, or will list them on the BMR as a workaround until the BMR is completed (in case a code change is done rather than a new logical). Several performance BMRs have been passed that deliver new logical files for just this reason. Remember that the term 'SSA recommends' is like hearing someone say 'they said on the news. . . '. Who the 'they' is, is important. For example, was the SSA person who mentioned the need for these logicals speaking as an individual to an individual company to resolve a specific problem - or were they speaking for the entire company about a logical files policy? In this case if an SSA consultant made such a recommendation to put logicals over work files, in my opinion they were mistaken in that recommendation. SSA R&D publishes product bulletins and announcements on OGS Online which give BPCS performance tuning guidelines, and also co-authored the IBM Redbook for BPCS which lists the official recommendations for handling performance issues in BPCS applications. Recommendations for all customers are posted as product bulletins, and if a magic list of recommended logicals existed, it would reside there. However, there is no such document, for reasons I have just explained. Thanks Genyphyr Novak SSA -----Original Message----- From: pgreenfi@ssax.com <pgreenfi@ssax.com> To: BPCS-L@midrange.com <BPCS-L@midrange.com> Date: Tuesday, February 15, 2000 3:47 PM Subject: Re: BPCS 6.1mm performance and the AS/400 - more ord performance >I agree with most of what Peggy is saying except for: > >"SSA recommends the following logicals be build over order entry files:" > >SSA recommends that you investigate performance problems as they occur by using >DBMON. This will assist you in defining which Logicals are required for your >implementation. Creating Logicals suggested by other installations may not work >for you, and in some cases can actually impede performance. > >Work files such as ZEF, ECLW, ECHW, etc. should not require logical files for >performance as they should not contain many records. If they do contain a >substantial amount of records then there is possibly another problem. > >Changing the force ratio to '1' was a work around for a problem caused by >Parallel Processing which has subsequently been fixed, and should not now be >required. > >Regards >Peter > > > > > > > >"Peggy A. Heritz" <pheritz@CroweChizek.Com> on 02/15/2000 09:36:46 AM > >Please respond to BPCS-L@midrange.com > >To: BPCS-L@midrange.com >cc: (bcc: Peter Greenfield/SSA/US) >Subject: Re: BPCS 6.1mm performance and the AS/400 - more ord performance > > > > > >More info related to performance tuning for green screen order entry. > >In addition to ZEF, there are a number of work files that should have no records >in them when no one is using BPCS: > > >ECHW >ECLW >ZPD >EWR >ZQWAP >QQWRP >ZQWSP >DQH >DQD > > >In one client situation, after clearing these files, some responses that were >originally 45 seconds to 1.5 minutes went to around 5 seconds > >Additionally, SSA recommends the following logicals be build over order entry >files: > >file key field(sequence) > >ZEF EFKEY4(ASC) >ELCW CLSGRP(ASC) >PDM DMNMBR(ASC,DMLINE(ASC) >ECH HEDTE(DSC),HORD(DSC) >ECHW HORD(ASC),WKTYOR(ASC) >EST TCUST(ASC),TSHIP(ASC),STADTP(DSC) > > >Peggy Heritz >Senior BPCS Specialist >Crowe, Chizek & Company, LLP >http://www.crowechizek.com/scg/ >phone: 219.236.8698 >fax: 219.236.7615 > > >+--- >| This is the BPCS Users Mailing List! >| To submit a new message, send your mail to BPCS-L@midrange.com. >| To subscribe to this list send email to BPCS-L-SUB@midrange.com. >| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com. >| Questions should be directed to the list owner: dasmussen@aol.com >+--- > > > > > > >+--- >| This is the BPCS Users Mailing List! >| To submit a new message, send your mail to BPCS-L@midrange.com. >| To subscribe to this list send email to BPCS-L-SUB@midrange.com. >| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com. >| Questions should be directed to the list owner: dasmussen@aol.com >+--- > +--- | This is the BPCS Users Mailing List! | To submit a new message, send your mail to BPCS-L@midrange.com. | To subscribe to this list send email to BPCS-L-SUB@midrange.com. | To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com. | Questions should be directed to the list owner: dasmussen@aol.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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.