I used to work for the late great Security Pacific, at the time the largest 
bank based in Los Angeles. When DFSORT was a pimply-faced teenager, some of us 
sysprogs were invited to Santa Teresa to meet with product developers to share 
some real-world feedback. They were a young and earnest bunch. They wanted us 
to help them decide between two frequently conflicting goals:

  Minimize CPU time
  Minimize I/O count

Enhancing one often came at the expense of the other. We couldn't wait to lay 
it on them. Every business day at 2 AM, a messenger would arrive at our data 
center to collect a bag containing all the checks processed that day along with 
reports tied to them. The bag was to be delivered to 'the feds downtown'. If 
the bag was ready for pickup, all was sweetness and light. If the bag was late, 
there would be h*ll to pay. That's all that mattered: wall clock time. It was a 
revelation to the developers. 

Every serious business has to sort data for a myriad reasons, all of which boil 
down to this: somewhere along the line--surely more than once--data must be 
processed in some kind of order. Maybe by account number. Maybe by account 
name. Maybe by account value. Each of these needs requires ordering unsorted 
data or data previously sorted for another purpose. Sort is a huge lynchpin in 
the foundation of any large business. Argue about CPU or I/O stats all you 
want. You either meet your 'messenger' deadline or you don't.  

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Blaicher, Christopher Y.
Sent: Sunday, April 03, 2016 6:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Why sort (was Microprocessor Optimization Primer)

Along with the other reasons outlined by others, it significantly improves bulk 
processing, I shy away from the term batch because that has come to have a bad 
connotation.

When dealing with individual transactions, such as an ATM transaction or a web 
transaction, sorted data is not needed.  But, when company goes to process all 
the payments received that day, or checks that cleared, etc., processing is 
much improved when the data coming in is in the same sequence as the existing 
data structure.  It improves because of locality of reference.

Using a relational data base, or any other random access method, doesn't mean 
you have to access it randomly.

Chris Blaicher
Technical Architect
Software Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Andrew Rowley
Sent: Sunday, April 03, 2016 2:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Why sort (was Microprocessor Optimization Primer)

On 02/04/2016 10:09 PM, David Crayford wrote:
> IBM switched the magic bit to offload the JZOS JNI C/C++ workload to a 
> zIIP so they could do the same for DFSORT. A well engineered library 
> could handle the callbacks so the client just reads records like a 
> normal API. That would certainly push Java batch up a notch.
One question that puzzles me (maybe it's my lack of an application programming 
background): Why is sort used so much on z/OS?

I know you can then e.g. do grouping based on key changes, but is that really 
necessary in current programs? Is that the reason it is commonly used?

I generally use e.g. Java HashMap, C# Hashtable for grouping so the data 
doesn't need to be sorted. Do other common languages on z/OS provide similar 
functions? (C++ I know.) Are there opportunities to use programming language 
features to avoid sorts altogether?

Andrew Rowley

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to