10 Apr
2012
10 Apr
'12
11:35 a.m.
Peter Coghlan wrote:
Yes done Autogen several times and nailed pagefile.sys and swapfile.sys to
0 now in modparams.dat.
Nothing clear until now... maybe you want to check yourselfes:
http://polarhome.com/vim/files/source/vms/vim-73-src-vms.zip
I think this is the source I'm using currently, it should unzip into an
vim73-69 directory. In this directory you have some Install doc
INSTALLVMS.TXT, an mms Makefile MAKE_VMS.MMS and so on.
I've edited the mms file to build an text only version on the VAX7000 and a
motif Gui variant on the VS4000. There is no difference, the compiler
(Compaq cc v 6.4 or so from the hobbyist 7.3 CD) is hanging in sha256.c and
blowfish.c for ever. The process is cpu bound, the program counter (sh
proc/cont/id=) rotates around 200 Bytes in the 1B18xx .. 1B1Axx Area on
both machines, the 7000 on OpenVMS7.2 the VS on OpenVMS7.3.
I've tried to comment something out of blowfish.c to find what is
disturbing the compile but found nothing special until now. (mabe thats
realted to the fourdimensional array in there)
Currently I've disabled the crypto entirely in feature.h (Search for CRYPT)
and want to look if the rest is working.
Vaxman sayd, that he remembers that the C-compiler has a bug where it
simply stalls, this seems to be that bug..
I've stopped the tests on the VAX7000 since there are other things/people
that want some CPU time...
Kind Regards,
Holm
--
Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe,
Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583
www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741
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.
I'm glad the original problem is solved.
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...
You can check what the compiler is doing with the command:
$ SHOW PROCESS /CONTINUOUS /ID=xxxxxxxx
where xxxxxxxx is the process id of the process doing the compile.
You can also use MONITOR to see what the whole machine is doing.
$ MONITOR MODES
will tell you which processor modes are in use most. If it shows mostly user
mode, the compile is CPU bound. If it shows mostly kernel mode or interrupt
stack, there is an i/o bottleneck. If it shows mostly idle, something is wrong
and the compiler is not getting sufficient access to the machines resources.
$ MONITOR PROCESSES /TOPCPU
should show the compiling process as getting most of the CPU. If something else
is getting a significant amount of CPU, there may be something wrong.
I've compiled a fair amount of C on my VAX 4000/100A which is also pretty fast
and on my VAX 3100 model 76 which is less fast and I don't remember any single
source file taking anything like even 1 hour to compile. Are the sources
involved particularly large or complex? Does the compile show any signs of
making progress (for instance, is the object file or listing file growing in
size) or could it be stuck in a loop doing nothing useful? Is there too much
detail being logged in the listing file resulting in a huge listing output?
You haven't said whether you did an AUTOGEN or not. If you have not, I would
suggest doing one as this should help sort out any other system parameters
that might be incorrect.
I'll report later what happens..
I'd certainly be interested to know what's going on.
Regards,
Peter Coghlan.