On 4/04/2016 7:41 AM, John McKown wrote:
On Sun, Apr 3, 2016 at 6:00 PM, Andrew Rowley <and...@blackhillsoftware.com>
wrote:
On 3/04/2016 22:43, David Crayford wrote:
Good question! Sort can be utilised for other purposes than sorting, it
can be used as an I/O engine. DFSORT (or Syncsort) implements bespoke
highly optinized I/O using low-level programming interfaces such as chained
EXCPs which are significantly faster than using standard access methods
like QSAM or BSAM, including overlapping BSAM I/O. DFSORT has exit routines
(callbacks) which get called for each record. Basically it's supercharged
I/O. One of our products does just that as do many others. IIRC, IBM
FileManager uses sort for I/O. The trouble with using this technique with
Java is the JNI/callback overhead.
I'm aware of the efficient I/O, but I'm more interested in the use to put
data into a particular order. My own programs I never sort input data,
frequently sort small subsets of data during processing (likely always too
small quantities for something like DFSORT) and almost always sort for
presentation. Presentation is hopefully also too small quantities for
DFSORT.
It is an interesting idea though to use it to read data via the exits
without actually giving it back to DFSORT to process.
I'm not an application programmer. But I can just imagine the looks of
astonishment and the "talk", if I were to write a COBOL program which does
a SORT verb with INPUT PROCEDURE IS and OUTPUT PROCEDURE IS which only did
a SORT FIELDS=COPY operation. Even more astonishment if I coded the INCLUDE
or EXCLUDE to subset my data in addition to, or instead of, using COBOL
code. I don't know if such coding would pass the majority of the "peer
review" type processes. I'd love to try. Especially if I were smart enough
to do so initially and keep the output listing. Then allow code review to
force me to use normal COBOL methods. And then show the differences,
assuming the SORT method actually is superior. Of course, I'd better know
my management. I was at one shop (sysprog) where my boss (sysprog +
manager) did that with a major application that would max the 3083 (long
ago). Basically he proved it was due a flawed design. Unfortunately, that
cost him him his job because the design was actually done by the head of
the company (software development company).
I'm sure the application folks would thinks you're a crazy, performance
obsessed systems programmer and should go back to your cave!
FileManager was developed at the IBM APC labs in Perth. I worked with
one of the lead developers on that product and they try to utilize
DFSORT as much as possible.
There must be significant man years of work optimizing the I/O in
DFSORT. It's sensible to try and leverage that. In the case of Andrews
I/O bound product he could possibly
significantly accelerate the throughput if he could somehow hook into
sort. Is it a big deal that DFSORT doesn't run on a zIIP when most of
the workload is I/O bound?
http://www.ibm.com/support/knowledgecenter/SSXJAV_13.1.0/com.ibm.filemanager.doc_13.1/base/funtips.htm
LOL! IBM had to write a FASTREXX subset because standard REXX was a dog!
--
Andrew Rowley
Black Hill Software
+61 413 302 386
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
