Our top recommendation for improving DFSMShsm throughput is to use RLS for the HSM CDSes. In nonRLS mode, each HSM locks access to the CDSes while it performs its queued up I/O requests. While that host has the CDSes locked, all other HSM hosts are queueing up their I/O. When a host gets exclusive access, it has to first flush all of its buffers because they are no longer valid and then do a VSAM VERIFY. All of the buffers are then repopulated for the I/Os that have been queued up.
All of that overhead goes away with RLS. Also, Read I/Os are faster, so read intensive workloads like ExpireBV, Secondary Space Management and Audit perform faster, even when there isn't alot of multiple host concurrent workload. The higher the amount of concurrent HSM host activity that you have, the greater the improvement that you'll see with RLS. In z/OS V2R1, DFSMShsm enhanced its error recovery for SMSVSAM server errors. Prior to V2R1, when there was an SMSVSAM server error, HSM lost access to the CDSes, so HSM would just take a fatal abend. (Yes, very ugly, we know). Starting in V2R1, DFSMShsm will hold I/O when it identifies that there is an SMSVSAM error. HSM waits for the SMSVSAM server to restart. After the server restart, HSM will automatically retry all of the I/Os that were held. The only I/Os that have to be failed are Update I/Os after a Read for Update, when the Read for Update was before the server error. Glenn Wilcock DFSMShsm Architect ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
