Re: system tuning question

Buck wrote:

So maybe I should amend my post to say something like 'You need a goal
expressed in numbers even if you have to keep that goal a private,
internal goal and not publish it.' I strongly believe that going
through the process of determining a target number has value far beyond
the simple number itself.

The vague hand waving so many of us have lived through (it just seems
slow, deal with it!) almost always has an underlying technical issue.
Thinking about a goal (the dude says his TPS report takes a long time)
will help guide the analyst toward an understanding about what slow
might mean.

Sometimes, working to get to a hard number reveals that there's nothing
technically wrong with the system's performance. The TPS reports are
taking the same amount of CPU and clock time as they always did. But it
turns out that the dude's TPS reports are waiting in a job queue behind
other work. So 'tuning' might mean moving the dude's job to a different
job queue so it doesn't wait. Boom, TPS reports speeded up 1000%.

If one works in a highly political environment, keeping records /
printouts of the status as one tunes can be valuable evidence to
demonstrate that progress is being made against goals. One needs to
show the business benefit of one's technical proficiency to the chain of
command.

Buck -

Performance problems are not always caused by system resource issues. 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