As others have already stated, the physical disk space to represent an
emulated 3390 volume is only data-dependent if you are dealing with
log-mapped emulated DASD storage, like the Iceberg RVA, where each write
of an emulated track goes to a new physical location in the DASD
subsystem. I suspect most of the emulated 3390's these days are
fixed-mapped, which means when you define a 3390 drive you allocate
physical space capable of storing the maximum possible 56,664 bytes per
3390 track for as many tracks/cylinders as are in the emulated 3390
volume.
For fixed-mapped drives, if you choose to write blocks that only allow
fewer bytes to be used per 3390 track, that doesn't affect the physical
drive space allocated for the track and the difference can't be used for
anything else. So on fixed-mapped emulated 3390's, throwing away
emulated track capacity with a poor choice of block size is also
throwing away real physical DASD space.
Spreading the same amount of data over more blocks and emulated tracks
increases the CPU overhead of reading/writing the data in z/OS (more
buffers and blocks to manage, and either longer channel programs or more
channel programs to run), and would also end up spreading the data over
more real physical tracks on the DASD subsystem, which would surely
raise the overhead there as well, even if that impact on performance
might be hard to measure.
Joel C Ewing
On 07/23/2013 12:20 PM, Eric Bielefeld wrote:
> 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
>
--
Joel C. Ewing, Bentonville, AR jcew...@acm.org
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
