Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Shmuel Metz (Seymour J.)]

In , on 03/27/2009
   at 09:50 AM, Tom Marchant  said:

>IIRC, the 3350 had 30 tracks per cylinder.  The 2305 model 2 had 768
>tracks and non-movable heads, so it would have needed more bits for the
>head address.

The 2305 only had 8 tracks per cylinder; 4 bits is plenty.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Shmuel Metz (Seymour J.)]

In , on 03/26/2009
   at 01:53 PM, John McKown  said:

There is a 4 byte area in the CCW. Historically
this is the  (in nybbles) field.

The address is 5[1] bytes, and it's not in the CCW. CCHHR

>Now, why is 14 tracks per cylinder so sacrosanct? 

c/14/15/

[1] For large values of 5, e.g., BBCCHHR.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Shmuel Metz (Seymour J.)]

In , on 03/27/2009
   at 05:44 PM, Anne & Lynn Wheeler  said:

>discusses that the 2301 "drum" 

Why the quotation marks? The 2301 and 2303 *were* drums, the 2305 *was* a
disk. Now, if you were referring to the 4305 I could understand writing
"disk" instead of disk.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[John Ticic]

Eric,

the SUN/STK Virtual Tape system (VSM) uses this kind of DASD as their 
internal buffer (SVA).

John

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Farley, Peter x23353]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Gibney, Dave
> Sent: Wednesday, April 01, 2009 2:40 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: "A foolish consistancy" or "3390 cyl/track architecture"
 
> I don't see the problem with coding over generous space estimates. For
> most of allocations I don't require a space parameter at all. The
> default DATACLAS allows a big extended striped dataset. And with SMS
> compression.  We only see x37 abends when the JCL explicitly calls for
> too small an allocation, and extended/striping/compression isn't
> selected by DFSMSdfp. Usually due to fragmentation.
> 
> Yes, I have  sizable pools with and generous free space threshold, but
> DASD is cheap. I've probably spent more writing this note than being
> stingy on disk space would buy me.
> 
> From a user prospective, and even from a z/OS Sysprog perspective, I
> don't care about the underlying FBA or CKD or QED of the architecture.
> 
> We still have many outdated parsimonious attitudes from the days when
> bytes were expensive. DASD is cheap, so is memory. z/OS CPU is also
> cheap, too bad the software (mostly ISV) is still priced by old time
> thinking.

Indeed, many storage administrators still hold such parsimonious
attitudes, because disk isn't "cheap" in the multi-terabyte quantities
that large companies have to buy it.  Six figures per "box" acquisition
is not unusual for a large organization.  Those kinds of numbers get the
attention of bean counters, who tell the executive suite, who tell the
CIO to tell the storage administrators to figure out a way make do with
what they've already got.  Most programmers (of any kind) have no say in
the matter.

Yes, disk is *relatively* cheap for what you get, and getting more so
every day.  That doesn't make any particular acquisition "cheap" by
financial measurements.

You are very lucky to be where you are, and to have the management
blessing to do as you have described.

Peter
This message and any attachments are intended only for the use of the addressee 
and
may contain information that is privileged and confidential. If the reader of 
the 
message is not the intended recipient or an authorized representative of the
intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication in
error, please notify us immediately by e-mail and delete the message and any
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Farley, Peter x23353
> Sent: Wednesday, April 01, 2009 7:49 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: "A foolish consistancy" or "3390 cyl/track architecture"
> 
> 
> The biggest problem is that estimating file size for many production
> batch applications is mostly or totally dependent on input (perhaps
> client-supplied) file sizes.  And there is no way in JCL to say "this
> new output file will be about x(percent) or x(times) the size of the
> input file(s) named A (B, C, ...).  Today I may have 1M records and
> tomorrow I may have 10M records, depending on how active the day's
> business has been.  The only alternative we have today is to allocate
> for the maximum possible size, which is often a very poor estimate of
> the actual size.  It doesn't really matter that much if one uses
> records
> or megabytes or cylinders (though I agree that records/megabytes are
> probably more application-friendly methods).  When the business grows,
> the original estimates hard-coded into the JCL become too small.

I don't see the problem with coding over generous space estimates. For
most of allocations I don't require a space parameter at all. The
default DATACLAS allows a big extended striped dataset. And with SMS
compression.
We only see x37 abends when the JCL explicitly calls for too small an
allocation, and extended/striping/compression isn't selected by
DFSMSdfp. Usually due to fragmentation.

Yes, I have  sizable pools with and generous free space threshold, but
DASD is cheap. I've probably spent more writing this note than being
stingy on disk space would buy me. 

>From a user prospective, and even from a z/OS Sysprog perspective, I
don't care about the underlying FBA or CKD or QED of the architecture.

We still have many outdated parsimonious attitudes from the days when
bytes were expensive. DASD is cheap, so is memory. z/OS CPU is also
cheap, too bad the software (mostly ISV) is still priced by old time
thinking.



Dave Gibney
Information Technology Services
Washington State University

> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Schwarz, Barry A]

I'm using an STK (now Sun, soon to be IBM?)SVA 9500 attached to a z9.

-Original Message-
From: Eric Bielefeld 
Sent: Wednesday, April 01, 2009 10:42 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: "A foolish consistancy" or "3390 cyl/track architecture"

snip

I have a couple of questions.  Does anyone have an RVA still?  Is there
any 
current DASD that still works this way?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Eric Bielefeld]

You've refreshed more of my memory.  So you really could have more or less 
volumes at different times, depending on how much data, blocksizes, etc. 
that you have on them.  But, I would think you need to define a static set 
of volumes for normal processing, although I could see that at times such as 
month end you might need more volumes.


I have a couple of questions.  Does anyone have an RVA still?  Is there any 
current DASD that still works this way?


Eric

Eric Bielefeld
Sr. Systems Programmer
Milwaukee, Wisconsin
414-475-7434


- Original Message - 
From: "Tom Marchant" 

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Wednesday, April 01, 2009 9:28 AM
Subject: Re: "A foolish consistancy" or "3390 cyl/track architecture"



On Tue, 31 Mar 2009 17:50:08 -0500, Eric Bielefeld wrote:


...  I read a lot about it the time, but in the end we didn't get
one.  What you wrote below I remember, especially the compression, and
writing all new and updated data in a new location.  BUT, you define so 
many

volumes.  Once you have them defined, and all of the space is allocated...


When you define volumes on an RVA, space is not allocated except for a 
track

index.  (I don't remember if that's what they called it, but that was its
function.)  The track index has a pointer to the physical location of the
track and some flags.  All mainframe access to data is through cache, and
cache is managed in full tracks.  When a track is destaged from cache, the
entire track is written to a new location and the space required for that
track is allocated.

When Snapshot is used to copy a volume or a data set, the only thing that 
is

copied is the relevant entries in the track index.  At that moment, the
copied volume doesn't take up any space.  As tracks are updated, the track
indexes diverge and space is used for the new volume or data set.
Somewhere, it also records the number of track indexes that point to each
track and when that count reaches zero, the space that the track occupied
becomes available for reuse.

We made extensive use of snapshot copy of full volumes when we were
upgrading from MVS 3.1.3 to OS/390 2.4.  It is a big unsupported jump and 
we

maintained a completely isolated copy of our entire DASD farm for the test
system.  When a test was finished, we discarded the snapshot copies,
performed whatever maintenance was necessary and created new copies.

There is software on the mainframe that tells the RVA that tracks are no
longer needed.  For example, when a data set is deleted.  The tracks are
discarded and made available for reuse.  When this is done, the NCL drops.

--
Tom Marchant 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Tom Marchant]

