Re: SORT vs. IDCAMS was Re: Combining Fields From Files Without COBOL Pgm?
docdwarf_at_panix.com
Date: 07/27/04
- Previous message: Richard: "Re: cobol woes"
- In reply to: Clark F. Morris, Jr.: "SORT vs. IDCAMS was Re: Combining Fields From Files Without COBOL Pgm?"
- Next in thread: Chuck Stevens: "Re: SORT vs. IDCAMS was Re: Combining Fields From Files Without COBOL Pgm?"
- Reply: Chuck Stevens: "Re: SORT vs. IDCAMS was Re: Combining Fields From Files Without COBOL Pgm?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 27 Jul 2004 14:53:26 -0400
In article <ce5vaj$qv1$1@news.eusc.inter.net>,
Clark F. Morris, Jr. <cfmtech@istar.ca> wrote:
>This is for IBM z/OS and maybe VSE environments only. See below for
>discussion
>docdwarf@panix.com wrote:
[snip]
>> ... ultimately served to confirm my original prejudices and designs. The
>> first job was my original design, three steps of (Mr Yager's) SORT, a
>> DELETE/DEFINE and a Repro; given two input files of 64,159 records and an
>> output KSDS of 64,158 (header records dropped) the JESLOG showed:
>>
>> I/O COUNT CPU TIME(SECONDS) ESTIMATED COST
>> 316 1.45 $2.62
>> 28 .07 $.13
>> 1240 .73 $1.33
>>
>> JOB I/O COUNT= 1584 JOB CPU TIME= 2.25 EST. COST= $4.08
>>
>> ... and a second job, the first step being a DELETE/DEFINE, the second
>> being (Mr Yaeger's) SORT but OUT DD going to the KSDS defined in the first
>> step showed:
>>
>> I/O COUNT CPU TIME(SECONDS) ESTIMATED COST
>> 30 .07 $.13
>> 1906 2.20 $4.00
>>
>> JOB I/O COUNT= 1936 JOB CPU TIME= 2.27 EST. COST= $4.13
>>
>> ... showing clearly and unambiguously that Less is, in fact, More.
>>
>> DD
>>
>
>I find this interesting because my experienced with the competitor
>SYNCSORT has been the opposite.
Hey, if I wanted only agreement I would speak with my mirror.
>With SYNCSORT, you definitely lose if
>you specify BUFND and BUFNI (data and index buffering) because the SORT
>likes to optimize buffering. I used it for both dumping and reloading
>files. With IDCAMS unless you specify buffering you get poor
>performance because IDCAMS uses the defaults.
No buffering specified anywhere, I'm taking what the system offers. The
DEFINE is coded as:
DEFINE CLUSTER (NAME (MYUID.VSAM.KSDS) -
KEYS (9 1) -
VOLUMES (FILE25) -
CYLINDERS (550 100) -
RECORDSIZE (248 248) -
FREESPACE (15 20) -
REUSE -
SHAREOPTIONS (2 3))
... and it was done that way because 'That's The Way It Is Done Here'.
>Is there anything in the
>DF/SORT manuals about reading and writing VSAM files?
I found
<http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ICE1CA00/1.8.3.4?SHELF=&DT=20031124143823&CASE=>
... and it doesn't seem to mention anything too hectic about this
situation... but maybe another set of eyes or more might find something
I've missed.
>Given the
>original I-O counts, I would have expected an I-O count of no more than
>500 for the SORT step.
If expectations were always met there'd be so much less to learn, aye.
DD
- Previous message: Richard: "Re: cobol woes"
- In reply to: Clark F. Morris, Jr.: "SORT vs. IDCAMS was Re: Combining Fields From Files Without COBOL Pgm?"
- Next in thread: Chuck Stevens: "Re: SORT vs. IDCAMS was Re: Combining Fields From Files Without COBOL Pgm?"
- Reply: Chuck Stevens: "Re: SORT vs. IDCAMS was Re: Combining Fields From Files Without COBOL Pgm?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
