|
All this discussion about manually recovering from program abends and power failures and other interrupted transactions..... I feel a soap box speech coming on.... The _right_ way to do this is with journaling and commitment control. It continues to astound me that nearly all the application vendors that get paid a lot of money from a lot of customers don't build this in. I used to run a MACPAC shop, and while it was often missing the bells and whistles, it had the fundamentals right. I ran MACPAC on a B45 with no UPS (!) in an area with power problems. The CFO didn't want to spend the $10K until one of his reports got delayed by a ten second power outage followed by an 8 hour logical file rebuild. MACPAC did have full journaling and commitment control, so when any transaction failed, it automatically backed itself out. I _never_ had to go poking around trying to finish half posted transactions, and I _never, EVER_ went poking around with DFU, DBU or something similar. Since I was running the vanilla software and I never did any DFU-ing, any time the system had a problem I knew EXACTLY whose fault it was.... I ran that system for 8 years for a hundred million dollar business across several countries and even the GL detail files _still_ balanced and rolled up. Assets still equalled liabilities plus owner's equity. A statistical miracle. So far, none of the other canned packages I've run across do commitment control out of the box, and to say it's a bear to implement would be an understatement. BUT - this is what the software vendors are supposed to do for you, the customer. That's why they get paid the big bucks for these systems. Has JBA ever considered adding this feature? Has the user community ever requested it? Many people will voice concerns over performance degradation with journaling. In my opinion, don't worry about performance. I ran that B45 for about 50 people running MRP, distribution, and financials with no problem. Given that today's boxes are about 100 time faster.... no sweat. Just my opinion.... +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Add archiving to your JBA purge programs WITHOUT PROGRAMMING!!! Purge and Archive your AS/400 Data Without Programming with ARCTOOLS (tm) DCSoftware, Inc. (508) 435-8243 (508) 435-4498 (fax) http://www.arctools.com mailto:info@arctools.com +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -----Original Message----- From: Mike Godson <MGodson@hach.com> To: 'JBAUSERS-L@midrange.com' <JBAUSERS-L@midrange.com> Date: Wednesday, June 23, 1999 9:09 PM Subject: RE: Recovering Sessions >Regarding incomplete A/P sessions (those with a status="I"), has anyone >dealt with recovering these? > >Michael Godson >Programmer / Analyst >Hach Company >Loveland, CO 80539 > > >-----Original Message----- >From: Cathy Mastej [mailto:cathym@sgfootwear.com] >Sent: Friday, June 11, 1999 12:30 PM >To: JBAUSERS-L@midrange.com >Subject: Re: Recovering Sessions > > >We also have the same problems with unprocessed A/P sessions.What we do >to recover in A/P is bring down our subsystem in A/P and run Option 15 >in APU Rebuild bal. update data queue. We are following the same >procedure in G/L. We are not live in A/R yet. I hope this helped you. > >Glenn Schreiner wrote: >> >> Does anyone else have problems with unprocessed A/R, G/L, and A/P >sessions? >> Everyday we have several sessions that need to be recovered due to JBA >> program failures and PC problems. JBA has provided some very manual >> procedures on how to recover most A/R sessions, but apparently we're on >our >> own as far as A/P and G/L. So far we've been able to recover all of our >> sessions by plugging record values and creating records using DBU, but I >was >> hoping someone might have stream-lined these recovery processes. >> +--- >> | This is the JBA Software Users Mailing List! >> | To submit a new message send your mail to JBAUSERS-L@midrange.com. >> | To subscribe to this list send email to JBAUSERS-L-SUB@midrange.com. >> | To unsubscribe from this list send email to >JBAUSERS-L-UNSUB@midrange.com. >> | Questions should be directed to the list owner: doug333@aol.com. >> +--- >+--- >| This is the JBA Software Users Mailing List! >| To submit a new message send your mail to JBAUSERS-L@midrange.com. >| To subscribe to this list send email to JBAUSERS-L-SUB@midrange.com. >| To unsubscribe from this list send email to JBAUSERS-L-UNSUB@midrange.com. >| Questions should be directed to the list owner: doug333@aol.com. >+--- >+--- >| This is the JBA Software Users Mailing List! >| To submit a new message send your mail to JBAUSERS-L@midrange.com. >| To subscribe to this list send email to JBAUSERS-L-SUB@midrange.com. >| To unsubscribe from this list send email to JBAUSERS-L-UNSUB@midrange.com. >| Questions should be directed to the list owner: doug333@aol.com. >+--- > +--- | This is the JBA Software Users Mailing List! | To submit a new message send your mail to JBAUSERS-L@midrange.com. | To subscribe to this list send email to JBAUSERS-L-SUB@midrange.com. | To unsubscribe from this list send email to JBAUSERS-L-UNSUB@midrange.com. | Questions should be directed to the list owner: doug333@aol.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.