Transactional-Execution Facility... (continued)

[Fish-Git]

NOTE: This issue is a continuation of the original "Transactional-Execution Facility design / implementation" issue, #263.
NOTE: This issue should be considered a specific sub-issue of issue #77 "MISSING Facilities support".

The following items still remain to be done:

(Feel free to add additional items as needed)

• FORMAL TESTING:  We still need a comprehensive set of tests (preferably standalone runtests) to verify proper functionality of all aspects of TXF!  Right now we're simply using z/OS and z/VM and just presuming it's working correctly as long as both operating systems appear to function "normally", but of course that is not good enough!

• 'txf' tracing

• #define DEBUG tracing (TRACE macro)

• PTT tracing (PTT_TXF ==> PTT( PTT_CL_TXF ...)

• Constrained transactions constraint: 2. "All instructions in the transaction must be within 256 contiguous bytes of storage, including the TRANSACTION BEGIN (TBEGINC) and any TRANSACTION END instructions." (page 5-107)

• Constrained transactions constraint: 4. "The transaction’s storage operands access no more than four octowords. Note: LOAD ON CONDITION and STORE ON CONDITION are considered to reference storage regardless of the condition code." (page 5-109)

• Constrained transactions constraint: 5. "The transaction executing on this CPU, or stores by other CPUs or the channel subsystem, do not access storage operands in any 4 K-byte blocks that contain the 256 bytes of storage beginning with the TRANSACTION BEGIN (TBEGINC) instruction." (page 5-109)

• Constrained transactions constraint: 7. "Operand references made by each instruction in the transaction must be within a single double-word, except that for LOAD ACCESS MULTIPLE, LOAD MULTIPLE, LOAD MULTIPLE HIGH, STORE ACCESS MULTIPLE, STORE MULTIPLE, and STORE MULTIPLE HIGH, operand references must be within a single octoword." (page 5-109)

• PER as it relates to TXF.   (pages 4-26 to 4-40)

• SIE as it relates to TXF.   (Refer to GitHub Issue Comment below for some details)

• FPCR update on abort: "In addition to the diagnostic information saved in the TDB, when a transaction is aborted due to any data-exception program-exception condition and both the AFP-register control, bit 45 of control register 0, and the effective allow-floating-point-operation control (F) are one, the data-exception code (DXC) is placed into byte 2 of the floating-point control register (FPCR), regardless of whether filtering applies to the program-interruption condition." (page 5-97)

• Key Quiescing: "Key setting instructions (SSKE/PFMF) should cause a quiescing operation to be performed unless the Nonquiescing Key-Setting Facility (14) is installed and enabled and, for SSKE, the 'NQ' mask bit is 1 to suppress the quiescing operation." (page 5-120, 5-133 and the description of the SSKE and PFMF instructions)

Note that constraints #​4 and #​7 seem to contradict one another. One says four octowords (4x32=128 bytes) whereas the other says a single double-word (8 bytes). Unless #​4 means four octowords in total?? I suspect Constraint 5 is going to be next to impossible. Not sure what to do about 7 though.

[Fish-Git]

Folks (@Peter-J-Jansen, @Juergen-Git),

I have completed the TXF PER item (commit d5410a2). z/VM tracing now works even when there is a transaction in the range (as long as TRACE TXSUSPEND is added to your trace set of course!(*)).

Even though technically there are still some uncompleted items remaining (Formal Testing and Constrained transactions constraints 5 and 7), I would like to close this issue anyway. IMO, Constrained transactions constraints 5 and 7 are not only unclear and contradictory, but also far too difficult to implement to be worth the effort.

And our lack of a formal test suite is IMHO not that big of a deal given how thoroughly TXF has already been tested on both z/OS as well as on z/VM too.

Therefore I would like to consider this Issue as having now been completed, and therefore should be closed.

Would you agree?

---

(*)   See: "Tracing Transactions" and "TRACE TXSUSPEND/NOTXSUSPEND".

[Juergen-Git]

Hi Fish I agree: It makes sense to close those issues, given the practical experience of a stable and fully functional TXF. There are still those well-known incomplete capabilities and a few question marks around how to handle transactional stress. But as long as z/OS gets along with our implementation we can ignore them. Of course, the biggest question of all remains, whether we deliver _correct_ results in all successfully executed transactions, i.e. whether we don't miss abort situations. We simply cannot answer this question, and thus we have to let it be ambivalent until someone runs into a reproducible problem. Cheers Jürgen

[Fish-Git]

Closing.

[cfdonatucci]

Hi Guys, sorry to bother you. I was following both posts regarding this issue but it's not clear to me if it was fixed or not and how. I was able to IPL z/OS 2.4 with Hercules 4.4.1. Once started, I wanted to start RSED or zCEE but I got this error:

FEK010I (configuration directory = /S0W1/etc/zexpl/)                                                                               
FEK011I (log directory = /var/zexpl/logs/server)                                                                                   
CEE3250C The system or user abend S0E0  R=00000018 was issued.                                                                     
         From entry point ZJ9SYM1 at compile unit offset +0000000001C7D558 at entry offset -000000007AD82DB0 at address 0000000001C

According to your post I did the following configurations:

• I set this model TXF_MODEL( 8561, z15 )
• I enabled these facilities:

FACILITY    ENABLE    044_PFPO
FACILITY    ENABLE    050_CONSTR_TRANSACT
FACILITY    ENABLE    051_LOCAL_TLB_CLEARING 
FACILITY    ENABLE    073_TRANSACT_EXEC
FACILITY    ENABLE    074_STORE_HYPER_INFO

• I'm using HercGUI 1.18.

Could you please tell me if there is anything I can do to configure or to mitigate this error?

Thank you very much in advance.

Carlos

[Juergen-Git]

Hi Carlos

The majority of problems we had with TXF are solved, which is why we decided to close the issue. However, there still remain a few open problems which we cannot solve analytically. They all have to do with a vague term I'm calling transactional stress. Vague, because I can't even provide a clear metric for it. Basically, if too many constrained transactions per unit of measurement (time, cycles, or what else) get retried, stress arises. LE applications react on stress by trying to execute unconstrained transactions, which in turn can run wild (i.e. get out of control) and end up later in any kind of completely unrelated abend, with S0E0-18 being the most typical.

Sadly, all Java applications fall into this "transactional stressing" category. :-(

There are nonetheless a few things you can do, to get your application to work:

• Set the TIMERINT configuration parameter to a higher value. The default when transactional execution is enabled is 400. Try using 1200 instead.
• Use the latest ADCD level available to you. Z24D runs much smoother when it comes to Java, then A, B and C.
• Clear the CVTTX and CVTTE flags before starting your application. Once the Java VM is up, set those flags again, LE checks for them during startup only. Doing this, will completely prevent the use of unconstrained transactions by this Java VM instance and thus it will sail smoothly.

Good luck!

Jürgen

[cfdonatucci]

Hi Jurgen, Thank you for your answer. I have ADCD B. Cannot get another so far. I tried using TIMERINT 1200 and it didn’t work. Could you please tell me how to clear those flags? I could write a program, but I don’t understand when it should be run and how the following flags should be set then. I enabled these functions. FACILITY ENABLE 050_CONSTR_TRANSACT FACILITY ENABLE 051_LOCAL_TLB_CLEARING FACILITY ENABLE 073_TRANSACT_EXEC FACILITY ENABLE 074_STORE_HYPER_INFO I’d appreciate any tech tip. Carlos

[Juergen-Git]

Hi Carlos

I'm attaching quick and dirty utilities to handle those flags:

• txonoff.zip

After installing, issue S TXOFF at the console (or txoff from the z/OS Unix shell) to clear the flags, and S TXON at the console (or txon from the z/OS Unix shell) to set them. As I mentioned, clear the flags before starting a critical application (like a Java VM) and set them, after the the application has started.

Cheers
Jürgen

[cfdonatucci]

Hi Jurgen, I successfully implemented TXOFF and TXON, and both zosExpl and zCEE are working now on z/OS 2.4 B. I really appreciate your help. Regards Carlos