× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Without the SHARE(*YES), each program creates its own open data path (ODP).
So you aren't saving anything.

26K records isn't very large. How many other records in other files are hit
for each one of the 26K?

Some of the more expensive operations on the system
Creating a new job
Creating a new Activation Group (make sure programs called repeatedly aren't
using ACTGRP(*NEW)
Program initialization (programs called repeatedly should return with
*LR=*OFF)
Creating ODP (use SHARE(*YES) or SQL to allow ODP reuse)
Database I/O (eliminate writing/reading 'work' DB files for temporary data,
if you must have 'work' files don't journal them, if you must journal them,
make sure you write to them under commitment control)

Lastly, are the RPG programs RPG III or RPG IV?

Having an RPG IV program call bound procedures is faster an dynamic program
calls, but you have to be making lots of calls to really see it.

5M Iter 50M Iter OPM calling OPM 6 62 Dynamic Program 12 122 Bound
Procedure 1 4
Another programming technique, use INTEGERS instead of ZONED or PACKED
fields when you have zero decimal places. Loop counters for instance. My
test show integers as being about three times faster than packed decimal. A
simple for loop of 500M iterations took 17s of CPU time when the index (I)
was an integer vs. 46s when using packed decimal. Granted, 500M iterations
is awfully high, but the results are even more interesting when you add an
EVAL Z = X * Y into the loop. With I, X, Y and Z being integer the loop
takes 18s vs. 83s when I,X, Y, and Z as packed decimal.

The best way to handle a performance question is to trace the job and see
where the time is being spent, then you can concentrate your improvement
efforts at that point.

HTH,
Charles


On Wed, Nov 12, 2008 at 1:09 PM, Marvin Radding <
marvin.radding@xxxxxxxxxxxxxxxxxxxxx> wrote:

All,

I am assigned a project to attempt to improve the running time for the
nightly process. So here is the situation: One program reviews over 26,000
records nightly by calling a pricing program that calls over 20 different
RPG programs to determine a price for the customer. And this pricing program
is called again to provide the customer with an alternate price should they
choose to avoid the price increase. This program requires several hours each
night to review these records.

My question has to do with a technique that I saw many years ago, when
computers were slower. That technique was an attempt to make programs start
faster by issuing an OPNDBF for every file that would be needed. I think the
programmer thought that if the operating system already had the file open,
when the RPG program attempted to open the file, there would be less
overhead.

My question is, would issuing an OPNDBF for a file that is not flagged
SHARE(*YES) reduce the overhead to start RPG programs? Would I need to make
the files shared reduce the overhead?

Thanks ahead of time.

Marvin

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.