The E4 (names Sense I/O Type) would tell you, with only one I/O request, the DASD controller and device model numbers. From this info you would then know how many tracks were on a cylinder, how many bytes were on a track, and what kind of squirrely functions to use in computing the effective track size of a DASD record with any given key length and data length.
Or you could find out this info yourself the hard way. Try to do a seek track command to track 29 on cylinder 0. If it worked, then you knew the device had at least 30 tracks per cylinder, which meant it had to be a 3350. If track 29 failed, then try track 18. If that worked, then the device had between 19 and 29 tracks per cylinder, so it was a 3330 or a 2314. Etc.. By changing the values for a seek track and/or a seek cylinder, you could eventually deduce the device and controller types. I assume this is how IBM did it before they had debugged the E4 command. Of course, you also had to remember that there was one 230x DASD that IBM made that had around 96 or 100 "tracks" per cylinder (a drum, maybe?), so you would want to check for that device type first. Bill Fairchild Rocket Software -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Anne & Lynn Wheeler Sent: Monday, August 02, 2010 9:41 AM To: [email protected] Subject: Re: History of Hard-coded Offsets [email protected] (Rick Fochtman) writes: > Most of those geometry-related "System Services" didn't exist! :-) E4 channel command (extended sense) was introduced to start providing device characteristics (theoritically starting to minimize the amount of device information that had to be provided in system/IO sysgens). Then, FBA further drastically simplified (compared to CKD) ... eliminating having to know/specify anything ... recent comment http://www.garlic.com/~lynn/2010l.html#76 History of Hard-code Offsets Recently there has been some issues/nits related to FBA ... regarding efforts to migrate from 512 byte to 4096 byte sectors (which might be the closest analogy to all the CKD transitions) ... aka things like Linux Not Fully Prepared for 4096-Byte Sector Hard Drives http://www.osnews.com/story/22872/Linux_Not_Fully_Prepared_for_4096-Byte_Sector_Hard_Drives but it is the first major change since the 70s (other than some transitions involving total number of blocks/sectors supported). wiki page discussing some of the issues: http://en.wikipedia.org/wiki/Advanced_Format a lot of the discussion (aligned & multiples) in the above is almost identical to issues I faced when I did the page-mapped enhancements to cp67/cms filesystem (nearly 40yrs ago) ... some past posts http://www.garlic.com/~lynn/submain.html#mmap -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- 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
