But even if compiled with *yes the QILE is used when the RPG program is called...
The most likely causes of that are (1) you are calling the program in the same session after calling it earlier into the QILE activation group, and (2) you haven't reclaimed the QILE activation group yet.
Because QILE is the default activation group name, reclaiming QILE can cause unexpected side-effects. There may be any number of other programs that are active in QILE in the same job.
The best course may be to call the newly compiled program in a new session. The QILE version will not appear in the new session (unless QILE is where the new program also activates.)
Change the compile to *CALLER, *NEW or a name that you can reliably control with RCLACTGRP. For an ILE program that uses an OPNQRYF open data path, the activation group should usually be *CALLER to ensure that the ILE program activates in the same activation group as the OPNQRYF command.
If you want a trivial test set, here is a small ILE CL program and an even smaller ILE RPG program that can be used to test scenarios.
The ILE CL:
pgm ( + &pKey + ) dcl &pKey *char 10 dcl &Key *char 10 chgvar &Key &pKey monmsg ( mch3601 ) exec( do ) rcvmsg msgtype( *LAST ) rmv( *YES ) monmsg ( cpf0000 ) chgvar &Key '*BAL' enddo ovrdbf QCUSTCDT ovrscope( *JOB ) share( *YES ) /* ovrdbf QCUSTCDT ovrscope( *JOB ) share( *YES ) opnscope( *JOB ) */ if ( &Key *eq '*BAL' ) + opnqryf QCUSTCDT keyfld(( BALDUE )) opnscope( *JOB ) else + opnqryf QCUSTCDT keyfld(( CDTDUE )) opnscope( *JOB ) call TSTOVRK clof QCUSTCDT dltovr QCUSTCDT lvl( *JOB ) return endpgm
And the ILE RPG:
FQCUSTCDT ipe e k disk DSortDS DS D BALDUE 6 2 D 1 inz( ' ' ) D CDTDUE 6 2 /free dsply SortDS ; /end-free
The CL expects the RPG to be named "TSTOVRK" (Test Override Key), but choose your own names.
The CL is to be compiled with CRTBNDCL using basic defaults. The RPG should be first compiled with:
CRTBNDRPG PGM( mylib/TSTOVRK ) SRCFILE( mylib/QRPGLESRC ) SRCMBR( TSTOVRK ) DFTACTGRP( *NO ) ACTGRP( *CALLER ) REPLACE( *NO )
Later, different activation group settings can be set to see how it affects OPNQRYF.
Note that the CL has a commented OVRDBF. The OPNQRYF commands may be commented the same way and replaced with ones that do not include opnscope( *JOB ). It doesn't matter if the OPNSCOPE() parameter is specified as *ACTGRPDFN, *JOB or if it isn't specified at all -- as long as the compiles are done appropriately. Same for the OVRSCOPE() parameter. (An exception can be if someone changed defaults to specify *CALLLVL, but that would affect things even in OPM programming.)
If the CL is compiled into the default activation group and the RPG is compiled so that it activates in the activation group of its *CALLER, then *ACGRPDFN and *JOB affect the OPNQRYF open data path the same way as far as these programs are concerned.
Now, TSTOVRK program uses a file named QCUSTCDT. You should find a copy of that file in the QIWS library on your system. Use CRTDUPOBJ DATA(*YES) to get a version into a library that you can mess with.
Look at its file description to see that it is a non-keyed physical file. Once you have a copy to compile over, note that the compile has no problem using 'K' in the F-spec. The file doesn't have to be 'K'eyed at all. All it needs is the correct record format.
I named my CL program TSTOVRKC. When you call it, it can accept a parameter that can have a value of '*BAL' or something different, or it can be omitted. If omitted, it will default to '*BAL'.
When the value is '*BAL', the OPNQRYF will cause the records to be ordered in sequence by the BALDUE field. Any other value will cause the records to be ordered in the CDTDUE sequence.
The field values are stored in a trivial DS that is used by DSPLY to show that the sort order changes depending on (1) the OPNQRYF KEYFLD() or (2) the file that is actually opened in case an activation group or other external control causes a redirection.
It shouldn't take much experimentation to see that the most likely cause of the unexpected behavior is that the RPG program was recompiled with different attributes back a week or so ago.
That's only "most likely", not guaranteed. A temporary restore of the previous *PGM object, along with the CL *PGM object, should should any differences in attributes.
Given the coding of the CL snippet, it looks as if the behavior is under the control of the compile command. And unless command defaults were changed previously on your system, the V6R1 command parameter settings are the same as for V5R4. The V6R1 behavior is the same as long as the compiles are the same. (This is the kind of thing that a Change Management product is supposed to help ensure.)
Keep in mind that this info is 15 or more years old. It's been like this for most of the history of AS/400s.
Having a few small test utilities like the code above can help with investigation. You can see the effects of parameters in the commands and relationships with compiles.
Thanks Tom for the details.