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 firstname.lastname@example.org.
> Jon Paris wrote:
> This got me thinking. Has anyone here done any tests to compare the
execution speed of MI programs vs comparable C programs? IBM doesn't
write in MI any
> more and by sticking with MI you lose most of the optimization
options that are available to ILE programs. The vast majority of MI
instructions are surfaced in the
> C compiler and if I recall correctly are not called as functions (as
they would be if called from RPG) but replaced by in-line code streams
which should be a lot
> more efficient.
There are a large number of OPM MI instructions that are not available
as ILE built-ins. As to performance, it depends on the algorithms used
and how they are coded. In many cases, OPM MI can perform very well.
> C code has to be a lot more maintainable than MI and there are many
more tools to work with it.
It is certainly possible to write very obtuse code in C, almost as
cryptic and unreadable as some examples I have seen in APL.
> SO is there really any reason to use MI for new code? Does it really
perform any better?
> Jon Paris
There is still one issue that IBM has not yet resolved. If you make any
syntax or semantic errors using any of the MI built-in functions in any
ILE language, instead of getting a meaningful and helpful error message,
you get a "dump" and an ugly message that says "compiler internal error
- call support" and it opens up a "problem". For this reason, I use the
OPM MI QPRCRTPG API to "debug" any MI code I write, before ever
attempting to use equivalent embedded MI built-in functions, to make
sure I have the arguments to the instructions coded correctly, etc.
Until IBM "fixes" this, there will still be a need for the OPM MI
Mark S. Waterbury
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2023 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
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.