I can't speak to all (most?) of the current architecture boxes, but to attempt 
to answer Jantje's question, yes the boxes I'm familiar with will definitely 
store less data on small block sizes.  I am not speaking of the boxes that do 
thin provisioning because I haven't used this feature, but on IBM DS6800, EMC 
Symm (VMAX and DX4 w/o thin provisioning), and older HP/Hitachi XP arrays, when 
the physical disk was carved up into logical volumes for the emulated 3390 on 
top of them, storage was reserved for the physical capacity of the emulated 
drives.  Thus if I carved up physical disk into 3390-9 volumes, the array would 
reserve 8.3 GB of physical space per 3390-9 volume.

Rex
________________________________________
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Eric Bielefeld [eric-ibmm...@wi.rr.com]
Sent: Tuesday, July 23, 2013 12:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BLKSIZE=3120

I believe that the net result of coding smaller blocksizes does result in
being able to store less data.  If you had 1,000 volumes all defined as
3390-9s, and each volume had 100 datasets that filled the volume blocked at
512 bytes, you would store a fraction of the data if you blocked each of
those datasets at 1/2 track blocking.  That is a function of the z/OS
archictecture.

I don't know exactly how the data is stored on the tracks, but I believe
that the result of smaller blocksizes means that you will store a lot less
data.

Ron Hawkins probably is the best definitive source on this subject.

Eric Bielefeld
Retired z/OS Systems Programmer
Milwaukee, Wisconsin
414-475-7434

----- Original Message -----
From: "Jantje." <jan.moeyers...@gfi.be>
Newsgroups: bit.listserv.ibm-main
To: <IBM-MAIN@LISTSERV.UA.EDU>
Sent: Tuesday, July 23, 2013 5:32 AM
Subject: Re: BLKSIZE=3120


Taking the risk of starting another flame war here...

Are there still any shops that have actual SLED? In today's world of
emulated DASD, would it really still hold true that using smaller block
sizes is actually wasting space? After all, these bytes are in the end
physically written to FBA devices with 512 byte sectors, no? In the old
days, there were inter-record gaps that took up space, but is this still the
case? And even if the emulation is so good that it simulates those, what is
happening with the actual capacity of the physical disks. Is that being
eaten by simulated IRG?

Thanks for shedding some light on this, whoever knows the internals of these
current DASD boxes,

Jantje.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

The information contained in this e-mail may contain confidential and/or 
privileged information and is intended for the sole use of the intended 
recipient. If you are not the intended recipient, you are hereby notified that 
any unauthorized use, disclosure, distribution or copying of this communication 
is strictly prohibited and that you will be held responsible for any such 
unauthorized activity, including liability for any resulting damages. As 
appropriate, such incident(s) may also be reported to law enforcement. If you 
received this e-mail in error, please reply to sender and destroy or delete the 
message and any attachments. Thank you.



NOTICE:  This e-mail message, including any attachments and appended messages, 
is for the sole use of the intended recipients and may contain confidential and 
legally privileged information.
If you are not the intended recipient, any review, dissemination, distribution, 
copying, storage or other use of all or any portion of this message is strictly 
prohibited.
If you received this message in error, please immediately notify the sender by 
reply e-mail and delete this message in its entirety.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to