I guess I have two questions. The first-- is it a good idea to keep the program alive like this, with a PERFORM UNTIL loop? Other CICS code I've seen Actually exit the program with a RETURN back to the current transaction (with data in the commarea), but I personally hate that concept because it uses GO TOs all over the place, and besides, this particular program does not have its own transaction ID; it is only called (using a XCTL command) from a menu program, so I couldn't figure a way to do the ol' RETURN-- there's no transaction ID to use.
That leads to the second question. The DB2 tables I update and insert inside this loop seem to get locked up to any other update, even with those COMMITS in place. I have encountered this table lock problem with an ad-hoc query while the screen is alive; I haven't done any other testing.
Is there any way I can get around this table lockup issue?[/code]
I'd agree with you with regards to the concurrent update/insert issue, but I have tried my best to lock the screen up with two screens up running side by side doing updates/inserts, and I can't cause a lockup. As long as having the screen up and running waiting for input doesn't prevent another user from making updates and inserts, I can't see a problem. But, perhaps it's different with 10-20 users actively using the screen?
I'd be OK using a RETURN, but I can't figure out how to return to a program that doesn't have a transaction ID associated with it. Is there a way to issue a RETURN to a program name rather than a transaction ID?