On Wed, 2006-02-15 at 16:29 -0500, Bruce Black wrote:
What does ISMF say about your default device geometry?
I am pretty sure that the SMS default geometry only affects space
calculations, converting CYL and TRK requests to bytes, and does not
affect SDB
I think Bob Rutledge has nailed the
In [EMAIL PROTECTED], on 02/15/2006
at 08:39 AM, David Andrews [EMAIL PROTECTED] said:
Is this really so? When SMF reports a particular number of EXCPs, I
believe it's really just counting blocks
It's counting EXCP's and adjusting the count to allow for chaining.
Keep in mind, however, that
On Wed, 2006-02-15 at 04:31 -0600, Ron MacRae wrote:
We have some fairly large LRECL FB sequential work files and were
finding them unblocked, which increased our I/O quite a bit.
Is this really so? When SMF reports a particular number of EXCPs, I
believe it's really just counting blocks (SMF
: Wednesday, 15 February 2006 6:31 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: DASD allocation guidelines
Guys,
That explains most of my issues. We have some fairly large LRECL FB
sequential work files and were finding them unblocked, which increased our
I/O quite a bit. So SDB always blocks
Ron and Jenny Hawkins [EMAIL PROTECTED] wrote in message news:[EMAIL
PROTECTED]...
Ron,
With Sequential pre-fetch in all cache controllers nowadays I don't think
you will see much of a difference between BLKSIZE=7000 and BLKSIZE=21000,
unless this is a very large file. If you want almost
roughly the same performance without wasting
space.
Ron
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Vernooy, C.P. - SPLXM
Sent: Wednesday, 15 February 2006 11:57 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: DASD allocation guidelines
In a recent note, Ron and Jenny Hawkins said:
Date: Thu, 16 Feb 2006 00:14:01 +0800
If you have been following this thread you will see that track usage is not
always better with larger blocksizes. I was corrected on this as well - for
an LRECL of 7000 a BLKSIZE of 21000 wastes more
Ron, I'm not sure I understand your advice. Could you explain the
difference between specifying BLKSIZE=0 and coding BLKSIZE=0?
TIA,
Greg Shirey
Ben E. Keith Company
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED]
Behalf Of Ron and Jenny Hawkins
Sent:
In a message dated 2/15/2006 10:49:37 A.M. Central Standard Time,
[EMAIL PROTECTED] writes:
Ron, I'm not sure I understand your advice. Could you explain the
difference between specifying BLKSIZE=0 and coding BLKSIZE=0?
It's a payfor service
I have found that DSORG PS and PO don't always get half track blocking with
SDB. For example, SDB picks a BLKSIZE of 7000 for LRECL 7000.
Assuming you are talking about RECFM=FB,
a blocksize of 7000 gets 6 blocks per track or 42000 bytes/track
a blocksize of 21000 (half-track) also gets 42000
was IEBGENERing an 80-byte
LRECL file to SYSUT2.
Jon
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Jon Brock
Sent: Wednesday, February 15, 2006 1:20 PM
Subject: Re: DASD allocation guidelines
I think he is referring to the difference between specifying BLKSIZE=0
Good point. I'll try again another way. But first I'll smack myself in the
face with a fish for forgetting this. 'S what I get for doing too many things
at once.
Jon
snip
Most forms of IEBGENER (including the real one these days, I believe)
preserve the input (SYSUT1) BLKSIZE unless it is
On 14 Feb 2006 08:27:41 -0800, in bit.listserv.ibm-main
(Message-ID:[EMAIL PROTECTED])
[EMAIL PROTECTED] (John P Kalinich) wrote:
I have found that DSORG PS and PO don't always get half
track blocking with
SDB. For example, SDB picks a BLKSIZE of 7000 for LRECL 7000.
Well, that makes
On 14 Feb 2006 09:22:07 -0800, in bit.listserv.ibm-main
(Message-ID:[EMAIL PROTECTED])
[EMAIL PROTECTED] (David Andrews) wrote:
Interesting. On my system (z/OS 1.3... yeah, I know) an
extended
sequential dataset at LRECL=6991 yields
BLKSIZE=27964. LRECL=6992
yields BLKSIZE=6992.
But
On Wed, 15 Feb 2006 12:46:53 -0500, Bruce Black [EMAIL PROTECTED]
wrote:
Assuming you are talking about RECFM=FB,
a blocksize of 7000 gets 6 blocks per track or 42000 bytes/track
a blocksize of 21000 (half-track) also gets 42000 bytes/track, no
difference.
By my calculation (verified by
On Wed, 2006-02-15 at 14:37 -0500, Arthur T. wrote:
Does your SMS pool have at least one 3380 defined?
No 3380s defined anywhere. HCD doesn't mention 3380s, D U,DASD
doesn't return 3380s. VATLSTxx says 3390s. VIO emulation is for 3390s.
I can't find 3380 anything. But it was a very
If you really want to maximize the FB blocksize (in the hopes of improving
performance without regard to impact on size), then specify the blocksize in
the JCL DD statement or DCB macro with a value computed as (32767/LRECL)*LRECL
using integer arithmetic. If you are willing to compromise a
On Wed, 2006-02-15 at 15:42 -0500, Bob Rutledge wrote:
What does ISMF say about your default device geometry?
Default Device Geometry :
Bytes/track . . . . . : 56664
Tracks/cylinder . . . : 15
--
David Andrews
A. Duda and Sons, Inc.
[EMAIL PROTECTED]
By my calculation (verified by experimentation) a blocksize of 7000 gets
7 blocks per track for 49000 bytes/track.
Oops, ur right. I read the 3390 blocksize chart wrong. So for
LRECL=7000, BLKSIZE=7000 gets MORE data on the track than 21000
(half-track).
BTW, the largest half-track record
In a recent note, Barry Schwarz said:
Date: Wed, 15 Feb 2006 12:15:39 -0800
If you really want to maximize the FB blocksize (in the hopes of improving
perfor
mance without regard to impact on size), then specify the blocksize in the
JCL DD
statement or DCB macro with a value
What does ISMF say about your default device geometry?
I am pretty sure that the SMS default geometry only affects space
calculations, converting CYL and TRK requests to bytes, and does not
affect SDB
--
Bruce A. Black
Senior Software Developer for FDR
Innovation Data Processing 973-890-7300
Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Greg Shirey
Sent: Thursday, 16 February 2006 12:45 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: DASD allocation guidelines
Ron, I'm not sure I understand your advice. Could you explain the
difference between specifying BLKSIZE=0
was not the best practice.
Greg
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED]
Behalf Of Ron and Jenny Hawkins
Sent: Wednesday, February 15, 2006 3:56 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: DASD allocation guidelines
Greg,
Coding this
//DD1 DD
February 2006 6:44 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: DASD allocation guidelines
Hmm, I get that, and maybe I'm just being slow, but you said:
...best practice for SDB is not to specify BLKSIZE=0, it is to specify
the
DCB and omit the BLKSIZE, or specify the DCB and code BLKSIZE=0.
I'm
Of Paul Gilmartin
Sent: Thursday, 16 February 2006 5:27 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: DASD allocation guidelines
In a recent note, Barry Schwarz said:
Date: Wed, 15 Feb 2006 12:15:39 -0800
If you really want to maximize the FB blocksize (in the hopes of
improving
In a recent note, Greg Shirey said:
Date: Wed, 15 Feb 2006 16:44:12 -0600
Hmm, I get that, and maybe I'm just being slow, but you said:
...best practice for SDB is not to specify BLKSIZE=0, it is to specify the
DCB and omit the BLKSIZE, or specify the DCB and code BLKSIZE=0.
I'm
Guys,
Thanks for the replies. Sorry I should have been clearer on the
question.
The problem I have is that SDB is not producing the block sizes I, or more
importantly my management, expect. Now it could be my understanding that is
wrong or it could be that SDB is not getting it right, or,
)*LRECL
- DSORG PS and PO both get half track blocking
Ron
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Ron MacRae
Sent: Tuesday, 14 February 2006 7:06 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: DASD allocation guidelines
Guys
:
@I-CABLE.COMSubject: Re: DASD allocation
guidelines
Sent by: IBM
Mainframe
On Tue, 2006-02-14 at 10:03 -0600, John P Kalinich wrote:
I have found that DSORG PS and PO don't always get half track blocking with
SDB. For example, SDB picks a BLKSIZE of 7000 for LRECL 7000.
Interesting. On my system (z/OS 1.3... yeah, I know) an extended
sequential dataset at LRECL=6991
allocation
guidelines
Mainframe
Discussion List
IBM-MAIN
Certain pathalogical LRECLs for FB data sets can store an odd number of records
if unblocked but one less if blocked close to half track. In the case of 7000,
7 unblocked records will fit on a track Blocking at 14000 will allow 3 blocks
(6 records) and blocking at 21000 will allow 2 blocks
but we didn't care while under RVA
because only the data was put onto real disk, we assumed this wastage of
3390 space was deliberate because there was no real correlation between
3390 space and RVA disk space.
We have STK devices. But I still worry about proper blocking of files and
try to
:[EMAIL PROTECTED] On
Behalf Of John P Kalinich
Sent: Wednesday, 15 February 2006 12:03 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: DASD allocation guidelines
I have found that DSORG PS and PO don't always get half track blocking
with
SDB. For example, SDB picks a BLKSIZE of 7000 for LRECL 7000
Appologies if anyone got this twice, it didn't seem to come through first
time.
Guys,
At the time that real 3390s were replaced by RVA/ICEBERG DASD we threw
away all our DASD allocation guidelines on blocksizes and space allocation
as RVA compressed the track anyway before storing only
I think your best answer here may be the shortest one.
Use BLKSIZE=0 and overallocate a bit with RLSE and let
the system take care of it. Another thought is to use
extended format QSAM files with software compression
and striping via DFSMS.
Subject: Re: DASD allocation guidelines
I think your best answer here may be the shortest one.
Use BLKSIZE=0 and overallocate a bit with RLSE and let
the system take care of it. Another thought is to use
extended format QSAM files with software compression
and striping via DFSMS
On Feb 13, 2006, at 11:40 AM, Ron MacRae wrote:
Appologies if anyone got this twice, it didn't seem to come through
first
time.
Guys,
At the time that real 3390s were replaced by RVA/ICEBERG DASD
we threw
away all our DASD allocation guidelines on blocksizes and space
allocation
38 matches
Mail list logo
