The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
peter.far...@broadridge.com (Farley, Peter x23353) writes: > PMFJI here, but the facts that Media Manager underlies these "new" (FSVO > "new") file technologies and that Media Manager is page-oriented in its > use of disk storage *could* be taken as a sign (however faint and > clouded) that IBM is (ver-r-ry slowly) moving towards direct support of > FBA in z/OS, perhaps only for those file types supported by MM, perhaps > eventually for all file types. > > Maybe one day a z/OS successor will IPL from the /boot file system? > > Wild and rampant speculation with just two chances of being right (slim > and none, and slim is out to lunch), but interesting thoughts > nonetheless. re: http://www.garlic.com/~lynn/2010d.html#0 PDS vs. PDSE note that industry fixed-block has been 512 byte records ... & CKD emulation on top of underlying fixed-block has its own space inefficiencies (in addition to processing inefficiencies and significantly increased complexity ... with all the associated costs that complexity brings). however, the industry is started moving to larger fixed block size ... (because of the per block physical overhead becoming increasing factor) HDD Manufacturers Moving To 4096-Byte Sectors http://hardware.slashdot.org/story/09/12/28/1422253/HDD-Manufacturers-Moving-To-4096-Byte-Sectors Western Digital's Advanced Format: The 4K Sector Transition Begins http://anandtech.com/storage/showdoc.aspx?i=3691 Western Digital brings Advanced Format to Caviar Green http://techreport.com/discussions.x/18115 misc. past posts mentioning CKD, multi-track searches, etc http://www.garlic.com/~lynn/submain.html#dasd for some historical perspective ... original CMS filesystem was 800byte physical blocks (logical fixed block) mapped on CKD dasd. One of the features was that it provided for "small" record allocation ... i.e. four independent 200byte records within 800byte physical record. This resulted in inefficiency since anytime a 200byte record was involved ... the whole 800byte record had to be read/written (cases where a 200byte physical record could just be written ... would involve first having to read in the 800 byte physical record, update a 200 byte portion and then write out the record). Of course analogous stuff is seen today in real hardware when there is updates in RAID5 environment. In any case, direct support of 512byte fixed-block ... could still mean certain inefficiencies for smaller records ... either optimize for space (say allowing mapping of four 128byte blocks in single physical block) or transfer (& "waste" the ondisk space). -- 42yrs virtualization experience (since Jan68), online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
