Path: utzoo!utgpu!water!watmath!clyde!rutgers!cmcl2!husc6!think!ames!pasteur!ucbvax!VENUS.YCC.YALE.EDU!LEICHTER
From: LEICHTER@VENUS.YCC.YALE.EDU ("Jerry Leichter ", LEICHTER-JERRY@CS.YALE.EDU)
Newsgroups: comp.os.vms
Subject: re: Process Page Table Quota Errors
Message-ID: <8802210452.AA28899@ucbvax.Berkeley.EDU>
Date: 16 Feb 88 22:59:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 32


	1) $CRMPSC a disk file section (in our case it's about 12000 blocks in
	size) 	[the available PTE count (watched with SDA) drops by about
	12000 blocks],

	2) Use the section for a little while,

	3) $DELTVA the section to release the virtual memory, but the
	available PTE count does *not* go back up!

	This is an intermittant problem which, when it strikes, causes the
	progam to eventually die with a SYSTEM-F-VASFULL error, since the
	program eventually tries to map in 48000 pages of disk file sections
	against a VIRTPAGCNT of 50000.  If the process page table thinks that
	it has one or two extra 12000  pages pieces of disk file section(s),
	this exceeds the VIRTPAGCNT by at least 10000 pages.

Are these writable sections?  Getting rid of a large, writeable section can
take quite some time (many seconds) - what VMS does is dump all the modified
pages onto the modified page list, then kick the modified page writer.  The
modified page writer will write out EVERYTHING on the modified page list.
Not until it's finished with that will the section really be freed up.  (This
same factor can cause very slow screen updates - "tiling" - on GPX's, BTW.
It's a recognized limitation of the current implementation of the VMS file
section flushing algorithms.  Not that $UPDSEC does the same thing - you don't
actually have to unmap the section.)

The only work-around I can think of is to have your code check the error
return from $CRMPSC and, if it's VASFULL, try again every again.  Trying
every second for perhaps 20 seconds should do it....

							-- Jerry