Re: DFSORT chooses not to use Hipersorting for large SORTIN

2010-10-10 Thread Yifat Oren
For the records;

EXPMAX in effect was NOT set to MAX but much lower, which prevented DFSORT
from using any Hipersort option.

Many thanks to David Betten for his excellent assistance.

Best Regards,
Yifat

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: DFSORT chooses not to use Hipersorting for large SORTIN

2010-10-06 Thread David Betten
DFSORT evaluates the available resources and the characteristics of each
sort to determine whether or
not it would be beneficial to exploit Hiperspace, memory object or
dataspace.  Even though your system
is not paging, it's possible that DFSORT determined there was not enough
central strorage available to
be of benefit.  If you would like more detailed analysis, send a note with
your joblog to the DFSORT hotline,
dfs...@us.ibm.com and we can look more closely at it.  It would also be
helpful if you were able to rerun the
sort with //SORTDIAG DD DUMMY added to the JCL.  This causes DFSORT to
write additional diagnostic
message to sysout.



Have a nice day,
Dave Betten
DFSORT Development, Performance Lead
IBM Corporation
email:  bet...@us.ibm.com
1-301-240-3809
DFSORT/MVSontheweb at http://www.ibm.com/storage/dfsort/

IBM Mainframe Discussion List  wrote on 10/06/2010
01:19:53 PM:

> [image removed]
>
> DFSORT chooses not to use Hipersorting for large SORTIN
>
> Yifat Oren
>
> to:
>
> IBM-MAIN
>
> 10/06/2010 01:14 PM
>
> Sent by:
>
> IBM Mainframe Discussion List 
>
> Please respond to IBM Mainframe Discussion List
>
> Hello All,
>
> I have a sort of about 4GB, 15M records of variable length.
>
> For some reason DFSORT chooses not to use dataspace/hiperspace or memory
> objects for this sort for no obvious reason;
>
> Parameters are all set corrects (EXPMAX, RES, OLD and HIPRMAX and so on).
> The system is not paging at all.
>
> Only thing not tuned for this SORT (as far as I can see) is that it does
not
> know the AVGRLEN in advance, and wrongly calculated the
> number of expected records in the SORTIN (it expects 350k instead of 15m,
> based on the SORTIN LRECL).
>
> So, DFSORT volunteered not to use Hipersorting.
>
> Looking for answers I found this excerpt from DFSORT Tuning Guide on
> Hipersorting:
>
> When Hipersorting cannot be used, DFSORT uses disk work data sets to
store
> its intermediate data, which is referred to as disk-only
> mode. Note that Hiperspace-only mode usually provides the best
performance
> when compared to Hiperspace-mixed and disk-only
> modes. However, this is not always true for Hiperspace-mixed mode when
> compared to disk-only mode. Due to the additional
> Hiperspace overhead, the use of disk-only rather than Hiperspace-mixed
mode
> can at times be more advantageous in terms of
> performance, and therefore DFSORT may choose not to use Hipersorting.
>
>
>  So, what are those "times"; what made DFSORT use disk-only mode? The
file
> size (4GB)? The variable-length? The wrong records number?
>
> Any ideas would be appriciated,
> Yifat
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


DFSORT chooses not to use Hipersorting for large SORTIN

2010-10-06 Thread Yifat Oren
Hello All,
 
I have a sort of about 4GB, 15M records of variable length.
 
For some reason DFSORT chooses not to use dataspace/hiperspace or memory
objects for this sort for no obvious reason;
 
Parameters are all set corrects (EXPMAX, RES, OLD and HIPRMAX and so on).
The system is not paging at all.
 
Only thing not tuned for this SORT (as far as I can see) is that it does not
know the AVGRLEN in advance, and wrongly calculated the  
number of expected records in the SORTIN (it expects 350k instead of 15m,
based on the SORTIN LRECL).
 
So, DFSORT volunteered not to use Hipersorting.
 
Looking for answers I found this excerpt from DFSORT Tuning Guide on
Hipersorting:
 
When Hipersorting cannot be used, DFSORT uses disk work data sets to store
its intermediate data, which is referred to as disk-only 
mode. Note that Hiperspace-only mode usually provides the best performance
when compared to Hiperspace-mixed and disk-only 
modes. However, this is not always true for Hiperspace-mixed mode when
compared to disk-only mode. Due to the additional 
Hiperspace overhead, the use of disk-only rather than Hiperspace-mixed mode
can at times be more advantageous in terms of 
performance, and therefore DFSORT may choose not to use Hipersorting.

 
 So, what are those "times"; what made DFSORT use disk-only mode? The file
size (4GB)? The variable-length? The wrong records number?
 
Any ideas would be appriciated,
Yifat

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html