When you issue the IXGWRITE service to write data to a log stream,
you cannot consider the data committed until system logger returns
control to the user with a successful return code. Particularly when
dealing with a coupling facility log stream, you should never rely
on a block ID associated with uncommitted data. For example, consider
the following scenario involving a
coupling facility log stream:
- Application 1 issues an IXGWRITE service, and the data is written
to the coupling facility.
- Before the data can be duplexed to staging data sets and control
returned to the user, application 2 issues IXGBRWSE for that block
of data and successfully reads the data.
- Now, suppose the coupling facility fails - the data that application
2 read was never committed and is now lost! Application 2 is using
log data which no longer exists.
- At this point, system logger might assign the identical block
ID to a different log block and applications 1 and 2, which are trying
to share a log, are now out of sync.
For a DASD-only log stream there is less likelihood of losing data,
because log data is duplexed automatically to a staging data set.
Data is committed when the log data has been written to local storage
buffers and duplexed to the staging data set. Note that for a DASD-only data
set, log data cannot be browsed until it is committed.
See Synchronous and asynchronous processing for more details on the methods used by
system logger to provide return code information to the invoking program.
When an IXGWRITE request cannot be completed synchronously, system
logger indicates this by returning to the invoking program with the
specific return code X'4' and reason code X'401' (IxgRetCodeWarning
and IxgRsnCodeProcessedAsynch, re: macro IXGCON). IXGWRITE requests
that are completed synchronously will result in system logger returning
a return code X'0' or a return code of X'4' with a
reason code other than X'401' (IxgRetCodeOK, or IxgRetCodeWarning
and not IxgRsnCodeProcessedAsynch).