On Wed, 1 Apr 2009 15:15:45 +, Ted MacNEIL wrote:
>
>I DO NOT want to see a conversion to FBA, or anything else, until well
after we see conversion of all allocations to an SMS-based device
independent scheme.

It has been available since at least DFP 3.2, with MVS version 3.  If
conversion is so important to you, why haven't you done it?

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Ted MacNEIL]

>I understand that changing the track and cylinder architecture would involve 
>lots of changes, and that it would also involve a lot of vendor changes to 
>their software too.

That's why IBM promised to not change the geometry again.
I've lived through 3330-3350-3380-3390(compat)-3390 conversions.
They were expensive and time consuming, and error-prone.
Complaining about the archaic architecture is NOT a solution!

I DO NOT want to see a conversion to FBA, or anything else, until well after we 
see conversion of all allocations to an SMS-based device independent scheme.
-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Farley, Peter x23353]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Walt Farrell
> Sent: Wednesday, April 01, 2009 6:42 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: "A foolish consistancy" or "3390 cyl/track architecture"
> 
> On Tue, 31 Mar 2009 12:50:16 -0500, Eric Bielefeld  ibmm...@wi.rr.com>
> wrote:
> >Thanks for clearing up how the current drives actually work.  It just
> >seems like IBM could get away from the track and cylinder stuff,
which
> >artificially restricts the amount of storage you use.  If you use
short
> >blocksizes, or long ones that just go over 1/2 track, you waste an
awful
> >lot of space.  Of course, well written SMS routines can correct that,
but
> >it still makes things a lot more complicated than it should be.
> 
> Perhaps I don't understand your point, Eric, but from the user
perspective
> aren't things simple already? Just let the system pick the block size,
and
> while you're at it allocate the space in terms meaningful to the
> user/application: megabytes or records.
> 
> Thus, the only things that -should- be affected by the cylinder/head
> architecture are programs, and it's a lot simpler to leave them alone
than
> it is to have to change them.  Remember it's not just IBM code that
would
> have to change.  Many vendors and customers have written code that
knows
> and depends on the cylinder/head architecture.

The biggest problem is that estimating file size for many production
batch applications is mostly or totally dependent on input (perhaps
client-supplied) file sizes.  And there is no way in JCL to say "this
new output file will be about x(percent) or x(times) the size of the
input file(s) named A (B, C, ...).  Today I may have 1M records and
tomorrow I may have 10M records, depending on how active the day's
business has been.  The only alternative we have today is to allocate
for the maximum possible size, which is often a very poor estimate of
the actual size.  It doesn't really matter that much if one uses records
or megabytes or cylinders (though I agree that records/megabytes are
probably more application-friendly methods).  When the business grows,
the original estimates hard-coded into the JCL become too small.

This is not, of course, a problem of ECKD vs FBA or some entirely
different virtual architecture for storage, but a problem of how poor
JCL is as a file specification and control-flow language.  REXX or bash
scripts are far more flexible for that purpose, but each of those
languages has far more onerous problems than JCL (TSO and the bash
shell, respectively), not to mention poor to non-existent connection
with scheduling software, which is (IMHO, of course) part of why JCL is
still almost exclusively used for production batch processing.

Burroughs' WFL (Work Flow Language) was always my ideal of a
well-integrated and flexible control language.  If REXX could be as well
integrated as WFL was in the Burroughs MCP system as to become the
replacement for JCL, that would be a step in the right direction, IMHO.

Not that I ever expect it to happen.

Peter


This message and any attachments are intended only for the use of the addressee 
and
may contain information that is privileged and confidential. If the reader of 
the 
message is not the intended recipient or an authorized representative of the
intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication in
error, please notify us immediately by e-mail and delete the message and any
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Tom Marchant]

On Tue, 31 Mar 2009 17:50:08 -0500, Eric Bielefeld wrote:
>
>...  I read a lot about it the time, but in the end we didn't get
>one.  What you wrote below I remember, especially the compression, and
>writing all new and updated data in a new location.  BUT, you define so many
>volumes.  Once you have them defined, and all of the space is allocated...

When you define volumes on an RVA, space is not allocated except for a track
index.  (I don't remember if that's what they called it, but that was its
function.)  The track index has a pointer to the physical location of the
track and some flags.  All mainframe access to data is through cache, and
cache is managed in full tracks.  When a track is destaged from cache, the
entire track is written to a new location and the space required for that
track is allocated.

When Snapshot is used to copy a volume or a data set, the only thing that is
copied is the relevant entries in the track index.  At that moment, the
copied volume doesn't take up any space.  As tracks are updated, the track
indexes diverge and space is used for the new volume or data set. 
Somewhere, it also records the number of track indexes that point to each
track and when that count reaches zero, the space that the track occupied
becomes available for reuse.

We made extensive use of snapshot copy of full volumes when we were
upgrading from MVS 3.1.3 to OS/390 2.4.  It is a big unsupported jump and we
maintained a completely isolated copy of our entire DASD farm for the test
system.  When a test was finished, we discarded the snapshot copies,
performed whatever maintenance was necessary and created new copies.

There is software on the mainframe that tells the RVA that tracks are no
longer needed.  For example, when a data set is deleted.  The tracks are
discarded and made available for reuse.  When this is done, the NCL drops.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Eric Bielefeld]

Walt,

I understand that changing the track and cylinder architecture would involve 
lots of changes, and that it would also involve a lot of vendor changes to 
their software too.  I'm not saying IBM should change it - it just seems 
overly complicated.  I have no idea how IBM could change it, although 
several have mentioned FBA architecture, where everything is written out in 
4K blocks.  I have mixed feelings about this subject.  To me it seems 
complicated, but that's also one of the things that gives z/OS the power it 
has.


Eric Bielefeld
Sr. Systems Programmer
Milwaukee, Wisconsin
414-475-7434


- Original Message - 
From: "Walt Farrell" 

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Wednesday, April 01, 2009 5:42 AM
Subject: Re: "A foolish consistancy" or "3390 cyl/track architecture"


On Tue, 31 Mar 2009 12:50:16 -0500, Eric Bielefeld 


wrote:
Thanks for clearing up how the current drives actually work.  It just 
seems

like IBM could get away from the track and cylinder stuff, which
artificially restricts the amount of storage you use.  If you use short
blocksizes, or long ones that just go over 1/2 track, you waste an awfull
lot of space.  Of course, well written SMS routines can correct that, but 
it

still makes things a lot more complicated than it should be.


Perhaps I don't understand your point, Eric, but from the user perspective
aren't things simple already? Just let the system pick the block size, and
while you're at it allocate the space in terms meaningful to the
user/application: megabytes or records.

Thus, the only things that -should- be affected by the cylinder/head
architecture are programs, and it's a lot simpler to leave them alone than
it is to have to change them.  Remember it's not just IBM code that would
have to change.  Many vendors and customers have written code that knows 
and

depends on the cylinder/head architecture.

--
 Walt 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Bill Fairchild]

At the SHARE in Austin last month, several IBM presentations on FlashDrives 
said that sequential access is still faster on controllers with devices that 
spin than with FlashDrive.  That was what I meant about lower access times.  

They also discussed the problem with rewriting into the same byte too many 
times.  That poor byte wears out.  FlashDrives are therefore really good for 
read-only data that is accessed randomly.

Bill Fairchild
Rocket Software



From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Ron Hawkins
Sent: Wednesday, April 01, 2009 1:06 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: "A foolish consistancy" or "3390 cyl/track architecture"

Bill,

No moving parts doesn't mean they don't wear out. There's a lot of redundant
capacity in those babies to handle cell failures due to writes. This is why
you'll see Flashdrive articles talk about "wear leveling" algorithms, and
also one of the reasons why you won't see Enterprise Flashdrives on the
shelf at Frys.

