-----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Wayne Driscoll Sent: Thursday, July 03, 2008 3:34 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Another difference between platforms...
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? 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