Updated info from IBM, 7/24
*** Updated by: Keith NIELSEN *** Email: [email protected]<mailto:[email protected]> . Additional comments I tested various increases in the MAXLIM, MINLIM, and TMAXLIM installation parms and saw no change in the performance. From what I can tell Striped datasets are using less than system definition for striped datasets. I compared the sort to an EZTRIEVE program. Each job simply read the input and ignored outputing. The eztrieve took 21 cpusec and sort 14 cpu secs. But on elapsed time the EZTRieve took 22 secs and SORT 61 secs elapsed. I would expect adding or specifying buffers for the SORTIN and SORTOUT files would be the easiest coding for the DFSORT developers compared to everything else. Keith . Smith, Samuel R A7/22/14 7:43 PM Hello Keith, I have discussed this issue in great detail with my DFSORT colleagues and we do not see this as a defect. As per my previous update, IOMAXBF is really just a limit. For a SORT operation, DFSORT must read the input differently in anticipation of passing records to sort. Thus we have to keep virtual storage available for SORTWK buffers and other areas required for sorting. We also tend to read smaller amounts of data at a time to facilitate sort processing and overlap. The logic for COPY is much simpler and thus we have opportunity to better optimize. . I will pass your comments along to the rest of my team to see if they have any additional comments based on your testing. Best Regards, Sam Smith - DFSORT ****ACTION TAKEN**** Advised Keith that the DFSORT team does not recognize this as a defect. ****ACTION PLAN**** Re-queue to the attention of Keith. Customer Update7/24/14 4:12 PM *** Electronic submission by customer via SR tool, version 3.1.A *** Preferred contact method: Daytime phone. *** Customer contact full name: Keith NIELSEN *** Telephone: 704-2874161 *** Email: [email protected]<mailto:[email protected]> *** Updated by: Keith NIELSEN *** Email: [email protected]<mailto:[email protected]> . Additional comments I reran my tests against Ezytrieve with 15 buffers using the same large striped dataset (16 volumes). Ezytrieve again outran the SORT performing INCLUDE only. Rerunning the SORT without the include and actually sorting the data and writing out to the SORTOUT file took 200 secs elapsed time. SORT reading of the file takes about 60 secs and assuming SORTOUT takes 60 secs this implies 80 secs for the actual sorting of the data. The SORT itself used 29 GB of hiperspace storage which is about 29 thousand times as much storage as was used for the buffering. Keith . Smith, Samuel R 7/24/14 5:03 PM Hello Keith, I can't really comment on what EASYTRIEVE does or doesn't do. However, in DFSORT we have record level tracing which occurs when running a SORT. We found from our testing that it is this record level tracing which leads to the higher CPU times. When record level tracing was eliminated via testing it showed the CPU time for SORT to be nearly equivalent to CPU time for COPY. I am discussing your comments in more detail with my colleagues. I will promptly pass you another update as soon as I have some additional information for you. Best Regards, Sam Smith - DFSORT ****ACTION TAKEN**** Provided keith with a status for this issue. ****ACTION PLAN**** Continue with analysis and internal discussion. Smith, Samuel R A7/24/14 8:14 PM Hello Keith, I have discussed this issue in more detail with my colleagues. We appreciate your bringing this issue to our attention and the testing and results you have provided for us. However DFSORT is currently working as intended. We will certainly consider your results for future optimization of the product. We would like to suggest opening a design request form so that the Developers may evaluate and correspond directly with you regarding the elements of performance you have brought up. Again, we appreciate the time and effort you have put into this analysis and we are always looking for ways to improve the performance of our product. . To submit a design change request you need to go to the following URL: . //www.ibm.com/developerworks/rfe/ . The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time. . This will allow you: - To be a part of the community and to provide open communications - To control the text within the RFE so privacy concerns are not exposed to the community - To communicate directly with the IBM Product Management and Community peers Best Regards, Sam Smith - DFSORT ****ACTION TAKEN**** Provided Keith with a URL to the new IBM RFE Community. ****ACTION PLAN**** Re-queue to the attention of Keith. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
