|
These days most of the anomalies that RCLSTG uncovers on our systems would be invisible otherwise. They mostly involve objects left in QTEMP after jobs fail in some spectacular fashion. (Also those re-orgs IBM's database files.) As the system and O/S have advanced over the years I've seen fewer and fewer damaged objects, especially since IBM started including batteries to keep main-store from being wiped out so that MI instructions could be completed. That's not to say that such things can't happen anymore, but these days RCLSTG mostly recovers storage on disk that would otherwise have been lost forever. In our shop we're more suspicious of RCLSTG fouling things up then we are of GO-SAVE-Option-21 completely failing on a damaged object. We don't have operators or a weekend staff so we developed an application that first does a GO-SAVE-Option-21 and then optionally does a RCLSTG (and an IPL when there are PTFs to be applied). We've done a RCLSTG on all of our systems every weekend for 3 1/2 years and we've never had a problem. Only recently we had to stop doing it on one system because the IFS portion of the save was taking 3 hours to complete, but once we resolve this problem we'll start doing RCLSTG again. ----- Original Message ----- From: Dave Snyder To: Midrange Systems Technical Discussion Sent: Tuesday, August 15, 2006 9:01 AM Subject: Reclaim storage question Since the reclaim storage question has come up again, I am wondering if I need to do another soon. The last one I ran was on a previous box (820) and that was on Feb 1, 2004. I have not done one on this new box (520). That was on v5r1 and we are now on v5r3. We have had no abnormal shutdowns since on this 520. We went to this 520 last October so I am not overly concerned about running one, but thought I would ask. Any guidelines or hints as to how often to run one if things are going smooth, as they normally do? Is there are value to watch for a certain threshold to trigger one? Dave *********************************************** PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is for the exclusive use of the addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. *********************************************** -- This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.