Re: Disaster/recovery Plan for BPCS -- BPCS-L

You might ask your management some questions with respect to what kind of
protection they think is needed.

You might also ask the folks here what kinds of mishaps or risks we find are
the most common & make most sense to protect against.

I have been working with BPCS for over 10 years.  I have been in
manufacturing for over 15 years & prior to that in other computing
environments for over 25 years.  95% of this was on IBM platforms.  I have
been at an employer that experienced a hard disk crash on IBM midrange
platforms exactly twice in my over 40 year career & both times IBM recovered
over 99% of what was on the lost hardware, or walked us through the process
of doing so.  The most recent crash was on hardware that was 13 years old &
IBM's mean time to failure was 10 years ... in other words it was 3 years
beyond IBM's estimated failure point when it did fail.  I have lost track of
how many times some PC has had a crash & it has never been affordable to
recover what was on it.

If there is a disaster so bad that it destroys the building that is your
factory, do you even need to be able to recover your computer files, or is it
all over for the company?

Is your inventory accuracy & accounting records in such a state that it would
be acceptable after a disaster to recover your data to what it was as of the
end of the last business day?  In other words it is sufficient to do daily
backups & make sure you have some off site storage of some, so that if there
is a physical disaster that trashes the computer room, you do not lose the
computer and all the backups in one fell swoop.  It then becomes a question
of how frequently you rotate backup off site ... weekly?  We do ours monthly
& we have two off-site sets.

Do you have adequate UPS protection on the main computer room servers etc.
and do you have non-lemon surge protection on connected PCs & other
peripherals?

One of the steps of our end-month process is to back up everything on one of
the two off-site backup sets.  That set goes to our off-site backup place
BEFORE the previous month set comes into our building, so we NEVER have all
our backups in the same place.

You might also consider what paperwork ought to be off-site.
Phone numbers of tech support.
Copies of serial numbers & proof of legal ownership.

The recent 9/11 man made disaster in New York City has led to a lot of places
rethinking their disaster recovery plans with respect to people skills.  What
good does it do to recover your data if you do not have the people who know
what to do with it?  There have been recent articles in the computer trade
press about this.  There were also some after the last major California
earthquake ... what can we learn from companies that have gone through a
major disaster?

I give management an annual briefing on security.
Most of the high level security officer passwords are in my head.
What happens if I have a brain dump or anthrax disaster or a union truck runs
over me?
What will be your options with respect to getting into the security systems &
how many security systems are there?
What I suggested is that copies of the master security & BPCS security & PC
Network Administrator security access information be placed in a sealed
envelope & given to the company auditors or lawyers to be placed in their
safety deposit box so that in the event of something dire happening to top
company management, the new owners would be able to get into the systems.
Management decided to do something a little different & for security reasons
I am not saying exactly what.

For general thinking about what you might want to recover after a disaster &
how to go about protecting it & make sure you not forgotten anything, check
out
http://www.TechRepublic.com/forumdiscuss/thread_detail.jhtml?thread_id=17159

There have also been seminars by the computer professional association
conventions on topics like this.
I have recently done some posts to other lists giving links to a diversity of
computer professional associations if you interested in that.

As to whether you really need journaling, you might ask your IS staff for
access to your site's BPCS sizing questionairre.  This is where management
participated in saying what level of performance & protection the company
wanted & was willing to pay for.  For you to propose an increase in
protection, you have to know how expensive it would be & basically do a cost
benefit analysis.

When we got our BPCS installation, I asked for RAID & some other things & was
basically told that regular backups were good enough & cost a heck of a lot
less.

Companies that need 24 hour up time for their users may need more protection
than in our situation, where we basically have one office workers shift &
darn little night user access.

There are several kinds of disasters.
What I have talked about so far is the big time one where you suddenly lose
central hardware or access to your data, any of it.

The more common situation in BPCS shops is where there is human error, a PC
getting disconnected in the middle of doing BPCS tasks, a bug in the
software, etc. in which the IS dept usually does not know exactly what
happened.  All we know is that the data or access to it is messed up for a
very narrowly defined application set of options.  The business imperative is
to clean up the data & get the users back in business as rapidly as possible.
 Management is not interested in IS spending several hours analysing journals
or anything else, to figure out what went wrong, if it means several hours of
the users not able to do their work.

In fact IS is not interested in spending hours analysing some situation that
might never happen again.  We can only justify this when the same kind of
scenario seems to frequently occur, so we need to figure out what is
responsible & what to do to lower the rate of problem.  This has led to some
modifications at our shop to offer users better choices in error recovery.

We do not do journaling.  The only time we have seriously considered it is in
bug tracing.  We know that there are data errors creeping into the system &
we suspect certain clusters of programs.  Journaling could be used to narrow
the suspects, but what works for me is to have a Query/400 that lists the
garbaged data, such as negative costs, negative requirements, cost buckets
that don't add up, on hand that does not add up, or whatever the problem is
... then I run the program that I suspect is contributing to this problem,
then I run the query again & see if there has been an increase in the
garbaged data & if there has, then I study the source code to see if it is
practical for me to fix it.  There are some cases where the program is just
too monstrous to fix & we have long since given up on SSA fixing it, so I
have developed some fix it programs, such as our recent addition of a cost
reorganization program that makes the cost buckets add up again.

We have occasionally done some logging for security reasons.  Basically to
find out who was sticking their noses into some highly confidential data.

Assuming you are on an AS/400 (most people on this list are, but BPCS can run
on other stuff) also check the midrange dot com archives on midrange_L
(general AS/400 technical topics) and the rest of the AS/400 community such
as
http://www.as400network.com
http://www.as400journal.com/
http://as400magazine.com/
http://www.ibm.com/servers/eserver/iseries/nation/
http://www.midrangesystems.com/
www.sourcebook400.com

You will find links to a spectrum of topics, of which Disaster/Recovery is
but one.
Some of these sites have archives of articles which you can search by topic.

The IBM classes on Security & Backup / Recovery 400 Administration have some
check lists on things worth considering.
http://www.training.ibm.com/ibmedu/spotlight/as400.html
http://www-3.ibm.com/services/learning/lsweb/educationcenters/

MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)
BPCS 405 CD Manager / Programmer @ Global Wire Technologies Incorporated
http://www.globalwiretechnologies.com = new name same quality wire
engineering company: fax # 812-424-6838

>  From:    afvaiv@wanadoo.es (afvaiv)
>
>  Hi, I'm new both to BPCS and to this List.
>  I'm also new to the IS Dept in a Factory where they just installed and
>  started BPCS in production...
>  Now I've got to prepare for a D/R Plan just in case...
>
>  Reading thru the archives I found several threads, but rather general.
>  Just one of them had something like
>  "I believe that journaling BPCS is essential to any BPCS energency
>  recovery procedure.Although BPCS does not include commitment control,
>  journaling may be
>  invaluable in both in case of a disaster, such as a disk crash, and in
>  debugging and investigating the BPCS database. "
>
>  To my surprise, I found out BPCS does not (am I wrong ?) any journalling
>  (at least in our shop).
>  I don't want to re-invent the wheel, so I'd like to know what you people
>  do as "normal" D/R procedures for your BPCS stuff. Just journal all
>  files as anything else?
>  Any other procedures?
>
>  Any ideas are welcome. TIA
>  -------------------------
>  Antonio Fernandez-Vicenti
>  afvaiv@wanadoo.es