Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
Yes, BDAM can use the key portion, however faster access was achived if the lookup value for finding a record was mapped by some calculation into CCHHR; otherwise BDAM's performance was not much better than ISAM's There was an article in Datamation (back when it was a good magazine) called The Hidden Speed of ISAM. Anyone still have a copy? There's a rhyme in German: ISAM ist langsam, VSAM is grausam. ISAM is slow, VSAM is horrible. And yes - in German it both scans and rhymes. -- Phil Payne http://www.isham-research.com +44 7785 302 803 +49 173 6242039
Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
For VSE with FBA devices, the VTOC wasn't keyed as it was on a CKD device; it's been years since I used a 3310 or a 3370; so I'm stretching here; but the if I remember correctly, the vtoc was built on a VSAM KSDS model. Yes, BDAM can use the key portion, however faster access was achived if the lookup value for finding a record was mapped by some calculation into CCHHR; otherwise BDAM's performance was not much better than ISAM's It is my understanding that most of the PDS/PDSE support in MVS nowadays is based on VSAM ESDS structures; with the changes for Systems Managed Storage support, DASD is actually viewed as VSAM space. A release or two back in OS/390 the ability to share packs between VSE MVS went away; the OS/390 VTOCs weren't structured the same way as they use to be, and VSE would no longer be able to access them. Garry E. Ward Senior Software Specialist Maritz Research Automotive Research Group 419-725-4123 -Original Message- From: John Summerfield [mailto:[EMAIL PROTECTED]] Sent: Friday, April 19, 2002 1:27 PM To: [EMAIL PROTECTED] Subject: Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?] The only folks that would really be in trouble are those who wrote code to mathmaticaly map some data value into a CCHHRR value, which is what Direct Access Method originally did. These people would have to come up with a way to convert their key value to a relative record number instead of a CCHHR VTOCs use keyed records, and AFAIK it's possible to share disks between DOS and OS families (heard of the DOS contamination bit?). The file I had in mind in the example below is the VTOC. BDAM can use keyed records. Partitioned dataset directories are keyed files. Or have these things changed over the years? For VSAM it isn't that bad; and Relative Byte Address is a Relative Byte Address, on FBA it's a little easier becasue you just map from the first byte on the pack. VTOC's used the relative record approach instead of an CCHHRR. I was think more of the CKD disks' ability to store and recognise keys as distinct from data. Mapping CCHR address is just a matter of simple arithmetic and bothers me not at all. However, if my program logic is to search the file for the record with the key accounts.sourcelib and read the data, then I don't see how this maps to the FBA architecture. Unless the drives have that capability. -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Note: mail delivered to me is deemed to be intended for me, for my disposition. == If you don't like being told you're wrong, be right! font size=1Confidentiality Warning: This e-mail contains information int ended only for the use of the individual or entity named above. If the reade r of this e-mail is not the intended recipient or the employee or agent respo nsible for delivering it to the intended recipient, any dissemination, public ation or copying of this e-mail is strictly prohibited. The sender does not a ccept any responsibility for any loss, disruption or damage to your data or c omputer system that may occur while using data contained in, or transmitted w ith, this e-mail. If you have received this e-mail in error, please immedia tely notify us by return e-mail. Thank you. -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Note: mail delivered to me is deemed to be intended for me, for my disposition. == If you don't like being told you're wrong, be right! font size=1Confidentiality Warning: This e-mail contains information intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, any dissemination, publication or copying of this e-mail is strictly prohibited. The sender does not accept any responsibility for any loss, disruption or damage to your data or computer system that may occur while using data contained in, or transmitted with, this e-mail. If you have received this e-mail in error, please immediately notify us by return e-mail. Thank you.
Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
The CKD's ability to handle separate keys from the data was born in the days of ISAM, when an indexed file was literally written with the index on the track. If the ISAM file was unblocked, then each record had the key for that record written first, then the data; an index search was data at the channel program level. If it was blocked, then the highest key in the block became the key written on the track. In this case, the channel program looked for a higher than key and the ISAM routines read that block and pulled it apart looking for the correct record. The separate index in ISAM was simply used to store the highest key in each cylinder, so that the channel program could be tailored to scan the keys in only one cylinder at a time, rather than trying to hunt across multiple cylinders. Also why ISAM files were preferred to be placed on cylinder boundaries A great technique for the 1960s; but in today's environment, not such a good idea. A VSAM Key Sequence file does not use the key part of the CKD; everything is in relative CI format, with the index part being nothing more than a collection of CIs with keys RBAs to where the record is located. Maps to FBA like a charm. The only folks that would really be in trouble are those who wrote code to mathmaticaly map some data value into a CCHHRR value, which is what Direct Access Method originally did. These people would have to come up with a way to convert their key value to a relative record number instead of a CCHHR Garry E. Ward Senior Software Specialist Maritz Research Automotive Research Group 419-725-4123 -Original Message- From: John Summerfield [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 18, 2002 10:13 PM To: [EMAIL PROTECTED] Subject: Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?] For VSAM it isn't that bad; and Relative Byte Address is a Relative Byte Address, on FBA it's a little easier becasue you just map from the first byte on the pack. VTOC's used the relative record approach instead of an CCHHRR. I was think more of the CKD disks' ability to store and recognise keys as distinct from data. Mapping CCHR address is just a matter of simple arithmetic and bothers me not at all. However, if my program logic is to search the file for the record with the key accounts.sourcelib and read the data, then I don't see how this maps to the FBA architecture. Unless the drives have that capability. -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Note: mail delivered to me is deemed to be intended for me, for my disposition. == If you don't like being told you're wrong, be right! font size=1Confidentiality Warning: This e-mail contains information intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, any dissemination, publication or copying of this e-mail is strictly prohibited. The sender does not accept any responsibility for any loss, disruption or damage to your data or computer system that may occur while using data contained in, or transmitted with, this e-mail. If you have received this e-mail in error, please immediately notify us by return e-mail. Thank you.
Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
Has anyone tried iSCSI with S/390 ? Yes. The limiting factor is currently network adapter performance, but it does work for everything except IPL (duh). We're doing a bit more stress testing internally before letting it loose on the world. -- db
Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
Really? As in talking to existing Fiber Channel[1] disk arrays that speak FC-SCSI? and/or via FC-SCSI bridges to random SCSI devices? Where can I find out more? I used to work on FC-attached storage array systems at Compaq... Yup. They were demonstrating it at LinuxWorld in NYC in January. Burning CDs from the z800. -- db
Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
The only folks that would really be in trouble are those who wrote code to mathmaticaly map some data value into a CCHHRR value, which is what Direct Access Method originally did. These people would have to come up with a way to convert their key value to a relative record number instead of a CCHHR VTOCs use keyed records, and AFAIK it's possible to share disks between DOS and OS families (heard of the DOS contamination bit?). The file I had in mind in the example below is the VTOC. BDAM can use keyed records. Partitioned dataset directories are keyed files. Or have these things changed over the years? For VSAM it isn't that bad; and Relative Byte Address is a Relative Byte Address, on FBA it's a little easier becasue you just map from the first byte on the pack. VTOC's used the relative record approach instead of an CCHHRR. I was think more of the CKD disks' ability to store and recognise keys as distinct from data. Mapping CCHR address is just a matter of simple arithmetic and bothers me not at all. However, if my program logic is to search the file for the record with the key accounts.sourcelib and read the data, then I don't see how this maps to the FBA architecture. Unless the drives have that capability. -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Note: mail delivered to me is deemed to be intended for me, for my disposition. == If you don't like being told you're wrong, be right! font size=1Confidentiality Warning: This e-mail contains information int ended only for the use of the individual or entity named above. If the reade r of this e-mail is not the intended recipient or the employee or agent respo nsible for delivering it to the intended recipient, any dissemination, public ation or copying of this e-mail is strictly prohibited. The sender does not a ccept any responsibility for any loss, disruption or damage to your data or c omputer system that may occur while using data contained in, or transmitted w ith, this e-mail. If you have received this e-mail in error, please immedia tely notify us by return e-mail. Thank you. -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Note: mail delivered to me is deemed to be intended for me, for my disposition. == If you don't like being told you're wrong, be right!
FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
I said (to John): S/390 does also have FBA (fixed block architecture) DASD devices. Sadly, even in the Linux world these are not widely known or used. I maintain that they should be employed heavily and heartily! The benefits are numerous. On Thu, 18 Apr 2002, Jay Maynard wrote: Oh? Like what? Using FBA hardware alleviates the need for the DASD driver to deal with C/H/S translation and work directly with blocks. A UNIX filesystem is a structure placed into a string-of-bytes. Where the hardware looks like a string-of-bytes, it is (theoretically, and I say in practice too) easier for the system to present a linear space since the device is already linear. Why does loop-back mounting work? Why is LBA preferred on PC hardware nowadays? Note that CD can be presented as FBA *today* on some S/390. Specifically, for P/390 (and presumably for Multiprise) a CD image, a .iso file, can be configured to the S/390 as an FBA. The support system may (in my case does) complain about no IBM volser, but it works as expected. I installed SuSE 7.0 directly from CD, as far as the S/390 knew. (It was an ISO image, but the S/390 did not know that it was not a CD copied block-for-block onto a 3370.) So CD could be attached to zSeries neatly if attached as FBA. With FBA, the effect of DDR approaches the effect of the Linux (UNIX) command 'dd' for copying a volume. And what will happen now with SCSI attachment to zSeries? I can only hope that there will NOT be some CKD protocol. It just doesn't seem worth it when FBA is what is really happening. Remember that, these days, most DASD is made up of huge RAID arrays emulating either classic FBA or CKD devices, and the emulation overhead of either is pretty small. Right. And since the actual backing store is fixed-block, I say let that which is presented also be fixed-block and ditch the track, record, count, and key info and the associated work. With CKD, Linux must play the C/H/S game. With emulated CKD, so must the DASD subsystem. Why not let both ends stop faking it?? John said: Back when I was a sysprog we used VS1, and that had no support for FBA devices (I think the 3370 was supported on MVS back then). then Jay said: MVS never has supported any FBA devices. The problem is that the CKD architecture is heavily embedded deep in two critical pieces of the MVS core: program fetch and VTOC processing. I'm not familiar with the details of PDSEs for program fetch, but if load libraries are PDSes, they're still searched by SEARCH KEY CCWs. But VSE and VM both work with FBA DASD. I'm not saying that we should endorse FBA to the demise of MVS. I am only saying that we should endorse FBA to the benefit of Linux, VM, and VSE. And with modern DASD subsystems, it should be no great pain to present either flavor as needed. Let MVS have its CKD. But let the rest have FBA when they want.
Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
[EMAIL PROTECTED] said: Right. And since the actual backing store is fixed-block, I say let that which is presented also be fixed-block and ditch the track, record, count, and key info and the associated work. With CKD, Linux must play the C/H/S game. With emulated CKD, so must the DASD subsystem. Why not let both ends stop faking it?? VSAM, Partitioned Datasets and VTOCs for starters all depend on keyed records. How well do these perform on VSE on FBA devices? With the emulation the stuffing around needed is done off the host CPU - I don't care a lot whether it's the channel or controller or the device itself. I presume that for the FBA devices to be supported directly then it would be done by the host CPU and people tell me it's not that strong. Of course, Linux would get along just fine with FBA devices, so the option to attach sharks etc natively would clearly be of use. -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Note: mail delivered to me is deemed to be intended for me, for my disposition. == If you don't like being told you're wrong, be right!
Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
Note that CD can be presented as FBA *today* on some S/390. Specifically, for P/390 (and presumably for Multiprise) a CD image, a .iso file, can be configured to the S/390 as an FBA. Yup. Works on a Multiprise too, as Dave Jones can attest. Adam
Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
On Thu, Apr 18, 2002 at 12:44:13PM -0500, Adam Thornton wrote: Note that CD can be presented as FBA *today* on some S/390. Specifically, for P/390 (and presumably for Multiprise) a CD image, a .iso file, can be configured to the S/390 as an FBA. Yup. Works on a Multiprise too, as Dave Jones can attest. And, for that matter, on Hercules. (Which is one reason I want .iso files to install Linux/390 from...it can't be any slower than an FTP install over a Hercules CTC.)
Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
On Thu, Apr 18, 2002 at 10:44:39AM -0500, Rick Troth wrote: And what will happen now with SCSI attachment to zSeries? I can only hope that there will NOT be some CKD protocol. It just doesn't seem worth it when FBA is what is really happening. Probably so, at least for VM, VSE, and Linux. With CKD, Linux must play the C/H/S game. With emulated CKD, so must the DASD subsystem. Why not let both ends stop faking it?? Mainframers - at least MVS types - aren't used to thinking that way. A sile as a stream of bytes is completely alien to them. But VSE and VM both work with FBA DASD. VM has always used a fixed-block structured filesystem internally anyway, so it was just a matter of changing block sizes. I can't speak to VSE, never having dealt with it. I'm not saying that we should endorse FBA to the demise of MVS. I am only saying that we should endorse FBA to the benefit of Linux, VM, and VSE. And with modern DASD subsystems, it should be no great pain to present either flavor as needed. Let MVS have its CKD. But let the rest have FBA when they want. I believe that's the case now. There's one benefit for Hercules users of using CKD instead of FBA: compressed DASD images. Compressed CKD is a big win. Unfortunately, there's no compressed FBA support.
Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
VSE used the FBA devices, 3310 3370s, in the 80s. As of VSE 2.4, 3310s are not listed as supported, and 3370s are listed as data volumes only, not for systems or installation use. There is a 9336 listed under FBA that appearently can still be used as a system or installation device, but I'm not familliar with it. Direct Access files are not support on any FBA device under VSE, which can make life difficult for some database software, like ADABAS Garry E. Ward Senior Software Specialist Maritz Research Automotive Research Group 419-725-4123 -Original Message- From: Jay Maynard [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 18, 2002 2:10 PM To: [EMAIL PROTECTED] Subject: Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?] On Thu, Apr 18, 2002 at 10:44:39AM -0500, Rick Troth wrote: And what will happen now with SCSI attachment to zSeries? I can only hope that there will NOT be some CKD protocol. It just doesn't seem worth it when FBA is what is really happening. Probably so, at least for VM, VSE, and Linux. With CKD, Linux must play the C/H/S game. With emulated CKD, so must the DASD subsystem. Why not let both ends stop faking it?? Mainframers - at least MVS types - aren't used to thinking that way. A sile as a stream of bytes is completely alien to them. But VSE and VM both work with FBA DASD. VM has always used a fixed-block structured filesystem internally anyway, so it was just a matter of changing block sizes. I can't speak to VSE, never having dealt with it. I'm not saying that we should endorse FBA to the demise of MVS. I am only saying that we should endorse FBA to the benefit of Linux, VM, and VSE. And with modern DASD subsystems, it should be no great pain to present either flavor as needed. Let MVS have its CKD. But let the rest have FBA when they want. I believe that's the case now. There's one benefit for Hercules users of using CKD instead of FBA: compressed DASD images. Compressed CKD is a big win. Unfortunately, there's no compressed FBA support.
Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
On Thu, Apr 18, 2002 at 01:04:28PM -0500, Jay Maynard wrote: On Thu, Apr 18, 2002 at 12:44:13PM -0500, Adam Thornton wrote: Note that CD can be presented as FBA *today* on some S/390. Specifically, for P/390 (and presumably for Multiprise) a CD image, a .iso file, can be configured to the S/390 as an FBA. Yup. Works on a Multiprise too, as Dave Jones can attest. And, for that matter, on Hercules. (Which is one reason I want .iso files to install Linux/390 from...it can't be any slower than an FTP install over a Hercules CTC.) Jay Maynard, if the author of hercules wants to have this, I'll reconsider this for the next rawhide upload. :-) At least our 64bit version already has iso images available, so you might already test with those if you have enough RAM/CPU available. cu, Florian La Roche
Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
On Thu, Apr 18, 2002 at 08:27:35PM +0200, Florian La Roche wrote: if the author of hercules wants to have this, I'll reconsider this for the next rawhide upload. :-) That would be nice. Thanks! I must point out, though, that I'm not really the author of Hercules; I'm just the guy who gets to build formal production releases and host the web site and talk about it in public. A lot of other folks have done a lot of work on the package, many of them contributors here. At least our 64bit version already has iso images available, so you might already test with those if you have enough RAM/CPU available. Oh, okkay...didn't know that. I just started a download. Having 30 GB on my laptop has its uses.
Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
For VSAM it isn't that bad; and Relative Byte Address is a Relative Byte Address, on FBA it's a little easier becasue you just map from the first byte on the pack. VTOC's used the relative record approach instead of an CCHHRR. Garry E. Ward Senior Software Specialist Maritz Research Automotive Research Group 419-725-4123 -Original Message- From: John Summerfield [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 18, 2002 1:36 PM To: [EMAIL PROTECTED] Subject: Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?] [EMAIL PROTECTED] said: Right. And since the actual backing store is fixed-block, I say let that which is presented also be fixed-block and ditch the track, record, count, and key info and the associated work. With CKD, Linux must play the C/H/S game. With emulated CKD, so must the DASD subsystem. Why not let both ends stop faking it?? VSAM, Partitioned Datasets and VTOCs for starters all depend on keyed records. How well do these perform on VSE on FBA devices? With the emulation the stuffing around needed is done off the host CPU - I don't care a lot whether it's the channel or controller or the device itself. I presume that for the FBA devices to be supported directly then it would be done by the host CPU and people tell me it's not that strong. Of course, Linux would get along just fine with FBA devices, so the option to attach sharks etc natively would clearly be of use. -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Note: mail delivered to me is deemed to be intended for me, for my disposition. == If you don't like being told you're wrong, be right! font size=1Confidentiality Warning: This e-mail contains information intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, any dissemination, publication or copying of this e-mail is strictly prohibited. The sender does not accept any responsibility for any loss, disruption or damage to your data or computer system that may occur while using data contained in, or transmitted with, this e-mail. If you have received this e-mail in error, please immediately notify us by return e-mail. Thank you.
Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
-Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED]]On Behalf Of Adam Thornton Sent: Thursday, April 18, 2002 10:44 AM To: [EMAIL PROTECTED] Subject: Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?] Note that CD can be presented as FBA *today* on some S/390. Specifically, for P/390 (and presumably for Multiprise) a CD image, a .iso file, can be configured to the S/390 as an FBA. Yup. Works on a Multiprise too, as Dave Jones can attest. Works very well, indeed. Hard part was figuring out how to make an .iso image from the CD, but once that was done, it was a piece of cake. DJ Adam
Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
On Thu, Apr 18, 2002 at 11:17:45PM +0200, Phil Payne wrote: Mainframers - at least MVS types - aren't used to thinking that way. A sile as a stream of bytes is completely alien to them. System types, or application types? We've had RBA since VSAM I - lots of things like DB2 logs are RBA-governed. Systems types that I know of, certainly. They tend to think of files in terms of records, not as a stream of bytes. VSAM ESDSs and the like are definitely in the minority. I can't speak to applications (or, for that matter, IMS and DB2 DBA) folks.
Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
Mainframers - at least MVS types - aren't used to thinking that way. A sile as a stream of bytes is completely alien to them. System types, or application types? We've had RBA since VSAM I - lots of things like DB2 logs are RBA-governed. -- Phil Payne http://www.isham-research.com +44 7785 302 803 +49 173 6242039
Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
On Thursday, 04/18/2002 at 10:44 EST, Rick Troth [EMAIL PROTECTED] wrote: And what will happen now with SCSI attachment to zSeries? I can only hope that there will NOT be some CKD protocol. It just doesn't seem worth it when FBA is what is really happening. As hard as it might be to believe, zSeries operating systems will talk SCSI over Fibre Channel Protocol adapters to SCSI devices. Alan Altmark Sr. Software Engineer IBM z/VM Development
Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
Really? As in talking to existing Fiber Channel[1] disk arrays that speak FC-SCSI? and/or via FC-SCSI bridges to random SCSI devices? Where can I find out more? I used to work on FC-attached storage array systems at Compaq... Has anyone tried iSCSI with S/390 ?
