>Note that use of transactional processing is inherently dual path.
I'd say, no, only non-constraned transactional processing (TBEGIN) is
inherently dual path. TBEGINC is not.
Yes, double-threaded queue manipulation can be done with a constrained
transaction.
z/OS 2.3 requires a machine that
On 8/12/2017 3:35 PM, Charles Mills wrote:
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
? 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
On 8/12/2017 2:20 PM, Charles Mills wrote:
> Let
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
rame Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Ed Jaffe
Sent: Saturday, August 12, 2017 1:40 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: PLO
On 8/11/2017 6:31 AM, Blaicher, Christopher Y. wrote:
> PLO is an expensive instruction. It can do a little or a lot.
About transactional processing:
>> You would still need the "other" path even if every machine in the world
already supported TBEGIN.
very valid, and a lot of work for an OS that does not already have it.
Easy (and less work to implement on a certain platform) for an OS that
has it already.
On 8/11/2017 6:31 AM, Blaicher, Christopher Y. wrote:
PLO is an expensive instruction. It can do a little or a lot. There are about
10 pages in the POP to describe it.
However, until transactional processing is supported in all environments,
ISV's, who never know what environment
I love transactional processing. I still remember the SHARE session where it
was fully described and thinking that this will make life so much easier in the
future. But I may fully retire before we can safely add it to our products
without dual paths for another technique. In this case PLO
Peter, would you care to share your opinion of CSST?
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Peter Relson
Sent: Friday, August 11, 2017 7:24 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: PLO
does anyone
PLO is an expensive instruction. It can do a little or a lot. There are about
10 pages in the POP to describe it.
However, until transactional processing is supported in all environments,
ISV's, who never know what environment they are running under, need to keep
using the PLO instruction
On Fri, Aug 11, 2017 at 6:23 AM, Peter Relson <rel...@us.ibm.com> wrote:
>
> does anyone know of good write-ups/presentations of PLO and its
> capabilities and uses for an assembler programmer who knows how to use CS
> and CDS.
>
>
> My hope is that, going forw
does anyone know of good write-ups/presentations of PLO and its
capabilities and uses for an assembler programmer who knows how to use CS
and CDS.
My hope is that, going forward once you have a machine that supports it
and, for those who care about z/OS under z/VM, once/if it is supported
On Sat, 16 Apr 2011 19:49:42 -0700 Edward Jaffe edja...@phoenixsoftware.com
wrote:
:On 4/16/2011 6:28 PM, Binyamin Dissen wrote:
: ... the basic advantage of the
: PLO is that it avoids the need for locks with non-contiguous serialized
areas
: if the retry rate is low.
:Also, unlike CD[S], PLO
On Apr 17, 2011, at 05:58, John McKown wrote:
Please forgive my ignorance, but I don't know what you mean by n
locked operations to per performed simultaneously. Do you mean that the
other three operations: TS, CS, and CDS cause all other CPs in a CEC to
stop processing instructions (at an
On 4/16/2011 6:28 PM, Binyamin Dissen wrote:
... the basic advantage of the
PLO is that it avoids the need for locks with non-contiguous serialized areas
if the retry rate is low.
Also, unlike CD[S], PLO allows for up to 'n' (model dependent) locked operations
to be performed simultaneously
Edward,
No doubt about it. PLO is a great instruction!
Difficult to understand at first, and the operand mapping could drive a
troll to fits, but it is very fast.
My point was that some of the PLO variants use lots of registers.
John P. Baker
-Original Message-
From: IBM Mainframe
16 matches
Mail list logo