I'm not sure about your access time comments. So far the performance I have
seen is very impressive. Can you elaborate?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Walt Farrell]

On Tue, 31 Mar 2009 12:50:16 -0500, Eric Bielefeld 
wrote:
>Thanks for clearing up how the current drives actually work.  It just seems
>like IBM could get away from the track and cylinder stuff, which
>artificially restricts the amount of storage you use.  If you use short
>blocksizes, or long ones that just go over 1/2 track, you waste an awfull
>lot of space.  Of course, well written SMS routines can correct that, but it
>still makes things a lot more complicated than it should be.

Perhaps I don't understand your point, Eric, but from the user perspective
aren't things simple already? Just let the system pick the block size, and
while you're at it allocate the space in terms meaningful to the
user/application: megabytes or records.

Thus, the only things that -should- be affected by the cylinder/head
architecture are programs, and it's a lot simpler to leave them alone than
it is to have to change them.  Remember it's not just IBM code that would
have to change.  Many vendors and customers have written code that knows and
depends on the cylinder/head architecture.

-- 
  Walt

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Ron Hawkins]

Bill,

No moving parts doesn't mean they don't wear out. There's a lot of redundant
capacity in those babies to handle cell failures due to writes. This is why
you'll see Flashdrive articles talk about "wear leveling" algorithms, and
also one of the reasons why you won't see Enterprise Flashdrives on the
shelf at Frys.

They do have huge potential to provide greener high performance, especially
in environments where short stroking of the HDD is the norm and I'm sure
customer acceptance will bring the price down from the current premium.

I'm not sure about your access time comments. So far the performance I have
seen is very impressive. Can you elaborate?

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
> Bill Fairchild
> Sent: Tuesday, March 31, 2009 10:56 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] "A foolish consistancy" or "3390 cyl/track
> architecture"
> 
> The Flash Drive concept makes the most sense - no moving parts.  The
geometry
> is emulated by the microcode.  They just need to get the access time
lower.
> 
> Bill Fairchild
> Rocket Software
> 
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
> Eric Bielefeld
> Sent: Tuesday, March 31, 2009 1:50 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: "A foolish consistancy" or "3390 cyl/track architecture"
> 
> Ron,
> 
> Thanks for clearing up how the current drives actually work.  It just
seems
> like IBM could get away from the track and cylinder stuff, which
> artificially restricts the amount of storage you use
> 
> Eric
> 
> Eric Bielefeld
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Thompson, Steve]

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Tom Marchant
Sent: Tuesday, March 31, 2009 5:23 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: "A foolish consistancy" or "3390 cyl/track architecture"

On Tue, 31 Mar 2009 15:54:09 -0500, Eric Bielefeld wrote:


When I worked at Wayne State University in Detroit, we bought an RVA.
That
was IBM's re-branded Iceberg.  AFAIK, Sun also sells it as the SVA.  On
that
box, all data stored on disk was compressed.  Because any new data
written
to a track may not fit in the same location, every time data on a track
was
written, the track was written to a new location, and only the disk
space
required for the compressed data was used.

There was a special utility used to report on how much of the back-end
disk
storage was used.  IIRC, it was called Net Capacity Load.  Allocating
another volume or creating a snapshot did not increase the NCL.

The micorcode has garbage collection routines that accumulate track
areas
that are no longer used and background tasks that move data around in
order
to maintain a contiguous area where new tracks can be written.  It is a
marvelous feat of engineering.  And it is no wonder that the Iceberg was
so
much later getting to markket than originally planned.

In order for any DASD subsystem to be insensitive to blocksize, it would
have to do something similar, compressing out the gaps and storing the
track
in discontiguous locations.

AFAIK, the rest of modern DASD subsystems allocate specific locations
for
each logical volume, and therefore for each logical track.  There has to
be
sufficient disk space to store the maximum amount of data in each track
location.  If short blocks are written, less data will fit in that
logical
track.



Wouldn't this effectively defrag DASD units? But then we would still
have to run some kind of defrag just to fix the VTOC (so it wouldn't
have so many extent entries for data sets), right?

Regards,
Steve Thompson

-- Postings by this poster may not reflect the views or opinions of
poster's employer. --

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Paul Gilmartin]

On Tue, 31 Mar 2009 17:50:08 -0500, Eric Bielefeld wrote:
>
>I don't think you answered my question.  I remember a year or two before we
>built our datacenter that opened in 1996, we looked at getting the STC box
>(Now STK).  I read a lot about it the time, but in the end we didn't get

Actually, now Sun (or SMI).  Never was STK officially.  There
were trademark problems with STC (England's Standard Telephone
and Cable); STK was the NYSE stock ticker symbol (like "JAVA"?),
and unlikely to be better, like any other TLA.  The branding
directives were to use StorageTek, not STK.  But keystroke
economy often prevailed.

>one.  What you wrote below I remember, especially the compression, and
>writing all new and updated data in a new location.  BUT, you define so many
>volumes.  Once you have them defined, and all of the space is allocated, you
>can't add volumes because they are blocked better, or delete volumes because
>you just wrote a couple huge files blocked at 150 bytes per block.  That
>just doesn't make sense.  (I hope this makes sense!)
>
>When we built the P&H datacenter, we added a bunch of 3380 and 3390 strings.
>I never quite understood why we didn't go with the new technowlogy, but they
>were cheap - at least the purchase price.  I don't know if they saved any
>money after maintenance though.  We totally filled up the datacenter with
>all the dasd.  Later, when we got a Hitachi box, and replaced the 3090S with
>a MP3000, we had a good sized ballroom available.
>
>- Original Message -
>From: "Tom Marchant" 
>Sent: Tuesday, March 31, 2009 5:23 PM
>
>> In order for any DASD subsystem to be insensitive to blocksize, it would
>> have to do something similar, compressing out the gaps and storing the track
>> in discontiguous locations.
>>
You can't quite get there; you still have the overhead of metadata
showing where the interblock gaps appear to be.  But if the metadata
are subject to compression, LZH may make them nearly vanish -- e.g.
the BDWs for equal 150 byte blocks (above) are identical and
highly redundant.

>> I suppose you might ask why the disk can't store more short blocks on the
>> track, reducing (or eliminating) the inter-record gap.  But then, it
>> wouldn't behave like a 3390, would it?  What might that break?
>>
Lots of things, people say.  But the answer should be FBA, not
virtualizing CKD.  And FBA should be highly compatible with
anything with its own abstraction layer, such as VSAM, PDSE,
z/FS, etc.  And with paging, which has no user API to low-level
I/O, thus with VIO.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Edward Jaffe]

Tom Marchant wrote:

In order for any DASD subsystem to be insensitive to blocksize, it would
have to do something similar, compressing out the gaps and storing the track
in discontiguous locations.

AFAIK, the rest of modern DASD subsystems allocate specific locations for
each logical volume, and therefore for each logical track.  There has to be
sufficient disk space to store the maximum amount of data in each track
location.  If short blocks are written, less data will fit in that logical
track.
  


We "grew" a couple of our 3390s from just under 64K cylinders to 220K 
cylinders with a single click on the DS8100's HMC. There was no need to 
copy data from device X to device Y. Device X simply "grew" in place 
while it was still on-line to z/OS. Either way, there must be some 
serious virtualization going on to make that possible.


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Eric Bielefeld]

Tom,

I don't think you answered my question.  I remember a year or two before we 
built our datacenter that opened in 1996, we looked at getting the STC box 
(Now STK).  I read a lot about it the time, but in the end we didn't get 
one.  What you wrote below I remember, especially the compression, and 
writing all new and updated data in a new location.  BUT, you define so many 
volumes.  Once you have them defined, and all of the space is allocated, you 
can't add volumes because they are blocked better, or delete volumes because 
you just wrote a couple huge files blocked at 150 bytes per block.  That 
just doesn't make sense.  (I hope this makes sense!)


