|
midrange.com
I disagree with part of your statements, Rob. Some I agree with.
That part about doing a special save for a DR test: unquestioningly valid.
To a point. But that doesn't mean that having an **extra** save along that
you don't intend to use, is a bad thing. D/R tests are very expensive. If
scheduled with a vendor, probably you'll arrange for a certain system for a
certain length of time, and it'll cost you $X. If you run across a bad
SAVSYS tape or other issue that prevents your test from continuing... do
you think the business will be happy paying for that time that you weren't
able to use because you didn't want to "invalidate" the test? I don't
think so. A LOT of value can be had by noting issues for improvement and
switching to plan B. And sometimes to plan C.
The comment about preparing with an alternative key invalidating the
test... gee, I don't agree with that at all! If the choices are:
1) Pre-contact the vendor so you can test the application
2) See if you can contact the vendor during the test; don't prepare
and if you take option 2, then don't plan to test that application. If the
application is the bread and butter of the business, and you know going in
that this might be a stumbling block, then what? Accept failure of the
test because of a technicality? Pack up and go home?
If you choose option 2 for a business-critical application, all you'll
prove is that you can restore your saves. That is not a disaster recovery
test.
Yes, there's some chance you won't be able to contact the vendor in certain
situations. And, yes, that possibilty is something that should be tested
as part of the plan. Call the vendor. If you get a key, then great. If
you don't (and you chose option 1), then you have your backup key that you
received while preparing for this... and you can mark the vendor issue as
an area of improvement for the next test.
This is the approach I've used over the years for several disaster recovery
tests. We get the key in advance, then during the test, we call the vendor
again and try to get a key at that time. It's worked great for me.
Gasp! If reasonable preparation Ðinvalidation, I'm in the wrong business!
And I don't think I'm in the wrong business. :)
Dennis
rob@dekko.com@midrange.com on 10/29/2001 10:53:57 AM
Please respond to midrange-l@midrange.com
Sent by: midrange-l-admin@midrange.com
To: midrange-l@midrange.com
cc:
Subject: Re: R: AS/400 Serial Number
Then, at least in the request for a key, it's a false test. Think of Al's
example of the WTC bombing. What if that vendor was in the next office?
This was my point. I agree with you that DR tests should be planned. But
if the planning requires stuff like
1) 'You know that GO SAVE option 21 that we do once every 2 years? Do
that tonight prior to our offsite test tomorrow.' Is an invalid test.
Unless you are going to do complete saves on a more timely fashion from now
on.
But then again you may decide that the applications that you can't get keys
on during the weekend can wait until Monday. For many operations this is
not unreasonable - for others it's absurd.
Rob Berendt
ÝÝÝÝÝÝÝÝÝÝÝÒThey that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin
"Dennis Lovelady"
<dlovelady@dtcc.com To:
midrange-l@midrange.com
> cc:
Sent by: Fax to:
midrange-l-admin@mi Subject: Re: R: AS/400
Serial Number
drange.com
10/29/2001 10:42 AM
Please respond to
midrange-l
Hi, Rob:
In all fairness, I believe most DR tests are planned. All should be, IMO.
One would hope that planning would include contacting the vendor ahead of
time for a key.
Dennis
rob@dekko.com@midrange.com on 10/29/2001 10:16:16 AM
Please respond to midrange-l@midrange.com
Sent by: midrange-l-admin@midrange.com
To: midrange-l@midrange.com
cc:
Subject: Re: R: AS/400 Serial Number
And I wonder how many people do their DR tests during the week when they
can contact the vendor and get a key.
Rob Berendt
ÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝ-hey that can give up essential liberty
to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin
barsa@barsaconsulti
ng.com To:
midrange-l@midrange.com
Sent by: cc:
midrange-l-admin@mi Fax to:
drange.com Subject: Re: R: AS/400
Serial Number
10/26/2001 09:15 PM
Please respond to
midrange-l
Faking out RTVSYSVAL isn't so easy. It's (to my knowledge) the only
command with a variable length return parameter for the System Value
itself.
I did change a serial number to run an application after the WTC bombing in
'93. The software vendor was unable to give me an emergency key over the
weekend. IBM got so mad at me that they changed the internal format of how
they were stored.
In TAATOOL we have a command that will buy you an additional 10 days on any
serial number or model, which should be good enough if you can't reach us
over a long weekend, or in the event that we had a disaster.
Al
Al Barsa, Jr.
Barsa Consulting Group, LLC
400>390
914-251-1234
914-251-9406 fax
http://www.barsaconsulting.com
http://www.taatool.com
Finucci Domenico
<Domenico.Finucci@Fid To:
"'midrange-l@midrange.com'" <midrange-l@midrange.com>
italia.it> cc:
Sent by: Subject: R: AS/400
Serial Number
midrange-l-admin@midr
ange.com
10/25/01 09:56 AM
Please respond to
midrange-l
How do you acquire serial number on your application ? Do you use RtvSysVal
QSRLNBR ? If so, you may need to create a NEW RtvSysVal wrapper in a
different library.
Sincerely
Domenico Finucci
Fiditalia , Milano, 02- 4301-2494
-----Messaggio originale-----
Da: Scott [mailto:sarntsen@itol.com]
Inviato: giovedì 25 ottobre 2001 15.40
A: MIDRANGE-L@midrange.com
Oggetto: AS/400 Serial Number
Is it possible to change the serial number on an AS/400? I'm in the
process
of setting up a system for disaster recovery.
_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
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.
