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



As you know Mark there were a lot of reasons for this - one being that the old protected mechanism was too slow for modern OO/highly modular coding practices.

You are correct in that there are no checks - but then there were really no checks on the OPM system either. The _only_ check was that the number of pointers matched and that you could not use a pointer that was not passed. There was _no_ check as to what type of data the pointer referenced and there was no check to make sure that all passed parms were used.

I would argue that RPG improved things by providing prototyping so that both number and type of parms can be checked.

If anything is missing it is to have a mechanism whereby the compilers can store the parameter details in the object - and that can be done by enhancing the existing PCML capabilities. Then you can have the kind of mechanism you talk about. Even then you really need prototyping to be added to CL and COBOL because otherwise you can't validate a call until the object you intend to call already exists.

Not saying things couldn't be improved - but there was nothing noble about OPM!


On Mar 11, 2020, at 6:27 PM, Mark Waterbury <mark.s.waterbury@xxxxxxxxxxxxx> wrote:

Dave,

Congratulations! You have uncovered one of IBM's "dirty little secrets" about ILE.

ILE does NO checking of parameters at run-time. There are NO checks to ensure the correct number of paramters are passed to any procedure, let alone, the correct types, lengths, decimal places, etc. And it has always been this way.

And, do not be "fooled" by the checking that the ILE RPG IV compiler does, when you use a /COPY or /INCLUDE member to include the "PR" specs for external procedures. There is no cross-*MODULE checking at "bind-time" either.

The only thing the ILE binder cares about are the procedure names and their relative positions within a service program (typically as defined by the binder source).

I have complained about this for many years, but so far, to no avail.

We were actually better off with OPM because when one OPM *PGM does a CALL to another OPM *PGM, at least it checks, at runtime, to ensure that the number of parameters being passed is within the range of allowed values, as specified for the MIN and MAX number of parameters.

Of course, not all the OPM compilers exposed this functionality. OPM RPG/400 for example, always sets the minimum to "zero" and the MAX to the number of PARMs you define in your *ENTRY PLIST. But that was still better than what IBM did, when they introduced ILE.


With ILE bound *PGMs, they always set the minimum to zero and the maximum to 255 (or in more recent releases, some very much larger number).

So, good luck if you pass the wrong number or type of parameters.

What is even worse, in my opinion, is that passing incorrect parameters can lead to storage overlays, corrupting the runtime stack, or heap space, etc.

We need a good RFE for this stuff, and we need to get lots of votes for it, to try to get it fixed.

At run-time, when an ILE *SRVPGM is activated, the activation process can check at that time to ensure that the number of parameters for each exported procedure matches what the *PGM that is using the *SRVPGM expects. This would only normally need to happen once per job or per activation group, the first time each *SRVPGM is loaded / activated. The payback could be huge, preventing undetected memory overlay errors, etc.

If you have ever had some unknown process cause data to get corrupted in your DB2 database tables, this is one way that can happen, by incorrect parameter passing, causing storage overlays, altering the values of certain variables in memory, that subsequently may get written out to your database tables.

All the best,

Mark S. Waterbury

On Wednesday, March 11, 2020, 6:00:49 PM EDT, dlclark@xxxxxxxxxxxxxxxx <dlclark@xxxxxxxxxxxxxxxx> wrote:

"RPG400-L" <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> wrote on 03/11/2020
05:53:48 PM:
On Wed, Mar 11, 2020 at 3:42 PM <dlclark@xxxxxxxxxxxxxxxx> wrote:
"RPG400-L" <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> wrote on 03/11/2020
05:37:22 PM:
If you actually had a PI/PR for a program with VALUE, you should
have
gotten a compile time error.


No compile-time error because CL/LE doesn't support
prototypes.

Even if one side was CL, the other side would have had to been RPG to
use
VALUE...

You still should have gotten a compiler error on the RPG side..


There was no compile-time error. The RPG service program compiled
just fine with VALUE in the PR and PI. The CL program compiled just fine
defaulting the CALLPRC parameters as ByRef. But at run time the RPG
service program could not receive the parameters from the CALLPRC. As
soon as I changed the CALLPRC to specify ByVal and recompiled, then at run
time everything was fine.


Sincerely,

Dave Clark
--
int.ext: 91078
direct: (937) 531-6378
home: (937) 751-3300

Winsupply Group Services
3110 Kettering Boulevard
Dayton, Ohio 45439 USA
(937) 294-5331




*********************************************************************************************
This email message and any attachments is for use only by the named
addressee(s) and may contain confidential, privileged and/or proprietary
information. If you have received this message in error, please
immediately notify the sender and delete and destroy the message and all
copies. All unauthorized direct or indirect use or disclosure of this
message is strictly prohibited. No right to confidentiality or privilege
is waived or lost by any error in transmission.
*********************************************************************************************
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com

--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com


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.