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



Doc,


Quantitatively (benchmark-wise) I can't say which (OPM or ILE) is faster. But your last post said anecdotal as well, so here goes.


Our base applications are still running in the /36 environment with RPG II programs and procedures. However, every new function/program is either RPG IV or ILE RPG. I recently, for example, had to add a new tax structure (ILE) to our existing on-line pricing module (RPG II). The ILE program had (currently) fifteen (15) subprocedures. The response is sub-second.


As for batch, I have no quantitative figures here either. But I quit using the SBMJOB simply because on our i/5 520 (and even on the old 720) it takes seconds to process files with 100k records.

The 520 probably forgives a lot of any inefficiencies I may (inadvertently) foist upon it. And I dare say that, if I wanted to do so, I could bring an ILE or IV program to its knees. We don't have any RPG III programs, but I have noticed no degradation in on-line response times when putting hooks (CALLs) from an RPG II program to an ILE or IV program. Plus the fact that I can easily add new tax structures to the above mentioned program and a myriad of other functions, such as IFS access, that simply cannot be done (or not done easily) in OPM makes eschewing OPM a no-brainer.


        * Jerry C. Adams
*iSeries Programmer/Analyst
B&W Wholesale Distributors, Inc.* *
voice
        615.893.8633x152
fax
        615.995.1201
email
        jerry@xxxxxxxxxxxxxxx <mailto:jerry@xxxxxxxxxxxxxxx>



e.h.doxtator@xxxxxxxxxxxxx wrote:


message: 2
date: Tue, 24 Jan 2006 12:54:34 -0500
from: Don <dr2@xxxxxxxx>
subject: Re: ILE V OPM Performance Increase?

Doc,

this should be fairly easy to roll-your-own on.  and you could modify it
to use customer data/apps which makes selling the case alot easier.

Don in DC


At 11:41 AM 1/24/2006 -0600, you wrote:
All

Just curious-- has anyone seen any performance improvement in either
batch or interactive after converting a program from OPM RPG to ILE
RPG?
(I'm talking about your run-of-the mill batch or interactive programs
that do native file I/O, basic calculating and reporting, etc.)

If so, are there any numbers that quantify any findings, for either
V5R1
or V5R3?

I remember reading several years ago that IBM swore off doing any
performance enhancements to the OPM runtime-- I'm wondering if the last
few releases have helped the ILE runtime performance.

Thanks

-Doc

OK, so there's nothing out there?  Nobody's looked into this?  Nobody
has even mentioned any anecdotal evidence.
The reason I ask is this-- I'm trying very hard to push my client into
ILE.  (Their entire codebase is OPM.) They're fighting with the Cone of
Fear argument ("We've never done that before."), so I need to have some
sort of quantifiable argument.  That sort of thing takes time.  I was
hoping that there was some sort of rudimentary analysis that someone had
done, just to see if I should even bother with it-- if the speed
increase is dinky, then there's no point in spending time on it.

Thanks

-Doc


This message is for the designated recipient only and may contain privileged, 
proprietary, or otherwise private information.  If you have received it in 
error, please notify the sender immediately and delete the original.  Any other 
use of the email by you is prohibited.



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.