×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Just my 2¢ on "objects not saved." Some people who implement SWA get caught up in trying to save every single object on the system, when in fact there are many that do not need to be saved. Two obvious (to me) examples are HTTP server logs and Performance data. These types of objects are not normally needed in a DR situation and automatically get re-created if necessary. I have always omitted the QMPGDATA or QPFRDATA libraries from daily SWA saves because a.) that data won't do you any good if you restore to a system that doesn't exactly match your production system and b.) who wants to waste the time needed to restore 10 or 20GB of performance data when you actually are in a DR situation?
These can easily be omitted from the save or the "objects not saved" messages can safely be ignored but you will need to know the difference between objects that can be ignored and objects that can't. As far as your data queues go I can't say, but the question I would ask is: Can they easily be re-created or do they HAVE to be restored? If they do have to be restored can they be restored from a monthly backup or does it have to be from the daily?
Regards,
Scott Ingvaldson
Senior IBM Support Specialist
Midwest Region Data Center
Fiserv.
-----Original Message-----
From: lgoodbar@xxxxxxxxxxxxxx [mailto:lgoodbar@xxxxxxxxxxxxxx]
Sent: Tuesday, September 01, 2009 12:20 PM
To: midrange-l@xxxxxxxxxxxx
Subject: RE: Using BRMS for SWA and save to save file?
Thanks Scott, John, and Pete! I was thinking that SWA might be the best solution, then I remembered Rob's recent post on "poorly implemented"
SWA (objects not saved, who needs a checkpoint, etc.).
The daily save signs off all interactive users (part of the backup
policy) but the system is not in a restricted state. Most of the time the only objects not saved are three data queues used by the ERP package. An ENDSBS to the dedicated subsystem monitoring the queues would fix them as well.
Our production people are good about working with us and the backup window, but recently they've had more trucks scheduled to ship and encroaching on our window.
Totally agree with disk utilization and potential slowdowns using virtual tape or SAVFs. Will look to continue saving directly to tape.
I'll give the SWA sections a good read!
Thanks,
Loyd
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Ingvaldson, Scott
Sent: Tuesday, September 01, 2009 10:57 AM
To: Midrange Systems Technical Discussion
Subject: RE: Using BRMS for SWA and save to save file?
But most likely SWA will get you all the uptime you need. The "right"
way to implement SWA is the way that makes sense for your business, but since you already have two hours of daily downtime taking 15 minutes (more likely 5) to establish the sync point should not be too difficult.
As an Amazon Associate we earn from qualifying purchases.
This thread ...
Re: Using BRMS for SWA and save to save file?, (continued)
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.