Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!sri-spam!mordor!lll-tis!ptsfa!dual!ucbvax!CLARKU.BITNET!DHASKIN
From: DHASKIN@CLARKU.BITNET (Denis W. Haskin, Manager, Technical Services)
Newsgroups: comp.os.vms
Subject: Virtually nuked...
Message-ID: <8706210314.AA17988@ucbvax.Berkeley.EDU>
Date: Fri, 19-Jun-87 15:08:00 EDT
Article-I.D.: ucbvax.8706210314.AA17988
Posted: Fri Jun 19 15:08:00 1987
Date-Received: Mon, 22-Jun-87 06:44:14 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 60

Help!

We have a research group working with a simulation of the effects of a reactor
accident (a la TMI).  They are having difficulty linking a FORTRAN program
that uses extremely large arrays for its work, and thus far I have not been
able to determine what might be done to allow it to link.  The last resort
is of course to re-write the routine, but they are pretty adamant that they
need these large arrays.

I am not positive that these data elements are actually the problem, but
they are the best candidates  -- note ACIXY, GCIXY, TACIXY, TGCIXY:

      COMMON /PLUME/ [...omitted...], ACIXY(60,80,0:80), GCIXY(60,80,0:80),
                     FRACIX(60,80)
      COMMON /PTIME/ [...omitted...], TACIXY(0:50,60,80,0:30),
                     TGCIXY(0:50,60,80,0:30), IHOUR, IMIN, ISEC

The original symptom was a "LINK-F-EXPAGQUO, exceeded page file quota" error at
link time.  Upping the user's PGFLQUO took care of that nicely.  Then, a
"LINK-F-MEMFUL, insufficient virtual address space to complete this link"
was the culprit.  The System Messages And Recovery Procedures manual suggests
either

   a) increasing virtual address space or
   b) descreasing the size of the image

and suggests that (b) might be accmplished by

   1) using shareable images or
   2) encouraging demand-zero compression.

(b)(2) seemed most reasonable, so I added an options file with the single
line: DZRO_MIN=1 (I also tried 0).  No effect.

What are our options (other than rewriting the original source)?  As I see
it, we can:

   - encourage demand-zero compression, but at this point it doesn't seem to
     be working (or even having any effect, for that matter); and will the
     problem just return at execution when that image 'demands' zero-filled
     sections of virtual memory the size of the Louisiana Purchase?

   - increase virtual address space, i.e. raising VIRTUALPAGECNT.  It is
     currently 45960.  What ramifications will this have on system behavior
     and other system parameters?

Or are there other options?  I'm not a FORTRAN whiz; is there something we can
do at compile time?  For background info, this is on an 8530 with 20 Mb.
If more information is needed please let me know!


aTdHvAaNnKcSe,

% Denis W. Haskin                             Manager, Technical Services %
% ----------------------------------------------------------------------- %
% DHASKIN@CLARKU.BITNET   Office of Information Systems     (617)793-7193 %
% Clark University               950 Main Street      Worcester MA  01610 %
%                                                                         %
%                       "Revenge is best served cold."                    %
%                                -- Anonymous                             %