× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: BPCS 6.1mm performance and the AS/400 - more ord performance
  • From: "Genyphyr Novak" <novakg@xxxxxxxx>
  • Date: Tue, 15 Feb 2000 17:55:58 -0600

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 thread ...


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

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.