Re: ACR500 -- BPCS-L

Hello,

This is a multi-faceted problem....

There was definitely a problem found in OS/400 when upgrading to V4R4 which
affected BPCS ACR500. The original PTF number for V4R4 were listed as
SF62599 (and SF62007 was also recommended, but was not for performance, it
was for a crash in CEA500) and this problem was worked on back in May 2000
with IBM and one of our BPCS customers. It may already be superceded by
other PTFs at this point, but ordering the original PTFs would get you the
superceded. Or check the Info APAR II11801, where the superceding PTF should
be listed. Note that these PTF numbers apply ONLY to V4R4 of OS/400. If you
are on another release of OS/400, check II11801 for your OS/400 release to
find recommended PTFs.

As regards file access paths staying open, it is normal for various numbers
of paths to stay open in a given job. This makes performance faster, not
slower, since the ODP does not have to be recreated each time you go back
into a program to do the same SQL statement. This will occur whenever a
program was compiled with close cursor *ENDJOB, rather than *ENDPGM (or
*ENDACTGRP rather than *ENDSQL in ILE). In earlier releases of BPCS only
some programs were written with the proper cursor handling to allow this
option to work properly. In 6.1.00 BPCS, all BPCS SQL programs are written
so that they can be compiled in this way.

After applying all possible IBM PTFs listed in II11801, run a DBMON over
your job and see if there is still a problem which can be resolved with
logicals.

Also note that performance BMR 55411 is outstanding, and you may wish to
escalate this with SSA R&D by phoning your BPCS rep or Helpline. Or view the
BMR Workaround notes on OGS for a list of recommended logical files found by
running DBMON at one customer site. (Note that the BMR was only updated
today, so this workaround listing is not available on OGS until tomorrow.
Also understand that these logical files worked for 1 customer, but were not
tested on many different ACR set ups, so your results may vary, depending
upon the product set up at your site). When the BMR is finished, the listed
workaround logical files may be delivered in the BMR, or the BMR may involve
a re-write of SQL so that the files are no longer necessary. Deciding to
escalate the BMR, or apply the workaround (or both) is up to you.

The problem with using PRTSQLINF to find recommended logical files as
mentioned by someone else, is that by doing this you get no sense of what
time savings may or may not be achieved with a given new logical, as
PRTSQLINF is all estimates, and not actual run times for the statements, and
you have no idea if the statement executes once or 500 times in your job, or
if it even executes at all. Therefore, it is not a very good tool for this
purpose, when there are so many better ones out there that measure what
really happens at runtime over a real job. Querying DBMON results in the
proper way allow you to see which statements take the most CPU time to run,
and thereby allowing you to build only the logical files that will represent
a real time savings in the job, rather than building every little file
recommended, which may only save you a small amount of time, but cost more
in overhead of maintaining the logical file in the long run.

Thanks

Genyphyr Novak
SSA Global Technologies

----- Original Message -----
From: <amitbhatia@gknindia.com>
To: <BPCS-L@midrange.com>
Sent: Monday, November 13, 2000 6:38 AM
Subject: Re: ACR500


> It seems to be PTF issue only. Please recheck on the PTF number given to
you by SSA. It could be some other PTF.
> DO not work on any other solution except PTF.
>
> >>> gkndom.GIFTPO."BPCS-L@midrange.com" 11/13 3:52 PM >>>
> >From           : BPCS-L@midrange.com
> To             : BPCS-L@midrange.com
> ;
> Subject        : ACR500
>
>
>  We are on BPCS 6.04 on an AS/400 running V4R4.  Cash & Memo posting
(ACR500) is
> incredibly S L O W and when looking at the joblog, there are thousands of
access
> paths open (one job had over 25 000 access paths open!) with most files
> appearing numerous times.  SSA advised that we needed to apply PTF
SF63292,
> which we have done and it has had no effect.  Has anyone else experienced
this
> problem and what was done to correct it?
>
>
> +---
> | 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
+---