Peter:
This story spans 2 decades of stories and hist and OS/s (and sorts).
In the 70's we were gasping for CPU and looked at practically
everything.
We tried doing things to economize on CPU resources.
We tore apart programs and tried to quantify items.
We even had the assembler people write sort exits E15, E35 (and god
yes E61) amongst others.
I think looking back it came down with COBOL (I have long lost the
papers we wrote). That the "worst" performance was what you did when
you did during the input procedure and output procedure. By "did" I
mean how much other I/O and CPU the program did. BUT in the end
splitting up programs did little in saving time (CPU & ELAPSED). Yes
sure there is step init/ending time etc etc but we are usually
talking small amounts of time .
Don't get me wrong adding up times amounts to at best 10-15 minutes a
day, but usually re-examining tape unmount/remount time was most of
it. With a few judicious disp=(new,pass) it saved most of it. With
disk there is little to manage so if you manage the resources well
its very little to save.
USING DISK input output takes it down even further, so doing a good
job on Disk should help.
The second thing is that difficulty in sorting with a program is that
when it breaks (and it does) your people have to be pretty good
debuggers.
We had a few programmers who tried to dump their S0C4's and S0C7's on
us.
My rule of thumb is that only when they can present a dump that us
SYSPROGS can't explain while we take any responsibility.
I have kick out several programmers who were to lazy to debug.
Ed
On Nov 25, 2013, at 12:28 PM, Farley, Peter x23353 wrote:
I mean the second, using the COBOL SORT verb to invoke the SORT
from within the program. And I tend to agree with you. Just
looking for reasons other than the ones I have thought of to refute
the claim that was made.
Peter
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-
[email protected]] On Behalf Of Shmuel Metz (Seymour J.)
Sent: Monday, November 25, 2013 11:30 AM
To: [email protected]
Subject: Re: Has anyone measured CPU savings using external SORT's
vs internal (COBOL) SORT's?
In
<985915eee6984740ae93f8495c624c6c231f711...@jscpcwexmaa1.bsg.ad.adp.co
m>,
on 11/25/2013
at 10:43 AM, "Farley, Peter x23353" <[email protected]>
said:
It has been suggested to management here that there could be
potentially significant CPU savings from re-engineering application
programs such that any SORT's are done in a separate step, so that
a program with a single internal SORT would be broken up into a
pre-SORT process followed by an external SORT of the massaged data
followed by a post-process of the SORTed data.
By "internal sort" do you mean a sort programmed in COBOL, or do you
mean invoking the sort utility from within the COBOL program? If the
latter, why would separate job steps be more efficient? For that
matter, why wouldn't it be less efficient?
--
This message and any attachments are intended only for the use of
the addressee and may contain information that is privileged and
confidential. If the reader of the message is not the intended
recipient or an authorized representative of the intended
recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this
communication in error, please notify us immediately by e-mail and
delete the message and any attachments from your system.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send 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
