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
midrange.com