When we built the P&H datacenter, we added a bunch of 3380 and 3390 strings. 
I never quite understood why we didn't go with the new technowlogy, but they 
were cheap - at least the purchase price.  I don't know if they saved any 
money after maintenance though.  We totally filled up the datacenter with 
all the dasd.  Later, when we got a Hitachi box, and replaced the 3090S with 
a MP3000, we had a good sized ballroom available.


Eric

Eric Bielefeld
Sr. Systems Programmer
Milwaukee, Wisconsin
414-475-7434


- Original Message - 
From: "Tom Marchant" 

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Tuesday, March 31, 2009 5:23 PM
Subject: Re: "A foolish consistancy" or "3390 cyl/track architecture"



On Tue, 31 Mar 2009 15:54:09 -0500, Eric Bielefeld wrote:


You may be right, but from your reply you apparently don't know for sure
whether bad blocksizes actually take up more dasd or not.  Does anyone 
know

whether this affects the total amount of dasd or not that can be used?


When I worked at Wayne State University in Detroit, we bought an RVA. 
That
was IBM's re-branded Iceberg.  AFAIK, Sun also sells it as the SVA.  On 
that

box, all data stored on disk was compressed.  Because any new data written
to a track may not fit in the same location, every time data on a track 
was

written, the track was written to a new location, and only the disk space
required for the compressed data was used.

There was a special utility used to report on how much of the back-end 
disk

storage was used.  IIRC, it was called Net Capacity Load.  Allocating
another volume or creating a snapshot did not increase the NCL.

The micorcode has garbage collection routines that accumulate track areas
that are no longer used and background tasks that move data around in 
order

to maintain a contiguous area where new tracks can be written.  It is a
marvelous feat of engineering.  And it is no wonder that the Iceberg was 
so

much later getting to markket than originally planned.

In order for any DASD subsystem to be insensitive to blocksize, it would
have to do something similar, compressing out the gaps and storing the 
track

in discontiguous locations.

AFAIK, the rest of modern DASD subsystems allocate specific locations for
each logical volume, and therefore for each logical track.  There has to 
be

sufficient disk space to store the maximum amount of data in each track
location.  If short blocks are written, less data will fit in that logical
track.

I suppose you might ask why the disk can't store more short blocks on the
track, reducing (or eliminating) the inter-record gap.  But then, it
wouldn't behave like a 3390, would it?  What might that break?

--
Tom Marchant 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Tom Marchant]

On Tue, 31 Mar 2009 15:54:09 -0500, Eric Bielefeld wrote:

>You may be right, but from your reply you apparently don't know for sure
>whether bad blocksizes actually take up more dasd or not.  Does anyone know
>whether this affects the total amount of dasd or not that can be used?

When I worked at Wayne State University in Detroit, we bought an RVA.  That
was IBM's re-branded Iceberg.  AFAIK, Sun also sells it as the SVA.  On that
box, all data stored on disk was compressed.  Because any new data written
to a track may not fit in the same location, every time data on a track was
written, the track was written to a new location, and only the disk space
required for the compressed data was used.

There was a special utility used to report on how much of the back-end disk
storage was used.  IIRC, it was called Net Capacity Load.  Allocating
another volume or creating a snapshot did not increase the NCL.

The micorcode has garbage collection routines that accumulate track areas
that are no longer used and background tasks that move data around in order
to maintain a contiguous area where new tracks can be written.  It is a
marvelous feat of engineering.  And it is no wonder that the Iceberg was so
much later getting to markket than originally planned.

In order for any DASD subsystem to be insensitive to blocksize, it would
have to do something similar, compressing out the gaps and storing the track
in discontiguous locations.

AFAIK, the rest of modern DASD subsystems allocate specific locations for
each logical volume, and therefore for each logical track.  There has to be
sufficient disk space to store the maximum amount of data in each track
location.  If short blocks are written, less data will fit in that logical
track.

I suppose you might ask why the disk can't store more short blocks on the
track, reducing (or eliminating) the inter-record gap.  But then, it
wouldn't behave like a 3390, would it?  What might that break?

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Eric Bielefeld]

You may be right, but from your reply you apparently don't know for sure 
whether bad blocksizes actually take up more dasd or not.  Does anyone know 
whether this affects the total amount of dasd or not that can be used?  I 
would think that since you have to define the dasd on a new box, that once 
it is defined and all used, that you would have the potential for so many 
TB, but the actual data that you store would still be affected by 
blocksizes.


I know when I was at Washington University, we got a new Shark that had 15TB 
(I think), and was triple the capacity of the old one.  I know we defined 
all the dasd that we had defined on the old one, and then set up a whole new 
copy of everything.  We then flashed everything (5TB), which took less than 
a minute, although the under the cover copying took a lot longer.  We still 
had 5TB left, which they were using up for DB2 stuff when my contract ended. 
I suspect that once another 2.5TB was defined, and its mirror image to be 
flashed was defined, that no more dasd could be defined, but I don't know 
that for sure.


Eric

Eric Bielefeld
Sr. Systems Programmer
Milwaukee, Wisconsin
414-475-7434


- Original Message - 
From: "Patrick O'Keefe" 

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Tuesday, March 31, 2009 2:22 PM
Subject: Re: "A foolish consistancy" or "3390 cyl/track architecture"



On Tue, 31 Mar 2009 12:50:16 -0500, Eric Bielefeld  wrote:


...   It just seems
like IBM could get away from the track and cylinder stuff, which
artificially restricts the amount of storage you use.  If you use short
blocksizes, or long ones that just go over 1/2 track, you waste an
awfull lot of space. ...
... it still makes things a lot more complicated than it should be.



I think that logic may not apply.  It all depends on how the emulation
works.  The "wasted" track space may not take any space on the
real hardware.  We may be protected from our old stupidity (but I'm
sure there is lots of new stupidity to make up for that).

It's still complicated.  Now you have to know which old guideleines
still hold, which can be discarded, and what new guidelines are
needed.

Pat O'Keefe 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Anne & Lynn Wheeler]

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main as well.


patrick.oke...@wamu.net (Patrick O'Keefe) writes:
> I think that logic may not apply.  It all depends on how the emulation
> works.  The "wasted" track space may not take any space on the 
> real hardware.  We may be protected from our old stupidity (but I'm
> sure there is lots of new stupidity to make up for that). 
>
> It's still complicated.  Now you have to know which old guideleines
> still hold, which can be discarded, and what new guidelines are
> needed.  

cyl/track & ckd architecture are left over from 1960s trade-offs ...
cyl/track provided a direct 1:1 logical/physical correspondance so
that uses (application developers) could wring every possible bit out
of the infrastructure. ckd allowed for leaving information data
structure indexes out on disk ... rathing than caching them in
real-storage. this traded-off i/o channel, controller, and device
thruput against extremely (much more) scarce and expensive real
stroage.

the ckd architecture trade-off was already shifting in by the mid-70s
... where bottleneck had significantly switched from being real
storage to i/o thruput (and starting to see use of electronic storage
for caching and/or staging information to compensate for the
increasing bottlenecked i/o resources). I was being called into some
number of severe thruput bottlenecked customer situations where the
problem turned out how to minimize the use of PDS directory & VTOC
multi-track search.

at the same time, the disk price/bit was drastically dropping ... so
the cost effort to optimize every last bit of disk space was starting
to cost more than the disk bits saved.

FBA bascially addressed both issues; 

1) it drastically simplified the logical structure users and
application developers had to deal with and

