Re: Expensive op codes

[Vanja Jovic <vanja@xxxxxxxxx>]

Bob,

great example. Sometimes it really takes just a knwledge, and a little
more thinking to achieve great results. Still, you were a little bit
lucky. Taxation program obviously ends with GOBACK statement. If it
ended with STOP RUN, there wouldn't be any help. But, as they say, luck
follows the brave.

Have fun,

Vanja Jovic

Bob Larkin wrote:
> 
> 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
> +---
+---
| 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
+---