Out of curiosity, besides D3, are there other MV products that allow
for the use of "variable", rather than "literal", to dimension an
array? E.G., "DIM JC(xxx)", opposed to "DIM JC(50)". In D3, I was
able to follow an executed SELECT statement, in a BASIC program, with
something like, "CNTR=SYSTEM(11)", then "DIM JC(CNTR)", thereby
allowing me to address the size of the array, based on the current
number of items being inserted into the array.

I realize a dynamic array could be used, but with very large numbers
of items in some instances, the dimensioned array works much faster
than a dynamic array.

Jim Cronin
Kittery Trading Post

On 2011-07-12 12:32:34 -0400, JJCSR <JCronin (AT) ktp (DOT) com> said:

I believe that OpenQM can.


Yes, it is very hand for this.

--
Kevin Powick

Some platforms treat DIM, EQUATE, and other statements as compiler
directives where substitution is done at compile time rather than
runtime. That precludes the ability to change the number of elements
at runtime. I don't recall which products use which mechanism. I
think some products use Pick Flavor to change this behavior.

Uh, and I could be way wrong...

T

JJCSR <JCronin (AT) ktp (DOT) com> wrote:

Il 13/07/2011 0.14, Tony Gravagno ha scritto:
please note the use of ELEMENT

*
*; equates
EQU MATRIX TO ARRAY(10) ;* valid EQU, not usable in DIM
EQU ELEMENT TO ARRAY(INDEX) ;* valid EQU, usable, see below
*
*;
MAX=10 ;*
*
*;
DIM ARRAY(MAX) ;* this statement is valid
*; DIM MATRIX ;* this statement is NOT valid
*
*;
FOR I=1 TO MAX
ARRAY(I)=I*10
NEXT I
*
*;
FOR INDEX=1 TO MAX
*
CRT ELEMENT ;* substituded, at compile time, with ARRAY(INDEX)
*
NEXT INDEX
*

Stefano

On Jul 12, 5:32*pm, JJCSR <JCro... (AT) ktp (DOT) com> wrote:
Aside from a simple yes, here is a little detail....

My understanding (which may be wrong) is that in the early days of
multivalue, the Pick style systems only allowed static dimensioning of
arrays whereas the Information style products allowed dynamic
dimensioning at run time, including redimensioning an array in a
manner that preserved its existing content..

Underlying this is a fundamental difference about how the two
architectures store arrays in common blocks although now many systems
allow the developer to choose which model they want to use.

In the dimensioned model, an array is simply a series of consecutive
variables. Thus, if I create a common block defined as
COMMON A, B(3), C
what actually gets created is a set of five variables A, B(1), B(2),
B(3), C.

Because internally common blocks are accessed by variable number and
the actual names do not have to be the same from one program to
another, it would be possible for a second program to define this
common as
COMMON X(2), Y, Z(2)
and see the same data as a totally different structure. This is fairly
nasty but taken to the extreme has its uses
COMMON P(5)

It should be fairly clear why this model does not allow an array to be
redimensioned. It would change the size of the common and lead to all
sorts of interesting problems in trying to access data sensibly.

The dynamic dimensioning model is different. An array is represented
by a single data item that leads to a collection of items that are the
actual array. A common such as
COMMON A, B(3), C
contains three variables, one of which is a three element array.
Because the array is physically stored separately from the common,
there is no reason why it could not be redimensioned later to have a
different size.

None of this has much relevance to arrays outside of common blocks but
the physical storage process remains much the same. The common block
example just shows more clearly why it works as it does.

The Information style products take things a little further and, when
using dynamic dimensioning, introduce an extra element to a
dimensioned array known as the zero element. This item, A(0) for
example, was introduced to handle the problems associated with using
MATREAD to read a record that turns out to have more fields than
expected. The zero element behaves as a sort of overflow bucket and
ensures that programs continue to function correctly even though there
is excess data. There is actually nothing to stop the developer using
this element just like any other if they so wish. In a two dimensional
array, there is one zero element, A(0,0), not a whole row and column.


Martin Phillips, Ladybridge Systems

