Re: system tuning question

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