ginal Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
Pawel Leszczynski
Sent: Wednesday, January 27, 2010 9:23 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: why compression costs additional I/O?
Hi Yifat,
Thanks for answer - you are right! - I 've
Ron Hawkins
Sent: Wednesday, January 27, 2010 10:28 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: why compression costs additional I/O?
Peter,
Yes for your example I am recommending NCP=96, which means BUFNO=96. I
habitually put both NCP and BUFNO on BSAM files because I've never been sure
if BSAM cal
n
Behalf Of
> Farley, Peter x23353
> Sent: Wednesday, January 27, 2010 11:51 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] why compression costs additional I/O?
>
> Ron,
>
> If a PS-E dataset has 6 stripes, are you recommending using NCP=96 (=16
> * 6)? If so, what BUF
To: IBM-MAIN@bama.ua.edu
> Subject: Re: why compression costs additional I/O?
>
> Pawel,
>
> For a regular DSORG=PS dataset DFSORT and SYNCSORT use their own
access
> method to read and write the SORTIN and SORTOUT using very efficient
long
> chained Start Sub-Channels. The E
the start and end of the SORT.
Ron
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
> Pawel Leszczynski
> Sent: Wednesday, January 27, 2010 2:56 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: [IBM-MAIN] why compression co
Pawel Leszczynski wrote:
generally all of it probably mean that using DFSORT for compressed datasets is
not good idea.
The EXCP access method is not supported for extended sequential data
sets--whether compressed or not, striped or not. I/O for these data sets
is performed by Media Manager
s.ibm.com
DFSORT/MVSontheweb at http://www.ibm.com/storage/dfsort/
IBM Mainframe Discussion List wrote on 01/27/2010
10:23:22 AM:
> [image removed]
>
> Re: why compression costs additional I/O?
>
> Pawel Leszczynski
>
> to:
>
> IBM-MAIN
>
> 01/27/2010 10:26 AM
>
010 12:56 PM
>To: IBM-MAIN@bama.ua.edu
>Subject: why compression costs additional I/O?
>
>Hello everybody,
>Recently we are reviewing our EndOfDay jobs looking for potential
>performance improvements (reducing CPU/elapsed time).
>We have several jobs sorting big datasets where out
.
Hope that helps,
Yifat Oren.
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Pawel Leszczynski
Sent: Wednesday, January 27, 2010 12:56 PM
To: IBM-MAIN@bama.ua.edu
Subject: why compression costs additional I/O?
Hello everybody,
Recently
On Wed, 27 Jan 2010 12:28:56 +0100, R.S.
wrote:
>W dniu 2010-01-27 11:55, Pawel Leszczynski pisze:
>> Hello everybody,
>> Recently we are reviewing our EndOfDay jobs looking for potential
performance
>> improvements (reducing CPU/elapsed time).
>> We have several jobs sorting big datasets where
Pawel,
>Hello everybody,
>Recently we are reviewing our EndOfDay jobs looking for potential >performance
>improvements (reducing CPU/elapsed time).
>We have several jobs sorting big datasets where output is SMS-compressible
>(type: EXTENDED) datasets.
>When we compare such sorting with sorting on
f 5 - or any larger number you
specified originally,
Nigel
Nigel Wolfendale
nigel.wolfend...@btinternet.com
+44(0)1494 723092
+966(0)540217367
From: R.S.
To: IBM-MAIN@bama.ua.edu
Sent: Wednesday, 27 January, 2010 14:28:56
Subject: Re: why compression costs addi
W dniu 2010-01-27 11:55, Pawel Leszczynski pisze:
Hello everybody,
Recently we are reviewing our EndOfDay jobs looking for potential performance
improvements (reducing CPU/elapsed time).
We have several jobs sorting big datasets where output is SMS-compressible
(type: EXTENDED) datasets.
When we
Hello everybody,
Recently we are reviewing our EndOfDay jobs looking for potential performance
improvements (reducing CPU/elapsed time).
We have several jobs sorting big datasets where output is SMS-compressible
(type: EXTENDED) datasets.
When we compare such sorting with sorting on non-compress
14 matches
Mail list logo
