In message
<[log in to unmask]>,
"Shahan, Ray" <[log in to unmask]> writes
>Hi all, and good morning!!
>
>        In an effort to squeeze out every last drop of 'oomph' from the
>3k, we're reviewing some of the existing programs to see if we can do
>anything to increase their performance.  One thing that I noticed in
>some of the programs is that they have very large internal arrays (one
>prog has two separate arrays that both have 9999 elements).  In the
>past, I've always used the DEPENDING ON phrase to dynamically allocate
>the elements as required (and to downsize the array when the elements
>were no longer needed).
>
>         I have been told that using the depending on phrase no longer
>matters since MPE (via the COBOL compiler?) will allocate the space
>required for the upper limit of the array's size regardless of what the
>array size variable contains.  I searched the archives, but did not see
>the answer for this, so does anyone out there have the definitive answer?
>
>As always, TIA for your help,
>
>Ray Shahan

I found an issue with large arrays in COBOL programs, and got some good
help from Walter Murray, then at HP, and others, in resolving it.

The program source was a pretty normal size, and it gave a 150-sector
NMOBJ. But when it was linked, it expanded hugely to 28,500 sectors -
about 7 mB.

The program did contain a large array - 3000 x 60 x 40 characters. Which
had no VALUE clause, but was INITIALISEd in the body of the program.

And I could see that the array was the culprit, by changing various of
these attributes.

So it was clear that the linker was generating the entire explicit
starting array in the NMPRG  but how to stop this?

Walter suggested adding EXTERNAL to the definition of the array. Fixed
it just like that - NMPRG back down to ~350 sectors. Link time, and more
importantly load time, for the program slashed to the bone...

I can't answer for running time or efficiency improvements, but smaller
has got to be better for a memory footprint, hasn't it?

EXTERNAL is incompatible with any VALUE clause, but this was not an
issue for me, as I did not have one. (FWIW, adding a VALUE clause, to
see if that was the problem, gave about the same results as the
VALUEless version).

But if your large arrays are initialised via VALUE clauses, give some
thought to perhaps making them EXTERNAL and initialising them
procedurally in the program instead.

If they don't have VALUE, it's probably a no-brainer to try using
EXTERNAL.

Of course, it all depends on how big is big - your 9999 elements may be
only a few bytes each. In which case, you should get an improvement, but
not perhaps such a big one. But if you want to squeeze that last
drop....

A good rule of thumb might be to list your NMOBJs and NMPRGs in
descending size order (LISTF,2 or whatever into a file, import it into
Excel -using Text-to-Columns if necessary - and then sort on the file
EOFs, descending). Anything whose NMPRG is unexpectedly large - much
nearer the top of the list that its NMOBJ is in its list - is a likely
candidate.

HTH
--
Roy Brown        'Have nothing in your houses that you do not know to be
Kelmscott Ltd     useful, or believe to be beautiful'  William Morris

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *