× 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.



You probably have more than most of the "one off" PTF installs, but our policy is to install PTFs on the target system first. Then we know it didn't cause a major failure and can be installed on production. Therefore, target HA system is always equal or higher on PTFs and can easily be used for restore. Though if there is a problem that affects a production app that wasn't really running on the target, well.... update resume?
--
Sean Porterfield
________________________________________
From: midrange-l-bounces@xxxxxxxxxxxx [midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx [rob@xxxxxxxxx]
Sent: Friday, October 02, 2009 17:41
To: Midrange Systems Technical Discussion
Subject: Re: Alternatives to Iron Mountain

Ok, back to the beginning...
We were discussing why you need to have full system saves of your primary
system offsite. If the primary dies, along with the tape, you'll have to
catch back up on ptf's. I do agree that ptf's should be 'somewhat' in
sync. I say somewhat because you shouldn't IPL both machines at the same
time.

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From:
"Bob P. Roche" <BRoche@xxxxxxxxxxxxxxxxx>
To:
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date:
10/02/2009 05:28 PM
Subject:
Re: Alternatives to Iron Mountain
Sent by:
midrange-l-bounces@xxxxxxxxxxxx



i don't know about all of those, but you should put the ptf's on your HA
system yourself as part of standard system maintenance. not do it when you

fail over.



From:
<rob@xxxxxxxxx>
To:
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date:
10/02/2009 03:49 PM
Subject:
Re: Alternatives to Iron Mountain
Sent by:
<midrange-l-bounces@xxxxxxxxxxxx>



The HA process does NOT keep both boxes identical. Think about it. Would


they have the same
- IP addresses
- Same system name
- same WRKRDBDIRE
- same network attributes
- same routing

They also will not have the same vendor keys. These are often tied into
serial number, processor and what not. Many times a vendor will have a
technote that says to omit data area x in library y from your HA software.

Do you really expect a change to WRKRDBDIRE on one system to be propagated


over to the other system? No. User profiles, user libraries and so on,
yes. I don't even expect a HA solution to keep DSPPTF in sync. How would


you expect it to?

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From:
BMay@xxxxxxxxx
To:
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date:
10/02/2009 04:28 PM
Subject:
Re: Alternatives to Iron Mountain
Sent by:
midrange-l-bounces@xxxxxxxxxxxx



Rob, I think you are missing what he is saying. If your HA process keeps
both boxes IDENTICAL and you back both up to tape every night, there is no



need for offsite storage for either set of tapes because they are already
in separate locations and should be identical.

So if something happened to your tapes in your primary location, you would



have an identical set of tapes you could retrieve from the other location.






Brian May
Project Lead
Management Information Systems
Garan, Incorporated
Starkville, Mississippi

Young i Professionals
http://www.youngiprofessionals.com



rob@xxxxxxxxx
Sent by: midrange-l-bounces@xxxxxxxxxxxx
10/02/2009 03:00 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc

Subject
Re: Alternatives to Iron Mountain






Tell you what, you sound very confident of your HA process. Next time you




do a switch, do a full system backup of your primary machine. Then use
the I_BASE CD to format the disk drives. Then see if you can bring it
back without touching a backup tape. Are you game?

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From:
rob@xxxxxxxxx
To:
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date:
10/02/2009 03:40 PM
Subject:
Re: Alternatives to Iron Mountain
Sent by:
midrange-l-bounces@xxxxxxxxxxxx



No, those do not have to be done regardless of HA or not. You can do a
complete system restore and get this done. However, if you have no backup





other than your HA machine you will miss vendor software keys,
configurations, ptfs, and a host of other data.

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From:
Bryce Martin <BMartin@xxxxxxxxxxxx>
To:
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date:
10/02/2009 01:12 PM
Subject:
Re: Alternatives to Iron Mountain
Sent by:
midrange-l-bounces@xxxxxxxxxxxx



If you have a data backup at the HA site and a data backup at the
production site then you have offsite storage built into the plan,
correct? Its the same data and same libraries.

As far as loading up lic keys and PTF's... those have to be done
regardless of HA or not. So there is no gain by having offsite data tape
backups. That really has nothing to do with it. The fact is that don't
have to send tapes out to a seperate location if they are already being
backed up from the HA machine that is in another location. Unless both
facilities are in areas where the same natural disaster could wipe out
both place I would think you are ok. But in the vast majority of cases I
think it would be overkill.


Thanks
Bryce Martin
Programmer/Analyst I
570-546-4777



rob@xxxxxxxxx
Sent by: midrange-l-bounces@xxxxxxxxxxxx
10/02/2009 12:31 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc

Subject
Re: Alternatives to Iron Mountain






Actually on the early part (before discussing short comings of the HA
machine) let me throw another wrinkle into the mix, fire. Backup tapes
are destroyed from the primary machine. They weren't sent offsite.

Do you really think that after you have the lic and os loaded from DVD
it's really only an hour or two to get your PTF's up to snuff, license
keys, configuration, system values, edit codes, what not, HA config, and
then start replicating data?

I still think you need to store backups off site and relying on data
replication from your HA machine for everything is a mistake.

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From:
Bryce Martin <BMartin@xxxxxxxxxxxx>
To:
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date:
10/02/2009 11:40 AM
Subject:
Re: Alternatives to Iron Mountain
Sent by:
midrange-l-bounces@xxxxxxxxxxxx



Yes the machine has an HA backup. Let me ask you this, if your primary
lost several drives (perhaps you were on vacation and no one else noticed
the errors piling up) how long would it take you to get it back up and
running? I bet I could get mine up and running in 24 hours. How long
would it take you?

-----Only as long as it takes to get drives in house and get everything
back in order.

- Have to order keys for machine: HA software, ERP software, barcode
software, and so on.

-----Already have SWMA with vendors. In disaster its as simple as a phone








call

- Have to reconfigure all the comm: Gee, who remembers how to configure a









Schowler route?
-----Comm is set up so it only takes a flush of the DNS to switch us to
the back up machine.

Meanwhile you're running on a machine you've only did swap tests on during









the occasional weekend, and while running live for a week you discover:
- There were several libraries that people thought were static and didn't
need HA replication. They were wrong.

-----All our production programs and data are replicated. Even user
libraries and our programming libraries.


- How come all the vendor fixes we put on the primary machine are not on
the HA machine?

-----Like I said, all production code and objects already synched.

- What clown thought we could do without certain applications during a
crisis and people should just "cowboy up" until the crisis is over?

-----That's why its not a true HA system if this is the case.

- Oh, and you really thought we could go from running on a 570-MMA to a
9408-M25 actually running more lpars and the users wouldn't start talking
about how the director of IS should now become a eunuch for letting
performance get this bad?

-----Your HA machine should ALWAYS be as big as your production, otherwise








what's the point? If your main facility burns to the ground and you need
to run on the HA box for a while then you'd be in bad shape. That is a
major mistake made by many HA implementors. They go cheap instead of
reliable.

- And the BOFH is pitching a fit about having to back up on a single
cartridge tape drive instead of a 6 drive tape loader capable of holding
over a 100 cartridges.

-----Why not have the redunant set up like production?

- Oh and that was a clever idea to offload query processing to our HA
machine. However now that the primary is down and the undersized HA
machine is not only running the primary load but also the query processing









the users are saying "them's that die are the lucky ones...".
-----Mistake.




If you aren't going to set up your HA disaster recovery plan to include
everything that you do in production its really not much of an HA disater
recovery plan. Its just a "little" better than your nightly backup
solution. Most of these issues shouldn't be issues if HA disaster
recovery is set up properly. Its not cheap or easy to test, that's why
you need to practice fail overs and roll overs a few times a year and have








people run production on the backup system to make sure all the pieces are








there.

just .02


Thanks
Bryce Martin
Programmer/Analyst I
570-546-4777

This email is confidential, intended only for the named recipient(s) above and may contain information that is privileged. If you have received this message in error or are not the named recipient(s), please notify the sender immediately and delete this email message from your computer as any and all unauthorized distribution or use of this message is strictly prohibited. Thank you.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.