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