On Jul 12, 6:07*pm, Kevin Powick <nos... (AT) spamless (DOT) com> wrote:
I should have added to the above example, stating that in D3, I could
also "re-dim" during the program. I had certain applications that
would build a large output files, not knowing the exact number of
items that would be processed. I may have started with a 200,000+
item file, being read sequentially, and have conditions that each item
had to pass before being written to the output file. Consequently, I
didn't always know how many items I would be outputting. I would
start with a dim of, say, 200, then every 200 items, re-dim to another
level. D3 allowed for me to move from a DIM array to a DYNAMIC
array, as well.

DIM JC(200); MAT JC=''
CNTR=''
*
*
10*
READ ITEMIN from infile else .....
IF ITEMIN ...passes criteria... then
CNTR=CNTR + 1
JC(CNTR) = ITEMIN
IF REM(CNTR,200) = 0 THEN
WORKITEM=JC
NEWDIM=CNTR+200
DIM JC(NEWDIM)
MAT JC=''
JC=WORKITEM
END
GO 10
END
GO 10

I have not been on D3 for about 15 months, and my current MV platform
doesn't allow for these type of operations, so I may have missed a
command-or-2, but I think you get the jest. The end result was a
very fast file-creation for large number of input items.

Jim Cronin

IIRC the ability to use a run-time variable to dim a static array came
around R91 or thereabouts. I seem to recall it being introduced on
the ADDS first. I may be mistaken.

Prior to this, I wrote a generalized routine that would do the re-dim
"faking out" the system, by merely changing the DIM statement within
the code, recompiling the program on-the-fly and then relaunching it
again by CHAINing to a main-line routine, or reCALLing a subroutine.

Then within a year or two they made my cleverness obsolete

Will Johnson

stefano <stefano (AT) friuldata (DOT) it> wrote:

That's a perfect example, Stefano. What's happening there is that a
pre-compiler is running against the source to change instances of
ELEMENT to ARRAY(INDEX), which is then compiled into object code.
Prime-based environments thusly allow us to create code shortcuts
which can easily be changed, rather than manually repeating code
segments as we often do in Pick platforms (requiring abstraction to
subroutines or Included items).

NOTE: That pre-compiler capability is very powerful and is used by
many of us to give BASIC functionality which is not provided by the
DBMS vendor. Look at FTBP in AccuTerm installations to see how Pete
includes source for all platforms in a single item. I do the same for
my products using Kevin King's XBASIC. Mark Brown does this to add
Functions() and Object-Oriented capabilities to D3, just like QM.

That's different from this situation:

In this case, DIM is processed at runtime, not compile-time. For
environments that support functions and OOP, it should be easy to see
how a function could replace the need for a dimensioned array, and
with minor code changes. With a combination of pre-processing, file
operations and/or string manipulation, D3 and other Pick-flavor
environments can be enabled easily with runtime array definitions.

As always, we can do anything we want with these environments, and I
maintain that I'd rather have the DBMS vendors working on major model
enhancements than stuff like this which we can do ourselves.

T

"JJCSR" wrote
be good enough for seldom-run applications; DIM foo() to 100,000 and
use subvalue marks {or char(200) or '|' or something} to stack a smallish
number of tokens in each dimensioned element. Messy at both reads and
writes of foo(), but better than nothing if DIM foo(sizevariable) is not
allowed.

If for example 300,00 tokens were folded into a foo()
DIMmed to 100,000 places, then foo(1) might eventually become
'guy000001' : '|': 'guy100001' :'|': 'guy200001'
and foo(2) might become
'guy000002' : '|': 'guy100002' :'|': 'guy200002'

Frank

On Jul 13, 5:00*am, stefano <stef... (AT) friuldata (DOT) it> wrote:

curiosity") is exactly what you presented in your example. The
statement, DIM ARRAY(MAX), is not a valid statement in REALITY
(variables cannot be used in place of literals when defining
DIM's). They do use WRITESEQ, READSEQ, etc., which does build a
file very quickly. I was just interested in knowing whether the use
of variables, defining DIM, was commonly present, or missing, in other
versions of MV.

Thanks, all, for your input to my question.

Jim Cronin
Kittery Trading Post