Re: system tuning question

[DrFranken <midrange@xxxxxxxxxxxx>]

And sometimes just an 'oops' with a safety.

Back in the S/36 days it was common practice to delete records by 
placing a "D" in a particular column, very often column 3. A routine to 
actually delete records would be run later perhaps day or month end. At 
one point I got sick of writing those programs so I created a routine 
that you passed a file name and column number and letter. e.g. INTRAN, 
3, "D" and it did everything needed including access path rebuilds etc.

Fast forward to a new component we created that also used the "D" 
function but said "D" was in column 200 something. The program didn't 
use any indices because the file would never have more than a few 
hundred records and did all manipulation in memory. (It was a 'need to 
buy' program for purchasing).  When the program opened it inhaled all 
records. About 6 months in I got harangued by one of the ladies in 
purchasing about how long it took to open that program every morning. 
Seems it was up to 20 minutes now when it used to be a couple seconds. 
Looking at the file every single need to buy record was still there from 
day one and it had to read 'em all and reject the ones with "D"s. There 
were a TON of 'em!

Checking it out we found that yes we were running the routine every 
night to cull out all the "D" records, yes we were, but the program had 
been created with only a 32 byte area that the "D" could be in. ( 
remember I said it was mostly in 3!) Anything beyond that and the 
program had a safety in it: If column greater than 32 simply return so 
as not to crash the job stream.

oops!

        - Larry "DrFranken" Bolhuis

www.Frankeni.com
www.iDevCloud.com - Personal Development IBM i timeshare service.
www.iInTheCloud.com - Commercial IBM i Cloud Hosting.

On 4/23/2016 9:49 AM, Steve Landess wrote:
> Sometimes it is poor program design.
>
> I was a consultant at Blockbuster Video in Dallas during their JDE World
> software implementation in 1990.  Shortly after go-live it was
> determined that there was a serious performance issue in the batch sales
> update program which runs nightly - it was taking several hours to run,
> sometimes over four hours.  The nightly backup window was pretty tight
> and this was before the days of save-while-active, and this run time was
> unacceptable.
>
> They were opening several new stores each day, resulting in thousands of
> sales orders detail lines being processed each night by sales update, so
> this was a persistent problem that needed an immediate fix.
>
> I was tasked with analyzing the problem, and while watching the job run
> I was seeing hundred of thousands of I/O's against the F0006
> (Branch/Plant) file, but we didn't have that many branch/plant records...
>
> Studying the pristine JDE code (which was machine-generated by their
> CASE tool and tweaked by humans), I determined that while processing a
> given sales order detail record that the program would CHAIN to the
> F0006 file several times (usually in different subroutines) using the
> same key value. This problem was occurring on other master files as well.
>
> It appears that the CASE tool wasn't smart enough to know if a record
> had been retrieved, so it just generated the additional code and
> retrieved it again...
>
> Solution:
> If a record has been previously retrieved, there is no need to retrieve
> it again, so my quick-fix solution was to code something like this
> around each CHAIN to reduce the redundant I/O's:
>
> SDMCU       IFNE   SVMCU
>                    MOVELSDMCU     SVMCU
> SDMCU       CHAINI0006
>                    ENDIF
>
> The result was that the job which was taking four hours to run was now
> running in 2 hours or less...
>
> Regards,
> Steve