Re: Expensive op codes

[Bob Larkin <blarkin@xxxxxx>]

Knowledge is power, and in the batch world, it can make a big difference.
Point in case. Customer had a nightly billing process that ran 11+ hours! With a
planned merger and increasing sales, the future looked bleak for this job. A few
minutes with a job trace revealed the problem. An RPG program was calling a
program for determining taxes. The program was from a vendor that specializes in
determining taxes based on geographical position. The package was available on
many platforms, and had been written in COBOL.

A gotcha of COBOL is that when the Rn Unit (program) ends, it behaves like an 
RPG
program ending with LR on. Every time the taxation program was called the 
program
had to perform all initialization again. since the source code was not 
available,
we could not change how the program's run Unit ended. Reaching into the
bag-o-tricks, I pulled out a little tidbit. If a COBOL program is running below
another COBOL program, it will act like an RPG program returning with LR off.
Even if there is an RPG program between them in the stack.

A simple COBOL program that did nothing but call the initial program of the
billing process was created. FTPed the saved object to the system, and installed
it. the next morning, I was called into the bosses office. the operator's
reported that there was a problem with the billing, and they did not think it 
had
ran. Their reasoning was that the job only ran for 17 MINUTES. We checked the
run, and it was flawless! We had shaved over 10 1/2 HOURS off of the nightly 
run.
The customer could increase his billings ten-fold, and be done in less than 
three
hours.

All with a little knowledge!

Bob

Joel Fritz wrote:

> Even if we seemed to disagree in the past about optimization, I think the
> phrase "relatively inexpensive fast hardware" is the key.  I'm prodigal with
> machine resources for things like building screens for interactive programs.
> Who really cares about .001 sec vs .1 sec? (I made that up, but it is two
> orders of magnitude.  There are probably some things to consider for large
> numbers of concurrent users in the same application, too.)  I think where
> you can make a case for being frugal with machine resources is the batch job
> that runs over millions of records where you have a choice of doing
> something cheap or expensive several million times.  That can add up to a
> noticeable difference.
>
> I am curious about the sorts of things that can help me improve batch
> performance.
>
> > -----Original Message-----
> > From: Peter Dow [mailto:pcdow@yahoo.com]
> > Sent: Friday, October 15, 1999 2:29 PM
> > To: RPG400-L@midrange.com
> > Subject: Expensive op codes
> >
> >
> > > Barbara Morris wrote:
> >
> > > With date operations, the contest should be regarding the
> > number of date
> > > opcodes, not the number of statements.  (Date opcodes are
> > very expensive.)
> >
> > > Hans Bold wrote:
> > > Ah, another FAQ!  A long time ago, I did a comparison
> > > comparing the performance of the old MULT 100.0001 trick.
> > > I found that using MULT was about 100 to 150 times slower
> > > than doing the date conversion using a couple of moves.
> >
> > I'd be very interested in a discussion of just how "expensive" various
> > opcodes are and how much of a difference it makes in a
> > typical business
> > application. In these days of relatively inexpensive fast
> > hardware, my rule
> > of thumb has been to spend more time optimizing I/O than
> > worrying about how
> > many MULT, ADDDUR, etc. op codes I  use. I tend to prefer
> > solutions that
> > require fewer source statements unless there is solid
> > evidence that it will
> > noticeably impact performance.
> >
> > Which is faster, ADD 1 X or EVAL X=X+1?  READE or READ then IF
> > key='constant'? Is there a list of FAQ's about this?
> >
> > Peter Dow
> > Dow Software Services, Inc.
> > 909 425-0194 voice/fax
> >
> > > +---
> > > | This is the RPG/400 Mailing List!
> > > | To submit a new message, send your mail to RPG400-L@midrange.com.
> > > | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> > > | To unsubscribe from this list send email to
> > RPG400-L-UNSUB@midrange.com.
> > > | Questions should be directed to the list owner/operator:
> > david@midrange.com
> > > +---
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Bid and sell for free at http://auctions.yahoo.com
> >
> > +---
> > | This is the RPG/400 Mailing List!
> > | To submit a new message, send your mail to RPG400-L@midrange.com.
> > | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> > | To unsubscribe from this list send email to
> > RPG400-L-UNSUB@midrange.com.
> > | Questions should be directed to the list owner/operator:
> > david@midrange.com
> > +---
> >
> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to RPG400-L@midrange.com.
> | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator: david@midrange.com
> +---

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---