Re: Which of the SYSIBM tables/views show the row count for

Lukas Beeler wrote:

On Sun, Mar 9, 2008 at 6:02 PM, Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx> wrote:

I'm not going to argue with you; you like journals and I think they're
often overkill. But I will say this: journals do NOT protect you from
application failures. If you write bad code, it will write bad
transactions, and the journal will happily record them. The only time a

Thus allowing point-in-time-recovery just before application failure.
You'll still be in a mess and will have a lot of problems fixing
everything up. But a journal can allow you to roll back to consistent
point of the database, they'll also allow you to see which changes
have been written.

I'm not saying Journals are your personal saviour. They are just an
important tool off a system that was setup defensively - like
passwords, object security, encryption, etc.

Yes, but I think you might be overestimating the usefulness of this particular capability.

Picture the situation: because of a programming failure, you are now shutting down your entire system, disabling all files (because you can't be accessing them during the time you are rolling back transactions) and trying to roll back to a "consistent point of the database". How far back is that? How many other applications are updating the same files? How many valid transactions will you be losing?

Let's say this is a bank - a new teller application blows up, and the operator calls the help desk. The help desk realizes this is a critical bug and calls to get authorization to SHUT DOWN THE ENTIRE SYSTEM. How long is that going to take? During that time, how many ATM transactions have already gone through? How much money has been given out? How do you "undo" those transactions? You'll certainly never get the money back.

No, the idea that you can somehow halt production and roll back files because of an application failure is a bit simplistic in all but the most trivial cases. The only way this really works is to roll back to a specific point, then selectively re-apply transactions, and even that is a dicey proposition because journals give you before and after images, and you have to then figure out how to create a delta to apply to the new file. Was this amount being replaced, or was it being accumulated?

I'll say it again: journals do not protect you against bad programs. If you are using journals to diagnose and recover from application errors in production, your IT manager needs to find a new job.

Anyway, enough on this thread. If your position is that journals are a tool that can be effectively applied on a case-by-case basis, then we agree 100%. If however you insist that all files should be journaled all the time, then we just have a difference of opinion.

Joe