OPEN Problem

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