Not to digress, but possibly doing so anyway, that's an interesting comment, Roland. Twice now, for two different projects, I've seen eejit developers write two CICS/Db2 programs; one to insert a row into a table as a kind of 'store 'n' forward' repository (Db2 trying to put MQ out of business, basically) and firing another program to process the row and, ultimately, delete it. Or update it. Or wot eva. And in both cases, occasionally this 2nd program fails to find the row to process. Basically because the 2nd program is being passed details on the row's key via some CICS storage mechanism and looking up/processing the row that way, rather than looking in the table. I'm sure you can guess where this is going, as occasionally the 1st program hasn't committed the row before the fired 2nd program goes looking for it to update/delete – and of course can't find it.
All that I understand. But the bit I don't, and it was mentioned in passing by a CICS Sprog here which I haven't had time to follow up, is that if the two programs were in the same CICS region... it would work! Might that be related to what Mr. Campbell (that's James, not the 'other' Mr. Campbell) said, about all CICS trans in the same region sharing/running from the same TCB? In my case the two programs were in different CICS regions. In my colleague's case they were also different, but his CICS Sprog said if they were in the same region it would have worked. That can only be true if they're in the same UOW.
Just trying to get my head around how one program can, in some cases, modify the uncommitted Db2 changes made by another. And I can only see that happening if they're in the same UOW, which sharing a TCB might effectively mean.
I'll leave that to the Warsteiner, you lager lout.
Think I have a Franziskaner waiting for me later...
UPS6756, #1544403 Oleander Drive, Suite CWilmington, NC 28403 Phone: (910) 660-8649Fax: (910) 523-5504