2) eliminated the whole search infrastructure; recognizing that it was
more efficient to cache/save high use data structures in electronic
storage so that I/O read/write operations would directly specify
required record.

I was told that even if I provided fully developed, tested, and
integrated MVS FBA support ... it would still cost (an additional) $26M
to ship (changes to documentation, education, etc). Supposedly I had to
show incremental revenue/sales as result of shipping MVS FBA support
(i.e. on the order of $200m-$300m in incremental disk sales). The theory
was customers were buying as much disk as they required and the only
thing that MVS FBA support would provide would be the disks sold would
be FBA rather than CKD (but no incremental sales). Any argument about
infrastructure and long-term life-cycle savings with any MVS shift to
FBA was discounted (as well as indirect sales because of simpler/faster
development)

I also was pontificating about how relative system disk thruput had
dropped by factor of ten times over a period of yrs. Eventually some
executive in the disk division asked their performance group to refute
my statements. After several weeks, they came back and basically said
that I had slightly understated the issue; i.e. disks may have gotten
five times faster ... but with fewer arms and/or more data/arm to
access, the avg. thruput per access (because of higher loading and
queuing issues) was possibly only three times better. At the same
time, processor had gotten possibly 50 times faster (processors 50
times faster, disks 5 times faster ... ratio of disk:processor thruput
had declined by order of magnitude).  Applications using 60s disk i/o
techniques weren't able to keep the processors busy ... w/o heavy
leveraging of electronic storage.

In any case, the disk performance group turned the study around into a
SHARE presentation recommending how to optimize disk configurations
(basically attempting to mitigate the thrutput bottlenecks).

In the meantime trying to get ECKD debugged and working as a subset
solution for the multi-track search overhead ... was a monumental
undertaking.

lots of past posts mentioning ckd, multi-track search, fba, etc
http://www.garlic.com/~lynn/submain.html#dasd

semi-related, misc. past posts mentioning getting to play disk
engineer in bldg 14 (disk engineering) & bldg 15 (disk product test).
http://www.garlic.com/~lynn/subtopic.html#disk

then as all physical disk technology shifted to "FBA" ... there was
another major effort required to continue to emulate CKD
infrastructure on top of an underlying infrastructure that is
fundamentally FBA.

slightly related to the technology paradigm trade-off CKD/FBA shift
was the discussions in the '70s between the STL IMS group and SJR
system/r relational database group (original relational/sql)
http://www.garlic.com/~lynn/submain.html#systemr

The IMS group position was that direct record pointers as part of the
data infrastructure required half the disk space as System/R
(relational, later sql/ds, db2, etc) and significantly fewer disk
i/os. Basically the internal index structure 

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Patrick O'Keefe]

On Tue, 31 Mar 2009 12:50:16 -0500, Eric Bielefeld  wrote:

>...   It just seems
>like IBM could get away from the track and cylinder stuff, which
>artificially restricts the amount of storage you use.  If you use short
>blocksizes, or long ones that just go over 1/2 track, you waste an 
>awfull lot of space. ... 
>... it still makes things a lot more complicated than it should be.


I think that logic may not apply.  It all depends on how the emulation
works.  The "wasted" track space may not take any space on the 
real hardware.  We may be protected from our old stupidity (but I'm
sure there is lots of new stupidity to make up for that). 

It's still complicated.  Now you have to know which old guideleines
still hold, which can be discarded, and what new guidelines are
needed.  

Pat O'Keefe 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Bill Fairchild]

The Flash Drive concept makes the most sense - no moving parts.  The geometry 
is emulated by the microcode.  They just need to get the access time lower.

Bill Fairchild
Rocket Software

From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Eric Bielefeld
Sent: Tuesday, March 31, 2009 1:50 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: "A foolish consistancy" or "3390 cyl/track architecture"

Ron,

Thanks for clearing up how the current drives actually work.  It just seems 
like IBM could get away from the track and cylinder stuff, which 
artificially restricts the amount of storage you use

Eric

Eric Bielefeld

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Eric Bielefeld]

Ron,

Thanks for clearing up how the current drives actually work.  It just seems 
like IBM could get away from the track and cylinder stuff, which 
artificially restricts the amount of storage you use.  If you use short 
blocksizes, or long ones that just go over 1/2 track, you waste an awfull 
lot of space.  Of course, well written SMS routines can correct that, but it 
still makes things a lot more complicated than it should be.


Eric

Eric Bielefeld
Sr. Systems Programmer
Milwaukee, Wisconsin
414-475-7434


- Original Message - 
From: "Ron Hawkins" 

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Tuesday, March 31, 2009 10:31 AM
Subject: Re: "A foolish consistancy" or "3390 cyl/track architecture"



Perhaps there is more to the emulation of CKD than the thread touches on.
Disk Drives stopped recording in CYLS some time ago because the time for
head switching is greater than the minimum seek time. Drives today record 
in

a serpentine method across the platters, doing a switch-back (best word I
can think of) to the next head at intervals defined by the HDD designers.

The whole idea of tracks and CYLS is really dead and buried as far as the
real hardware is concerned.

Ron 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Rick Fochtman]

---
Perhaps there is more to the emulation of CKD than the thread touches 
on. Disk Drives stopped recording in CYLS some time ago because the time 
for head switching is greater than the minimum seek time. Drives today 
record in a serpentine method across the platters, doing a switch-back 
(best word I can think of) to the next head at intervals defined by the 
HDD designers.


The whole idea of tracks and CYLS is really dead and buried as far as 
the real hardware is concerned.


Long ago, when I worked in a heavily-modified CP67/CMS environment (on 
168's and 2305's), we had a fairly sophisticated mechanism for handling 
page files on the 2305's. Each track was written with three page 
records, and a "gap" record between each pair of page records. We 
learned that the "gap" record afforded us enough time to swap exposures 
on the 2305, so we could read three pages, from the same track, on three 
different exposures of the 2305, in one revolution. We did the writing 
on a different trio of exposures as well. (Thank you, Grant Tegtmeier.) 
I would venture to guess that modern DASD storage uses a far more 
sophisticated version of the same mechanism to read/write records on 
multiple physical drives today, even though the "logical" perception, 
from the program point of view is the "traditional" view.


Back to the original starting point of this thread: I, for one, am 
grateful for the "solidification" of a single geometry. Recomputing 
space parameters and updating legacy applications can become a MAJOR and 
EXPENSIVE process, frought with errors and omissions. By maintaining the 
same geometry, we can let these old applications, etc. die off by 
attrition, rather than having to spend valuable resources updating 
legacy code and JCL because a "new device" is being brought into the shop.


The fact that a device has more "cylinders" available should NOT be a 
matter for application programmers to be concerned about; let the system 
manage the space, and the systems programmers worry about the details, 
if they really feel it's necessary. Same opinion concerning "tracks". By 
leaving the basic geometry alone, a shop can go forward with new 
development and let the programmers learn about SMS-friendly space requests.


My two cents worth. :-)

--
Rick
--
Remember that if you’re not the lead dog, the view never changes.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[R.S.]

Ron Hawkins pisze:

Perhaps there is more to the emulation of CKD than the thread touches on.
Disk Drives stopped recording in CYLS some time ago because the time for
head switching is greater than the minimum seek time. Drives today record in
a serpentine method across the platters, doing a switch-back (best word I
can think of) to the next head at intervals defined by the HDD designers.

The whole idea of tracks and CYLS is really dead and buried as far as the
real hardware is concerned.


