Hi,

i´m looking to find a way to make db2 luw behave the same way as db2 Z/OS in terms of commit processing. Here´s my problem:

We migrated some Cobol-Batch-Pgms from Z/OS to Suse Linux.
Host-Batches run under TSO connecting to DB2 Z/OS via CAF.
Pgm-Logic ends each UOW by an explicit commit stmt. However, there are some sqls executed without explicit commit before pgm-termination.
In case of "normal" program-terminination ( RC < 8 ) those changes are committed otherwise a rollback is performed.

In DB2-LUW the Batch-Pgm connects via DB2-Connect to our DB2-LUW-V9.1-DB. All DB-Changes within a UOW ending with commit are committed. The sqls performed before pgm-end without an explicit coded commit-stmt are rolled back after program-termination even if the pgms ends with RC=0.

What causes this different behaviour ? Is there a possebility to configure DB or DB-Client to behave as Z/OS does ?

Read many articles on the web but found no satisfying answer. I&#180;m quite sure that this is nothing dealing with autocommit-configuration, right ?

That is the way DB2 for LUW works. Only UOW that are committed will be written to the database. If a UOW is active and the connection is broken (program ends with or without explicitly closing the connection) the UOW is rolled back. This prevents corruption in the DB.

Andy

Under DB2 z/OS the TP monitor (TSO, CICS, IMS, etc) is typically the coordinator of the two-phase commit process, which is why when the progarm ends a final commit is issued automatically.

You might try executing the program using an XA connection, which is two-phase commit process for DB2 LUW. I have worked with XA using Jboss, but not sure how that would work with a COBOL program. But that is the only thing I can think of.

Of course, adding a final commit to every program would not be that difficult.