Re: R: AS/400 Serial Number -- MIDRANGE-L

Oh, I definitely agree that cost is a significant factor in doing a DR
test.  And yes that should take the steps necessary to be able to complete
these tests at the DR site.  However if you take the steps necessary just
to complete the tests and don't prepare for them on an onging basis then I
still argue that your plan is invalid.

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 11:18 AM
                    Please respond to
                    midrange-l







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 �nvalidation, 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

�����������������������-hey 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

�����������������������������������������������They
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.




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