Re: Disaster recovery question.

[bdietz@xxxxxx]

Comments inline............
---------------------------------------------------------------

>The thought was to ship the 150 quickly to the 170 site in the event of
a disaster, restore the M36, and any M36 cnfigs, but the result would
only yield a stand alone M36 that supported only the 1 site, and not
it's remote branch.
==>  What you would support in case of distaster should be defined in your
distaster plan.
If they want more functionality, then they must pay for it.

>Here is where one gets into device descriptions, outq configs...etc, so
the exercise would be quite time consuming, and I don't believe would
mirror the production machine.
==> Device descriptions will be something to worry about.  If the 150 has
the base twinax you then get 7 twinax devices.  Subtract one for OS/400 and
you have 6.  In backup mode will that work?  Outq's will be easy they are
just objects, unless they attach to real printers.

>Apart from the 170's remote site, (data can be batch
processed), and assuming the M36 objects can be restored to the 150,
what oter pointers can you think of?
==>  You can test this any time you want.  Just save and restore the
library where the *M36 lives.
You will have to play around with the configuration to match up the 400
config objects wit the 36 resources, it should be a good exersize.
Play around with the 36 side and see what type of a system you would be
able to provide your users.

>I mentioned the fact that the 150 seemed a bit sluggish in comparison to
the 170, any ideas....
==> Sluggish should not matter much for the *M36, sure the users might
notice, but at least they are getting *some* work done.