info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: The Transaction state (was Model 2827 New Instructions)
109 views
Skip to first unread message
Peter Relson
Sep 19, 2012, 8:26:12 AM9/19/12
to
In z/OS 1.13 it is true that the intended "for real" user is Java.
z/OS 1.13 provides support for transactional execution only
as a test environment. This is identified by bit CVTTXTE which is
documented in the hold for doc for APAR OA38829 (PTF UA66429):
398 (18E) BITSTRING 1 CVTCTLFG - System Control Flags
1... .... CVTTXTE X'80' - A Transactional
Execution test
environment is available.
When only such a test
environment exists, you
should not use
Transactional Execution
in product code. In this
test environment, the
limited diagnostic data
available upon such
failures as program
interrupts may well be
inadequate to debug
programs
I.e., if that bit is off, you cannot use transactional execution.
If it is on, transactional execution should be used only in a test
environment.
>Only the updater needs to use the transaction state ("TS"). Scanners
>won't interfere with him. Other updaters (whether they're also in the
>transaction state or not!) may interfere. I.e. they may try to update
>the same fields at the same time. This is called a "collision"...
Correction: Scanners *do* interfere with him. Their read access
conflicts with the updater's write access. AND unless the update can
be done with a constrained transaction, none of this does any good
because a fallback path is needed which does obtain the serialization,
and that serialization would need to be obtained by the reader to
serialize against an updater using that fallback path.
Fortunately, with care, many updates can be done with a constrained
transaction.
>It seems to be an extended PLO instruction.
In a way, yes. It is a PLO "environment". But much more. Keep in mind,
for example, that PLO serializes only against other uses of PLO. It
does not serialize against (for example) users of CS for the same
field(s).
>From my read of the doc it appears that TS only serializes with other
code
>equally doing TS. I don't see how non-TS code running a linked-list is
>protected if the TS code removes an item from the list.
But it is. The point really is that the transactional remover cannot
remove
while the runner is running through that part of the queue because the
runner is accessing data for "read" which conflicts with the remover's
accessing of the same data for "write". Once the runner is beyond that
point
(or if it has not yet gotten up to that point) the removal can occur, so
when the runner gets there it will find the update already done (or if it
is beyond, it will not care that an earlier part of the queue has been
changed).
>"abort random transactions at a random instruction".
This capability is not supported by z/OS 1.13.
Peter Relson
z/OS Core Technology Design
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
z/OS 1.13 provides support for transactional execution only
as a test environment. This is identified by bit CVTTXTE which is
documented in the hold for doc for APAR OA38829 (PTF UA66429):
398 (18E) BITSTRING 1 CVTCTLFG - System Control Flags
1... .... CVTTXTE X'80' - A Transactional
Execution test
environment is available.
When only such a test
environment exists, you
should not use
Transactional Execution
in product code. In this
test environment, the
limited diagnostic data
available upon such
failures as program
interrupts may well be
inadequate to debug
programs
I.e., if that bit is off, you cannot use transactional execution.
If it is on, transactional execution should be used only in a test
environment.
>Only the updater needs to use the transaction state ("TS"). Scanners
>won't interfere with him. Other updaters (whether they're also in the
>transaction state or not!) may interfere. I.e. they may try to update
>the same fields at the same time. This is called a "collision"...
Correction: Scanners *do* interfere with him. Their read access
conflicts with the updater's write access. AND unless the update can
be done with a constrained transaction, none of this does any good
because a fallback path is needed which does obtain the serialization,
and that serialization would need to be obtained by the reader to
serialize against an updater using that fallback path.
Fortunately, with care, many updates can be done with a constrained
transaction.
>It seems to be an extended PLO instruction.
In a way, yes. It is a PLO "environment". But much more. Keep in mind,
for example, that PLO serializes only against other uses of PLO. It
does not serialize against (for example) users of CS for the same
field(s).
>From my read of the doc it appears that TS only serializes with other
code
>equally doing TS. I don't see how non-TS code running a linked-list is
>protected if the TS code removes an item from the list.
But it is. The point really is that the transactional remover cannot
remove
while the runner is running through that part of the queue because the
runner is accessing data for "read" which conflicts with the remover's
accessing of the same data for "write". Once the runner is beyond that
point
(or if it has not yet gotten up to that point) the removal can occur, so
when the runner gets there it will find the update already done (or if it
is beyond, it will not care that an earlier part of the queue has been
changed).
>"abort random transactions at a random instruction".
This capability is not supported by z/OS 1.13.
Peter Relson
z/OS Core Technology Design
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
Mary Anne Matyaz
Sep 19, 2012, 9:19:21 AM9/19/12
to
Peter, did you mean to cross post this from the assembler list?
For everyone else's reference, here's part of the thread cross posted from ASSEMBL...@LISTSERV.UGA.EDU, because it's a pretty good thread:
I have reviewed the "Transactional Execution" section of the new zProOps and I see that I need to make a correction of my earlier description. Previously, I had believed that fetch accesses could not lead to collisions. That is incorrect. Fetches (both transactional and non-transactional) made against the same storage (cache lines actually) as transactional stores give rise to collisions that cause the (or a) storing transaction to abort. Consequently, the process doing the nontransactional fetch will see only pre-transaction values and will simply proceed as if nothing has happened.
So my revised description follows:
At 9/18/2012 02:46 PM, David Cole wrote [revised]:
>The transaction state is expected to replace many instances of
>acquiring either a latch or a lock. It's benefit arises because
>latches/locks do not distinguish between a "shared" need vs. an
>"exclusive" need, so all latches/locks are, effectively, "exclusive".
>
>Consider a thousand processes needing to scan a queue and one
>process, every year or so, updating that queue. The scan processes
>do not need to defend against each other, only against the updater.
>So a vast majority of the time, scanners are "unnecessarily"
>delayed. "Unnecessary" in the sense that the updater just ain't
>there, only other scanners.
>
>With the transaction state, neither scanners nor updaters need to
>acquire any latch or lock. In fact, the scanners don't need to
>acquire anything at all. They can simply scan the queue and be
>assured (a) their scan will both complete and succeed, and (b) they
>will see all queue elements either prior to update, or after update,
>but never mid-update; i.e. they will always see a coherent queue.
>
>Only the updater needs to use the transaction state ("TS"). Other
>updaters and scanners (whether they're also in the transaction state
>or not!) may interfere. I.e. they may try to see or update the same
>fields at the same time. When two processes attempt to access the
>same storage at the same time, and one of those accesses is an
>update, this is called a "collision"... (I'll call the participants
>"colliders".)
>
>- If both colliders are in the transaction state, then one will win
>(and will proceed undisturbed) and one will lose (will TABORT and
>will have to retry).
>
>- If one is in the TS state and one is not, then the one who is not
>will always win (and will see pre-update data), and the one who is
>will always have to retry.
>
>Scanners need not be in the TS state, but of course, every updater
>should be. This is because if two updaters collide when neither is
>in the TS state... well that is what you want to avoid.
IHTH Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow Road VOICE: 540-456-8536 Afton, VA 22920 FAX: 540-456-6658
For everyone else's reference, here's part of the thread cross posted from ASSEMBL...@LISTSERV.UGA.EDU, because it's a pretty good thread:
I have reviewed the "Transactional Execution" section of the new zProOps and I see that I need to make a correction of my earlier description. Previously, I had believed that fetch accesses could not lead to collisions. That is incorrect. Fetches (both transactional and non-transactional) made against the same storage (cache lines actually) as transactional stores give rise to collisions that cause the (or a) storing transaction to abort. Consequently, the process doing the nontransactional fetch will see only pre-transaction values and will simply proceed as if nothing has happened.
So my revised description follows:
At 9/18/2012 02:46 PM, David Cole wrote [revised]:
>The transaction state is expected to replace many instances of
>acquiring either a latch or a lock. It's benefit arises because
>latches/locks do not distinguish between a "shared" need vs. an
>"exclusive" need, so all latches/locks are, effectively, "exclusive".
>
>Consider a thousand processes needing to scan a queue and one
>process, every year or so, updating that queue. The scan processes
>do not need to defend against each other, only against the updater.
>So a vast majority of the time, scanners are "unnecessarily"
>delayed. "Unnecessary" in the sense that the updater just ain't
>there, only other scanners.
>
>With the transaction state, neither scanners nor updaters need to
>acquire any latch or lock. In fact, the scanners don't need to
>acquire anything at all. They can simply scan the queue and be
>assured (a) their scan will both complete and succeed, and (b) they
>will see all queue elements either prior to update, or after update,
>but never mid-update; i.e. they will always see a coherent queue.
>
>Only the updater needs to use the transaction state ("TS"). Other
>updaters and scanners (whether they're also in the transaction state
>or not!) may interfere. I.e. they may try to see or update the same
>fields at the same time. When two processes attempt to access the
>same storage at the same time, and one of those accesses is an
>update, this is called a "collision"... (I'll call the participants
>"colliders".)
>
>- If both colliders are in the transaction state, then one will win
>(and will proceed undisturbed) and one will lose (will TABORT and
>will have to retry).
>
>- If one is in the TS state and one is not, then the one who is not
>will always win (and will see pre-update data), and the one who is
>will always have to retry.
>
>Scanners need not be in the TS state, but of course, every updater
>should be. This is because if two updaters collide when neither is
>in the TS state... well that is what you want to avoid.
IHTH Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow Road VOICE: 540-456-8536 Afton, VA 22920 FAX: 540-456-6658
Steve Comstock
Sep 19, 2012, 10:59:31 AM9/19/12
to
On 9/19/2012 6:25 AM, Peter Relson wrote:
> In z/OS 1.13 it is true that the intended "for real" user is Java.
>
>
> z/OS 1.13 provides support for transactional execution only
> as a test environment. This is identified by bit CVTTXTE which is
> documented in the hold for doc for APAR OA38829 (PTF UA66429):
> 398 (18E) BITSTRING 1 CVTCTLFG - System Control Flags
> 1... .... CVTTXTE X'80' - A Transactional
> Execution test
> environment is available.
> When only such a test
> environment exists, you
> should not use
> Transactional Execution
> in product code. In this
> test environment, the
> limited diagnostic data
> available upon such
> failures as program
> interrupts may well be
> inadequate to debug
> programs
>
> I.e., if that bit is off, you cannot use transactional execution.
> If it is on, transactional execution should be used only in a test
> environment.
Peter,
> In z/OS 1.13 it is true that the intended "for real" user is Java.
>
>
> z/OS 1.13 provides support for transactional execution only
> as a test environment. This is identified by bit CVTTXTE which is
> documented in the hold for doc for APAR OA38829 (PTF UA66429):
> 398 (18E) BITSTRING 1 CVTCTLFG - System Control Flags
> 1... .... CVTTXTE X'80' - A Transactional
> Execution test
> environment is available.
> When only such a test
> environment exists, you
> should not use
> Transactional Execution
> in product code. In this
> test environment, the
> limited diagnostic data
> available upon such
> failures as program
> interrupts may well be
> inadequate to debug
> programs
>
> I.e., if that bit is off, you cannot use transactional execution.
> If it is on, transactional execution should be used only in a test
> environment.
I look at things from an application programmer's perspective. Your
comments above provoke some questions for me:
1. In z/OS 1.13, is CVTTXTE set on automatically if the hardware
is determined to be a zEC12?
2. If this bit is set on, what defines "a test environment"?
3. Is the message here that it's early days for this facility so
applications programmers should not count on the facility
being available, and if it is, it might not work as expected?
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-355-2752
http://www.trainersfriend.com
* Check out our sale of training materials at
http://www.trainersfriend.com/SpecialSale/
(sale absolutely ends 19 October, 2012)
* Let us know if you are interested in our
training materials reseller program
Tom Harper
Sep 19, 2012, 11:09:51 AM9/19/12
to
I can see that a session to be given by Dan Greiner at the upcoming SHARE in San Francisco, February 3-8, 2013 will be a hot ticket.
Dan is the editor-in-chief of the Principles of Operation and SHARE is fortunate to have him be a featured speaker.
Tom
Dan is the editor-in-chief of the Principles of Operation and SHARE is fortunate to have him be a featured speaker.
Tom
Peter Relson
Sep 20, 2012, 7:54:55 AM9/20/12
to
1. In z/OS 1.13, is CVTTXTE set on automatically if the hardware
is determined to be a zEC12?
Answer: No. Obviously you need to have the PTF installed, but
is determined to be a zEC12?
ignoring that: zEC12 running z/OS under VM does not support
transactional execution facility. CVTTXTE will not be set there.
And of course for prior releases it will never be on (your question
correctly asked only about z/OS 1.13). In general, the bit will
be on if the z/OS support is present and the STFLE facility bits for
transactional execution and constrained transactions are on. Once
the bit is on for an IPL, it will never change.
A typical coding practice would be
If CVTTXTE is off then use fallback path
Else CVTTXTE is on
Try transaction
If that aborts too much, then use fallback path
Nothing specific to a z/OS release is likely to be in this code path.
2. If this bit is set on, what defines "a test environment"?
understanding of the difference between "test" and "production".
If an unauthorized user uses a transaction it will not harm
anyone else.
3. Is the message here that it's early days for this facility so
applications programmers should not count on the facility
being available, and if it is, it might not work as expected?
commentary says it is. The full support is not present in z/OS 1.13
nor will it ever be, and the lack of that full support will make
testing and debugging difficult (if even possible).
Shmuel Metz , Seymour J.
Sep 20, 2012, 6:13:18 PM9/20/12
to
In <3682632231537456.WA....@listserv.ua.edu>, on
09/19/2012
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2 <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
09/19/2012
at 08:19 AM, Mary Anne Matyaz <maryan...@GMAIL.COM> said:
>I have reviewed the "Transactional Execution" section of the new
>zProOps
Do you have a publicly accessible URL for SA22-7832-09?
>I have reviewed the "Transactional Execution" section of the new
>zProOps
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2 <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
Sri h Kolusu
Sep 20, 2012, 6:16:52 PM9/20/12
to
Try this
http://www-01.ibm.com/support/docview.wss?uid=isg2b9de5f05a9d57819852571c500428f9a
IBM Mainframe Discussion List <IBM-...@listserv.ua.edu> wrote on
09/20/2012 03:15:49 PM:
> From: "Shmuel Metz (Seymour J.)" <shmue...@PATRIOT.NET>
> To: IBM-...@listserv.ua.edu,
> Date: 09/20/2012 03:13 PM
> Subject: Re: The Transaction state (was Model 2827 New Instructions)
http://www-01.ibm.com/support/docview.wss?uid=isg2b9de5f05a9d57819852571c500428f9a
IBM Mainframe Discussion List <IBM-...@listserv.ua.edu> wrote on
09/20/2012 03:15:49 PM:
> From: "Shmuel Metz (Seymour J.)" <shmue...@PATRIOT.NET>
> To: IBM-...@listserv.ua.edu,
> Date: 09/20/2012 03:13 PM
> Subject: Re: The Transaction state (was Model 2827 New Instructions)
Tom Marchant
Sep 21, 2012, 8:23:04 AM9/21/12
to
On Thu, 20 Sep 2012 18:15:49 -0400, Shmuel Metz (Seymour J.) wrote:
>Do you have a publicly accessible URL for SA22-7832-09?
David Bond posted this link on the Assembler list:
>Do you have a publicly accessible URL for SA22-7832-09?
http://publibfi.boulder.ibm.com/epubs/pdf/dz9zr009.pdf
And for the reference summary:
http://publibfi.boulder.ibm.com/epubs/pdf/dz9zs007.pdf
--
Tom Marchant
Shmuel Metz , Seymour J.
Sep 23, 2012, 2:18:08 AM9/23/12
to
In
<OF0C35E5BB.434C2DB4-ON88257A...@us.ibm.com>,
on 09/20/2012
at 03:16 PM, Sri h Kolusu <sko...@US.IBM.COM> said:
>Try this
>http://www-01.ibm.com/support/docview.wss?uid=isg2b9de5f05a9d57819852571c500428f9a
That's the one I used. It gives me
"To download this publication you will need to sign in to the IBM
Resource Link web site with your IBM ID and password. If you do not
have an IBM ID, you can register now (registration is free)."
<OF0C35E5BB.434C2DB4-ON88257A...@us.ibm.com>,
on 09/20/2012
at 03:16 PM, Sri h Kolusu <sko...@US.IBM.COM> said:
>Try this
>http://www-01.ibm.com/support/docview.wss?uid=isg2b9de5f05a9d57819852571c500428f9a
That's the one I used. It gives me
"To download this publication you will need to sign in to the IBM
Resource Link web site with your IBM ID and password. If you do not
have an IBM ID, you can register now (registration is free)."
Shmuel Metz , Seymour J.
Sep 23, 2012, 10:21:55 AM9/23/12
to
In <7845989131359869.WA.m...@listserv.ua.edu>, on
09/21/2012
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2 <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
09/21/2012
at 07:22 AM, Tom Marchant <m42tom-...@YAHOO.COM> said:
>David Bond posted this link on the Assembler list:
>http://publibfi.boulder.ibm.com/epubs/pdf/dz9zr009.pdf
>And for the reference summary:
>http://publibfi.boulder.ibm.com/epubs/pdf/dz9zs007.pdf
Thanks.
>David Bond posted this link on the Assembler list:
>http://publibfi.boulder.ibm.com/epubs/pdf/dz9zr009.pdf
>And for the reference summary:
>http://publibfi.boulder.ibm.com/epubs/pdf/dz9zs007.pdf
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2 <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
Steve Comstock
Sep 23, 2012, 11:32:22 PM9/23/12
to
On 9/20/2012 5:54 AM, Peter Relson wrote:
> 1. In z/OS 1.13, is CVTTXTE set on automatically if the hardware
> is determined to be a zEC12?
>
> Answer: No. Obviously you need to have the PTF installed, but
> ignoring that: zEC12 running z/OS under VM does not support
> transactional execution facility. CVTTXTE will not be set there.
> And of course for prior releases it will never be on (your question
> correctly asked only about z/OS 1.13). In general, the bit will
> be on if the z/OS support is present and the STFLE facility bits for
> transactional execution and constrained transactions are on. Once
> the bit is on for an IPL, it will never change.
>
> A typical coding practice would be
>
> If CVTTXTE is off then use fallback path
> Else CVTTXTE is on
> Try transaction
> If that aborts too much, then use fallback path
>
> Nothing specific to a z/OS release is likely to be in this code path.
>
>
> 2. If this bit is set on, what defines "a test environment"?
>
> Answer: That is not for me to say. I think everyone has a basic
> understanding of the difference between "test" and "production".
Well, it wasn't clear from your original wording if there
> 1. In z/OS 1.13, is CVTTXTE set on automatically if the hardware
> is determined to be a zEC12?
>
> Answer: No. Obviously you need to have the PTF installed, but
> ignoring that: zEC12 running z/OS under VM does not support
> transactional execution facility. CVTTXTE will not be set there.
> And of course for prior releases it will never be on (your question
> correctly asked only about z/OS 1.13). In general, the bit will
> be on if the z/OS support is present and the STFLE facility bits for
> transactional execution and constrained transactions are on. Once
> the bit is on for an IPL, it will never change.
>
> A typical coding practice would be
>
> If CVTTXTE is off then use fallback path
> Else CVTTXTE is on
> Try transaction
> If that aborts too much, then use fallback path
>
> Nothing specific to a z/OS release is likely to be in this code path.
>
>
> 2. If this bit is set on, what defines "a test environment"?
>
> Answer: That is not for me to say. I think everyone has a basic
> understanding of the difference between "test" and "production".
was some additional bit indicating 'test environment' or not.
Now I see what you were saying.
> If an unauthorized user uses a transaction it will not harm
> anyone else.
>
> 3. Is the message here that it's early days for this facility so
> applications programmers should not count on the facility
> being available, and if it is, it might not work as expected?
>
> Answer: Not really. The message is what the CVTTXTE
> commentary says it is. The full support is not present in z/OS 1.13
> nor will it ever be, and the lack of that full support will make
> testing and debugging difficult (if even possible).
>
> Peter Relson
> z/OS Core Technology Design
--
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-355-2752
http://www.trainersfriend.com
* Check out our sale of training materials at
http://www.trainersfriend.com/SpecialSale/
(sale absolutely ends 19 October, 2012)
* Let us know if you are interested in our
training materials reseller program
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-355-2752
http://www.trainersfriend.com
* Check out our sale of training materials at
http://www.trainersfriend.com/SpecialSale/
(sale absolutely ends 19 October, 2012)
* Let us know if you are interested in our
training materials reseller program
0 new messages