Under z/OS, "device type" implies the architecture and usage protocols
for the device. You can't call a device a 3390 and not have it
accurately emulate the characteristics of a 3390, nor can z/OS
communicate with a device defined to it as a 3390 as if it were
something else and expect success. The blocks per track, tracks per
cylinder, and CKD characteristics of a 3390 were fixed when real 3390's
were created and are indeed embedded within the z/OS understanding of
what is a 3390. To change that definition after the fact would break
all sorts of things which currently depend on knowing how to calculate
cylinder/track/record locations of internal blocks in a dataset and
allocation requirements of a dataset, and data capacity of a track.
The only way to change those rules without breaking existing data
requires defining a new device type to z/OS, connecting devices of that
type to z/OS, and placing datasets on those devices. In the old days
before emulated DASD, DASD upgrades not infrequently involved changes in
device types and migration/copying of data to convert it to the new
device-type rules. Migration could involve considerable effort, and in
some cases one would even find applications that wouldn't work on the
new architecture because of some embedded assumptions about maximum
records per track or cylinder that were violated on higher capacity
devices. When emulated DASD became the norm, freezing the device type
at 3390 eliminated the need for non-productive DASD device-type
migration activities, even if it did also preserve the peculiar
block-per-track rules of the 3390.
Emulating the 3390 architecture does not necessarily require throwing
away "overhead" bytes on physical DASD. Some emulations (e.g. Iceberg
RVA) not only compressed the logical data but didn't even store "empty"
tracks. This did however complicate things in other areas and create
other performance issues, which is why cheaper physical DASD seems to
have encouraged fixed mappings between logical tracks and physical DASD,
even though that means track "overhead" bytes represent lost capacity.
Perhaps in light of the FBA architecture that typically underlies the
today's emulated 3390 DASD it might make sense to consider a new
emulated DASD device type that is somewhat similar to a 3390 but with no
"overhead" bytes lost between emulated physical blocks. This would
perhaps be "cleaner" than a permanent 3390 solution, but it would have
to be perceived to have enough benefit to justify the migration effort.
My guess is that we have stuck with the 3390 type for so long
precisely because so far no one has been able to cost-justify such a
change.
My personal long-term DASD ideal would be some kind of new DASD
architecture that would require one to think only in terms of the
logical data, not in terms of tracks, cylinders, or even FBA-device
blocks; but this would be a massive change of many things in z/OS
including the internal structure of a number of dataset types, also
difficult to cost-justify.
JC Ewing
On 02/07/2012 10:01 AM, Dana Mitchell wrote:
That leads to a question that I've been thinking about for some time. Since
the 3390 geometry is emulated by modern storage control units, why then are
the inefficiencies of small blocks emulated also? There are not SLEDs actually
storing the data, why are IBG's, sectors, and all the other CKD nastiness
emulated that makes 80 byte blocks such a bad idea? IOW, why can't the
control unit simply store 708 * 80 byte blocks on a 56,664 byte 3390 track?
Does zos's calculations take these inefficiencies into account and only write
78 of these blocks per track?
Inquiring minds want to know
Dana
On Tue, 7 Feb 2012 16:28:33 +0100, R.S.<[email protected]> wrote:
RAID has very little to do with half-track blocks.
Nowadays 3390's are emulated, usually on RAID protected disk arrays (*),
but the 3390 geometry remains unchanged from z/OS point of view.
So half-track blocks (**) are still the most effective in terms of
storage utilisation and performance.
...
--
Joel C. Ewing, Bentonville, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
