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" <[email protected]> >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 [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
