Data Areas and Journals
Tony Smithurst
Does anyone out there know how, or if, it is possible to include data areas
in a journal. I can find no reference to this, but guess that most
transaction based systems are using data areas to keep the most recent, or
next available, transaction number in.
Any help would be appreciated...
Tony Smithurst
Martin Neugebauer
Tony Smithurst wrote:
Why do you think so?
Dataareas are scratch-paper type objects and can not be journaled.
Martin
OSITim
>Does anyone out there know how, or if, it is possible to include data areas
>in a journal. I can find no reference to this, but guess that most
>transaction based systems are using data areas to keep the most recent, or
>next available, transaction number in.
>
>Any help would be appreciated...
>
>Tony Smithurst
>
>
Unfortunately, there is no system provided means to journal a data area.
Although, there are several alternatives depending on why you want to journal
your data areas.
if you only want to track changes to the data area for recovery purposes, use
the SNDJRNE command (there's an equivalent API as well) whenever you change the
data area. In a recovery situation you can use DSPJRN to find out the last
value a data area had prior to a cut-off.
If you are journaling in order to mirror changes to a remote system, many of
the mirroring packages can handle data areas via a polling method. or through
an Object Mirroring method.
If you are journaling in order to keep remote systems informed of the current
value of a data area, consider using *DDM type data area. A ddm data area works
similarly to a ddm file in that the application program using it has no
knowlege that the data resides on a remote system. Furthermore, updates and
locking is enforced.
If you are just trying track the data area's usage, consider activating object
auditing on the data area. although this will not keep track of how the data
area's value has changed.
The TEAMIBM Network
Though there is no direct system support for journaling of data areas,
one could use the Commitment Control APIs (found in the System API
Reference) to build your own commit control support for data areas.
Bruce Vining
Tony Smithurst
OSITim wrote:
<Snip>
If you are journaling in order to mirror changes to a remote system, many of
the mirroring packages can handle data areas via a polling method. or
through
an Object Mirroring method.
<Snip>
This is exactly the reason that we are journalling. Thanks for your help, I
don't like the idea of polling as our data areas are kept very active. Looks
like I'll probably have to reconstruct the data areas at the mirror end
during our journal application routine. Until we get around to storing
transaction numbers in the database, that is.
Tony Smithurst
Ps to IBM:
Don't suppose there's any chance of this is a future release ?
Dave Shaw
Tony Smithurst wrote in message <69vo6q$kk9$1...@hermes.is.co.za>...
>Does anyone out there know how, or if, it is possible to include data areas
>in a journal. I can find no reference to this, but guess that most
>transaction based systems are using data areas to keep the most recent, or
>next available, transaction number in.
If you can reasonably change the programs that update the data area, you can
use the SNDJRNE command, or the equivalent API, to write a user-defined
entry to the journal. You could then write a program to read the entries
from the journal and apply the changes to the data areas. Depending on your
situation, this may work better for you than the polling methods that have
been suggested.
--
Dave Shaw, General Nutrition, Greenville, SC (just down the road from BMW -
Bubba Makes Wheels :)
The opinions expressed may not be my employer's unless I'm sufficiently
persuasive...