- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: VASFUL
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-08-2008 11:14 AM
тАО09-08-2008 11:14 AM
VASFUL virtual address space is full
I have increase the Pgflquo,WSquo,WSdef to a reasonable extent,but still receiving the error.
How it can be resolved,please let me know.
Thanks!
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-08-2008 11:25 AM
тАО09-08-2008 11:25 AM
Re: VASFUL
HELP /MESSAGE VASFUL
?
Did you think that no one would care which
VMS version you're running, or on what?
> [...] WSquo,WSdef [...]
It's complaining about _virtual_ memory, not
physical memory.
> [...] to a reasonable extent, [...]
Define "reasonable".
I won't bother asking about which "an image",
as it must be Top Secret as well as
unimportant.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-08-2008 11:41 AM
тАО09-08-2008 11:41 AM
Re: VASFUL
and I have increased the Pgflquo: from 500000 to 600000.
I also get this error :
CRMP
Suggestions please
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-08-2008 12:16 PM
тАО09-08-2008 12:16 PM
Re: VASFUL
You've failed to map a global section. So you've exhuasted one of gblsections, gblpages or gblpagfil. If you're attempting to open a file that has global buffers enabled then take a look at gblpagfil. If you're otherwise attempting to create a global section take a look at remaining pages or sections.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-08-2008 03:00 PM
тАО09-08-2008 03:00 PM
Re: VASFUL
What made you think an additional 100,000 would be sufficient? Has this unspecified program ever worked? If so, what has changed since it did work?
Jon
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-08-2008 03:18 PM
тАО09-08-2008 03:18 PM
Re: VASFUL
Some possible options to go with the possible problems:
Use INSTALL LIST/GLOB/SUMM to view gblsections/pages used. Run autogen and check feedback. How much memory physical/free on the system? Page file used?
Anal/system or F$GETJPI will provide process information. You can install Availablity Manager as well and monitor/modify the process on the fly.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-08-2008 04:29 PM
тАО09-08-2008 04:29 PM
SolutionMost likely it means what it says... Virtul addres speece full. Duh!
So go check by monitoring a process about to fail with SYS$GETJPI ... frep0va (and frep1va). For example:
$ write sys$output f$getjpi(pid,"frep0va")
The max is 0x3fffffff (1GB)
The most common cause I have seen is address spece laddering due to files with RMS Global buffers being opened and closed frequently in non-LIFO order.
Certainly any application performing frequent CRMPS + DELTVA calls can easily suffer from this. Workaround? Cache a series of address spaces 'holes' for re-use.
Jim K> You've failed to map a global section. So you've exhuasted one of gblsections, gblpages or gblpagfil
Huh? the process ran out of VA. Is that not enough of a reason? Nothing to do with any GBLxxx param.
Andy wrote> Use INSTALL LIST/GLOB/SUMM to view gblsections/pages used.
Please help me understand how that might help.
>> Run autogen and check feedback. How much memory physical/free on the system?
And then what? VIRTUAL = PROCESS address space is reported full, not physical.
Andy> Anal/system or F$GETJPI will provide process information.
Yes.. That should lead to understnading and explanation.
Jon> Has this unspecified program ever worked? If so, what has changed since it did work?
Yes... that is a good question to ask: wWhy now? Why not yesterday?
Attached a command file I wrote to monitor FREP0VA in a system every 10 minutes (by default) and send en Email the first time some process crosses 1/2 GB (default setting)
hth,
Hein van den Heuvel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-08-2008 10:06 PM
тАО09-08-2008 10:06 PM
Re: VASFUL
Virtual Address Space Full = no sufficient virtual memory available. That is: either real, or on-disk ==> page- or swapfile.
$ SHOW MEMORY/FILES
will probably tell.
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-09-2008 03:25 AM
тАО09-09-2008 03:25 AM
Re: VASFUL
No memory SPACE. This likely more than enough actual memory and virtual memory backing store. See my longish reply just earlier.
Willem> $ SHOW MEMORY/FILES ... will probably tell.
Probably not. It is a process thing, not a system thing.
The fact that the error is reported wit CRMPSC is why I do not thing this is a (virtual) memory problem/PGFLQUOTA.
CRMPSC does NOT use any (ok, very little) memory. It just reserves address space. It is when you touch a freshly mapped page that it starts to eat into pgflquota and/or te working set.
Here is how CRMPSC eats into Virtual memory SPACE:
Map S1 10MB, be told it is say on address 50MB. Unmap/deltva S1. Map S2 20MB. It is like to be mapped at address 50M as well (unless some mallocs + EXPREG address space expansion happened).
Map S1 10MB again. It will now be at address 70M.
Unmap S2. The adress space will not longer be used BUT since it is not the last sections, the FREP0VA can not be adjusted down. Nor remap S2. It will live at 80M-100M.
Do something like this 50 times and boom, the 1GB P0 space is gone before you know it, with hardly any pagefile or physical memory used.
One compounding factor is often other growth for P0 space, for example the malloc/GETVM I hinted at, and RMS local buffers and control block. You can sometime sufficiently mitigate the problem by pre-allocating both early: malloc/getm all your eventual needs in one chunk early on, and free that right away: For example a 50MB malloc + free.
For RMS be sure to LINK with the IOSEGMENT option set high (max 64K).
hth,
Hein.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-09-2008 02:20 PM
тАО09-09-2008 02:20 PM
Re: VASFUL
New details emerged, possibly applying to this question, in topic 1267093
It seems RMS global buffer may play a role.
If so, PLEASE upgrade to OpenVMS 8.2 at least, but 8.3 preferrably where the RMS GLobal buffer potential problem with VASFUL is pretty much fixed. RMS was tought to remember its REGIONs and re-maps same sized global buffers back to the last space used for that size which fixes that for all.
Not to mention that in 8.3 RMS will use P2 space for desperate case... but you would eventually run out of P1 if you really eat into P2 over and over.
hth,
Hein