Re: OPEN Problem

[Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>]

Hi Jerry,

Is it possible that there's an override (OVRDBF) in effect for the file? 
 An OVRDBF would take precedence over EXTFILE.

Just a thought.


Jerry Adams wrote:
> We have two companies, which use the same database structure but in different libraries.  I was given the task of synchronizing the two Item Masters; that is, whenever interactive maintenance was done to the primary company's Item Master, make sure that the secondary company's item (same number) had the same cost, codes, etc. - but only if it exists.  It actually gets a bit more complicated, but that's the issue with which I am dealing today.
>
> I wrote a new program (IVU044) to do this, which is called from the regular program for doing standard Item Master file maintenance.  IVU044 is a cycle program, not a service program.
>
> OK, so the tables have the same name/fields/format on disk but in different libraries.  I wrote the following F-specs (the NVADJNCT set is included for comparison below):
>
>      FNVWHSLE   IF   E           K DISK    USROPN
>      F                                     ExtFile(Whsle)
>      F                                     Rename(NVMASTR:NVMASTW)
>      F                                     Prefix(WH:2)
>      FNVMKT     UF A E           K DISK    USROPN
>      F                                     ExtFile(Mkt)
>      F                                     Rename(NVMASTR:NVMASTM)
>      F                                     Prefix(MK:2)
>      FNVADJWH   IF   E           K DISK    USROPN
>      F                                     ExtFile(ADJWH)
>      F                                     Rename(NVADJNCT:NVADJNCTW)
>      F                                     Prefix(WA:2)
>      FNVADJMKT  UF A E           K DISK    USROPN
>      F                                     ExtFile(ADJMKT)
>      F                                     Rename(NVADJNCT:NVADJNCTM)
>      F                                     Prefix(MA:2)
>
> This *should* keep everything separate and easily recognizable.  The external file definitions are:
>
>      D Whsle           S             21a
>      D Mkt             S             21a
>      D Library         S             10a
>
> I have a subprocedure to open the tables, which has the following code:
>
>        IF  l$flib  = 'QS36F';
>          library = 'BWMS36F';
>        ENDIF;
>
>        IF  l$flib  = 'TSTQS36F';
>          library = 'TSTMS36F';
>        ENDIF;
>
>        IF  not %open(NVMKT);
>          mkt = %trim(Library)  + '/NVMAST';
>          OPEN  NVMKT;                        <--Problem child.
>        ENDIF;
>
>        IF  not %open(NVWHSLE);
>          whsle = %trim(l$flib) + '/NVMAST';
>          OPEN  NVWHSLE;
>        ENDIF;
>
>        IF  not %open(NVADJWH);
>          adjwh = %trim(l$flib) + '/NVADJNCT';
>          OPEN  NVADJWH;
>        ENDIF;
>
>        IF  not %open(NVADJMKT);
>          adjmkt  = %trim(Library)  + '/NVADJNCT';
>          OPEN  NVADJMKT;
>        ENDIF;
>
> Under debug the value of "library" is BWMS36F, which I would expect since the File Library (36 Env) is QS36F (l$flib).  The value of "mkt" is 'BWMS36F/NVMAST' and the OPEN runs (no errors).  But it is opening the file in QS36F!  I verified that by using the WRKUSRJOB command and displaying the open files as it stepped through each OPEN.  The other three files OPEN correctly; i.e., the correct libraries are used to locate the file.
>
> The two basic files (NVMAST and NVADJNCT) are also opened by the cycle (not me) in the calling program.  They are all in the same activation group (this program uses *Caller for the activation group).  I would have expected that, if the activation group was the problem, that the NVADJNCT table would have also been opened using the wrong library, but it looks OK when I look at the list of open files.
>
> Except for a controlling mainline of 4 lines, everything is done in subprocedures, not subroutines (if that matters).
>
> I have OPENed files dynamically dozens of times, though, admittedly, I cannot recall trying the open mirrors of a file in the same program, and I have never had an issue.  Usually just to determine which library to use for a file based upon some condition
>
> The open file list, if it helps, is:
>
>                       Member/
> File       Library    Device      Scope       Activation
> QDUI132    QSYS       D3          *ACTGRPDFN  *DFTACTGRP
> QDSPMNU    QSYS       D3          *ACTGRPDFN  *DFTACTGRP
> NVADJNCT   QS36F      NVADJNCT    *ACTGRPDFN  BWWHOLE
> OVRTAX     PRICELIB   OVRTAX      *ACTGRPDFN  BWWHOLE
> APBRND     PRICELIB   APBRND      *ACTGRPDFN  BWWHOLE
> HSTLINL8   HIST2008   HSTLINL8    *ACTGRPDFN  BWWHOLE
> HSTLINL8   HISTORY    HSTLINL8    *ACTGRPDFN  BWWHOLE
> CUSITMX9   QS36F      CUSITM      *ACTGRPDFN  BWWHOLE
> CATOLG     QS36F      CATOLG      *ACTGRPDFN  BWWHOLE
> A.GLIFAC   QS36F      GLIFAC      *ACTGRPDFN  BWWHOLE
> A.UNMEAS   QS36F      UNMEAS      *ACTGRPDFN  BWWHOLE
> A.IGROUP   QS36F      M890118     *ACTGRPDFN  BWWHOLE
> PRICES     QS36F      PRICES      *ACTGRPDFN  BWWHOLE
> NVMAST     QS36F      NVMAST      *ACTGRPDFN  BWWHOLE
> IVU010D    ADSOE200   D3          *ACTGRPDFN  BWWHOLE
> LISTIV     QS36F      LISTIV      *ACTGRPDFN  CUSTOMER
> NVMAST     QS36F      NVMAST      *ACTGRPDFN  BWWHOLE
> NVMAST     QS36F      NVMAST      *ACTGRPDFN  BWWHOLE
> NVADJNCT   QS36F      NVADJNCT    *ACTGRPDFN  BWWHOLE
> NVADJNCT   BWMS36F    NVADJNCT    *ACTGRPDFN  BWWHOLE
>
> The first BWWHOLE group is from the calling program (IVU010).  The CUSTOMER group is from a trigger program that fires when the Item Master is updated.  The last four files are from this program; the first NVMAST *should* be pulled from BWMS36F.
>
> I know that the error is going to turn out to be something simple.  And, worse, I'll probably wind up exemplifying David's "Cardboard Analyst phenomenon" once again.  But any help would be appreciated>
>
> Thanks.
>
> Jerry C. Adams
> IBM System i Programmer/Analyst
> B&W Wholesale
> office: 615-995-7024
> email:  jerry@xxxxxxxxxxxxxxx