When a DB2 database goes into rollforward pending mode, and the
rollforward is then started, does DB2 have a preconceived notion
about what log it should roll forward TO? Or does it simply keep
incrementing the log number until there are no logs left to
process?
I am using the db2uext2.cdisk userexit, and have modified it so
that, rather than using a cp command, it calls a java app (inside a
VM of course) to archive/retrieve the log to/from another server.
I don't think the VM is passing back the proper return code to the
db2uext2 executable, because db2uext2 is trying to retrieve logs
that have not yet been archived. The logs it is looking for are
active logs, those that disappear from the log path dir when
rollforward pending starts.
The C source in db2uext2.cdisk seems to indicate that, if the log
file that was just attempted to be retrieved does not actually exist,
then an RC_OK success return code should be returned..
TIA
allen
One additional observation:
The following messages appeared in my db2diag.log when the
rollforward was done (I removed the timestamps and headers):
Rollforward iteration completed
ExtNum 119 not found. FirstArchNum 4294967295 LastArchNUm 4294967295
DB2 is waiting for log S0000119.LOG to be archived.
(This one above repeats once a minute for 5 ot 6 minutes)
DB2 was unable to confirm log S0000119.LOG was archived.
Log 119 was my last archived log file, and it WAS successfully
archived. It looks like something went wrong, but the rollforward
apparently worked just fine (I checked my last few transactions).
Any idea what is happening here?
TIA
Allen
The db2diag.log messages are spurious. Fixpack 8 fixes this...
allen