OPNQRYF and iSeries V6R1 issue

300 pts.
Tags:
IBM iSeries
OPNQRYF
RPGLE
I had responded on a previous issue and it is suggested I create a new one for mine. Doing that and I am adding some of the info below my question.  I hope this is not too confusing.  I apologize in advance if so. 

I starting having an issue with a RPGLE program after it was recompiled due to a different file change 2 weeks ago. I was searching for something like my issue and found this that sounds like it may be what is happening to me.

 Link to previous issue http://go.techtarget.com/r/12585115/9007042/9

The program was working fine until the recompile. Since that recompile the OPNQRYF is no longer working. The physical file is keyed by shipto and the opnqryf command says to use billto. The RPG that is called is using the arcust in shipto order.

Below is a snippet of the CL.

OVRDBF FILE(ARCUST) TOFILE(&CSLIB/ARCUST) SHARE(*YES)

OPNQRYF FILE((ARCUST)) OPTION(*ALL) + KEYFLD(BILLTO)

CALL PGM(ARR0402) PARM(&AGCY &AGNAME &EDATE + &DETAIL &BTTOT &DAYS1 &DAYS2 &DAYS3 + &DAYS4 &DAYS5 &BSUM &ARDAYS)

Am I understanding it correctly that the ARR0402 program has to be recompiled over an ARCUST file that is in billto order for this to work now? Was this something that changed in OS 6.1? The last time the program was changed was in 2000 and recompiled in 2007 on iSeries OS 5.3.  Gail

Phil answered and asked:

 

 My answer. both billto and shipto are alpha 10. There was a previous ovrdb for calling a different program higher in the CL. I added a dltovr but the same results.

Software/Hardware used:
iSeries V6R1

Answer Wiki

Thanks. We'll let you know when a new response is added.

Thanks Tom for the details.

Gail

Discuss This Question: 4  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • VGP
    Thanks guys but my problem is solved. Although I think it is an IBM bug, using OPNSCOPE(*job) on the OPNQRYF command in the CL has solved my issue. I was hoping for a simple compile option instead of having to change every CL in the system that uses OPNQRYF. For the info below I had changed the arcust to arcustl6, an existing logical in the billto order I needed. That solved my sort issue. But in the same CL calling the same program is a selection to use only the user selected billto. That was not working either. I did not want to cloud the issue by mentioning it but to be sure the below example is clear I do now. :-) On the RPGLE compile there is an option for activation group. The default is to use the default activation group. Default activation group . . . . *YES If you say * no you get another parameter to use QILE Default activation group . . . . > *NO Activation group . . . . . . . . QILE But even if compiled with *yes the QILE is used when the RPG program is called and the file is opened. In debug I see the arcustl6 open from the OPNQRYF and then when the RPG is run the arcustl6 is open again with QILE type, it does not use the file already open from the opnqryf command. When opnscope(*job) is used on the opnqryf, the file is opened only 1 time and the sort or select works correctly. The same results is found whether I use the parameters on ovrdbf or not. Looks to me like the RPG compile is using QILE activation group regardless of what is specified in the compile….IBM bug? Now to answer the last questions: Phil asked: I would try to simplify the issue. Start with just a cl with a command with the override, opnqryf and the call .. does that work? Phil I did the above basically with using a goto in the CL and debug and same results. Using the logical instead of arcust did solve the sort issue but I still had the select issue to fix. Tom asked: FARCUST IP E K DISK That says it’s a basic ‘I’nput file in ‘K’ey order. It’s not an ‘U’pdate file. But this: OPNQRYF FILE((ARCUST)) OPTION(*ALL) + KEYFLD(BILLTO) implies that updates will be done. Why set up OPTION(*ALL) if only OPTION(*INP) will be used? As I said, this is a very old program and was only recompiled recently and then quit working. It had been running on the previous compile for many years. Thanks for the info you have given me, it got me on the track to find the solution. Gail
    300 pointsBadges:
    report
  • TomLiotta
    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. Tom
    125,585 pointsBadges:
    report
  • TomLiotta
    Gail: I don't know if your question was truly answered, but I hope the example lets you explore many of the possible variations. Compile-time options can be combined with run-time to give most results that you can imagine. A little practice can solidify concepts quickly. Tom
    125,585 pointsBadges:
    report
  • VGP
    Tom, Was I answered? Yes, I think so. I just added the opnscope(*job) to the critical CL that the user was asking for and it is working correctly for them now. I have 34 others to change and found during testing that some actually have the issue and some do not. Like you said it seems to be if the same file is open previously in the same CL. Hopefully I will have time soon to play around with your program suggestions to get a good grasp on what is happening. Thanks again for the detail info and explainations. Gail
    300 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following