home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / vms / 22143 < prev    next >
Encoding:
Text File  |  1993-01-28  |  3.8 KB  |  75 lines
  1. Newsgroups: comp.os.vms
  2. Path: sparky!uunet!UB.com!pacbell.com!decwrl!spool.mu.edu!uwm.edu!linac!unixhub!slacvx.slac.stanford.edu!fairfield
  3. From: fairfield@slacvx.slac.stanford.edu
  4. Subject: Re: MEMFUL on large arrays
  5. Message-ID: <1993Jan26.235037.1@slacvx.slac.stanford.edu>
  6. Lines: 62
  7. Sender: news@unixhub.SLAC.Stanford.EDU
  8. Organization: Stanford Linear Accelerator Center
  9. References: <4582@winnie.fit.edu> <1993Jan26.155520@mccall.com>
  10. Distribution: usa
  11. Date: Wed, 27 Jan 1993 07:50:37 GMT
  12.  
  13. In article <1993Jan26.155520@mccall.com>, tp@mccall.com (Terry Poot) writes:
  14. > In article <4582@winnie.fit.edu>, karin@zach.fit.edu (Karin Nicholson) writes:
  15. >>I have a friend who wants to run a program that has large arrays. He hasn't
  16. >>been able to get beyond linking the darn thing.  His declaration section
  17. >>reads as follows:
  18. >>
  19. >>     COMMON X(2400,2400),A1(2400,2400),A2(2400,2400),WT(5,2400),
  20. >>     & XT(2400,2400),D(2400),XMEAN(2400),SUM(2400),SD(2400),DT(2400)
  21. >>      CHARACTER*15 IN(12),OUT1,OUT2
  22. >>
  23. >>When he tries to link, he gets the following messages:
  24. >>
  25. >>%LINK-E-MEMFUL, insufficient virtual address space to complete this link
  26. >>-LINK-E-NOIMGFIL, image file not created
  27. >
  28. > I assume you know how big this is!  Anyway, this happened to me a long long
  29. > time ago, and the answer was to raise the sysgen parameter VIRTUALPAGECNT.
  30. > Apparently, you need to be able to virtually address the whole image to
  31.                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  32. > link it.  You also had better check the size of your page file.  This
  33. > program uses over 100 megabytes of virtual memory, which means you are
  34. > going to need a page file well over 200,000 blocks, and your virtualpagecnt
  35. > parameter is going to have to be upwards of 200,000 also.  Read the manuals
  36. > to learn all the ramifications of this, do _not_ simply take my word for
  37. > it.  This was about 10 years ago, on VMS 3.2 or something like that!
  38.  
  39.     You don't have to be able  to  virtually address the whole image.  I
  40.     know  because  I  recently had a user come to me  with  the  related
  41.     problem that he could link an image, he  but  couldn't  activate  it
  42.     because of insufficient VIRTUALPAGECNT...and see below.
  43.  
  44.     However, something the Terry neglected to mention is that the user's
  45.     PGFLQUO (set via AUTHORIZE) must also be large enough to contain the
  46.     virtual address space of the image.  Thus to run your large, >200000
  47.     page image, you'll need VIRTUALPAGECNT  and PGFLQUO larger than, but
  48.     on  the  order of, 200000 pages, and you'll need  your  PAGEFILE.SYS
  49.     about the same size (in blocks :-).
  50.  
  51. >>I'd like to know where in the grey wall I can find out more information about
  52. >>demand-zero compression.  I have looked in a couple of places, but came up
  53. >>empty-handed.
  54. >
  55. > The linker manual.  VIRTUALPAGECNT is in the sysgen manual, and you'll also
  56. > want to look at the various system management guides about sysgen
  57. > parameters and managing page files and virtual memory.
  58.  
  59.     There was an interesting thread in this group at the end of December
  60.     under the subject "ballooning  EXE  size"  that  explored use of the
  61.     ISD_MAX  linker option to increase the allowed number of demand-zero
  62.     image sections.  You may  want  to  retrieve  these  items  from  an
  63.     INFO-VAX archive near you.  But I found Steve Lionel's suggestion to
  64.     use  the  COLLECT  linker option the most interesting.  I've saved a
  65.     copy that I can forward  if  you  like  to  see it (won't solve your
  66.     problem).
  67.  
  68.         -Ken
  69. --
  70.  Dr. Kenneth H. Fairfield    |  Internet: Fairfield@Slac.Stanford.Edu
  71.  SLAC, P.O.Box 4349, MS 98   |  DECnet:   45537::FAIRFIELD (45537=SLACVX)
  72.  Stanford, CA   94309        |  BITNET    Fairfield@Slacvx
  73.  ----------------------------------------------------------------------------
  74.  These opinions are mine, not SLAC's, Stanford's, nor the DOE's...
  75.