Open VMS i64 insufficient virtual memory error

[Munawar Hayat_1]

Hi All
I am facining the following error in open VMS 8.3 i64.

Error:
System service Error:
%sort/w/syserror.system

Insufficient virtual memory:
service error-lib-F-INF.virmem

The above problem is occour in sorting. We have increase the virtual memory using sysgen utility but it did not help, still the same error in sorting.

Please advise.

regards
Munawar Hayat

[kari salminen]

This might help:

http://h71000.www7.hp.com/wizard/wiz_9501.html

[Admin: The above link is no longer valid, please use the below link]

https://support.hpe.com/hpesc/public/km/search#q=Open%20VMS%20i64%20insufficient%20virtual%20memory%20error&t=Documents&sort=relevancy&layout=table&numberOfResults=25&f:@kmdoclanguagecode=[cv1871440]&hpe=1

[Karl Rohwedder]

You should also check the user quota, e.g. PGFLQUOTA and increase it accordingly (using the AUTHORIZE utility).

regards Kalle

[John Gillings]

Munawar,

No excuse for INSVM or INSVIRMEM errors on today's systems. You probably have gigabytes of main memory, you should have tens of gigabytes of pagefile space and huge page file quotas. Memory is cheap, time is expensive. Artificially constraining processes to small memory spaces is bad economics.

SORT has a quirk in its memory management logic which can result in INSVIRMEM errors when PGFLQUOTA is less than WSEXTENT (and note that WSEXTENT will most often be derived from the SYSGEN parameter PQL_MWSEXTENT, rather than the UAF value). Check from the process getting the error:

$ WRITE SYS$OUTPUT F$GETJPI("","PGFLQUOTA")
$ WRITE SYS$OUTPUT F$GETJPI("","WSEXTENT")

Make sure PGFLQUOTA is several times WSEXTENT.

Also check the file you're sorting for an oversized LRL:

$ WRITE SYS$OUTPUT F$FILE(file,"LRL")

if it's 32767, it's probably wrong! If you know the "real" LRL (Longest Record Length), fix it with:

$ SET FILE/ATTR=LRL: file

or (safer):

$ CONVERT file newfile/FDL="RECORD; FORMAT VARIABLE"

CONVERT will set the LRL of the output file to the size of the longest observed record.

If the LRL is wrong, as well as potential INSVIRMEM errors, even if it completes your SORT is probably taking much longer than necessary. You'll almost certainly find a CONVERT then SORT will be *much* faster than sorting the original file (I've seen cases where SORTs went from more than 20 minutes to sub second after correcting the LRL).

[Hein van den Heuvel]

Munawar,

Welcome to the OpenVMS forums.
The most important advise has been given already. Read carefully and apply.


I'm curious as to what you changed in SYSGEN and how and why !?

Did you change VIRTUALPAGECNT as perhaps suggested (for VAX) by: $help /mess/fac=lib insvirmem
That param is already set to the max and clearly marked as 'Obsolete'.

Also, PLEASE very carefully retype error messages, or better still cut & paste it.
Every detail may be important.
The 'mess' you presented is not acceptable for serious support work.

Hope this helps some,
Regards,
Hein.

[The Brit]

I see similar "virtual memory" errors in my job streams when the data sets are large, (and/or when many keys are used). Try using the "HyperSort" utility, it is much more efficient.

$ Define/Sys SortShr Sys$Library:HyperSort.Exe

Dave.

[Colin Butcher]

Hello,

As others have said, this is working set quota related. I've seen it a few times when working sets have been increased dramatically, often to provide large working sets for Java based programs.

One other thing you may wish to consider is using Hypersort instead of "normal" sort. Simply follow the instructions in the relevant manual, but do read and understand the limitations of Hypersort carefully.

In general it will get you improved sort performance.

Cheers, Colin (http://www.xdelta.co.uk).