Re: VALUES IDENTITY_VAL_LOCAL() Question

Define exactly what is meant by 'mirroring'; i.e. how is whatever is being done,
actually implemented.<br />
<br />
Where is the activity for both the identity value alter and retrieval taking
place?<br />
<br />
Would it be possible, instead of describing in words, that a script combing CL
and SQL requests, provides a simple example that is an effective /start from
nothing/ to an /And then this request fails/, at each step being clear, on what
system the activity is being performed.<br />
<br />
For example, something like:<br />
 @systemA<br />
 create table ... (... identity ...) /* if assumes journaled, then state it; to
a remote journal, to a local journal that later... etc. */<br />
 insert into table (/* not id col */ c2...cn) values( v1...vn ),(
v1...vn),etc.<br />
 crtsavf fortable...<br />
 savobj tablename ...<br />
 @systemB<br />
 rstobj tablename ...<br />
 @systemA<br />
 insert into table (/* not id col */ c2...cn) values( v1...vn ),(
v1...vn),etc.<br />
 crtsavf forjrnrcv...<br />
 chgjrn ... *gen<br />
 savobj thercv ... savf(forjrnrcv)<br />
 @systemB<br />
 etc....... until somewhere the program source and creation invocation, and the
failure are finally listed in that script.<br />
<br />

Our definition of mirroring is we utilize the HA product from Vision Solutions
to reflect any add/change/deletes done on our Production system tables to our
Target system tables.  <br />
<br />
When a record is added to a table on Production that has identity columns, that
record is also sent to the target system, but the Identity value assigned is
only invoked on the Production system.  So if the Production table was last
assigned a identity value of 12345, the Target system won't be in sync and could
be at '1'.<br />
<br />
What I wanted to do was to find a way to retrieve what the table believes it's
next assignable Identity value will be, without having to do an insert to use
the IDENTITY_VAL_LOCAL.  So if I could run a statement, etc against the
production table, I would expect to get '12346', and if I ran it against the
Target table I would expect '2'.<br />
<br />
The script I have now will work in a roll swap scenario to alter and reset the
identity value to the max value + 1, but I wanted to record in a log file what
the table thought it's value was, and what I changed it to.<br />
<br />

I'm confused why in the following paragraph you state that your script doesn't 
support your log file?  If IBM did provide some function to return the next 
Identity value, would you care if that next value included the cache value?

 > The script I have now will work in a roll swap scenario to alter and reset

the > identity value to the max value + 1, but I wanted to record in a log
file 
what > the table thought it's value was, and what I changed it to.

omar.pricca@marks.com wrote:
> Our definition of mirroring is we utilize the HA product from Vision
Solutions to reflect any add/change/deletes done on our Production system tables
to our Target system tables.  <br />
> <br />
> When a record is added to a table on Production that has identity columns,
that record is also sent to the target system, but the Identity value assigned
is only invoked on the Production system.  So if the Production table was last
assigned a identity value of 12345, the Target system won't be in sync and could
be at '1'.<br />
> <br />
> What I wanted to do was to find a way to retrieve what the table believes
it's next assignable Identity value will be, without having to do an insert to
use the IDENTITY_VAL_LOCAL.  So if I could run a statement, etc against the
production table, I would expect to get '12346', and if I ran it against the
Target table I would expect '2'.<br />
> <br />
> The script I have now will work in a roll swap scenario to alter and reset
the identity value to the max value + 1, but I wanted to record in a log file
what the table thought it's value was, and what I changed it to.<br />
> <br />

In the case of a rollswap, I would run my utility on the target system to reset
the Identity column value to max + 1 no matter what.  What I wanted to log was
what the current target table would have generated as an identity value so I can
compare it to what my utility actually set it to.  Just a before and after
snapshot.<br />
<br />

So it sounds like you don't care if the Cache value was included in the next 
generated value returned by DB2.

omar.pricca@marks.com wrote:
> In the case of a rollswap, I would run my utility on the target system to
reset the Identity column value to max + 1 no matter what.  What I wanted to log
was what the current target table would have generated as an identity value so I
can compare it to what my utility actually set it to.  Just a before and after
snapshot.<br />
> <br />