Re: Flash memory arrays

[Rick Fochtman]

--

I saw a 1TB for $300 and heard about the same for under $300 at  
Walmart (unconfirmed).


Ed

ps: They have a Fry's here in the Chicago Suburbs and everybody I  
have talked to says that they will avoid it for anyplace else 
(including me).


-
I'm within about 15 minutes of Fry's, MicroCenter and CompUSA; each 
outlet has strengths and weaknesses. If you go to Fry's, here in Downers 
Grove, you better know exactly what you want, because most of the 
"children" on the sales staff know just enough about a computer to turn 
it on, and tell the difference between a keyboard and a mouse. And even 
that is considered "Highly Trained".  :-)) The same holds true of the 
other two I mentioned.


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

Re: Flash memory arrays

[Ed Gould]

On Jan 18, 2008, at 7:48 PM, Tom Moulder wrote:

Fry's in the Dallas/Fort Worth area has a 500GB SATA drive on sale  
this week

for $90.  How low can you go?


Tom,

I saw a 1TB for $300 and heard about the same for under $300 at  
Walmart (unconfirmed).


Ed

ps: They have a Fry's here in the Chicago Suburbs and everybody I  
have talked to says that they will avoid it for anyplace else 
(including me).




Tom Moulder

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED]  
On Behalf

Of Dave Kopischke
Sent: Friday, January 18, 2008 1:02 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Flash memory arrays

On Fri, 18 Jan 2008 12:44:22 -0600, McKown, John wrote:

I think that they are either SCSI, or Fibre Channel. For a mere  
1.2Tb,

you can use 3 500Gib eSATA drives.


I was at the PC store the other day and they had 1TB SATA drives  
for sale. I


didn't catch the price. I settled for a mere 250G for $70. I  
haven't been

able
to dent the capacity of a 30G drive in three years. Give my son  
iTunes and 6


weeks and 40G are gone.

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

No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.19.6/1231 - Release Date:  
1/18/2008

11:55 AM


No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.19.6/1231 - Release Date:  
1/18/2008

11:55 AM


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Flash memory arrays

[Ron Hawkins]

Bill

But 1999 is more than half a decade ago. 

