Article 62375 of comp.os.vms:
Path: jac.zko.dec.com!crl.dec.com!pa.dec.com!news1.digital.com!nntp-hub2.barrnet.net!news3.near.net!paperboy.wellfleet.com!news-feed-1.peachnet.edu!usenet.eel.ufl.edu!news.mathworks.com!mvb.saic.com!info-vax
From: Nigel <sysmgr@maxwell.ph.kcl.ac.uk>
Newsgroups: comp.os.vms
Subject: re:  FORTRAN oddity
Message-ID: <0099177B.21024C41.1@maxwell.ph.kcl.ac.uk>
Date: Tue, 06 Jun 1995 09:48:23 EDT
Organization: Info-Vax<==>Comp.Os.Vms Gateway
X-Gateway-Source-Info: Mailing List
Lines: 65

I well remember the puzzlement this caused me the first time I ran into it:

> I'm posting this for some of our astro guys here who have asked me to look into
> an anomaly they are experiencing trying to compile and link a rather large
> FORTRAN program. Without going into too much detail the symptom is as follows:
> 
> They added an additional file containing a single subroutine to the entire
> program. Their make.com is simply a matter of compiling each of the several
> files containing source subroutine(s), followed by a link of the main program
> and all of the subroutines it references. They are making no exotic calls
> beyond that as these guys are in the business of flying satellites and not
> VMS programmers. 
> 
> They've noticed that the addition of this one subroutine has
> caused the .exe size to go from something like 6000 blocks to 24000 blocks.
> I suggested moving the  position of the subroutine in the linking sequence
> to the top of the routines listed in their link command and lo and behold
> the size comes back down to about 6000 blocks !
> 
> The subroutine in question passes nearly all of it's arrays (some multi-
> dimensional and most real*8) as calling args with very few arrays in the
> common blocks.
> 
> I'm not looking for anything in horrendous detail but wondered if anyone
> could comment on the behaviour as I've not seen it before. Since we've
> evidentally overcome the "problem" it might be useful to know how it arose
> in the first place so as to avoid it the next time -- if possible.
> 
It's a LINK feature, not necessarily to do with FORTRAN. When the LINKER
finds a run of data pages that are all un-initialized, it will create a
"demand-zero" section, which occupies no space in the EXE file and which
will create a page of zeroed memory at runtime when the page is first
referenced. This makes for much smaller EXE files if you have big
uninitialized common blocks. EXCEPT...

There is a maximum number of such sections for some reason (efficiency?).
The creation of demand-zero sections is controlled by two LINK options:
DZRO_MIN and ISD_MAX. A demand-zero section is created for more than
DZRO_MIN pages of all-zero, and provided no more than ISD_MAX of them
have been created so far.

If you have a FORTRAN program with a lot of subroutines with uninitialized
arrays and initialized variables, the arrays create demand-zero sections
which stop at/near the next initialized variable, and it's easy to reach
ISD_MAX, at which point all subsequent data space goes into the EXE file, 
zero or nonzero, hence a big .EXE. In the case above you've just tipped over
the edge for the defauts.

On my big program I use SMALLEXE.OPT containing

DZRO_MIN=10
ISD_MAX=150

(the numbers are of course BIGGER than the default values). Your mileage
may vary; experiment or work out your best values. Alternatively where
appropriate replace link-time initialisation of arrays by
runtime initialisation to avoid fragmentation of data psects into multiple 
demand-zero sections.

	Yours,
		Nigel Arnot

		NRA@MAXWELL.PH.KCL.AC.UK                   ...or,
		NRA%ipg.ph.kcl.ac.uk@nsfnet-relay.ac.uk   (internet relay)
		NRA%uk.ac.kcl.ph.ipg@ukacrl.bitnet        (bitnet relay)


