CLLE calling RPGLE, MCH3601

[JustPassing]

Hi,

We're having trouble with CLLE programs calling RPGLE. I thought the issue was about 1-byte parameter and having to either make the parameter 2-byte or add the ExtProc(*CL) to the RPGLE prototype declaration, but the programs are not passing or returning 1-byte parameters. I believe the problem may be coming from an OVRDBF in the CLLE before calling the RPGLE. If my understanding is correct, it must be the 1-byte fields of the OVRDBF'd file that cause the problem in the RPGLE?

Here's the relevant code (CLLE calling RPGLE) :

DCL &PARM1  *CHAR 30
OVRDBF     FILE(FILE1) SHARE(*YES)
CALL PGMà (&PARM1)

And the RPGLE :

FFILE1   IF   E           K DISK
D PARM1           DS
D  VAR1                 1      1
D  VAR2                 2      4  0
D  VAR3                 5      7
D  VAR4                 8      8
D  VAR5                 9     30
C     *ENTRY        PLIST
C                   PARM                    PARM1

Converting the CLLE to CLP works fine, so I'm convinced it has to do with the parameter passing differences that also cause the 1-byte parameter problem. Just to make sure, I tried the ExtProc method without success (still crashes with MCH3601).

Thanks.

[B.Hauser]

Are the CLLE and the RPGLE running within the same activation group

Birgitta

[JustPassing]

The CLLE is actually called from another RPGLE that's in the active group (*Caller), as is the RGPLE that the CLLE calls.

Upon further inspection, the program actually crashes at the OVRDBF command in the CLLE.

[john.sev99]

OVRDBF FILE(FILE1) SHARE(*YES)

Is this really called FILE1 or have you substituted this? If so, what is the real code?
A MCH3601 usually means you haven't passed a parameter.

[JustPassing]

No, that's not the actual name, what difference would having put the actual file name make? It just has to be known that it is the same file being used in the called RPGLE that is being OVRDBF. Perhaps you suspect we are doing OVRDBF on the physical file in the CLLE whereas the RPGLE uses a logical, or the contrary, or something like that? No, it's the same file. In this case, it is a logical file (the same one) but we tried putting the physical file (in both the CLLE and RPGLE) with the same results.

Again, once we change it to CLP, everything works as expected. I'm not quite sure what else could be causing the problem. In this particular case, the program crashes at the OVRDBF. However, I have had issues with programs crashing with this error when calling an RPGLE from an CLLE (the CALL PGM line), which is why I initially suspected the issue be the same. And again, changing it to CLP fixed the issues as well.

We are aware that this issue is generally caused when not passing parameters. But if this were the case, it should not work either if making it CLP. The only other issues I can find with CLLE and this error is that one-byte parameter issue that requires using EXTPROC(*CL) or using the two-byte workaround. So I figured it had something to do with that or with some other obscure parameter passing mechanic between CLLE and RPGLE.

In this particular case, we do an OVRDBF before doing an OPNQRYF (and before calling the RPGLE). However, since it is crashing at the OVRDBF line, I don't think the issue is with the OPNQRYF. Our developers are not used to coding in CLLE. Most of our CL programs (even new ones) are developed in CLP. It's mostly me and the younger developers that create CLLE programs. However, I would like for us to be able to use CLLE instead for the advantages it offers. But if we keep running into such issues, maybe we 'll just stick to CLP.

[john.sev99]

I only asked in case you were using a variable instead of an actual file name (should have been more specific, sorry). If you are using a hard coded file name it doesn't matter but if you were using a variable and it wasn't being passed, well...

[Scott Klement]

I don't see what the one byte parameter thing has to do with this issue? You aren't even making a subprocedure call, this is just a standard program call.

I've been coding ILE CL for 25 years, I've never heard of OVRDBF causing an MCH3601. Something bad is happening, you need to find it and fix it rather than chasing wild geese.

[JustPassing]

Ok, thanks for the replies. We'll try to see if we can resolve it.

[Rocky]

As a footnote - the OVRDBF won't do anything for you as is. I suggest adding OVRSCOPE(*JOB) to it.

[Rocky]

I have an activation group that in my case is CCGOV - ALL of my CLLE and RPGLE programs are compiled using that activation group. Try recompiling the programs here in a named activation group and see what happens. Next I'd convert the ILE to:

Dcl-DS PARM1_DS;
  VAR1      Char(1);
  VAR2      Zoned(4:2);
  VAR3      Char(3);
  VAR4      Char(1);
  VAR5      Char(21);
End-DS;

Dcl-PI Test8;
  Parm1 Char(30);
END-PI;

....

Parm1-DS = Parm1;

[Rocky]

Test8 should be changed to the name of your program.

[tomliotta]

Problem solved?

If it happens on the OVRDBF, I'd first look at the outer RPGLE CALL statement that calls the CLLE and the CLLE's PGM command. Unless there are loops calling the inner RPGLE multiple times, either within the CLLE or via the outer RPGLE, I don't see much chance that the inner RPGLE has much to do with the problem.

[jamief]

If you are still having this issue -- write up some equivalent code both CL and RPG and repost.
I'd be willing to play with it..