I think you are talking about the 1 inch pixie dust drives. They are made by
Hitachi now. You'll find them in your IPOD, but not in EMC. The last
contract I recall between EMC and IBM for HDD was the 36GB drive, and that
was cancelled due to heat problems. (I am repeating a rumour - happy to be
corrected)

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of (IBM Mainframe Discussion List)
> Sent: Friday, January 18, 2008 8:31 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: [IBM-MAIN] Flash memory arrays
> 
> 
> 
> In a message dated 1/18/2008 9:05:19 A.M. Central Standard Time,
> [EMAIL PROTECTED] writes:
> >IBM, EMC and HDS send faulty drives back to Seagate and
> Hitachi for  analysis for their modular products as well. There is no
> difference between  drives used in Enterprise and Modular arrays. IT's
> not a
> hidden service, it's  simply the warranty that the Disk manufacturer
> provides
> (it's been half a  decade since IBM made a disk drive).
> 
> Around mid-1999 EMC signed a multi-$billion contract to buy a HUGE
> number  of
> little disks from IBM over a period of several years.  So IBM was
> making
> disks then.  And I think that contract expired about half a decade
> ago.
> 
> Bill  Fairchild
> Franklin, TN
> 
> 
> 
> 
> 
> **Start the year off right.  Easy ways to stay in shape.
> http://body.aol.com/fitness/winter-exercise?NCID=aolcmp0030002489
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Flash memory arrays

[Tom Moulder]

Fry's in the Dallas/Fort Worth area has a 500GB SATA drive on sale this week
for $90.  How low can you go?

Tom Moulder

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Dave Kopischke
Sent: Friday, January 18, 2008 1:02 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Flash memory arrays

On Fri, 18 Jan 2008 12:44:22 -0600, McKown, John wrote:

>I think that they are either SCSI, or Fibre Channel. For a mere 1.2Tb,
>you can use 3 500Gib eSATA drives.

I was at the PC store the other day and they had 1TB SATA drives for sale. I

didn't catch the price. I settled for a mere 250G for $70. I haven't been
able 
to dent the capacity of a 30G drive in three years. Give my son iTunes and 6

weeks and 40G are gone.

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

No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.516 / Virus Database: 269.19.6/1231 - Release Date: 1/18/2008
11:55 AM
 

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.516 / Virus Database: 269.19.6/1231 - Release Date: 1/18/2008
11:55 AM
 

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

Re: Flash memory arrays

[Shane]

On Fri, 2008-01-18 at 16:09 -0600, Tony Harminc wrote:

> >(I might be able to pick up an old 2105-F20 for the cost of a rental
> >truck. It's currently at 1.2 TB)
> 
> Someone with an MP3000 or the like might be happy to have it.

Or anybody thinking of bidding on an 890 maybe ...

Shane...

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

Re: Flash memory arrays

[Tony Harminc]

On Fri, 18 Jan 2008 12:40:16 -0600, Rick Fochtman <[EMAIL PROTECTED]> wrote:

>I can't help but wonder: when a purchased storage array device is
>decommissioned, are all those little drives of any use for PC
>replacements? What sorts of interfaces do those drives require? (E)IDE
>or SCSI of SCSI-2 ??

Some of them are SSA; some SCSI. Some newer ones are FC. They show up on
eBay quite regularly, at prices varying from a few bucks to hundreds. They
generally don't sell at all at any price. Search eBay with keywords SSA DRVC
for some examples. You can find PCI SSA interface cards if you look around,
so they are not impossible to use on a PC. (When searching, it's usually
wise to include negative keywords of -Social -Security and -Administration,
for reasons that quickly become obvious, even to a non-American like me.)
You'd also need suitable data and power connectors and cables, none of which
are compatible with anything else on the planet, and none of which are easy
to find or cheap. 

So really, what's the point when you can buy a shiny new SATA drive with
better specs, a warranty, and vastly more space, for a couple of hundred bucks.

>(I might be able to pick up an old 2105-F20 for the cost of a rental
>truck. It's currently at 1.2 TB)

Someone with an MP3000 or the like might be happy to have it.

Tony H.

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

Re: Flash memory arrays

[Dave Kopischke]

On Fri, 18 Jan 2008 12:44:22 -0600, McKown, John wrote:

>I think that they are either SCSI, or Fibre Channel. For a mere 1.2Tb,
>you can use 3 500Gib eSATA drives.

I was at the PC store the other day and they had 1TB SATA drives for sale. I 
didn't catch the price. I settled for a mere 250G for $70. I haven't been able 
to dent the capacity of a 30G drive in three years. Give my son iTunes and 6 
weeks and 40G are gone.

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

Re: Flash memory arrays

[Anne & Lynn Wheeler]

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


[EMAIL PROTECTED] (, IBM Mainframe Discussion List) writes:
> Around mid-1999 EMC signed a multi-$billion contract to buy a HUGE number  of 
> little disks from IBM over a period of several years.  So IBM was making  
> disks then.  And I think that contract expired about half a decade  ago.

san jose plant site (disk unit) now belongs to hitachi. most recent,
hitachi talking about selling off the unit.
http://www.garlic.com/~lynn/2007v.html#33 Hitachi, Silver Lake in talks about 
hard drives, sources say

a few other references
http://www.garlic.com/~lynn/2003d.html#9 IBM says AMD dead in 5yrs ... -- 
Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003i.html#25 TGV in the USA?
http://www.garlic.com/~lynn/2003n.html#39 DASD history
http://www.garlic.com/~lynn/2006.html#21 IBM up for grabs?
http://www.garlic.com/~lynn/2006o.html#18 RAMAC 305(?)
http://www.garlic.com/~lynn/2006r.html#14 50th Anniversary of invention of disk 
drives
http://www.garlic.com/~lynn/2006r.html#15 50th Anniversary of invention of disk 
drives
http://www.garlic.com/~lynn/2006r.html#20 50th Anniversary of invention of disk 
drives

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

Re: Flash memory arrays

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Rick Fochtman
> Sent: Friday, January 18, 2008 12:40 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Flash memory arrays
> 
> 
> --
> 
> >Around mid-1999 EMC signed a multi-$billion contract to buy 
> a HUGE number  of 
> >little disks from IBM over a period of several years.  So 
> IBM was making  
> >disks then.  And I think that contract expired about half a 
> decade  ago.
> >  
> >
> --
> I can't help but wonder: when a purchased storage array device is 
> decommissioned, are all those little drives of any use for PC 
> replacements? What sorts of interfaces do those drives 
> require? (E)IDE 
> or SCSI of SCSI-2 ??
> 
> (I might be able to pick up an old 2105-F20 for the cost of a rental 
> truck. It's currently at 1.2 TB)

I think that they are either SCSI, or Fibre Channel. For a mere 1.2Tb,
you can use 3 500Gib eSATA drives.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it. 

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

Re: Flash memory arrays

[Rick Fochtman]

--

Around mid-1999 EMC signed a multi-$billion contract to buy a HUGE number  of 
little disks from IBM over a period of several years.  So IBM was making  
disks then.  And I think that contract expired about half a decade  ago.
 


--
I can't help but wonder: when a purchased storage array device is 
decommissioned, are all those little drives of any use for PC 
replacements? What sorts of interfaces do those drives require? (E)IDE 
or SCSI of SCSI-2 ??


(I might be able to pick up an old 2105-F20 for the cost of a rental 
truck. It's currently at 1.2 TB)


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

Re: Flash memory arrays

[Anne & Lynn Wheeler]

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-mai,alt.folkore.computers as well.

[EMAIL PROTECTED] (, IBM Mainframe Discussion List) writes:
> Around mid-1999 EMC signed a multi-$billion contract to buy a HUGE number  of 
> little disks from IBM over a period of several years.  So IBM was making  
> disks then.  And I think that contract expired about half a decade  ago.

san jose plant site (disk unit) now belongs to hitachi. most recent,
hitachi talking about selling off the unit.
http://www.garlic.com/~lynn/2007v.html#33 Hitachi, Silver Lake in talks about 
hard drives, sources say

a few other references
http://www.garlic.com/~lynn/2003d.html#9 IBM says AMD dead in 5yrs ... -- 
Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003i.html#25 TGV in the USA?
http://www.garlic.com/~lynn/2003n.html#39 DASD history
http://www.garlic.com/~lynn/2006.html#21 IBM up for grabs?
http://www.garlic.com/~lynn/2006o.html#18 RAMAC 305(?)
http://www.garlic.com/~lynn/2006r.html#14 50th Anniversary of invention of disk 
drives
http://www.garlic.com/~lynn/2006r.html#15 50th Anniversary of invention of disk 
drives
http://www.garlic.com/~lynn/2006r.html#20 50th Anniversary of invention of disk 
drives

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

Re: Flash memory arrays

[(IBM Mainframe Discussion List)]

 
 
In a message dated 1/18/2008 9:05:19 A.M. Central Standard Time,  
[EMAIL PROTECTED] writes:
>IBM, EMC and HDS send faulty drives back to Seagate and
Hitachi for  analysis for their modular products as well. There is no
difference between  drives used in Enterprise and Modular arrays. IT's not a
hidden service, it's  simply the warranty that the Disk manufacturer provides
(it's been half a  decade since IBM made a disk drive).
 
Around mid-1999 EMC signed a multi-$billion contract to buy a HUGE number  of 
little disks from IBM over a period of several years.  So IBM was making  
disks then.  And I think that contract expired about half a decade  ago.
 
Bill  Fairchild
Franklin, TN





**Start the year off right.  Easy ways to stay in shape. 
http://body.aol.com/fitness/winter-exercise?NCID=aolcmp0030002489

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

Re: Flash memory arrays

[Van Dalsen, Herbie]

Ron,

Thanks for the enlightenment... I'll have to speak the engineer that
spun me the big story... And to myself for believing him... 

Still, I can format the ESS for MF / Open systems, but I have never had
the chance to compare the actual GB available to Open systems compared
to the actual available to MVS on the exact same array. Yet having said
that, the current server room has a short life expectancy, and guess
what I will be doing as part of the de-mantling process... Just exactly
that, as well as to see for myself the usage difference/loss with all
the raid / PAV options available, there just isn't anything like
first-hand experience...

Herbie 


-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Ron Hawkins
Sent: 18 Januarie 2008 03:05 nm
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Flash memory arrays

Herbie,

Good Guess, but IBM, EMC and HDS send faulty drives back to Seagate and
Hitachi for analysis for their modular products as well. There is no
difference between drives used in Enterprise and Modular arrays. IT's
not a
hidden service, it's simply the warranty that the Disk manufacturer
provides
(it's been half a decade since IBM made a disk drive).

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Van Dalsen, Herbie
> Sent: Friday, January 18, 2008 6:42 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: [IBM-MAIN] Flash memory arrays
> 
> I can certainly see why "mainframe disk" is more expensive, but is
this
> the really case? Nowadays most unix / windows servers needs some sort
> of
> a SAN environment. That costs a lot of money, like an Clariion, or the
> like. I am still convinced that the hidden service that IBM provide
> where they remove a faulty disk from an ESS and send it back to be
> analyzed and the regularity with which they provide microcode...
> 
> Just my $0.01
> 
> Herbie
> 
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Elavon Financial Services Limited
Registered in Ireland: Number 418442
Registered Office: Block E, 1st Floor, Cherrywood Business Park, Loughlinstown, 
Co. Dublin, Ireland
Directors: Robert Abele (USA), John Collins,  Terrance Dolan (USA),  Pamela 
Joseph (USA), Declan Lynch, John McNally, Malcolm Towlson
Elavon Financial Services Limited, trading as Elavon, is regulated by the 
Financial Regulator

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

Re: Flash memory arrays

[Ron Hawkins]

Herbie,

Good Guess, but IBM, EMC and HDS send faulty drives back to Seagate and
Hitachi for analysis for their modular products as well. There is no
difference between drives used in Enterprise and Modular arrays. IT's not a
hidden service, it's simply the warranty that the Disk manufacturer provides
(it's been half a decade since IBM made a disk drive).

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Van Dalsen, Herbie
> Sent: Friday, January 18, 2008 6:42 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: [IBM-MAIN] Flash memory arrays
> 
> I can certainly see why "mainframe disk" is more expensive, but is this
> the really case? Nowadays most unix / windows servers needs some sort
> of
> a SAN environment. That costs a lot of money, like an Clariion, or the
> like. I am still convinced that the hidden service that IBM provide
> where they remove a faulty disk from an ESS and send it back to be
> analyzed and the regularity with which they provide microcode...
> 
> Just my $0.01
> 
> Herbie
> 
> 

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

Re: Flash memory arrays

[Van Dalsen, Herbie]

I can certainly see why "mainframe disk" is more expensive, but is this
the really case? Nowadays most unix / windows servers needs some sort of
a SAN environment. That costs a lot of money, like an Clariion, or the
like. I am still convinced that the hidden service that IBM provide
where they remove a faulty disk from an ESS and send it back to be
analyzed and the regularity with which they provide microcode...

Just my $0.01

Herbie


-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Ron Hawkins
Sent: 18 Januarie 2008 06:07
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Flash memory arrays

John,

I'm not sure I agree with this. If your comparing so-called "enterprise
class" array price with "modular class" systems then it is not a valid
comparison. 

Assume a barebones DMX4, DS8K or USP-V with no software products except
a
basic element manager and microcode. If the only difference is Fibre
Channel
or FICON connectivity then I don't believe there is any considerable
difference in price.

The conversion from CKD to FBA is done in the PCB carrying the Host
ports.
For HDS it is simply two Microprocessors per FICON port pair, and they
are
usually considerably less busy than the MP that they hand off to.

Comparing any of the Arrays that support MF with "Modular class" SCSI
storage is oranges and apples. Modular storage is a one trick pony -
there
is not enough grunt to ever consider running XRC, Flashcopy V2, HUR or
SRDF/A. If you built all those capabilities into modular storage you
have a
price much higher than rack and stack market. It's not CKD that pushes
up
the price, it is the functionality of the box.

I have never heard anyone complain that Mustang cost more than a
Moped...

Ron

> 
> Hum, I see your point. My "concern" is the ongoing discussion around
> here as to why z/OS DASD costs more per gigabyte than the Windows or
> Solaris DASD. The reasons, as I see it, are two fold. First, the
vendor
> must write, validate, and support the emulation software on their DASD
> array. Second, the vendor is "gouging" the z/OS shops "because we
can".
> OK, the latter is cynical of me.
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Elavon Financial Services Limited
Registered in Ireland: Number 418442
Registered Office: Block E, 1st Floor, Cherrywood Business Park, Loughlinstown, 
Co. Dublin, Ireland
Directors: Robert Abele (USA), John Collins,  Terrance Dolan (USA),  Pamela 
Joseph (USA), Declan Lynch, John McNally, Malcolm Towlson
Elavon Financial Services Limited, trading as Elavon, is regulated by the 
Financial Regulator

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

Re: Flash memory arrays

[(IBM Mainframe Discussion List)]

 
 
On Thu, Jan 17, 2008 at 11:26 AM, in message  
<[EMAIL PROTECTED]>, Clark  Morris
<[EMAIL PROTECTED]> wrote:
>VSAM is already FBA
 
Sort of.  A VSAM file, once loaded, consists of blocks of all the  same size, 
but VSAM allows more than one block size (e.g., 4K and 8K).   FBA, to me, 
means that all blocks are always the same size.
 
In a message dated 1/17/2008 6:47:55 P.M. Central Standard Time,  
[EMAIL PROTECTED] writes:
>FBA is what the media is.
 
All of IBM's "CKD" devices have in one sense already been FBA for several  
decades.  Each new device has not necessarily had the same block size,  
however. 
 The block size I am talking about here is the size of the segment  of 
consecutive bytes that the controller allocates whenever any new piece of  data 
is 
to be written onto a track.  E.g., if you try to write a record  with a 
one-byte-long data field onto a 3390, the controller uses an entire  segment, 
consisting of around thirty bytes (31?  32?  37?) to hold the  one byte in the 
data 
field.  These extra bytes are in addition to the gaps  in between records and 
pieces of records on the track.  Whenever a skip  displacement has to be 
assigned, the size of the area to be skipped is always an  integral number of 
these 
segments.
 
The two FBA devices that IBM allowed to be used by VM and VSE, the 3310 and  
3370, have physical block sizes of 512 bytes.  At least the software must  
assume so.  But what the controller really writes onto a 3310 and 3370  track 
may 
be something different, as it is for a 3390.
 
Bill  Fairchild
Franklin, TN





**Start the year off right.  Easy ways to stay in shape. 
http://body.aol.com/fitness/winter-exercise?NCID=aolcmp0030002489

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

Re: Flash memory arrays

[Ron Hawkins]

John,

I'm not sure I agree with this. If your comparing so-called "enterprise
class" array price with "modular class" systems then it is not a valid
comparison. 

Assume a barebones DMX4, DS8K or USP-V with no software products except a
basic element manager and microcode. If the only difference is Fibre Channel
or FICON connectivity then I don't believe there is any considerable
difference in price.

The conversion from CKD to FBA is done in the PCB carrying the Host ports.
For HDS it is simply two Microprocessors per FICON port pair, and they are
usually considerably less busy than the MP that they hand off to.

Comparing any of the Arrays that support MF with "Modular class" SCSI
storage is oranges and apples. Modular storage is a one trick pony - there
is not enough grunt to ever consider running XRC, Flashcopy V2, HUR or
SRDF/A. If you built all those capabilities into modular storage you have a
price much higher than rack and stack market. It's not CKD that pushes up
the price, it is the functionality of the box.

I have never heard anyone complain that Mustang cost more than a Moped...

Ron

> 
> Hum, I see your point. My "concern" is the ongoing discussion around
> here as to why z/OS DASD costs more per gigabyte than the Windows or
> Solaris DASD. The reasons, as I see it, are two fold. First, the vendor
> must write, validate, and support the emulation software on their DASD
> array. Second, the vendor is "gouging" the z/OS shops "because we can".
> OK, the latter is cynical of me.
> 

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

Re: Flash memory arrays

[Mark Post]

>>> On Thu, Jan 17, 2008 at 11:26 AM, in message
<[EMAIL PROTECTED]>, Clark Morris
<[EMAIL PROTECTED]> wrote: 
-snip-
> There obviously would have to be a co-existence period where both
> architectures are supported.  VSAM is already FBA as are all of the
> newer data architectures.  The challenges will be spool, providing GDG
> like capability to the VSAM ESDS, moving PDSE read access to the
> Nucleus and deciding how to provide the current SYS1.NUCLEUS
> capability.  Maybe the MVS people should humble themselves and talk to
> the VM and VSE people to find out how they solved the problem.

You're conflating several distinct layers here and making things seem more 
difficult than they really are.  FBA is what the media is.  How that media is 
"formatted," that is, how many bytes per sector, what kind of data structures 
are used to keep track of where all the pieces of a file are, what metadata 
about them is kept (date modified, owner, etc.) can be thought of as the "file 
system."  What kind of data gets put into that file system, such as PDSes, 
spool space, etc., is entirely up to the operating systems/applications writing 
them.  Just because UNIX/Linux/VM etc. don't have a PDS dataset type doesn't 
mean it can't exist on FBA devices.  It just means that the underlying hardware 
and the access methods the OS uses to read and write data on it has to change.


Mark Post

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

Re: Flash memory arrays

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>,
on 01/17/2008
   at 08:48 AM, "Chase, John" <[EMAIL PROTECTED]> said:

>Weaning z/OS from (E)CKD would likely be such a monumental change

Adding FBA support would be far easier than weaning z/OS from ECKD.
Provide a CI for BPAM, BSAM and QSAM, support VSAM use of FBA and most
applications would run unchanged.

Addmitably code that uses EXCP would be affected, and possibly code that
reads the VTOC. but I don't see that as a major obstacle.
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Flash memory arrays

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Chase, John
> Sent: Thursday, January 17, 2008 8:49 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Flash memory arrays
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List On Behalf Of McKown, John
> > 
> > Only z/OS is stuck on ECKD formatted DASD. z/VM and z/VSE can 
> > both run on FBA. z/LINUX can run on FBA and/or on SAN/SCSI 
> > DASD. I think that the latest z/VM can also run on SAN/SCSI 
> > connected DASD as well. z/OS remains the hold out. For 
> > whatever reason that may be. 
> 
> Weaning z/OS from (E)CKD would likely be such a monumental 
> change as to
> require that it be done at a version boundary and provide perhaps an
> entire version life-cycle to complete. 
> 
> "Who knows" how much non-IBM code would have to be revisited 
> during the
> transition?  More than a few CBT utilities would be relegated to the
> dustbin of history.
> 
> It's probably also true that the longer such a transition is delayed,
> the less likely it is to be attempted.
> 
> -jc-

Hum, I see your point. My "concern" is the ongoing discussion around
here as to why z/OS DASD costs more per gigabyte than the Windows or
Solaris DASD. The reasons, as I see it, are two fold. First, the vendor
must write, validate, and support the emulation software on their DASD
array. Second, the vendor is "gouging" the z/OS shops "because we can".
OK, the latter is cynical of me.

Here is an idea to be shot down. Instead of having the ECKD emulation
software on the DASD box, how about putting it in the SAP on the System
z? I am not really aware of how powerful the SAP is or how "busy" it
might be doing whatever it is that it does. If not the SAP, then another
speciality engine. This may well be too difficult for the System z
engines, and difficult to maintain. I.e. the mapping from a logical
volume onto the physical volumes. OK, it was a stupid idea. What else is
new with me? I guess I figured that if Hercules/390 could do it, a SAP
should be able to as well.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it. 

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

Re: Flash memory arrays

[Anne & Lynn Wheeler]

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


[EMAIL PROTECTED] (Clark Morris) writes:
> There obviously would have to be a co-existence period where both
> architectures are supported.  VSAM is already FBA as are all of the
> newer data architectures.  The challenges will be spool, providing GDG
> like capability to the VSAM ESDS, moving PDSE read access to the
> Nucleus and deciding how to provide the current SYS1.NUCLEUS
> capability.  Maybe the MVS people should humble themselves and talk to
> the VM and VSE people to find out how they solved the problem.

re:
http://www.garlic.com/~lynn/2008b.html#15 Flash memory arrays
http://www.garlic.com/~lynn/2008b.html#16 Flash memory arrays
http://www.garlic.com/~lynn/2008b.html#17 Flash memory arrays

next week is 40yrs since i started on virtual machines ... i.e. three
people had come out from the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

to install (virtual machine) cp67 at the university (i had already been
doing optimization work on os/360 for a couple yrs). 

>From the original implementation in the mid-60s, both cp67 and cms had
been logical fba ... even when using ckd dasd (which effectively hasn't
changed .. and subsequently made it trivial to support real fba (3310 &
3370) devices.

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

Re: Flash memory arrays

[R.S.]

Vernooy, C.P. - SPLXM wrote:

"Chase, John" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]
m>...

-Original Message-
From: IBM Mainframe Discussion List On Behalf Of McKown, John

Only z/OS is stuck on ECKD formatted DASD. z/VM and z/VSE can 
both run on FBA. z/LINUX can run on FBA and/or on SAN/SCSI 
DASD. I think that the latest z/VM can also run on SAN/SCSI 
connected DASD as well. z/OS remains the hold out. For 
whatever reason that may be. 

Weaning z/OS from (E)CKD would likely be such a monumental change as

to

require that it be done at a version boundary and provide perhaps an
entire version life-cycle to complete. 


"Who knows" how much non-IBM code would have to be revisited during

the

transition?  More than a few CBT utilities would be relegated to the
dustbin of history.

It's probably also true that the longer such a transition is delayed,
the less likely it is to be attempted.

-jc-


What I miss in previous arguments is what is wrong with ECKD. 

Let me try:
- space waste when writing short blocks
- space waste when writing short files
- limited volume capacity
- limited record size and block size
- incompatibility between unlike devices



Why should a large bunch of
software be rewriten? By the time the conversion has finished, FBA will
probably be replaced by something different.
That's what I asked about. However I'm not sure about answer. IMHO it 
could be reasonable to rewrite the software to use "something different".



Remember: the break-pedal in your car still emulate the pedal on the
post coaches that pushed a chunk of wood against the outside of the
wheel. The real breaking infrastructure is hidden under the hood
(literally in this case). Who wants to the pedal to be rewritten to
control hydrolic breaksystems, with ABS control etc.?
Bad example. The break still operates in the same way. It was only 
enhanced. It's like very old DASD and new shining 1TB WD Caviar.
However flash memory works in completely different manner, although it 
can emulate rotating platters. Maybe elimination of this emulation would 
give some advantages, maybe those advantages are worth of rewriting the 
code (which can be evolutionary and long-term).


Just questions.

--
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.2007 r. kapita zakadowy BRE Banku SA (w caoci 
opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego 
podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 
r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 
z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone.

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

Re: Flash memory arrays

[Clark Morris]

On 17 Jan 2008 06:49:09 -0800, in bit.listserv.ibm-main you wrote:

>> -Original Message-
>> From: IBM Mainframe Discussion List On Behalf Of McKown, John
>> 
>> Only z/OS is stuck on ECKD formatted DASD. z/VM and z/VSE can 
>> both run on FBA. z/LINUX can run on FBA and/or on SAN/SCSI 
>> DASD. I think that the latest z/VM can also run on SAN/SCSI 
>> connected DASD as well. z/OS remains the hold out. For 
>> whatever reason that may be. 
>
>Weaning z/OS from (E)CKD would likely be such a monumental change as to
>require that it be done at a version boundary and provide perhaps an
>entire version life-cycle to complete. 

There obviously would have to be a co-existence period where both
architectures are supported.  VSAM is already FBA as are all of the
newer data architectures.  The challenges will be spool, providing GDG
like capability to the VSAM ESDS, moving PDSE read access to the
Nucleus and deciding how to provide the current SYS1.NUCLEUS
capability.  Maybe the MVS people should humble themselves and talk to
the VM and VSE people to find out how they solved the problem.
>
>"Who knows" how much non-IBM code would have to be revisited during the
>transition?  More than a few CBT utilities would be relegated to the
>dustbin of history.
>
>It's probably also true that the longer such a transition is delayed,
>the less likely it is to be attempted.
>
>-jc-
>

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

Re: Flash memory arrays

[Anne & Lynn Wheeler]

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


[EMAIL PROTECTED] (McKown, John) writes:
> Only z/OS is stuck on ECKD formatted DASD. z/VM and z/VSE can both run
> on FBA. z/LINUX can run on FBA and/or on SAN/SCSI DASD. I think that the
> latest z/VM can also run on SAN/SCSI connected DASD as well. z/OS
> remains the hold out. For whatever reason that may be. 

there have enormous problems with ckd (and/or trying to get eckd kludge
to compensate for the problems). 

part of it is configuration support ... i.e. device geometry
configuration issues are essentially non-existant in platforms
supporting fba ... especially vis-a-vis all the stuff that is
periodically seen here just on various 3390 model & associated geometry
problems.

another have been speed-matching ... mentioned in previous post
http://www.garlic.com/~lynn/2008b.html#16 Flash memory arrays

and/or latency issues.

in the same time-frame i originally offered FBA support ... i had also
done a channel-extender project for the IMS group in STL. STL was
bursting at the seams ... and they needed to move 300 from the IMS group
to remote off-site location. The problem was that they deemed that the
remote 3270 CMS interactive response was unacceptable compared to what
they were getting from local 3270 CMS within the STL bldg. The solution
was to get CMS local 3270 terminals (for the IMS group) at the remote
site (with local CMS 3270 response) back to the vm370 machines in the
stl bldg. This was accomplished with channel extender (from network
systems corporation) running over T1 (1.5mbit) link.

An unexpected side-effect of this effort ... was not only did the IMS
group continue to get local 3270 CMS interactive response ... but the
channel extender actually improved overall system thruput and
performance. The issue was that these were 168/3033 16 channel systems
... where the 3270 control units and disk controllers were spread out
over common channel pool. The problem was that the 3270 control units
had extremely high channel busy time for the operations they were
performing ... which was interferring with disk thruput activity. The
local 3270 control units were moved to remote site and replaced on local
channel interface with the channel extended boxes ... which had
significantly lower channel busy overhead. The resulting reduced channel
busy overhead getting 3270 control units off local channels, improved
overall system performance by 10-15percent.

Basically, I could pretty trivially support almost any kind of direct
channel controller at the remote site ... except for count-key-dasd ...
even tho the associated "speed-matching" mismatch for the channel
extender was much larger than the factor of two times that later was
being dealt with trying to attach 3mbyte 3380s on 370 1.5mbyte channels
... aka channel-extender local 1mbyte devices running over 1.5mbit T1
connection ... nearly a factor of ten speed-match difference compared to
the factor of two speed-match difference for 3880 speed-match
implementation. ... again, past posts mentioning fba, ckd, etc
http://www.garlic.com/~lynn/subtopic.html#dasd

getting local 3270 cms terminal thruput for the IMS group was one
of the early efforts in the hsdt effort
http://www.garlic.com/~lynn/subnetwork.html#hsdt

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

Re: Flash memory arrays

[(IBM Mainframe Discussion List)]

 
 
In a message dated 1/17/2008 10:01:17 A.M. Central Standard Time,  
[EMAIL PROTECTED] writes:
>Does the ECKD dasd give us the ability to have fixed record lengths and  
blocksizes?
 
Yes, but not automatically.  Fixed record lengths and block sizes  must be 
imposed by the software first.
 
Bill  Fairchild
Franklin, TN





**Start the year off right.  Easy ways to stay in shape. 
http://body.aol.com/fitness/winter-exercise?NCID=aolcmp0030002489

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

Re: Flash memory arrays

[Eric Bielefeld]

I'm curious about something.  Does the ECKD dasd give us the ability to have 
fixed record lengths and blocksizes?  Can you do that in Unix and Windows?  

It just seems to me that the file system in z/OS compared to the file systems 
on Unix and Windows is a lot more robust.  My feelings may be  predicated on 
the fact that z/OS is what I grew up with.  But then, seeing as everything runs 
on FBA dasd, it seems like a lot of extra overhead to translate back and forth.

Eric Bielefeld

 "McKown wrote: 
> 
> Only z/OS is stuck on ECKD formatted DASD. z/VM and z/VSE can both run
> on FBA. z/LINUX can run on FBA and/or on SAN/SCSI DASD. I think that the
> latest z/VM can also run on SAN/SCSI connected DASD as well. z/OS
> remains the hold out. For whatever reason that may be. 
> 
> --
> John McKown
> Senior Systems Programmer
> HealthMarkets
> Keeping the Promise of Affordable Coverage
> Administrative Services Group
> Information Technology
--
Eric Bielefeld
Systems Programmer
Aviva USA
Des Moines, Iowa
515-645-5153

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

Re: Flash memory arrays

[Vernooy, C.P. - SPLXM]

"Chase, John" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]
m>...
> > -Original Message-
> > From: IBM Mainframe Discussion List On Behalf Of McKown, John
> > 
> > Only z/OS is stuck on ECKD formatted DASD. z/VM and z/VSE can 
> > both run on FBA. z/LINUX can run on FBA and/or on SAN/SCSI 
> > DASD. I think that the latest z/VM can also run on SAN/SCSI 
> > connected DASD as well. z/OS remains the hold out. For 
> > whatever reason that may be. 
> 
> Weaning z/OS from (E)CKD would likely be such a monumental change as
to
> require that it be done at a version boundary and provide perhaps an
> entire version life-cycle to complete. 
> 
> "Who knows" how much non-IBM code would have to be revisited during
the
> transition?  More than a few CBT utilities would be relegated to the
> dustbin of history.
> 
> It's probably also true that the longer such a transition is delayed,
> the less likely it is to be attempted.
> 
> -jc-

What I miss in previous arguments is what is wrong with ECKD. We can
attach every device to it, they all talk (emulated) ECKD to the host, no
matter what organization they have inside. Why should a large bunch of
software be rewriten? By the time the conversion has finished, FBA will
probably be replaced by something different.

Remember: the break-pedal in your car still emulate the pedal on the
post coaches that pushed a chunk of wood against the outside of the
wheel. The real breaking infrastructure is hidden under the hood
(literally in this case). Who wants to the pedal to be rewritten to
control hydrolic breaksystems, with ABS control etc.?

Kees.
**
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain
confidential and privileged material intended for the addressee
only. If you are not the addressee, you are notified that no part
of the e-mail or any attachment may be disclosed, copied or
distributed, and that any other action related to this e-mail or
attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately
by return e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries
and/or its employees shall not be liable for the incorrect or
incomplete transmission of this e-mail or any attachments, nor
responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
Dutch Airlines) is registered in Amstelveen, The Netherlands, with
registered number 33014286 
**

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

Re: Flash memory arrays

[Anne & Lynn Wheeler]

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


[EMAIL PROTECTED] (Clark Morris) writes:
> Au contraire.  My USB key is FBA formatted in 512 byte sectors (I
> think it is one of the FAT formats available to Win 98 or earlier).
> FBA is oriented to both disk and even more so, solid state.  There are
> a number of limitations in CKD that will be painful to eliminate and
> even if they are we are still left with a KLUDGE for which the phase
> out should have started 25 years ago.

re:
http://www.garlic.com/~lynn/2008b.html#15 Flash memory arrays

i offered well over 25 yrs ago (i.e. 3370 fba). The response i got back
from the data management group was that (at the time) it would still
cost $26m for training, education, documentation, etc ... even if i
provided fully integrated and tested implementation. the claim was that
i wouldn't be able to show the necessary ROI for the $26m since
customers would just buy the equivalent in fba that they would have ben
spent on ckd (no incremental revenue ... and therefor no ROI). the
issues about life-cycle costs with regard to maintaining ckd (and
life-cycle savings converting to fba) were discounted.

other posts mentioning ckd, fba, multi-track search, etc.
http://www.garlic.com/~lynn/subtopic.html#dasd

one of the first "costs" was trying to get some of the eckd kludge to
work for various things ... like speed-matching buffer (aka 3880
supporting attaching 3380 3mbyte datastreaming, to 168/3033 1.5mbyte
channels). a couple recent posts on the subject:
http://www.garlic.com/~lynn/2007e.html#40 FBA rant
http://www.garlic.com/~lynn/2007o.html#54 mainframe performance, was Is a RISC 
chip more expensive?

including this old email reference mentioning problems getting eckd for
speed-matching buffer working
http://www.garlic.com/~lynn/2007e.html#email820907b

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

Re: Flash memory arrays

[R.S.]

Clark Morris wrote:

On 16 Jan 2008 08:57:35 -0800, in bit.listserv.ibm-main you wrote:

EMC announced DMX4 disk system ...without disks. Flash memory would be 
used as a disk module.

Questions/observations:
1. End of magnetic platters ?
2. Another level of virtualization (or translation). Flash device 
emulates disk module. Disk modules are used for CKD emulation.
3. Maybe there is no reason to force MVS to support FBA devices (as it 
would become fading technology), it is more far sighted to implement 
"technology of the future" - natively operated flash memory.


Au contraire.  My USB key is FBA formatted in 512 byte sectors (I
think it is one of the FAT formats available to Win 98 or earlier).
FBA is oriented to both disk and even more so, solid state.  
I dare to disagree. Your USB *emulates* FBA device. Your PC sees 
cylinders, heads and sectors, while flash memory is accessed in 
different way.



There are
a number of limitations in CKD that will be painful to eliminate and
even if they are we are still left with a KLUDGE for which the phase
out should have started 25 years ago.

CKD is not "format of the future". However FBA has shortcomings as well.
Maybe it would be wiser not to switch from CKD to FBA, and swtich to 
"new format" directly.



--
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.2007 r. kapita zakadowy BRE Banku SA (w caoci 
opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego 
podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 
r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 
z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone.

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

Re: Flash memory arrays

[Van Dalsen, Herbie]

IBM is just continuing on their "path of least resistance"... In this
case the resistance would be the cost of the re-coding?


-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Chase, John
Sent: 17 Januarie 2008 02:49 nm
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Flash memory arrays

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of McKown, John
> 
> Only z/OS is stuck on ECKD formatted DASD. z/VM and z/VSE can 
> both run on FBA. z/LINUX can run on FBA and/or on SAN/SCSI 
> DASD. I think that the latest z/VM can also run on SAN/SCSI 
> connected DASD as well. z/OS remains the hold out. For 
> whatever reason that may be. 

Weaning z/OS from (E)CKD would likely be such a monumental change as to
require that it be done at a version boundary and provide perhaps an
entire version life-cycle to complete. 

"Who knows" how much non-IBM code would have to be revisited during the
transition?  More than a few CBT utilities would be relegated to the
dustbin of history.

It's probably also true that the longer such a transition is delayed,
the less likely it is to be attempted.

-jc-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Elavon Financial Services Limited
Registered in Ireland: Number 418442
Registered Office: Block E, 1st Floor, Cherrywood Business Park, Loughlinstown, 
Co. Dublin, Ireland
Directors: Robert Abele (USA), John Collins,  Terrance Dolan (USA),  Pamela 
Joseph (USA), Declan Lynch, John McNally, Malcolm Towlson
Elavon Financial Services Limited, trading as Elavon, is regulated by the 
Financial Regulator

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

Re: Flash memory arrays

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of McKown, John
> 
> Only z/OS is stuck on ECKD formatted DASD. z/VM and z/VSE can 
> both run on FBA. z/LINUX can run on FBA and/or on SAN/SCSI 
> DASD. I think that the latest z/VM can also run on SAN/SCSI 
> connected DASD as well. z/OS remains the hold out. For 
> whatever reason that may be. 

Weaning z/OS from (E)CKD would likely be such a monumental change as to
require that it be done at a version boundary and provide perhaps an
entire version life-cycle to complete. 

"Who knows" how much non-IBM code would have to be revisited during the
transition?  More than a few CBT utilities would be relegated to the
dustbin of history.

It's probably also true that the longer such a transition is delayed,
the less likely it is to be attempted.

-jc-

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

Re: Flash memory arrays

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Clark Morris
> Sent: Thursday, January 17, 2008 8:23 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Flash memory arrays
> 
> 
> On 16 Jan 2008 08:57:35 -0800, in bit.listserv.ibm-main you wrote:
> 
> >EMC announced DMX4 disk system ...without disks. Flash 
> memory would be 
> >used as a disk module.
> >Questions/observations:
> >1. End of magnetic platters ?
> >2. Another level of virtualization (or translation). Flash device 
> >emulates disk module. Disk modules are used for CKD emulation.
> >3. Maybe there is no reason to force MVS to support FBA 
> devices (as it 
> >would become fading technology), it is more far sighted to implement 
> >"technology of the future" - natively operated flash memory.
> 
> Au contraire.  My USB key is FBA formatted in 512 byte sectors (I
> think it is one of the FAT formats available to Win 98 or earlier).
> FBA is oriented to both disk and even more so, solid state.  There are
> a number of limitations in CKD that will be painful to eliminate and
> even if they are we are still left with a KLUDGE for which the phase
> out should have started 25 years ago.

Only z/OS is stuck on ECKD formatted DASD. z/VM and z/VSE can both run
on FBA. z/LINUX can run on FBA and/or on SAN/SCSI DASD. I think that the
latest z/VM can also run on SAN/SCSI connected DASD as well. z/OS
remains the hold out. For whatever reason that may be. 

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it. 

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

Re: Flash memory arrays

[Clark Morris]

On 16 Jan 2008 08:57:35 -0800, in bit.listserv.ibm-main you wrote:

>EMC announced DMX4 disk system ...without disks. Flash memory would be 
>used as a disk module.
>Questions/observations:
>1. End of magnetic platters ?
>2. Another level of virtualization (or translation). Flash device 
>emulates disk module. Disk modules are used for CKD emulation.
>3. Maybe there is no reason to force MVS to support FBA devices (as it 
>would become fading technology), it is more far sighted to implement 
>"technology of the future" - natively operated flash memory.

Au contraire.  My USB key is FBA formatted in 512 byte sectors (I
think it is one of the FAT formats available to Win 98 or earlier).
FBA is oriented to both disk and even more so, solid state.  There are
a number of limitations in CKD that will be painful to eliminate and
even if they are we are still left with a KLUDGE for which the phase
out should have started 25 years ago.
>
>
>Disclaimer: IMHO it is on topic. DMX4 is mainframe array.
>-- 
>Radoslaw Skorupka
>Lodz, Poland

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

Re: Flash memory arrays

[Ron Hawkins]

Ed,

Later models would save the contents of the SSD to disk. No different to
writes in cache in current disk arrays. In a power failure it's battery
backed, destaged, or both.

Ron

> You have hit it the head. We had a unit that emulated a 2305 (don't
> remember which model) it worked well . except when we had a power
> failure. Then at power up *EVERYTHING* was gone. We had to analyze it

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

Re: Flash memory arrays

[Anne & Lynn Wheeler]

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

[EMAIL PROTECTED] (Ed Gould) writes:
> You have hit it the head. We had a unit that emulated a 2305 (don't
> remember which model) it worked well . except when we had a power
> failure. Then at power up *EVERYTHING* was gone. We had to analyze it
> and put a vtoc back and then redefine PLPA and then IPL again to get
> the system to use it. I think my hair started to go gray because of
> the blasted machine. It was gone within a month.
>
> Oh, yes we had an application that *NEEDED* (well at least they
> thought they did) the 2305. In the month that it was going out, we
> got the applications people to use  VIO. They were extremely happy
> and that was the end of the beast. If the machine survives through a
> power blink then I would reconsider it but it would take a lot to do
> so.

there were STC solid state ... and for internal datacenters there was
something referred to as a "1655" (several hundred) from a vendor that
was using memory chips that had failed normal acceptance tests ... but
could still be used in this manner. they were most commingly used as
paging devices and so not surviving power failure wasn't an issue.

they were surplanted by 3090 expanded storage (and later really large
real memory) and disk controller electronic caches (initially 3880-11
and 3880-13).

old email discussing 2305, 1655, and stc electronic disk comparison:
http://www.garlic.com/~lynn/2007e.html#email820805

old posts mentioning 1655, 3880-11, and/or 3880-13:
http://www.garlic.com/~lynn/2000d.html#13 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2001.html#18 Disk caching and file systems.  Disk 
history...people forget
http://www.garlic.com/~lynn/2001c.html#17 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001d.html#68 I/O contention
http://www.garlic.com/~lynn/2001l.html#53 mainframe question
http://www.garlic.com/~lynn/2001l.html#54 mainframe question
http://www.garlic.com/~lynn/2001l.html#63 MVS History (all parts)
http://www.garlic.com/~lynn/2002.html#31 index searching
http://www.garlic.com/~lynn/2002d.html#55 Storage Virtualization
http://www.garlic.com/~lynn/2002i.html#17 AS/400 and MVS - clarification please
http://www.garlic.com/~lynn/2002l.html#40 Do any architectures use instruction 
count instead of timer
http://www.garlic.com/~lynn/2002o.html#3 PLX
http://www.garlic.com/~lynn/2002o.html#52 ``Detrimental'' Disk Allocation
http://www.garlic.com/~lynn/2003b.html#7 Disk drives as commodities. Was Re: 
Yamhill
http://www.garlic.com/~lynn/2003b.html#15 Disk drives as commodities. Was Re: 
Yamhill
http://www.garlic.com/~lynn/2003b.html#17 Disk drives as commodities. Was Re: 
Yamhill
http://www.garlic.com/~lynn/2003c.html#55 HASP assembly: What the heck is an 
MVT ABEND 422?
http://www.garlic.com/~lynn/2003f.html#5 Alpha performance, why?
http://www.garlic.com/~lynn/2003m.html#39 S/360 undocumented instructions?
http://www.garlic.com/~lynn/2004d.html#73 DASD Architecture of the future
http://www.garlic.com/~lynn/2004e.html#3 Expanded Storage
http://www.garlic.com/~lynn/2004g.html#13 Infiniband - practicalities for small 
clusters
http://www.garlic.com/~lynn/2004g.html#17 Infiniband - practicalities for small 
clusters
http://www.garlic.com/~lynn/2004g.html#18 Infiniband - practicalities for small 
clusters
http://www.garlic.com/~lynn/2004g.html#20 Infiniband - practicalities for small 
clusters
http://www.garlic.com/~lynn/2004l.html#29 FW: Looking for Disk Calc program/Exec
http://www.garlic.com/~lynn/2005e.html#5 He Who Thought He Knew Something About 
DASD
http://www.garlic.com/~lynn/2005m.html#28 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005m.html#30 Massive i/o
http://www.garlic.com/~lynn/2005r.html#51 winscape?
http://www.garlic.com/~lynn/2005t.html#50 non ECC
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006c.html#1 Multiple address spaces
http://www.garlic.com/~lynn/2006c.html#8 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006c.html#46 Hercules 3.04 announcement
http://www.garlic.com/~lynn/2006e.html#45 using 3390 mod-9s
http://www.garlic.com/~lynn/2006e.html#46 using 3390 mod-9s
http://www.garlic.com/~lynn/2006i.html#41 virtual memory
http://www.garlic.com/~lynn/2006j.html#11 The Pankian Metaphor
http://www.garlic.com/~lynn/2006j.html#14 virtual memory
http://www.garlic.com/~lynn/2006k.html#57 virtual memory
http://www.garlic.com/~lynn/2006r.html#36 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006s.html#30 Why magnetic drums was/are worse than 
disks ?
http://www.garlic.com/~lynn/2006s.html#32 Why magnetic drums was/are worse than 
disks ?
http://www.garlic.com/~lynn/2006v.html#31 MB to Cyl Conversion
http://www.garlic.com/~lynn/2006y.html#35 The Future of CPUs: What's After 
Multi-Core?
http://www.garlic.com/~lynn/2007c.html#0 old discussion of disk contr

Re: Flash memory arrays

[Ed Gould]

On Jan 16, 2008, at 11:02 AM, Bob Shannon wrote:

EMC announced DMX4 disk system ...without disks. Flash memory  
would be

used as a disk module


Simply back to the future again. Solid state devices were prevalent  
twenty or so years ago. Still, with today's technology it makes  
sense. Hopefully it will provide both better performance (no seek  
time) and better reliability (no moving parts).



Bob,

You have hit it the head. We had a unit that emulated a 2305 (don't  
remember which model) it worked well . except when we had a power  
failure. Then at power up *EVERYTHING* was gone. We had to analyze it  
and put a vtoc back and then redefine PLPA and then IPL again to get  
the system to use it. I think my hair started to go gray because of  
the blasted machine. It was gone within a month.


Oh, yes we had an application that *NEEDED* (well at least they  
thought they did) the 2305. In the month that it was going out, we  
got the applications people to use  VIO. They were extremely happy  
and that was the end of the beast. If the machine survives through a  
power blink then I would reconsider it but it would take a lot to do so.


Ed
 


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

Re: Flash memory arrays

[Ron Hawkins]

B2F especially when you look at Moshe and EMC's history.. What goes around
comes around.

But I don't expect they'll be making furniture again :-)

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Bob Shannon
> Sent: Wednesday, January 16, 2008 9:02 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: [IBM-MAIN] Flash memory arrays
> 
> > EMC announced DMX4 disk system ...without disks. Flash memory would
> be
> > used as a disk module
> 
> Simply back to the future again. Solid state devices were prevalent
> twenty or so years ago. Still, with today's technology it makes sense.
> Hopefully it will provide both better performance (no seek time) and
> better reliability (no moving parts).
> 
> Bob Shannon
> Rocket Software
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Flash memory arrays

[Bob Shannon]

> EMC announced DMX4 disk system ...without disks. Flash memory would be
> used as a disk module

Simply back to the future again. Solid state devices were prevalent twenty or 
so years ago. Still, with today's technology it makes sense. Hopefully it will 
provide both better performance (no seek time) and better reliability (no 
moving parts).

Bob Shannon
Rocket Software

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

Flash memory arrays

[R.S.]

EMC announced DMX4 disk system ...without disks. Flash memory would be 
used as a disk module.

Questions/observations:
1. End of magnetic platters ?
2. Another level of virtualization (or translation). Flash device 
emulates disk module. Disk modules are used for CKD emulation.
3. Maybe there is no reason to force MVS to support FBA devices (as it 
would become fading technology), it is more far sighted to implement 
"technology of the future" - natively operated flash memory.



Disclaimer: IMHO it is on topic. DMX4 is mainframe array.
--
Radoslaw Skorupka
Lodz, Poland


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

Sąd Rejonowy dla m. st. Warszawy 
XII Wydział Gospodarczy Krajowego Rejestru Sądowego, 
nr rejestru przedsiębiorców KRS 025237

NIP: 526-021-50-88
Według stanu na dzień 01.01.2007 r. kapitał zakładowy BRE Banku SA (w całości 
opłacony) wynosi 118.064.140 zł. W związku z realizacją warunkowego 
podwyższenia kapitału zakładowego, na podstawie uchwał XVI WZ z dnia 21.05.2003 
r., kapitał zakładowy BRE Banku SA może ulec podwyższeniu do kwoty 118.760.528 
zł. Akcje w podwyższonym kapitale zakładowym będą w całości opłacone.

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