I think that the ability to have data sets in flash should be run something like the protected key stuff. Create RACF facility to mark a data set as eligible to be managed by/with flash. Gives the sysprog some degree of flexibility and creates a nice general way to manage specific resources.
Rob Schramm Senior Systems Consultant Imperium Group On Thu, Aug 30, 2012 at 1:02 PM, McKown, John <[email protected]> wrote: > From my understanding, the current use *is* for paging, but only when the > paging load (as determined by RSM) becomes "too great" for DASD. > > In my thoughts IPL'ing from the "Flash Express" would be more like how z/VM > implements NSS (Named Shared Segments). Basically, there would be a "logical > name" which you could put in the IPL screen on the HMC. This "logical name" > would basically be SSD storage which contained what is currently in > SYS1.NUCLEUS. Once copied into main memory, control is given to some specific > location and it does whatever is needed to initialize z/OS. All of this > without doing I/O. You would have IPL and NIP "in memory" super fast. I don't > know how difficult this would be to write. The only time you'd write to the > SSD for this process would be after doing maintenance which would affect this > "image" on the SSD. If the z/OS people were very careful, they might even be > able to develop a way to "patch" the "image" and only write "changed" pages > back to the SSD. I.e. if only one module was changed, then only that part of > the SSD which contained that module would be rewriting. From what I've read, > reading an SSD does not wear it out. Only rewriting a location. > > Of course, thinking about this, I wonder why IPL & NIP cannot be improved by > containing the same structure on an IPL volume and loading it from DASD in > the same way. IBM seems very reluctant to change how IPL and NIP actually > work. I don't know why. I'm sure they have their reasons. Perhaps making such > an image possible would simply be too difficult due to what IPL and NIP > currently do and how they do it. Hum, I could look at the MVS 3.8j source to > see what is going on. Perhaps one of the Hercules groups has already done > something like this. > > Also, most SSDs report under capacity. E.g. An SSD rated for 500Gb actually > contains 600 Gb of memory. Also, there is not a 1:1 mapping of a logical > sector number to a physical location on the device. The controller on the > device does "wear leveling" and maintains what is basically a "number of > times written" number for each "section". So when a given logical sector is > written to, the controller dynamically maps it to one of the "least" used > memory locations. This elongates the device's life time. > > -- > John McKown > Systems Engineer IV > IT > > Administrative Services Group > > HealthMarkets(r) > > 9151 Boulevard 26 * N. Richland Hills * TX 76010 > (817) 255-3225 phone * > [email protected] * www.HealthMarkets.com > > Confidentiality Notice: This e-mail message may contain confidential or > proprietary information. If you are not the intended recipient, please > contact the sender by reply e-mail and destroy all copies of the original > message. HealthMarkets(r) is the brand name for products underwritten and > issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake > Life Insurance Company(r), Mid-West National Life Insurance Company of > TennesseeSM and The MEGA Life and Health Insurance Company.SM > > >> >> Could you create IPL and Paging packs on these devices? In case of >> exceeding SSD write limits and the devices fail, you would have >> replace volumes on reqular volumes too. Of course, once you IPL you >> the I/O rate should be fairly low, and paging packs should have very >> low I/O. >> -- >> Mike A Schwab, Springfield IL USA >> Where do Forest Rangers go to get away from it all? >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
