HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Hours:
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
cancel
Showing results for 
Search instead for 
Did you mean: 

VASFUL

 
SOLVED
Go to solution
Mulder_1
Frequent Advisor

VASFUL

I'm receiving the error when an image is being executed.

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!
16 REPLIES
Steven Schweda
Honored Contributor

Re: VASFUL

Did you get anything useful from
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.
Mulder_1
Frequent Advisor

Re: VASFUL

The VMS version is 7.3-1

and I have increased the Pgflquo: from 500000 to 600000.

I also get this error :
CRMP
Suggestions please
Jim_McKinney
Honored Contributor

Re: VASFUL

> CRMP

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.
Jon Pinkley
Honored Contributor

Re: VASFUL

Without more details, no one without psychic abilities is going to be able to help any more than with what help/message provides.

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
it depends
Andy Bustamante
Honored Contributor

Re: VASFUL

As Jon asked what's changed and did this ever work.

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
If you don't have time to do it right, when will you have time to do it over? Reach me at first_name + "." + last_name at sysmanager net
Hein van den Heuvel
Honored Contributor
Solution

Re: VASFUL

Contrary to the HELP /MESS VASFUL output, I do not think this eerror is ever cause PGFLQUOTA. Mostg certainly is has nothing to do with Working Set (WS) params.

Most 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








Willem Grooters
Honored Contributor

Re: VASFUL

Just a thought.

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.
Willem Grooters
OpenVMS Developer & System Manager
Hein van den Heuvel
Honored Contributor

Re: VASFUL

Willem>> Virtual Address Space Full = no sufficient virtual memory available. That is: either real, or on-disk ==> page- or swapfile.

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.
Hein van den Heuvel
Honored Contributor

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
Guenther Froehlin
Valued Contributor

Re: VASFUL

Just to make sure...VASFUL means there is a system service call to map more virtual address space and it would exceed beyond the 1GB architecturally limit for the programm region 0 on OpenVMS.

And concluding the "CRMP" is part of a message relating to create-and-map section...oh well.


Unless there was some sort of an RMS error message I would not assume this is even RMS related.

WHY DO WE HAVE TO GUESS SO OFTEN?
CAN'T WE GET A COMPLETE ERROR MESSAGE?

Here I said it!

/Guenther
Wim Van den Wyngaert
Honored Contributor

Re: VASFUL

Guenther,

I fully agree. We should have better messages (sometimes). Not only in old VMS stuff but also in the new ***open*** stuff (remember Unix 15 years ago just giving "error" when something went wrong, so worse exists).

We had the discussion before ...
http://forums12.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1221030884306+28353475&threadId=1046817

(some people just give to much points for off topic answers)

Wim
Wim
Hein van den Heuvel
Honored Contributor

Re: VASFUL

Wim, you are right about the quota thing, and even more about the Unix thing (from thousands of documented error codes on Openvms to a few dozen criptic codes on Unix... that's progress... NOT!).

But I think you are wrong on the interpretation of Guenthers reply.
That was actually aimed at the problem description, not at the OpenVMS code.

As all to often too case the problem description leaves much room for speculation.

In this particular case, the OpenVMS error is VERY specific with no room for alternative interpretation which is why I'm so surprised by the various suggestions about looking at available memory and working sets .... but the HELP/MESS might not be entirely correct, or maybe it is me who is terribly confused.

As with so many question here, the initial detail are none-existant. "It doesn't work".
Here at least we have a correct spelled error code but no clue what is being tried, and eventually and other error code is offered without much context either.

If the CRMP code reported is correct, then that point 100% to RMS.
Check out with $HELP/MESS CRMP
And the VASFUL perfectly fits with a known failure scenario for CRMP for any OpenVMS version before 8.2. But that version was not initially provided.

fwiw,
Hein.
Wim Van den Wyngaert
Honored Contributor

Re: VASFUL

Stupid me.

BTW : are file stat activated for usage in monitor ?
This could also be the reason according to the help text.

Wim
Wim
GuentherF
Trusted Contributor

Re: VASFUL

My point was about the obscene meager problem description. I didn't even know that there was a specific RMS-F-CRMP...which would have pointed straight to RMS.

You guys are pretty good in associating the near nothing with something.

Ok, so it is clearly an RMS problem creating global buffers because there is not enough VA left in P0. This could be caused by program mallocs or, with the way the program opens/closes files with global buffers (and I am with you on that, Hein).

/Guenther
Mulder_1
Frequent Advisor

Re: VASFUL

Thanks to all !!

The error was with the application which was comsuming too much VA.

Jan van den Ende
Honored Contributor

Re: VASFUL

FOX,

>>>
Thanks to all !!
<<<

So, how about spending some points?

(Zero for this entry, please)

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.