× 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.



i agree that to speed up a program you should first look at the i/o logic,
but once you've done that, you can still make significant perf improvements,
especially if you have multiple calls per i/o.

  i had a situation where a nightly batch program processed several million
records.  each record did 8 calls, and some of those calls conditionally did
other calls.  those opm calls can take quite a while in a situation like
that.  it's even worse if those calls return with *inlr on.

as far as the maintenance issue goes, i would suggest creating a service
program from the procedure(s).  this way, you only need to re-compile
everything if the procedure interface (parm list) or f-specs change.

btw... does anyone know of an easy way to find out where a procedure/s.p.
is used when it does need to be changed?

owner-rpg400-l@midrange.com wrote on 8/9/99 8:02 pm:

Ed & V,

In reality, if the program does any I/O it is unlikely you will be able to
perceive any difference.  However, the first time you need to modify a
statically called procedure and have to re-compile all of the programs that
it is statically bound to, you may wish you had used a dynamic call. The
overhead to locate, fix, and re-bind those programs will usually exceed the
overhead saved in 10 years of calls.

David Morris

 >>> "Ed Komeshak" <kimosabu@mich.com> 08/07/99 11:04AM >>> granted, it's not
the most scientific method, but i recall doing some benchmarking a couple of
years ago.  i ran a program that did 1,000,000 calls to a OPM program and
1,000,000 static calls to an ILE program.  if i recall correctly, the ILE
calls ran in about 1/10 the time (cpu secs and clock time) the OPM calls
did.

my understanding is that ILE static calls are very similar in performace to
EXSR's.  so to answer your questions, two static calls should be quite a bit
faster than one dynamic call.

i would suggest running a similar benchmark on your machine.  please post
the results if you do.


 > -----Original Message-----
 > From: owner-rpg400-l@midrange.com [mailto:owner-rpg400-l@midrange.com]On
Behalf Of vjagadish
 > Sent: Friday, August 06, 1999 2:48 AM
 > To: 'RPG400-L@midrange.com'
 > Subject: query in ILE RPG...
 >
 >
 > HI all !
 > I have a query :
 >
 > How fast are bindable calls vis-a-vis dynamic calls?
 >
 > Let me try to explain the above question  In ILE we can bind modules to a
program. Now we know that a  bindable(static)
 > call is faster than the dynamic call.
 > In the application i have designed i am able to replace a dynamic  call
with
 > an equivalent two static(bindable) calls. Now i am interested to  know, is
it
 > still advantageous that i use two static calls in place of one  dynamic
call?
 > So the question
 > 'How fast are static calls vis-a-vis dynamic calls'
 >
 >
 > Regards,
 > V.Jagadish
 > Infosys Technologies Limited,
 > Plot No:44,Electronics City,
 > Hosur Road,Bangalore-561229
 > Ph: 8520261 Ext:3200


+---
| 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
+---END



+---
| 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
+---END



As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.