Hi,
in my former companies everything was journaled not only files but also data
queues and data areas and commitment control was used to make sure that a
transactions is either completed or completely resetted. If an error
occurred a rollback was performed so that we could easily restart at a
specific point for example with a sub-program.
In my current company journaling is not used, and this is one of the first
things I want to introduce.
If you are used to use journaling and commitment control, it is hard to go
back into middle age.
For example instead of doing a simple rollback if an error occurs, now I
have to program all steps back (and am finally not even sure that my data
are correctly resetted).
Or if you do an ad-hoc update or delete with SQL. If the files are journaled
and commitment control is set to an commit level other than *NONE, you do
not have to save your data before executing the update or delete. Just
execute a commit, do the update, check your data and if everything is ok
perform the next commit otherwise execute a rollback.
Mit freundlichen Grüßen / Best regards
Birgitta Hauser
"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"
-----Ursprüngliche Nachricht-----
Von: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] Im Auftrag von Glenn Hopwood
Gesendet: Thursday, 20. August 2009 19:26
An: Midrange Systems Technical Discussion
Betreff: Re: Modernizing applications (was: Explaining single level store to
non ipeople)
Michael Ryan wrote:
Certainly HA does...
And you're 100% out of a sample of one.
So...a poll? How many iSeries shops use journalling?
We journal all files. (We don't do commitment control, though.)
At my last employer there was no journaling of any kind.
Glenn
midrange.com
