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