Last but not least: there is no more "canonical geometry" - I mean fixed 
number of bytes (sectors) per track. The longer (physically) track the 
more bytes it keeps. All we know formula O=2*PI*r.
However even "the most modern" operating system like Unix or Windows do 
not know about it. The systems still treat disk like it would have fixed 
(equal) capacity tracks. They have to, because drive electronics still 
cheats (emulates) "canonical geometry".


Talking about future we should also consider non-disk devices (flash SSD).

--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m. st. Warszawy 
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, 
nr rejestru przedsibiorców KRS 025237

NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci 
wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego 
podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 
2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec 
podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym 
BRE Banku SA bd w caoci opacone.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Ron Hawkins]

Perhaps there is more to the emulation of CKD than the thread touches on.
Disk Drives stopped recording in CYLS some time ago because the time for
head switching is greater than the minimum seek time. Drives today record in
a serpentine method across the platters, doing a switch-back (best word I
can think of) to the next head at intervals defined by the HDD designers.

The whole idea of tracks and CYLS is really dead and buried as far as the
real hardware is concerned.

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
> Paul Gilmartin
> Sent: Friday, March 27, 2009 2:01 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] "A foolish consistancy" or "3390 cyl/track
> architecture"
> 
> On Fri, 27 Mar 2009 14:41:10 -0500, Chase, John wrote:
> >>
> >> Well, if IBM's new DASD architecture were manufactured in the same
> >> manner as previous DASD devices, you would have 278,921,216 tracks
> >> on each surface.  What diameter do you think such platters would be?
> >> How long would it take the access arm to traverse the radius?
> >
> >How much power would it take to spin them fast enough to be usable?  :-)
> >
> Long ago, I attended a Preview of XA presentation at which the IBM
> presenter (Bill Malleck?) stated that smaller rotational latency
> could be achieved only with smaller platters.  Mechanical
> disruption happens at a surface velocity roughly the speed of
> sound -- sqrt( Young's modulus / density ).  The problem
> engineers were confronting was oxide flying off the substrate.
> By analogy, "Have you ever watched the chef making pizza,
> throwing the dough in the air to form the crust?  Notice that
> he only puts the sauce on after."
> 
> Tetrahedral carbon platters?  Graphene?  (They're working on it.)
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Anne & Lynn Wheeler]

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main as well.

m42tom-ibmm...@yahoo.com (Tom Marchant) writes:
> Indeed, one could build a 3390 with only one recording surface and an arm
> that has 15 heads.
>
> IAC, the emulation of such a large number of tracks per cylinder would
> probably not be too difficult.  The real problem with that kind of
> architecture would be the software changes that would be needed.

from long ago and far away ... 16 data tracks & 1 servo track, head
with 16 r/w data interfaces with 2 service track interfaces:
http://www.garlic.com/~lynn/2006s.html#email871230

in this post
http://www.garlic.com/~lynn/2006s.html#30 Why magnetic drums was/are worse than 
disks ?

and related email in the same post
http://www.garlic.com/~lynn/2006s.html#email871122

above eamil discusses that initial 3380 intertrack gap was 20 track
widths ... 3380Es (double density) cut the inter-track gap to 10
track-widths (double the number of tracks per surface, double the number
of "cylinders").

the following post
http://www.garlic.com/~lynn/2006s.html#31 Why magnetic drums was/are worse than 
disks ?

discusses 3330s had 20 surfaces (20 heads per "cylinder") ... 19 "data"
surfaces & 20th surface for encoding positional information.

the post after that
http://www.garlic.com/~lynn/2006s.html#32 Why magnetic drums was/are worse than 
disks ?

discusses that the 2301 "drum" was fixed-head device ... with head per
track. actually there were two devices ... the 2303 "drum" that
read/wrote single head at a time ... and the 2303 "drum" that read/wrote
four heads in parallel (with four times the data transfer rate of 2303).

the 2305 was a fixed head "disk" (platters with head per track on
multiple platters ... as opposed to the 2303/2301 "drums").

above also shows my (incomplete) table of code names for different
products.

misc. past posts about getting to play disk engineer in bldg 14 (disk
engineering) and bldg 15 (disk product test)
http://www.garlic.com/~lynn/subtopic.html#disk

-- 
40+yrs virtualization experience (since Jan68), online at home since Mar70

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Bob Shannon]

>the IBM presenter (Bill Malleck?)

Bill Malik. He went to the Gartner Group after IBM.

Bob Shannon
Rocket Software

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Paul Gilmartin]

On Fri, 27 Mar 2009 14:41:10 -0500, Chase, John wrote:
>>
>> Well, if IBM's new DASD architecture were manufactured in the same
>> manner as previous DASD devices, you would have 278,921,216 tracks
>> on each surface.  What diameter do you think such platters would be?
>> How long would it take the access arm to traverse the radius?
>
>How much power would it take to spin them fast enough to be usable?  :-)
>
Long ago, I attended a Preview of XA presentation at which the IBM
presenter (Bill Malleck?) stated that smaller rotational latency
could be achieved only with smaller platters.  Mechanical
disruption happens at a surface velocity roughly the speed of
sound -- sqrt( Young's modulus / density ).  The problem
engineers were confronting was oxide flying off the substrate.
By analogy, "Have you ever watched the chef making pizza,
throwing the dough in the air to form the crust?  Notice that
he only puts the sauce on after."

Tetrahedral carbon platters?  Graphene?  (They're working on it.)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Tom Marchant]

On Fri, 27 Mar 2009 12:20:34 -0500, Paul Gilmartin wrote:

>On Thu, 26 Mar 2009 14:43:36 -0700, Raymond Noal wrote:
>
>>Well, if your new DASD architecture was manufactured in the 
>>same manner as previous DASD devices, you would have 32,769 
>>spinning platters to deal with and an access arm with 65,535 R/W 
>>heads to move back and forth with all of the implied momentum of 
>>a device that size. How tall do you think 32K of platters would be?
>>
>That's a big "if" and a somewhat remote "previous".
>
>32769?  2 surfaces per platter plus one for timing?  OK.  Is
>There a taboo against using surface ?
>
>Depends on how thick the platters are.  You forgot the smiley.

Indeed, one could build a 3390 with only one recording surface and an arm
that has 15 heads.

IAC, the emulation of such a large number of tracks per cylinder would
probably not be too difficult.  The real problem with that kind of
architecture would be the software changes that would be needed.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Rick Fochtman]

Well, if IBM's new DASD architecture were manufactured in the same
manner as previous DASD devices, you would have 278,921,216 tracks
on each surface.  What diameter do you think such platters would be?
How long would it take the access arm to traverse the radius?
   



How much power would it take to spin them fast enough to be usable?  :-)

   -jc-


---
Got any spare 6-71 Deisels laying around? ;-) Sounds like a new customer 
base for Detroit Deisel or EMD.


--
Rick
---

Remember that if you're not the lead dog, the view never changes.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin
> 
> [ snip ]
> 
> Well, if IBM's new DASD architecture were manufactured in the same
> manner as previous DASD devices, you would have 278,921,216 tracks
> on each surface.  What diameter do you think such platters would be?
> How long would it take the access arm to traverse the radius?

How much power would it take to spin them fast enough to be usable?  :-)

-jc-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Paul Gilmartin]

On Thu, 26 Mar 2009 14:43:36 -0700, Raymond Noal wrote:

>Well, if your new DASD architecture was manufactured in the same manner as 
>previous DASD devices, you would have 32,769 spinning platters to deal with 
>and an access arm with 65,535 R/W heads to move back and forth with all of the 
>implied momentum of a device that size. How tall do you think 32K of platters 
>would be?
>
That's a big "if" and a somewhat remote "previous".

32769?  2 surfaces per platter plus one for timing?  OK.  Is
There a taboo against using surface ?

Depends on how thick the platters are.  You forgot the smiley.

