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
