How to determine wsextent/pgflquo differences for hypersort

[bill crowley]

Are there any rule of thumb type of calcs that can be done to determine what the wsextent should be set to when switching from sort to hypersort on OpenVMS 7.3 ?

[Arch_Muthiah]

Bill,
PageFile quota need to be three times the workingset size or even larger.

If insufficient virtual memory is detected, hypersort terminates with INSVIRMEM or possibly ACCVIO error.


Archunan

[Arch_Muthiah]

Bill,

You many be known that hypersort has so many restrictions with OpenVMS V7.3, mentioned in the OpenVMS V7.3 release notes. You can find some tips using hypersort in the program to avoid working set and pagefile quota size related....

http://www.itec.suny.edu/scsys/vms/OVMSDOC073/V73/6637/6637pro_008.html


Archunan

[John Gillings]

Bill,

On most systems these days PQL_MWSEXTENT is set to WSMAX by AUTOGEN. In general, this is a good thing. For one it means you can forget about WSEXTENT in AUTHORIZE as SYSGEN will override anything you set with the maximum possible setting. If your PQL_MWSEXTENT is less than WSMAX, then set the process WSEXTENT to WSMAX.

If you haven't tuned it down in MODPARAMS, WSMAX will be set to 1/4 of physical memory on your system. Again, this is good. You paid for the memory, you may as well use it!

So, that just leaves PGFLQUOTA. The simple rule of thumb is LOTS. Make sure you have plenty of pagefile. With disk capacity prices as low as $1 per gigabyte, why not splash out and spend $20 on virtual memory ;-)

For serious SORTing (and why else would you use hypersort?) I'd recommend PGFLQUOTA at least 10x WSMAX. Remember quotas are only to protect you from malicious or buggy software consuming enough resources to affect other users.

As long as you don't set it higher than 1/2 your physical page file size, you should be safe enough. At the completion of the sort, check VIRTPEAK to see how much virtual memory you consumed.

Sanity check to make sure you don't consume way too much virtual memory, check the source file for the SORT. If it's STREAM_LF, make sure the LRL (Longest Record Length) is NOT 32767 (as created by some C programs). If it is, try CONVERTing the file to variable length before the SORT. A quicker fix is to use SET FILE/ATTR=LRL:new-value to a saner value. The downside if you set it smaller than the real longest record size, the SORT will fail with an RTB error.