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



On 12/18/2013 2:58 PM, D*B wrote:
<Buck>
... why not write...
</Buck>

reading some responses, I'm getting in these list, I'm thinking it might be a waste of time...
but anyway, if you've some questions, I will try to answer.

Hallo Dieter,

It is not always easy to tell the difference between a geezer who wishes
never to change from card processing and a programmer who has
thoughtfully considered the cost/benefit ratio of making a certain
change. But there is a difference.

There is nothing that any of us will be able to do about the geezers.
They already have their minds closed. They probably don't even
subscribe to a mailing list. Complaining about them here probably does
no good.

But thoughtful discussion does happen here on this list, and I
appreciate your offer. My comments below are not arguments against
commitment control - I think that most applications designed today would
benefit from CC. Rather, my comments are to show that I have actually
thought about the problem, and have a good idea of the work I'd need to
do in order to retrofit CC onto an ancient batch process.

@Buck: the first step is very easy:
- give your new programms a named activationgroup COMMIT
- if you issue a commit after each write and use all
defaults it's working as before and the problem of the OP is gone!

This is true on all counts. It is simple enough, and it avoids the
issue of COMMIT(NC). But does this add any business functionality? It
seems to me that a COMMIT cycle that holds exactly one master row is
meaningless. Isn't a 'normal' COMMIT cycle a master row and some rows
in child tables?

- starting from this point you could put some database
operations together, completing all together (you've said
commit), or all discarde (you've said rollback)

Yes, let's explore this. So now we need to consolidate 3 or 4 programs
into one. Instead of PGMA updating MASTER, PGMB updating SALESDETL,
PGMC updating EOMSALES and PGMD updating EOYSALES we'd now have PGMNEW
that updates all 4 tables.

- maybe your batch processe are workink like lots, I've seen,
reading some workfiles, producing another and changing a flag,
in the primary file to read => just put all operations for one
record of the primary file to one transaction and you would
have lots of benefit.

Yes. And today, if an error occurs updating SALESDETL, it goes on a
report and the database is a mess. But with ROLLBACK, the whole
transaction is undone and the database is internally consistent. Which
is Very Nice. This IS a benefit to the business.

But how would we correct the error and re-process the undone
transaction? The application needs another change - not impossible, but
it's another thing to think about - to track transactions that error'd
out. Today it prints a report and goes on. There are maintenance and
cleanup programs to handle the mess. Naturally we want to take the
'update the mess' bit out of the maintenance programs because we don't
want people mucking about with the clean data.

And then there's the question about batch totals - there are accountants
who are very unhappy if the total on 'the edit report' don't match the
total on the bank report. Today, this total matches whether the
database does or not - that's terrible! And until the cleanup / fix the
mess happens, the database will be 'out of synch' with reality. So we
need to redo 'the edit report'. When a ROLLBACK happens, subtract out
the 'details' from the total? Maybe. Or maybe we scrap the report
altogether and replace it with an SQL query that sums up the total after
the update completes? At least the total would match reality, even if
the reality isn't what the accountant likes...

- another effect will be, that you would have to start journaling
to all files, giving you much more information what did really
happen during the nightly batch, when you where lieing in your
bed, sleeping, coming to the office next morning and your batch
is sitting and waiting for you to answer soem inqiry message...

These days, the batch processes pretty much print an error and either
stop before processing another input transaction record or keep going
and let the programmers clean up the mess during the day. Another bad
process; put in place to let all of the night's work complete. Because
some of it is for Sales, some for Accounting, some for Inventory, some
for Payroll... Just because a Sales job has a problem, it doesn't mean
that Accounting's nightly work should wait. Yes, a proper analysis of
prerequisite jobs would solve the real problem, but there are only so
many hours in the day, and I'm mostly working on adding new
functionality rather than analysis of something that breaks twice a year.

But back to your comment, journalling is a tremendous help when it comes
to diagnosing what happened in the past - even if 'the past' is only
last night. You might be pleasantly surprised at how many of us have
journalling turned on even if commitment control isn't retrofitted to
every program.

Tschuess!
--buck

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.