Ok, THX guys,
I've managed to get this thing running again, don't ask me how :-)
It's hard to know how to advise you where to go next when you don't tell us
where you are now :-)
But my first problem, the cause of the fiddling with the system paramaters
persists.
This is the VIM73-69 source for VMS:
The adequate command for mmk is:
mmk /descrip=Make_vms.mms
NOTE: Because of empty /auto/config.h (needed for Unix configure)
build
will fail with very strange messages. Therefore before building, it is
recommended to make one clean up, to prepare everything for OpenVMS
development. The command is:
Buffer: INSTALLVMS.TXT | Write | Insert |
Forward
$ mms /descrip=Make_vms.mms
using DECW/Motif/XPM environment.
creating OS_VMS_MOTIF.OPT file.
cc
/def=("FEAT_BIG","HAVE_CONFIG_H","FEAT_GUI_MOTIF","HAVE_XPM"
)
/opt/prefix=
all /include=([.proto],decw$include:) BLOWFISH.C
%CLI-F-TEXT, Compiler abort - virtual memory limits exceeded.
%SYSTEM-F-ABORT, abort
%MMS-F-ABORT, For target BLOWFISH.OBJ, CLI returned abort status:
%X0000002C.
-SYSTEM-F-ABORT, abort
$
I've googled for the error and found this:
http://www.jcameron.com/vms/em12.htm
...that was the beginning of the problem.
[snip]
So what should I do next to try to compile that VIM source (hopefully w/o
to destroying the system again)
That webpage has some good advice. The C compiler installation guide should
include details on what SYSGEN parameters and user quotas need to be set to
for the compiler to function properly as well as how to set them.
If you don't have the installation guide, I would suggest finding out what
VIRTUALPAGECNT is now and if it is "small", increase it is smaller steps
than previously using AUTOGEN (not using SYSGEN, if that's what was used
before).
$ WRITE SYS$OUTPUT F$GETSYI("VIRTUALPAGECNT")
will tell you what VIRTUALPAGECNT is set to now. Suppose it 64000. You could
try adding the line:
MIN_VIRTUALPAGECNT=100000
to the bottom of SYS$SYSTEM:MODPARAMS.DAT using the editor.
and then use the following command to run AUTOGEN:
$ @SYS$UPDATE:AUTOGEN SAVPARAMS SETPARAMS
Then review the log files that AUTOGEN says it is producing and if things
look good, shut down and reboot.
Next, make sure that the userid running the compile has as much page file quota
as VIRTUALPAGECNT will allow:
$ SET DEFAULT SYS$SYSTEM
$ RUN AUTHORIZE
MODIFY HOLM /PGFLQUOTA=100000
If the userid is already logged in, be sure to log out and log back in to get
the new user quota to take effect. Then retry the compile. If it still fails,
check that VIRTUALPAGECNT has indeed been increased as expected and use:
$ SHOW PROCESS /QUOTA
in the same process as attemtped the compile to see what its pagefile quota is
set to. If they are as expected and the compile still fails, try increasing
both items some more as per the above procedure. Maybe try 150000 if 100000
is not sufficient.
The VS4000 has 64 Mbytes of Ram, I think that should be sufficient to
compile something like this, so it seems to me that some quote values are
the problem.
What a process sees is virtual memory, not physical memory. The amount of
virtual memory a process can use depends on system parameters such as
VIRTUALPAGECNT (and BALSETCNT as pointed out by someone else) and user quotas
such as PGFLQUOTA and the size of the page file on disk. The process can end
up seeing less memory than physically exists or more memory than physically
exists depending on how various system parameters are set and how big the
page file is. VMS has lots of parameters to control memory allocation in order
to try to avoid just giving processes what they ask for and ending up leaving
other more important processes starved for memory when they need it.
Regards,
Peter Coghlan.
I have cleared this in the meantime with some help of B. Ulmann aka vaxman.
The paging file was much to small, I've diabled swapping and created a
much bigger pagefile.sys (500000 blocks), raised PGFLQUOTA to 130000 blocks
and some other things. The compiling doesn't stop now anymore because of
vm-space outage.
There are orher problems now with that VIM Source, the files blowfish.c and
sha356.c take very very much time to compile. I do have an account on
Vaxmans VAX7000/820 and even on this machine the compiling was not done after
13hrs of CPU Time. SHA356.c behaves pretty much similar.
I'll look later this day if the compiling gets done on this machine, on my
VS4000 the same process is running now for 12hrs on the CPU and the
VS4000/90 isn't the slowest VAX so far as I know...
I'll report later what happens..
Kind Regards,
Holm
--
Technik Service u. Handel Tiffe,
, Holm Tiffe,
Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583