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


  • Subject: Re: Help on recovery
  • From: DAsmussen@xxxxxxx
  • Date: Fri, 13 Jun 1997 22:17:05 -0400 (EDT)

Sanjeev,

In a message dated 97-06-13 01:27:31 EDT, you write:

> We work on remote AS/400s through international satellite links. There
>  are frequent cases of link failure (3 to 4 times a day), and in those
>  cases, we lose all unsaved work. We are not able to get back to where we
>  were when the link comes up again. This is true even in the case of a
>  power failure in any of the local workstations.
>  
>  Having worked on an ES/9000 for over 2 years, I'm pretty surprised that
>  such a thing can happen especially when people claim that the AS/400 has
>  excellent recovery techniques.
>  
>  Is there any way of getting over this problem. I strongly feel that we
>  have overlooked certain factors when setting up the link as well as the
>  remote AS/400.

Unlike the ES/9K, DB/2 400 is NOT a "generational" database.  Automated
copies of transactions are NOT saved, and your application has to handle
this.  The AS/400 is geared toward "real-time", online processing.  It is NOT
geared toward handling large batch processes in a manner that is easily
recoverable at the system level.  You MUST engineer your applications to
handle the eventual failure, no matter how remote the possibility of this
occurring.

In my current environment, we pass data back and forth between an ES/9K, a
VAX, and a SCO UNIX PC using MQSeries, FTP, and SNADS.  While each transport
is different, we share a common recovery mechanism written in-house.  You
MUST prepare for every eventuality, including a DASD failure, by checking for
a good status on WRITE and UPDATE functions within the application.

It sounds like you are not planning for failure, rather, anticipating that it
will NOT occur.  This is a BIG mistake, IMHO.  You MUST identify possible
failure points, and program around them accordingly.  Otherwise, you are
doomed to losing transactions...

JMHO,

Dean Asmussen
Enterprise Systems Consulting, Inc.
Fuquay-Varina, NC  USA
E-Mail:  DAsmussen@AOL.COM

"I think of life as a good book.  The more you get into it, the more it
begins to make sense." -- Harold S. Kushner
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the Midrange System Mailing List!  To submit a new message,   *
* send your mail to "MIDRANGE-L@midrange.com".  To unsubscribe from     *
* this list send email to MAJORDOMO@midrange.com and specify            *
* 'unsubscribe MIDRANGE-L' in the body of your message.  Questions      *
* should be directed to the list owner / operator: david@midrange.com   *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.