On 3 Jul 2008 12:34:49 -0700, in bit.listserv.ibm-main you wrote: >Clark, >As was mentioned, FBA doesn't contain support for RESERVE/RELEASE, causing >RACF/VM and RACF-z/OS to be unable to share a mini-disk resident database. >If you can't share a RACF database, how would any other multi-system sharing >be done?
Is that inherent in FBA? How do multiple VM systems share data now? How is sharing handled on other architectures? > >Wayne Driscoll >Product Developer >NOTE: All opinions are strictly my own. > > > > >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf >Of Clark Morris >Sent: Thursday, July 03, 2008 1:27 PM >To: IBM-MAIN@BAMA.UA.EDU >Subject: Re: Another difference between platforms... > >On 2 Jul 2008 14:23:25 -0700, in bit.listserv.ibm-main you wrote: > >>On Wed, 2 Jul 2008 16:29:50 -0400, Thompson, Steve wrote: >>> >>>Is it CKD vs. FBA? Or is this caused by it being cheaper to emulate CKD >>>on RAID? And then, to continue with 3390 based geometry because it is >>>cheaper to do that than to put out a new DASD device? >> >>What does you mean, Steve? All of the disk drives that everyone makes >>today are FBA. Do you think it would be more expensive for a DASD >>subsystem to emulate FBA using FBA disks than it is to emulate CKD using >FBA >>disks? In fact, I'm pretty sure that every DASD manufacturer today will >let >>you define the logical devices as FBA. >>> >>>IF FBA were such a wonderful thing, why hasn't some company that makes >>>disk units (or did) put out FBA for "MVS" with their own device >>>handler/driver? >> >>What incentive does Seagate or EMC (for example) have to write a lot of >code >>for MVS to support FBA devices? >> >>How would they support using all the undocumented and unsupported >>interfaces that they'd have to use to do it? >> >>How many customers would want to modify MVS with that level of changes >>from a third party vendor? >> >>How much existing code would break? Example: PDS uses TTR in the directory > >>to point to the member. Lots of code depends on TTR. > >The transition would be 5 - 15 years during which both would have to >co-exist. My approach would be as follows: > >1. Replace SYS1.NUCLEUS with an enhanced IPL "track"/disk area. I >don't think any one would care so long as it wasn't more than a couple >of gigabytes. > >2. Improve PDSE so that it is available at IPL and can be used for >ALL IPL data sets. > >3. Add a GDG function to ESDS data sets and allow them in >concatenations. > >4 Enable all of the FBA related access methods on FBA devices. Note >that VSE and VM should have much of the code which could be ported. > >This would allow a migration path, better disk I-O routines because >FBA wouldn't have to be mapped to CKD. > >Clark Morris > >---------------------------------------------------------------------- >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 ---------------------------------------------------------------------- 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