Well, if IBM's new DASD architecture were manufactured in the same
manner as previous DASD devices, you would have 278,921,216 tracks
on each surface.  What diameter do you think such platters would be?
How long would it take the access arm to traverse the radius?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Walt Farrell]

On Fri, 27 Mar 2009 10:05:29 -0500, Eric Bielefeld 
wrote:

>Is the new format available in z/OS 1.11?  That's what I gathered from some
>of the postings, but it didn't seem definitive.  I should probably look at
>the announcement, but right now I'm feeling lazy.
>

z/OS V1.10: VSAM
previewed for z/OS V1.11: extended format sequential, too.

-- 
  Walt Farrell, CISSP
  IBM STSM, z/OS Security Design

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Spencer, Mike]

The new format is available in z/OS 1.10 with limitations as to what data may 
actually use the EAV space.  Only VSAM data can reside in this area, and even 
the VSAM data has limitations.  
z/OS 1.11 will reduce some of the data restrictions. 


Michael Spencer
BMC Software

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Eric Bielefeld
Sent: Friday, March 27, 2009 11:05 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: "A foolish consistancy" or "3390 cyl/track architecture"

Is the new format available in z/OS 1.11?  That's what I gathered from some of 
the postings, but it didn't seem definitive.  I should probably look at the 
announcement, but right now I'm feeling lazy.

Eric

Eric Bielefeld
Sr. Systems Programmer
Milwaukee, Wisconsin
414-475-7434
 

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at 
http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Tom Marchant]

On Fri, 27 Mar 2009 10:05:29 -0500, Eric Bielefeld wrote:

>Is the new format available in z/OS 1.11?  

1.10 for VSAM only. 

>  I should probably look at the announcement, 

Yes

>but right now I'm feeling lazy.

evidently.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Eric Bielefeld]

Is the new format available in z/OS 1.11?  That's what I gathered from some 
of the postings, but it didn't seem definitive.  I should probably look at 
the announcement, but right now I'm feeling lazy.


Eric

Eric Bielefeld
Sr. Systems Programmer
Milwaukee, Wisconsin
414-475-7434


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Tom Marchant]

On Fri, 27 Mar 2009 08:07:29 -0500, Mohammad Khan wrote:

>Please forgive my ignorance but how does robbing Hs to pay Cs increase the
>total addressable storage ? Unless off course those Hs were for show only.
>Mohammad

As Bill pointed out, 3390 and 3380 have only 15 tracks per cylinder, so the
head address fits in one nibble.

IIRC, the 3350 had 30 tracks per cylinder.  The 2305 model 2 had 768 tracks
and non-movable heads, so it would have needed more bits for the head address.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Rich Smrcina]

Mohammad Khan wrote:
Please forgive my ignorance but how does robbing Hs to pay Cs increase the 
total addressable storage ? Unless off course those Hs were for show only.

Mohammad


  
The high order H's were not used.  Since they were not used, they are 
being re-provisioned as high order cylinder addresses where they are needed.


--
Rich Smrcina
Phone: 414-491-6001
http://www.linkedin.com/in/richsmrcina

Catch the WAVV! http://www.wavv.org
WAVV 2009 - Orlando, FL - May 15-19, 2009

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Bill Fairchild]

From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Mohammad Khan
Sent: Friday, March 27, 2009 9:07 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: "A foolish consistancy" or "3390 cyl/track architecture"

>Please forgive my ignorance but how does robbing Hs to pay Cs increase the 
total addressable storage ? Unless off course those Hs were for show only.
Mohammad


Those Hs were for show only.  The Hs that are now robbed used to be unused and 
always had to contain zero.  For at least the last 25 years, all new DASDs from 
IBM have had 15 tracks per cylinder.  Long, long ago there were some DASDs with 
more or fewer, but now the number seems fixed for all time at 15.  Thus there 
are 12 bits (3 Hs) that are available for use for some other purpose, assuming 
that microcode and software can tell when the Hs bits really mean high-order 
cylinder numbers and when they don't.

Bill Fairchild
Rocket Software

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Mohammad Khan]

Please forgive my ignorance but how does robbing Hs to pay Cs increase the 
total addressable storage ? Unless off course those Hs were for show only.
Mohammad

On Thu, 26 Mar 2009 13:48:00 -0700, Edward Jaffe 
 wrote:

>
>Not the CCW, the disk address. The old, familiar R is now
>cccHR on EAV where the effective cylinder address is ccc.
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Spencer, Mike]

A lot of this has to do with the amount of code that would need to be changed 
in z/OS and also in the microcode for the DASD controllers.  The only DASD that 
supports EAV volumes are IBM DS8000 series.  
The existing 16 bit cylinder addressing (CCHH)  ( is the 16 bit 
cylinder number  is the 16 bit track number) is near the theoretical limit 
of 65,535.  The largest volume is 65,520.  IBM came up with a new format to 
handle cylinder numbers greater than 65,520.  
The new 28-bit cylinder number is cccH ( is low-order 16 bits of 28-bit 
cylinder number, ccc is high-order 12 bits of 28-bit cylinder number, H is 
4-bit track number (0-14)).  This is the format used by the DS8000, extent 
descriptors, access method, and channel programs to access a track.  Of course 
there are new DSCBs to help protect existing programs; Format 8/9 DSCB.  
There are quite a few limitations on the first go around for EAS data sets. 
When z/OS 1.11 comes out, many of the limitations; such as a data set extending 
from track managed to cylinder managed, will be resolved.  
As with some of the bad things that go along with the new EAV volumes, EAV 
opens a world of opportunity for customers reaching the limit of 65,280 devices 
(the 4 digit device number) and other limitations that large installations 
face.  DB2 appears to be a driving force with large table spaces becoming an 
issue for some IT organizations.   


Michael Spencer
BMC Software

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
John McKown
Sent: Thursday, March 26, 2009 2:53 PM
To: IBM-MAIN@bama.ua.edu
Subject: "A foolish consistancy" or "3390 cyl/track architecture"

I just had a Webinar with Dino software on z/OS 1.10 and ICF catalogs. Very 
interesting. The most interesting thing to me was how IBM implemented Extended 
Address Volumes. There is a 4 byte area in the CCW. Historically this is the 
 (in nybbles) field. What IBM has done is take the high order 3 nybbles 
of the  and made it part of the cylinder address, but although physically 
after the historical cylinder address, it is logically the first 3 nybbles of 
the cylinder address. I.e. C0C1C2C3H0H1H2H3 has become C3C4C5C6C0C1C2H0 (wish I 
could do subscripts properly).

Now, why is 14 tracks per cylinder so sacrosanct? Why didn't IBM create a new 
DASD with 2^16-1 (x'') cylinders where each cylinder has 2^16-1
(x'') tracks? Is it due to not wanting to "mess around" with the ECKD 
emulation in the physical DASD array? Is there some code deep within z/OS which 
is so crufty that to consider touching it sends paroxsyms of terror in the 
hearts of the DFP developers? 

And what makes 56K per tracks so sacred also?

Is this just a case of "how to make a really large volume while making the 
absolute minimum number of software changes"?

Oh, well. I would still prefer that z/OS kick ECKD to the curb and go FBA, 
using standard FCP (Fibre Channel) connection to the SAN fabric. z/Linux can do 
it. So the hardware is capable. I guess this is yet another case of cost vs. 
perceived benefit.

--
John

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at 
http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Raymond Noal]

Well, if your new DASD architecture was manufactured in the same manner as 
previous DASD devices, you would have 32,769 spinning platters to deal with and 
an access arm with 65,535 R/W heads to move back and forth with all of the 
implied momentum of a device that size. How tall do you think 32K of platters 
would be? 

