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?


-----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
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.

Reply via email to