How can I identify common variables outside of the programs they are defined in.

I have a number of named and unnamed common variables used throughout my programs. I'm getting a common miss-match error on a program with no commons at all. How can I tell what common variables are causing the problem. Is there a way to display named and unnamed common variables active at a given time? I'm sure the code is running a subroutine that may be conflicting with another common, just no way of seeing it from the viewpoint of the program without commons.

Jon

Jon,

The program throwing the error doesn't call or include anything with common? 

(Side-question: Do all of your accounts have the same flavor? I've had common problems at sites with more than one flavor, specifically PICK and INFORMATION.)

Jon,

The program throwing the error doesn't call or include anything with common? 

(Side-question: Do all of your accounts have the same flavor? I've had common problems at sites with more than one flavor, specifically PICK and INFORMATION.)

I was going to ask a related question as to what does the line of code throwing the error look like? 

Also, if you do VLIST on the object code for that program, do the rows defining COMMON both come back with 0?

>VLIST BP FILEINFO
Main Program "BP.O/FILEINFO"
Compiler Version: 11.3.0.0
Object Level    : 5
Machine Type    : 0
Local Variables : 1
Subroutine args : 0
Unnamed Common  : 3
Named Common Seg: 1

I have a number of named and unnamed common variables used throughout my programs. I'm getting a common miss-match error on a program with no commons at all. How can I tell what common variables are causing the problem. Is there a way to display named and unnamed common variables active at a given time? I'm sure the code is running a subroutine that may be conflicting with another common, just no way of seeing it from the viewpoint of the program without commons.

Jon

Since Snap-on Credit was UniVerse the last time I visited, these details are for UniVerse.

An example failure. The routine with the disagreement will appear in HOMEUV/errlog. Then you can put a DEBUG statement at the top of the failing routine, and comment out all of the COMMON. Put them back in one at a time until you find the problem child. This can be difficult if INCLUDE and EQUATE make it difficult to comment out sections of code. Of course, we are not looking for correct execution at this point (the DEBUG to stop execution), but to find the offending COMMON declaration. Most likely, there is a library routine somewhere that has an old definition of the COMMON that will need recompilation with new COMMON layout.
ct bp Mismatch1 Mismatch2

     Mismatch1
0001 COMMON /BAD/ One
0002 call Mismatch2
0003 end

     Mismatch2
0001 subroutine Mismatch2
0002 COMMON /BAD/ One,Two
0003 return
>run bp Mismatch1
Program "Mismatch1": Line 2, COMMON size mismatch in subroutine "Mismatch2".
Program "Mismatch1": Line 2, Unable to load file "Mismatch2".
Program "Mismatch1": Line 2, Unable to load subroutine.

#cat /homeuv/errlog... Program "Mismatch1": Line 2, COMMON size mismatch in subroutine "Mismatch2". 

Some additional details, which are probably more than you need:
1. Unnamed COMMON can be referenced as different sizes in different routines. Unnamed COMMON will not cause a COMMON size mismatch.
2. Named COMMON must contain the same number of VARTAB slots. 

Pick style arrays:

Every element takes a VARTAB slot. One subroutine can reference COMMON /NAME/ X(2), and another can reference COMMON /NAME/ X1, X2. X1 and X(1) reference the same element, and X(2) and X2 reference the same element. This requirement is why Pick style arrays are implemented in this fashion.

Since VARTAB slots are indexed with an unsigned short (0..65535) a routine can only dimension an array to a maximum of 64K without exceeding VARTAB space. DIM PickArray(75000) will fail.

You cannot redimension a Pick style array in a routine. DIMENSION is a compiler directive. Dimensions are not available at runtime. Element access needs the dimensions for bounds checking. Run machine instructions provide the dimensions in the instruction. Some element access may be resolved at compile time
     FixedArray
0001 program FixedArray
0002 dim X(2,3)
0003 A = INMAT(X)
0004 B = X(2,3)
0005 C = X(B,2)
0006 end

> vlist bp FixedArray

00001: program FixedArray

00002: dim X(2,3)     (compile time only. No runtime instruction)

00003: A = INMAT(X) 
00003 00000 : 090 fmake          (2, 3) X  => $R0   (make an array to get dimensions. You knew this at compile time.)
00003 0000A : 0A2 getdim         $R0  => A 

00004: B = X(2,3)
00004 00010 : 0F8 move           X [6]  => B  (Offset calculated at compile time)

00005: C = X(B,2)
00005 00016 : 094 fmatrix        (2, 3) X B 2  => C   (Need dimensions to access element)

00006: end
00006 00024 : 190 stop     

Information style arrays:

The array takes only one VARTAB slot and points to a descriptor that contains the array dimensions and a pointer to a list of DATUM for each array element. Rules determine how elements move when the array is redimensioned at runtime. Increasing the number of elements may require copying the DATUM to a new list of DATUM in a new area of memory.

DIMENSION is a runtime instruction. 

     RedimArray
0001 program RedimArray
0002 $options -STATIC.DIM
0003 dim X(2,3)
0004 A = INMAT(X)
0005 B = X(2,3)
0006 C = X(B,2)
0007 end

>vlist bp RedimArray

00001: program RedimArray

00002: $options -STATIC.DIM

00003: dim X(2,3)
00003 00000 : 056 dim            X 2 3  (runtime instruction)

00004: A = INMAT(X)
00004 00008 : 0A2 getdim         X  => A 

00005: B = X(2,3)
00005 0000E : 0E6 matrix         X 2 3  => B (Calculate offset from dimensions in array descriptor)

00006: C = X(B,2)
00006 00018 : 0E6 matrix         X B 2  => C 

00007: end
00007 00022 : 190 stop