Alan:

Actually, recoding the JCL is very simple.  I have a business partner that can 
provide a solution that can "recode" thousands of JCL steps in a matter of 
minutes to any desired coding, including site standards, if applicable.

Regards,

Mitch McCluhan,
Legacy Modernization Consultant



-----Original Message-----
From: Alan Field <[email protected]>
To: IBM-MAIN <[email protected]>
Sent: Mon, Nov 25, 2013 8:49 am
Subject: Re: Has anyone measured CPU savings using external SORT's vs internal 
(COBOL) SORT's?


Peter,
Review/research the COBOL compiler FASTSRT option. If you are using it 
hat you suggest will possibly make things worse. 
If you aren't using it, it may be a cleaner solution that recoding JCL. to 
chieve the desired savings.
Alan Field
echnical Engineer Principal
CBS Minnesota
Phone: 651.662.3546  Mobile:  651.428.8826


From:   "Farley, Peter x23353" <[email protected]>
o:     [email protected], 
ate:   11/25/2013 09:43
ubject:        Has anyone measured CPU savings using external SORT's vs 
nternal (COBOL) SORT's?
ent by:        IBM Mainframe Discussion List <[email protected]>

It has been suggested to management here that there could be potentially 
ignificant CPU savings from re-engineering application programs such that 
ny SORT's are done in a separate step, so that a program with a single 
nternal SORT would be broken up into a pre-SORT process followed by an 
xternal SORT of the massaged data followed by a post-process of the 
ORTed data.
The first obvious factor is that SORT (at least Syncsort and DFSORT) are 
far* more efficient at I/O than any COBOL program can be.  It is also 
bvious that the data volume would affect the relative CPU cost of the two 
ethods, with small volume possibly favoring an internal SORT and large(r) 
olume possibly favoring the external SORT process, FSVO "large(r)". 
ompressed (z/OS compression, not disk subsystem compression) vs 
on-compressed data files could also be another factor in CPU differences.
Has anyone else been asked to measure whether this claim is true or not, 
nd if true where the "break" point in volume might be?
TIA for any insight you can provide.
Peter
-
This message and any attachments are intended only for the use of the 
ddressee and may contain information that is privileged and confidential. 
f the reader of the message is not the intended recipient or an 
uthorized representative of the intended recipient, you are hereby 
otified that any dissemination of this communication is strictly 
rohibited. If you have received this communication in error, please 
otify us immediately by e-mail and delete the message and any attachments 
rom your system.
----------------------------------------------------------------------
or IBM-MAIN subscribe / signoff / archive access instructions,
end email to [email protected] with the message: INFO IBM-MAIN

---------------------------------------------------------------------
or IBM-MAIN subscribe / signoff / archive access instructions,
end email to [email protected] with the message: INFO IBM-MAIN


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to