The following all works in D3 and mvEnterprise, AFAIK:

TEST1
0001 COMMON XYZ(25)
0002 CALL TEST2
0003 ENTER TEST3

TEST2
0001 SUBROUTINE TEST2
0002 COMMON X(10)
0003 COMMON Y1,Y2,Y3,Y4,Y5
0004 COMMON Z(10)
0005 RETURN

TEST3
0001 COMMON XX(20)
0002 COMMON YY(5)
0003 PRINT "GOT TO TEST3"

In other words, I can define a single big array that overlays the
entire common space of another program or programs, subroutine or
mainline, even if some of the variables don't match in type or array
dimensions - all that's important is the total number of them in common
being equal (in this case, all have 25 total variables).

The problem is that in Universe, this doesn't fly. Neither TEST2 or
TEST3 is callable from TEST1; I get "COMMON size mismatch in TEST2" (or
TEST3).

Ignoring (please!) for the moment *why* someone would want or need to
do this, is there any way to make a "common overlay" fly in UV?

=jon=

D3 handles this sort of thing, or at least use to. The only requirement
is/was that the total number of array elements matched. After that for the
compiler allocates the pointers into the common area.

The only caveat is that the common area has/had to be the very first
variable declared in the program, and you had to know what happens if you
have arrays with two dimensions and when using different set of common
variables in subroutines. Although doing stuff that Jonathan indicates is
definitely not a good way of doing things.

It can be handy when calling subroutines, and I've seen it done. The common
declaration in the subroutines looked like: common
array(total.array.elements) while the main program defined many different
arrays. But is the declaration of a common area required in subroutines any
more if the common variables aren't used?

Donno if this makes things clearer.

regards,

Dale


"Glen B" <no$pamwebmaster@no$pamforallspec.com> wrote

Common "overlays" work in UV if you use Pick style matrices. They do
not (and could not) work with the default style of matrix because this
is accessed indirectly. Both styles have their advantages and
disadvantages.

Exactly the same is true in our QM database product.

Martin Phillips, Ladybridge Systems

This works because after the compile, there are no field names, just
descriptor table entries. So if you define 25 "common" fields in test1, that
just means the first 25 entries in the table are "common". When test2
loads, it knows there are 25 common elements, it just calls them by
different names, but the compiler recognizes that the first common field is
the first common field, regardless.

I used to do this all the time. It's quite handy to call an INIT subroutine
that just does ALFIELDS='' and returns.

If, in TEST2 or TEST3, you define more than 25 fields, they simply belong to
that routine and not the higher level ones; if you define fewer, you just
don't see all there is to see.

In this case, TEST2 would not be able to access XYZ(1), but it would be able
to access the same info in X(1); and the same data in XYZ(11) will be in Y1.

Mark Brown

"Glen B" <no$pamwebmaster@no$pamforallspec.com> wrote

Not at all. Variables n Pick style compiler are assigned numerically and can
be redefined as arrays, as long as total count is the same in all commons

I use this redef all the time and works fine on uv (and, I note on openQm as
well). You have to be in Pick style compiler.

Chandru Murthi

"Glen B" <no$pamwebmaster@no$pamforallspec.com> wrote

Martin:

Can you expand on this; specifically what's a "Pick style matrix"? Does
it depend on the flavor of the UV account that I'm in (Pick vs Ideal
vs...?) Or is there a UV compiler directive that enables compilation of
the program under Pick protocols instead of the normal UV ones?

Everyone else, thanks for the replies - Mark Brown is quite right; in
"pure" pick this works because descriptors are all (or at least were)
10 bytes long and so all that mattered was the total number of
descriptors matching (and the common area being the first thing in the
program). It's messy but can (as Glen B pointed out) be very handy on
occasion.

=jon=

Is this time for another advert for the UniVerse internals course???

UniVerse supports two styles of matrix. Ideal, Information and PI/open
flavours give you Information style matrices by default and Pick,
Reality and IN2 flavours give you Pick style matrices by default. In
both cases, you can use the $OPTION compiler directive to select the
other type.

A Pick style matrix is just a series of items, "end to end" such that a
common block defined as
COMMON A,B(2),C
would have four variables allocated which are
A | B(1) | B(2) | C

Because these are simply four consecutive items, you can redefine the
common to have other structures so long as there are always four
variables.

An information style matrix is a single variable that points to the
actual matrix. Thus, the above COMMON becomes
A | B | C
where B points to a further structure which contains
B(0) | B(1) | B(2)

Now, you cannot have a different view of the common because B is a
special type of variable.

Note also that Information style matrices have the "zero element" which
is used as an "overflow bucket" by MATREAD and MATWRITE but can also be
used for any other purpose you wish. In a two dimensional matrix, there
is just one extra element, B(0,0), not a whole row zero and column
zero.

The advantage of Information style matrices is that they are created
dynamically at run time so you can have a statement such as
DIM B(N)
and you can redimension them as your program progresses. Clearly, with
the Pick style end to end layout, this is not possible.

Aside from the zero element and the ability to do dynamic
redimensioning, the implementational differences are unimportant except
when used in a common block.


Martin Phillips, Ladybridge Systems

Mark Brown wrote:
MAT ALFIELDS=''

perhaps?

--
frosty

Not any more.

D3 took the concept of MatParse and MatBuild and shortened it to

dim.array = dynarray
dynarray = dim.array

The first one parses attributes into dimensioned elements, the other the
opposite.

So taking that to its natural conclusion, you can now say

dim.array = null

and each element will contain nothing

But, certainly, the old syntax (Mat array = something) works for putting a
single value into each element of the array.


Mark


"frosty" <frostyj (AT) bogus (DOT) tld> wrote