Recovery techniques...

["Reeve Fritchman" <reeve@xxxxxxxxxx>]

My transportation/logistics ERP application currently uses journaling (we
roll the receivers off-line to tape every three hours), commitment control,
and SAVLIB's as a backup/recovery strategy.  There are two major batch
processes and thousands of interactive updates in the course of a day;
transactions from one day can be updated and reprocessed many times over the
period of several months.  This is a real-time operations control system but
we have two applications (cash application and interline payables) using
interactive entry into transaction files and subsequent batch processing at
night.

An important customer has told me that the recovery approach described above
is not satisfactory.  His requirement is to capture all transactions (all
interactive: order entry, dispatch, status updates, cash application, etc.)
and to reprocess the transactions through a (possibly modified) set of
application programs in the event a problem is detected in one or more
application programs.  His volume varies between 50,000 and 100,000
application transactions daily.

Having a traditional application design already in place, I see such a
modification requirement as representing a staggering amount of work.  You
could argue that having a data queue/message-driven system would isolate
your business logic from your I-O interface and provide this forward
reprocessing capability, but that assumes you want to tackle, or can
justifying tackling, the former.

My real problem isn't the technical side; it's the implementation side and I
don't even know the proper terminology for describing the nature of the
problem.  But here's a sample situation: Program "A" misbehaves and does "X"
instead of "Y".  A user comes in and does various things to change the
incorrect result ("X") into the correct result ("Y").  This correction
process could be a master file update or a series of general journal
entries.  My customer thinks I should be able to fix program "A", restore
the database, and apply the original transaction through corrected program
"A" and get the correct result.  That's fine up to a point.

How do I exclude the correction transaction(s) unless an individual reviews
every non-original transaction?  And how do you identify an "original"
transaction?

Does anybody know of any ERP systems with this level of recovery?

Reeve Fritchman
Chairman, Transportation Technology Group, Inc.
reeve@transtechgroup.com
813-831-8574 (voice)



+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---