Yes, this seems to be what I am experiencing. I have a DCL-PROC with EXPORT. I have a prototype that is included with the accompanying module without the EXTPROC keyword. At this time, it is the only procedure in this NOMAIN module. The module is compiled into a service program, and that service program, for now, only has this module in it. When I reference the function in an RPG program with the incorrect parameters [using keyword EXTPROC] using the same prototype, I do get a compiler error. In the prototype definition copybook, I use compiler directive /IF DEFINED to tell the compiler whether or not to pull in the DCL-PR statement with EXTPROC keyword depending on the value being DEFINED from the copybook. In the module source, I have the DEFINE set to pull in the DCL-PR line without the EXTPROC. I am working on a V7R3 system.
But, when I compile the module and the prototype using PDM 15, and the DCL-PI in the module is different than the copied in DCL-PR from the copybook, I have seen multiple times where the compiler accepts the mismatch, when, prior to V7R1, the module would not compile, and I would have to make the DCL-PI and DCL-PR agree. It is easier to identify this mismatch issue during development and compile time, than it would be if there was a mismatch and the copybook, module, and service program are no longer in a Development environment.
Your RFE sounds exactly like the problem I am experiencing and I have voted for it. For now, I will be extra careful, and I agree with you that this behavior is a "huge step back to the old days of legacy parameter lists."
This mailing list archive is Copyright 1997-2020 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