Hmmm. I have not spent a whole lot of time on TBEGIN because as a vendor we have that back-level machine issue for the next several years. But this really makes me question the whole thing. Is the advantage of TBEGIN worth the complexity of a dual path? (Rhetorical question; not expecting a definitive answer from you, @Ed.)
Or phrasing the issue differently, I now have working queue management code using CSG and CSST. It is hard for me to envision how TBEGIN would be so advantageous that I would tear into this (tricky!) working code and re-write it for a second logic path. Comments? Anyone? Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Ed Jaffe Sent: Saturday, August 12, 2017 5:54 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: PLO <subject change: was Just Testing - It got very quiet> On 8/12/2017 2:20 PM, Charles Mills wrote: > Let me volunteer to be the dumb one here. > >> Note that use of transactional processing is inherently dual path. >> You would still need the "other" path even if every machine in the world >> already supported TBEGIN. > Why? A non-constrained transaction needs a fallback path to deal with anything other than CC=0 from TBEGIN. If you get CC=1 or CC=3 you really have no choice but to go to the fallback path. You could retry after CC=2, but you don't want to get into a loop doing so. So you really need to set a single-digit retry limit and go to the fallback path when it's reached.