HITACHI
 DATA SYSTEMS 
Raymond E. Noal 
Senior Technical Engineer 
Office: (408) 970 - 7978 

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Arthur T.
Sent: Thursday, March 26, 2009 2:29 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: "A foolish consistancy" or "3390 cyl/track architecture"

On 26 Mar 2009 11:54:41 -0700, in bit.listserv.ibm-main 
(Message-ID:) 
joa...@swbell.net (John McKown) wrote:

>Now, why is 14 tracks per cylinder so sacrosanct? Why 
>didn't IBM create a
>new DASD with 2^16-1 (x'') cylinders where each 
>cylinder has 2^16-1
>(x'') tracks?

  And, when someone runs old JCL which requests two 
cylinders for a new dataset?

  I expect that your solution would have been easier 
for IBM, but many of their customers would have issues as 
above.

-- 
I cannot receive mail at the address this was sent from.
To reply directly, send to ar23hur "at" intergate "dot" com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Arthur T.]

On 26 Mar 2009 11:54:41 -0700, in bit.listserv.ibm-main 
(Message-ID:) 
joa...@swbell.net (John McKown) wrote:


Now, why is 14 tracks per cylinder so sacrosanct? Why 
didn't IBM create a
new DASD with 2^16-1 (x'') cylinders where each 
cylinder has 2^16-1

(x'') tracks?


 And, when someone runs old JCL which requests two 
cylinders for a new dataset?


 I expect that your solution would have been easier 
for IBM, but many of their customers would have issues as 
above.


--
I cannot receive mail at the address this was sent from.
To reply directly, send to ar23hur "at" intergate "dot" com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Ted MacNEIL]

>There are tremendous advantages to keeping the 3390 geometry stable.

YES!

>You might not remember how much hassle it was in the past to transition from 
>e.g., 3330 to 3350, to 3380, to 9345 (for some of us), to 3390.

OH! YES!
I missed the 9345, but the rest hurt!
Remember 3390 in '3380-compatability'?


>Over two decades ago, IBM promised there would be no 

Etc. Etc. &c!

One of the best promises!

Until FBA/SDB comes out in z/OS, there is nothing better to do.

By SDB, I mean when people stop worrying about Block Size, and embrace it.
I know some who still insist on coding it!

-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Edward Jaffe]

Edward Jaffe wrote:
... The old, familiar R is now cccHR on EAV where the 
effective cylinder address is ccc.


Jeez. I make the same typing mistake every time. I should have written, 
"RR is now cccHRR". :-[


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Edward Jaffe]

John McKown wrote:

I just had a Webinar with Dino software on z/OS 1.10 and ICF catalogs. Very
interesting. The most interesting thing to me was how IBM implemented
Extended Address Volumes. There is a 4 byte area in the CCW. Historically
this is the  (in nybbles) field. What IBM has done is take the high
order 3 nybbles of the  and made it part of the cylinder address, but
although physically after the historical cylinder address, it is logically
the first 3 nybbles of the cylinder address. I.e. C0C1C2C3H0H1H2H3 has
become C3C4C5C6C0C1C2H0 (wish I could do subscripts properly).
  


Not the CCW, the disk address. The old, familiar R is now 
cccHR on EAV where the effective cylinder address is ccc.



Now, why is 14 tracks per cylinder so sacrosanct? Why didn't IBM create a
new DASD with 2^16-1 (x'') cylinders where each cylinder has 2^16-1
(x'') tracks? Is it due to not wanting to "mess around" with the ECKD
emulation in the physical DASD array? Is there some code deep within z/OS
which is so crufty that to consider touching it sends paroxsyms of terror in
the hearts of the DFP developers? 

And what makes 56K per tracks so sacred also?

Is this just a case of "how to make a really large volume while making the
absolute minimum number of software changes"?
  


There are tremendous advantages to keeping the 3390 geometry stable. You 
might not remember how much hassle it was in the past to transition from 
e.g., 3330 to 3350, to 3380, to 9345 (for some of us), to 3390. Over two 
decades ago, IBM promised there would be no more geometry changes. And, 
they've stayed true to their word.


It's the same reason we have tri-modal addressing in z/Architecture: 
24-bit, 31-bit, and 64-bit. Upward compatibility is important. IMHO, IBM 
does it better than any other vendor.


The new disk addressing scheme can describe a single volume with up to 
268,435,456 3390 cylinders--or nearly 223 TB--without changing the 3390 
geometry one iota. Impressive!



Oh, well. I would still prefer that z/OS kick ECKD to the curb and go FBA,
using standard FCP (Fibre Channel) connection to the SAN fabric. z/Linux can
do it. So the hardware is capable. I guess this is yet another case of cost
vs. perceived benefit.
  


De-support ECKD? Not likely. Instead, new I/O architectures like zHPF 
(FCX) solve ECKD's performance issues without changing *any* 
applications. Also, *darn* impressive!


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "A foolish consistancy" or "3390 cyl/track architecture"

[Bill Fairchild]

From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
John McKown
Sent: Thursday, March 26, 2009 2:53 PM
To: IBM-MAIN@bama.ua.edu
Subject: "A foolish consistancy" or "3390 cyl/track architecture"

>I just had a Webinar with Dino software on z/OS 1.10 and ICF catalogs. Very
interesting. The most interesting thing to me was how IBM implemented
Extended Address Volumes. There is a 4 byte area in the CCW. Historically
this is the  (in nybbles) field. What IBM has done is take the high
order 3 nybbles of the  and made it part of the cylinder address, but
although physically after the historical cylinder address, it is logically
the first 3 nybbles of the cylinder address. I.e. C0C1C2C3H0H1H2H3 has
become C3C4C5C6C0C1C2H0 (wish I could do subscripts properly).



Close, but no cigar.

The 4 bytes you mentioned are not in the CCW.  They are in the "disk address", 
aka "Record Identifier", part of the Count Field, which is the first of three 
possible fields in each CKD record stored on a track.  The rest of your EAV 
discussion was spot on.

The two constants of 15 tracks per cylinder and 56KB per track are embedded in 
gazillions of lines of code inside z/OS and also bazillions of lines of 
microcode in the DASD controllers/subsystems (and now maybe channels, too).

Bill Fairchild
Rocket Software

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

"A foolish consistancy" or "3390 cyl/track architecture"

[John McKown]

I just had a Webinar with Dino software on z/OS 1.10 and ICF catalogs. Very
interesting. The most interesting thing to me was how IBM implemented
Extended Address Volumes. There is a 4 byte area in the CCW. Historically
this is the  (in nybbles) field. What IBM has done is take the high
order 3 nybbles of the  and made it part of the cylinder address, but
although physically after the historical cylinder address, it is logically
the first 3 nybbles of the cylinder address. I.e. C0C1C2C3H0H1H2H3 has
become C3C4C5C6C0C1C2H0 (wish I could do subscripts properly).

Now, why is 14 tracks per cylinder so sacrosanct? Why didn't IBM create a
new DASD with 2^16-1 (x'') cylinders where each cylinder has 2^16-1
(x'') tracks? Is it due to not wanting to "mess around" with the ECKD
emulation in the physical DASD array? Is there some code deep within z/OS
which is so crufty that to consider touching it sends paroxsyms of terror in
the hearts of the DFP developers? 

And what makes 56K per tracks so sacred also?

Is this just a case of "how to make a really large volume while making the
absolute minimum number of software changes"?

Oh, well. I would still prefer that z/OS kick ECKD to the curb and go FBA,
using standard FCP (Fibre Channel) connection to the SAN fabric. z/Linux can
do it. So the hardware is capable. I guess this is yet another case of cost
vs. perceived benefit.

--
John

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html