NOTE: This issue has been closed and is now being continued in a NEW GitHub issue, #339: "Transactional-Execution Facility... (continued) "

I have been told the recently released z/OS 2.4 requires the availability of both the Transactional-Execution Facility and Constrained-Transactional-Execution Facility in order to successfully IPL:

Transactional-Execution enforcement

z/OS V2.4 provides enforcement to the effect that hardware Transactional-Execution, available on IBM Z servers since zEC12, is always available to programs running on z/OS V2.4 so that programs in such an environment can unconditionally assume and make use of Transactional-Execution.

https://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/0/877/ENUSZP19-0410/index.html

This GitHub Issue is being created so that we can, together, discuss how best to implement this facility. Please offer your suggested approach/design as a GitHub comment reply to this issue.

I myself have a vague idea of how maybe it might be implemented, but I don't know if it will even fly nor especially how good it is. It's entirely possible (even likely!) that one of you might be able to come up with a better idea. (Please?)

Besides the description of the facility in the Principles of Operation manual, here are some additional papers I found on the subject to help get your creative juices flowing:

Transactional-Execution Facility.zip

I've also assigned everyone to this issue because I really, really want everyone to contribute with their own thoughts/ideas on how is the best way to implement this facility in Hercules.

Thanks!

_NOTE: This issue should be considered a specific sub-issue of issue #77 "MISSING Facilities support".__

EDIT: 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!
[x] 'txf' tracing
[x] #define DEBUG tracing (TRACE macro)
[x] PTT tracing (PTT_TXF ==> PTT( PTT_CL_TXF ...)
[x] 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)
[x] 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++, 5-89++)
[x] SIE as it relates to TXF. (Refer to GitHub Issue Comment below for some details)
[x] 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)

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?? Constraint 5 is going to be next to impossible. Not sure about 7.

In a few days I intend to start participating with this TXF effort. But I am a bit confused as to where the most current source / repo is. I know about the fork by Fish: https://github.com/Fish-Git/hyperion-fish-txf, but is this also where Bob's contributions ended up in, e.g. his last fix to sie.c? Did Bob also experience the continuous PIC 12 problem (Issue #275)?

Cheers,

Peter

Peter Jansen wrote:

In a few days I intend to start participating with this TXF effort. But I am a bit confused as to where the most current source / repo is. I know about the fork by Fish: https://github.com/Fish-Git/hyperion-fish-txf, ...

That is indeed the latest and greatest TXF version, as far as I know!

... but is this also where Bob's contributions ended up in, e.g. his last fix to sie.c?

I was not aware that Bob made a fix to sie.c! If he did, I am not seeing it in either repo! Can you provide more information about this claimed fix of his?

ALL TXF development (and thus testing too, obviously) should be done with only my hyperion-fish-txf fork. It started out with Bob's original code (which I called "bob raw") and was followed by a long series of cosmetic updates to reach what I then called the "bob clean" state (basically still his original code but "cleaned up" a bit).

This was then followed by a short series of non-cosmetic changes made by myself to fix things which I felt were wrong (bugs). That's where we're at now.

But I am unaware of any "fix" to sie.c that Bob has made recently! I was not aware of that! Please tell me more!

Anyway, the current version of fish-txf (*) seems to be working mostly great!

There are still some problems with it however, which we're still trying to track down, but all-in-all it seems to mostly work. I would like to encourage *ALL of you to please help out by giving it a try and reporting back any problems you experience with it (not here! as an issue in the fish-txf repo instead!) so we can shake all the bugs out of it.

My fish-txf repo was created so that we can all work on TXF without impacting our current repo. Once TXF appears to be complete, all of the changes (commits) made to fish-txf will then be merged into our existing repo and released for general use to our general user population.

Thanks.

(*) It's only a name, folks! I'm not trying to get credit for Bob's hard work! No, no, no! It's only called "fish-txf" because it's "my" fork, created under my personal GitHub account/userid. Bob will get FULL credit for TXF, believe you me!!

Is there a pre-built binary of this?

Richard Pinion rpinion@netscape.com

-----Original Message----- From: Fish-Git notifications@github.com To: SDL-Hercules-390/hyperion hyperion@noreply.github.com Cc: rpinion rpinion@netscape.com; Mention mention@noreply.github.com Sent: Mon, Jan 20, 2020 5:09 pm Subject: Re: [SDL-Hercules-390/hyperion] Transactional-Execution Facility design / implementation (#263)

Peter Jansen wrote: In a few days I intend to start participating with this TXF effort. But I am a bit confused as to where the most current source / repo is. I know about the fork by Fish: https://github.com/Fish-Git/hyperion-fish-txf, ... That is indeed the latest and greatest TXF version, as far as I know! ... but is this also where Bob's contributions ended up in, e.g. his last fix to sie.c? I was not aware that Bob made a fix to sie.c! If he did, I am not seeing it in either repo! Can you provide more information about this claimed fix of his?ALL TXF development (and thus testing too, obviously) should be done with only my hyperion-fish-txf fork. It started out with Bob's original code (which I called "bob raw") and was followed by a long series of cosmetic updates to reach what I then called the "bob clean" state (basically still his original code but "cleaned up" a bit).This was then followed by a short series of non-cosmetic changes made by myself to fix things which I felt were wrong (bugs). That's where we're at now.But I am unaware of any "fix" to sie.c that Bob has made recently! I was not aware of that! Please tell me more!Anyway, the current version of fish-txf () seems to be working mostly great!There are still some problems with it however, which we're still trying to track down, but all-in-all it seems to mostly work. I would like to encourage ALL of you to please help out by giving it a try and reporting back any problems you experience with it (not here! as an issue in the fish-txf repo instead!) so we can shake all the bugs out of it.My fish-txf repo was created so that we can all work on txf without impacting our current repo. Once TXF appears to be complete, all of the changes (commits) made to fish-txf will then be merged into our existing repo and released for general use to our general user population.Thanks.(*) It's only a name, folks! I'm not trying to get credit for Bob's hard work! No, no, no! It's only called "fish-txf" because it's "my" fork, created under my personal GitHub account/userid. Bob will get FULL credit for TXF, believe you me!!— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

Is there a pre-built binary of this?

No. :(

But I suppose I can create one. Give me a few minutes.

p.s. FYI: "z/OS 2.4 continuous PIC 12".

Is there a pre-built binary of this?

No. :(

But I suppose I can create one. Give me a few minutes.

Here you go!

fish-txf.zip

*** Be sure to read the README! ***

Bob mentionned his sie.c update in here but in the mean time I'm pretty sure it refers to this commit. So all is clear to me now, I know where to build from.

Cheers,

Peter

Bob mentionned his sie.c update in here but in the mean time I'm pretty sure it refers to this commit.

Ah. Yes. You're right. I forgot all about that. Sorry. My bad.

So all is clear to me now, I know where to build from.

Cool! The more people we have testing and finding bugs, the better.

I'm still working on sprinkling some PTT tracing statements throughout TXF code, and then afterwards I still want to add support for a new t+txf tracing command that will allow us to trace things like the PDB whenever it's filled in during an abort, etc

But before I do that, I want to work on Ivan's issues first. Then after Ivan's issues, I'll add t+txf support.

Of course before I do either one of those I have to first go see my doctor about a minor(?) health issue: a new pain I'm having that's becoming annoying enough to impact my ability to sit at my desk and work on Hercules! (And anything that impacts my ability to work on Hercules is a concern!)

With the binary you sent me yesterday, I am able to run 2.4. But, I still can't run with more than one CPU.I get a wait state shortly after IPL. Here is the wait state code, Processor CP00: disabled wait state 0002000080000000 0000000000009064. I'm attaching a file that has my configuration and the Hercules log.

Richard Pinion rpinion@netscape.com

-----Original Message----- From: Fish-Git notifications@github.com To: SDL-Hercules-390/hyperion hyperion@noreply.github.com Cc: rpinion rpinion@netscape.com; Mention mention@noreply.github.com Sent: Tue, Jan 21, 2020 5:20 pm Subject: Re: [SDL-Hercules-390/hyperion] Transactional-Execution Facility design / implementation (#263)

Bob mentionned his sie.c update in here but in the mean time I'm pretty sure it refers to this commit. Ah. Yes. You're right. I forgot all about that. Sorry. My bad. So all is clear to me now, I know where to build from. Cool! The more people we have testing and finding bugs, the better.I'm still working on sprinkling some PTT tracing statements throughout TXF code, and then afterwards I still want to add support for a new t+txf tracing command that will allow us to trace things like the PDB whenever it's filled in during an abort, etcBut before I do that, I want to work on Ivan's issues first. Then after Ivan's issues, I'll add t+txf support.Of course before I do either one of those I have to first go see my doctor about a minor(?) health issue: a new pain I'm having that's becoming annoying enough to impact my ability to sit at my desk and work on Hercules! (And anything that impacts my ability to work on Hercules is a concern!)— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

Hercules Emulator Control file...

Description:

MaxShutdownSecs: 15

LoadUnit:

RCFile:

LogoFile:

IgnoreParseErrors: 0

HercGUI Version: 1.12.9.3467

System parameters

FACILITY ENABLE 006_ASN_LX_REUSE FACILITY ENABLE 044_PFPO FACILITY ENABLE 73 FACILITY ENABLE 50

MAXCPU 2

MAXCPU 1

ENGINES CP,CP

ENGINES CP

NUMCPU 2

NUMCPU 1

NUMVEC 1

HERCPRIO 0 TODPRIO -20 DEVPRIO 8 CPUPRIO 15

AUTO_SCSI_MOUNT NO CNSLPORT 3270 CONKPALV (3,1,10) CODEPAGE default CPUMODEL 2098 CPUSERIAL 0E45A4 CPUVERID 00 DEVTMAX 8 DIAG8CMD DISABLE NOECHO ECPSVM NO MODPATH D:/hercules/4.1 LEGACYSENSEID DISABLE LOADPARM 0AAA00M1 LPARNUM 01 LPARNAME HERCULES MAINSIZE 6G MANUFACTURER HRC MODEL EMULATOR "" "" "" MOUNTED_TAPE_REINIT ALLOW OSTAILOR Z/OS PANRATE 50 PGMPRDOS LICENSED PLANT ZZ SHCMDOPT ENABLE NODIAG8 SYSEPOCH 1900 TIMERINT 50 TRACEOPT TRADITIONAL TZOFFSET -0000 XPNDSIZE 0 YROFFSET 0

Display Terminals

0700-0701 3270 0702 3270 * 127.0.0.1

DASD Devices

0D02 3390 H:/HerculesDasdFiles/LDAV01 cu=3990-6 0D03 3390 H:/zos24/CFG001 cu=3990-6 0D00 3390 H:/HerculesDasdFiles/SARES1 cu=3990-6 0A94 3390 H:/HerculesDasdFiles/SPL001 cu=3990-6 0A95 3390 H:/HerculesDasdFiles/SPOOL2 cu=3990-6 0A96 3390 H:/HerculesDasdFiles/LDAV04 cu=3990-6 0A9A 3390 H:/HerculesDasdFiles/LDAV07 cu=3990-6 0A9B 3390 H:/HerculesDasdFiles/LDAV08 cu=3990-6 0A9D 3390 H:/HerculesDasdFiles/JAIMS1 cu=3990-6 0A9F 3390 H:/HerculesDasdFiles/LDAV05 cu=3990-6 0D0A 3390 H:/HerculesDasdFiles/LDA023 cu=3990-6 0D0B 3390 H:/HerculesDasdFiles/LDAV03 cu=3990-6 0D11 3390 H:/HerculesDasdFiles/LDA074 cu=3990-6 0D12 3390 T:/HerculesDasdFiles/LDA004 cu=3990-6 0D13 3390 T:/HerculesDasdFiles/LDA007 cu=3990-6 0D14 3390 T:/HerculesDasdFiles/LDA008 cu=3990-6 0D15 3390 T:/HerculesDasdFiles/LDA009 cu=3990-6 0D16 3390 T:/HerculesDasdFiles/LDA00A cu=3990-6

0A8A 3390 H:/HerculesDasdFiles/a3sys1 cu=3990-6 0A8B 3390 H:/HerculesDasdFiles/a3cfg1 cu=3990-6 0A8C 3390 H:/HerculesDasdFiles/a3dis1 cu=3990-6 0A8D 3390 H:/HerculesDasdFiles/a3dis2 cu=3990-6 0A8E 3390 H:/HerculesDasdFiles/a3dis3 cu=3990-6 0A8F 3390 H:/HerculesDasdFiles/a3res1 cu=3990-6 0A90 3390 H:/HerculesDasdFiles/a3res2 cu=3990-6

0AA0 3390 H:/zos24/a4res2 cu=3990-6 0AA1 3390 H:/zos24/a4usr1 cu=3990-6 0AA2 3390 H:/zos24/a4uss1 cu=3990-6 0AA3 3390 H:/zos24/a4uss2 cu=3990-6 0AA4 3390 H:/zos24/a4cfg1 cu=3990-6 0AA5 3390 H:/zos24/a4dis1 cu=3990-6 0AA6 3390 H:/zos24/a4dis2 cu=3990-6 0AA7 3390 H:/zos24/a4dis3 cu=3990-6 0AAA 3390 H:/zos24/a4sys1 cu=3990-6 0AAC 3390 H:/zos24/a4prd1 cu=3990-6 0AAD 3390 H:/zos24/a4prd2 cu=3990-6 0AAE 3390 H:/zos24/a4prd3 cu=3990-6 0AAF 3390 H:/zos24/a4res1 cu=3990-6 0AB0 3390 H:/zos24/a4prd4 cu=3990-6

TAPE Devices

0583 3490 T:/herculesawstapefiles/000004.aws awstape maxsizeM=170 eotmargin=131072

CTC Adapters

0E20-0E21 LCS --dev 192.168.1.81 192.168.1.106

08:35:30.139 **** HHC046I Acceptance of PGMPRDOS LICENSED setting verified 08:35:30.139 **** Program to be executed = D:/hercules/4.1/Hercules.exe 08:35:30.139 **** Control file to be used = D:/hercules/zos240.txt 08:35:30.144 Hercules started; process-id=00000694 08:35:30.173 00000694 HHC00100I Thread id 00001e34, prio 5, name 'impl_thread' started 08:35:30.173 00000694 HHC00100I Thread id 00003148, prio 4, name 'logger_thread' started 08:35:30.173 00000694 HHC01413I Hercules version 4.3.9999.9922-SDL-g1f6c1632 (4.3.9999.9922) 08:35:30.173 00000694 HHC01414I (C) Copyright 1999-2019 by Roger Bowler, Jan Jaeger, and others 08:35:30.173 00000694 HHC01417I EXPERIMENTAL TXF DEVELOPMENT VERSION 08:35:30.173 00000694 HHC01415I Build date: Jan 20 2020 at 15:13:29 08:35:30.173 00000694 HHC01417I Built with: Microsoft Visual Studio 2008 (MSVC 150030729 1) 08:35:30.173 00000694 HHC01417I Build type: Windows MSVC AMD64 host architecture build 08:35:30.173 00000694 HHC01417I Modes: S/370 ESA/390 z/Arch 08:35:30.173 00000694 HHC01417I Max CPU Engines: 64 08:35:30.173 00000694 HHC01417I Using shared libraries 08:35:30.173 00000694 HHC01417I Using Fish threads Threading Model 08:35:30.173 00000694 HHC01417I Using Error-Checking Mutex Locking Model 08:35:30.173 00000694 HHC01417I With Shared Devices support 08:35:30.173 00000694 HHC01417I With Dynamic loading support 08:35:30.173 00000694 HHC01417I With External GUI support 08:35:30.173 00000694 HHC01417I With Partial TCP keepalive support 08:35:30.173 00000694 HHC01417I With IPV6 support 08:35:30.173 00000694 HHC01417I With HTTP Server support 08:35:30.173 00000694 HHC01417I With sqrtl support 08:35:30.173 00000694 HHC01417I With Signal handling 08:35:30.173 00000694 HHC01417I With CCKD BZIP2 support 08:35:30.173 00000694 HHC01417I With HET BZIP2 support 08:35:30.173 00000694 HHC01417I With ZLIB support 08:35:30.173 00000694 HHC01417I With Regular Expressions support 08:35:30.173 00000694 HHC01417I With Object REXX support 08:35:30.173 00000694 HHC01417I Without Regina REXX support 08:35:30.173 00000694 HHC01417I With Automatic Operator support 08:35:30.173 00000694 HHC01417I Without National Language Support 08:35:30.173 00000694 HHC01417I With CCKD64 Support 08:35:30.173 00000694 HHC01417I With Transactional-Execution Facility support 08:35:30.173 00000694 HHC01417I Machine dependent assists: cmpxchg1 cmpxchg4 cmpxchg8 cmpxchg16 hatomics=msvcIntrinsics 08:35:30.173 00000694 HHC01417I Running on: RPINION-PC (Windows-6.2.9200 Intel(R) x64) LP=8, Cores=4, CPUs=1 08:35:30.173 00000694 HHC01417I Built with crypto external package version 1.0.0.31-gbf46d03 08:35:30.173 00000694 HHC01417I Built with decNumber external package version 3.68.0.84-g94144c9 08:35:30.173 00000694 HHC01417I Built with SoftFloat external package version 3.5.0.87-gb706677 08:35:30.173 00000694 HHC01417I Built with telnet external package version 1.0.0.48-gb90a708 08:35:30.173 00000694 HHC00018I Hercules is running in elevated mode 08:35:30.173 00000694 HHC02323W This build of Hercules has only partial TCP keepalive support 08:35:30.173 00000694 HHC00007I Previous message from function 'impl' at impl.c(865) 08:35:30.176 00000694 HHC00150I Crypto module loaded (C) Copyright 2003-2016 by Bernard van der Helm 08:35:30.176 00000694 HHC00151I Activated facility: Message Security Assist 08:35:30.176 00000694 HHC00151I Activated facility: Message Security Assist Extension 1, 2, 3 and 4 08:35:30.182 00000694 HHC17531W REXX(OORexx) dlopen 'rexx.dll' failed: The specified module could not be found. 08:35:30.182 00000694 HHC00007I Previous message from function 'OORexxLoad' at hRexxapi.c(1304) 08:35:30.182 00000694 HHC17511E REXX() Could not enable either Rexx package 08:35:30.182 00000694 HHC00007I Previous message from function 'Enable' at hRexx.c(514) 08:35:30.182 00000694 HHC17511E REXX() Could not enable default Rexx package 08:35:30.182 00000694 HHC00007I Previous message from function 'InitializeRexx' at hRexx.c(261) 08:35:30.182 00000694 HHC17500I REXX() Mode : Command 08:35:30.182 00000694 HHC17500I REXX() MsgLevel : Off 08:35:30.182 00000694 HHC17500I REXX() MsgPrefix : Off 08:35:30.182 00000694 HHC17500I REXX() ErrPrefix : Off 08:35:30.182 00000694 HHC17500I REXX() Resolver : On 08:35:30.182 00000694 HHC17500I REXX() SysPath (24) : On 08:35:30.182 00000694 HHC17500I REXX() RexxPath ( 0) : 08:35:30.182 00000694 HHC17500I REXX() Extensions ( 8) : .REXX;.rexx;.REX;.rex;.CMD;.cmd;.RX;.rx 08:35:30.185 00000694 HHC00111I Thread CPU Time IS available (_POSIX_THREAD_CPUTIME=1) 08:35:30.185 00000694 HHC00100I Thread id 00000620, prio 2, name 'Processor CP00' started 08:35:30.185 00000694 HHC00811I Processor CP00: architecture mode z/Arch 08:35:30.185 00000694 HHC00100I Thread id 00002f30, prio 7, name 'timer_thread' started 08:35:30.185 00000694 HHC00898I Facility( 006_ASN_LX_REUSE ) Enabled for z/Arch 08:35:30.185 00000694 HHC00898I Facility( 044_PFPO ) Enabled for z/Arch 08:35:30.185 00000694 HHC00898I Facility( 073_TRANSACT_EXEC ) Enabled for z/Arch 08:35:30.185 00000694 HHC00898I Facility( 050_CONSTR_TRANSACT ) Enabled for z/Arch 08:35:30.185 00000694 HHC02204I MAXCPU set to 2 08:35:30.185 00000694 HHC00827I Processor CP00: engine 00 type 0 set: CP 08:35:30.185 00000694 HHC00827I Processor CP01: engine 01 type 0 set: CP 08:35:30.185 00000694 HHC00100I Thread id 000017d8, prio 2, name 'Processor CP01' started 08:35:30.185 00000694 HHC00811I Processor CP01: architecture mode z/Arch 08:35:30.186 00000694 HHC02204I NUMCPU set to 2 08:35:30.186 00000694 HHC01441E Config file[28] D:/hercules/zos240.txt: error processing statement: NUMVEC 1 08:35:30.186 00000694 HHC00007I Previous message from function 'process_config' at script.c(431) 08:35:30.186 00000694 HHC02256W Command 'HERCPRIO' is deprecated and ignored. 08:35:30.186 00000694 HHC00007I Previous message from function 'deprecated_cmd' at hsccmd.c(3369) 08:35:30.186 00000694 HHC02256W Command 'TODPRIO' is deprecated and ignored. 08:35:30.186 00000694 HHC00007I Previous message from function 'deprecated_cmd' at hsccmd.c(3369) 08:35:30.186 00000694 HHC02256W Command 'DEVPRIO' is deprecated and ignored. 08:35:30.186 00000694 HHC00007I Previous message from function 'deprecated_cmd' at hsccmd.c(3369) 08:35:30.186 00000694 HHC02256W Command 'CPUPRIO' is deprecated and ignored. 08:35:30.186 00000694 HHC00007I Previous message from function 'deprecated_cmd' at hsccmd.c(3369) 08:35:30.186 00000694 HHC02204I AUTO_SCSI_MOUNT set to NO 08:35:30.186 00000694 HHC02323W This build of Hercules has only partial TCP keepalive support 08:35:30.186 00000694 HHC00007I Previous message from function 'conkpalv_cmd' at hsccmd.c(7743) 08:35:30.186 00000694 HHC02204I conkpalv set to (3,1,10) 08:35:30.186 00000694 HHC01474I Using internal codepage conversion table default 08:35:30.186 00000694 HHC02204I CPUMODEL set to 2098 08:35:30.186 00000694 HHC02204I CPUSERIAL set to 0E45A4 08:35:30.186 00000694 HHC02204I CPUVERID set to 00 08:35:30.186 00000694 HHC02204I DIAG8CMD set to DISABLE NOECHO 08:35:30.186 00000694 HHC02204I ECPSVM set to disabled 08:35:30.186 00000694 HHC01508I HDL: loadable module directory is 'D:/hercules/4.1' 08:35:30.186 00000694 HHC02204I MODPATH set to D:/hercules/4.1 08:35:30.186 00000694 HHC02204I LEGACYSENSEID set to disabled 08:35:30.186 00000694 HHC02204I LOADPARM set to 0AAA00M1 08:35:30.186 00000694 HHC02204I LPARNUM set to 01 08:35:30.186 00000694 HHC02204I LPARNAME set to HERCULES 08:35:30.197 00000694 HHC17003I MAIN storage is 6G (mainsize); storage is not locked 08:35:30.197 00000694 HHC02204I MANUFACTURER set to HRC 08:35:30.197 00000694 HHC02204I MODEL set to hardware(EMULATOR) capacity(EMULATOR) perm() temp() 08:35:30.197 00000694 HHC02204I MOUNTED_TAPE_REINIT set to enabled 08:35:30.197 00000694 HHC02204I PANRATE set to 50 08:35:30.197 00000694 HHC02204I PLANT set to ZZ 08:35:30.197 00000694 HHC02204I SHCMDOPT set to ENABLE NODIAG8 08:35:30.197 00000694 HHC02204I TIMERINT set to 50 08:35:30.198 00000694 HHC02204I TRACEOPT set to TRADITIONAL 08:35:30.198 00000694 HHC02204I TZOFFSET set to -0000 08:35:30.198 00000694 HHC17003I EXPANDED storage is 0 (xpndsize); storage is not locked 08:35:30.198 00000694 HHC02204I YROFFSET set to 0 08:35:30.210 00000694 HHC00100I Thread id 000020d4, prio 4, name 'console_connect' started 08:35:30.210 00000694 HHC01024I Waiting for console connections on port 3270 08:35:30.210 00000694 HHC00414I 0:0D02 CKD file H:/HerculesDasdFiles/LDAV01: model 3390-3 cyls 3339 heads 15 tracks 50085 trklen 56832 08:35:30.210 00000694 HHC00414I 0:0D03 CKD file H:/zos24/CFG001: model 3390-27 cyls 32760 heads 15 tracks 491400 trklen 56832 08:35:30.210 00000694 HHC00401E 0:0D00 CKD file H:/HerculesDasdFiles/SARES1: open error: not found 08:35:30.210 00000694 HHC00007I Previous message from function 'ckd_dasd_init_handler' at ckddasd.c(249) 08:35:30.210 00000694 HHC01463E 0:0D00 device initialization failed 08:35:30.210 00000694 HHC00007I Previous message from function 'attach_device' at config.c(1321) 08:35:30.211 00000694 HHC00414I 0:0A94 CKD file H:/HerculesDasdFiles/SPL001: model 3390-3 cyls 3339 heads 15 tracks 50085 trklen 56832 08:35:30.220 00000694 HHC00414I 0:0A95 CKD file H:/HerculesDasdFiles/SPOOL2: model 3390-9 cyls 10017 heads 15 tracks 150255 trklen 56832 08:35:30.220 00000694 HHC00414I 0:0A96 CKD file H:/HerculesDasdFiles/LDAV04: model 3390-3 cyls 3339 heads 15 tracks 50085 trklen 56832 08:35:30.228 00000694 HHC00414I 0:0A9A CKD file H:/HerculesDasdFiles/LDAV07: model 3390-3 cyls 3339 heads 15 tracks 50085 trklen 56832 08:35:30.236 00000694 HHC00414I 0:0A9B CKD file H:/HerculesDasdFiles/LDAV08: model 3390-3 cyls 3339 heads 15 tracks 50085 trklen 56832 08:35:30.244 00000694 HHC00414I 0:0A9D CKD file H:/HerculesDasdFiles/JAIMS1: model 3390-3 cyls 3339 heads 15 tracks 50085 trklen 56832 08:35:30.244 00000694 HHC00414I 0:0A9F CKD file H:/HerculesDasdFiles/LDAV05: model 3390-3 cyls 3339 heads 15 tracks 50085 trklen 56832 08:35:30.245 00000694 HHC00414I 0:0D0A CKD file H:/HerculesDasdFiles/LDA023: model 3390-27 cyls 32760 heads 15 tracks 491400 trklen 56832 08:35:30.303 00000694 HHC00414I 0:0D0B CKD file H:/HerculesDasdFiles/LDAV03: model 3390-3 cyls 3339 heads 15 tracks 50085 trklen 56832 08:35:30.311 00000694 HHC00414I 0:0D11 CKD file H:/HerculesDasdFiles/LDA074: model 3390-9 cyls 10017 heads 15 tracks 150255 trklen 56832 08:35:30.312 00000694 HHC00414I 0:0D12 CKD file T:/HerculesDasdFiles/LDA004: model 3390-9 cyls 10017 heads 15 tracks 150255 trklen 56832 08:35:30.312 00000694 HHC00414I 0:0D13 CKD file T:/HerculesDasdFiles/LDA007: model 3390-9 cyls 10017 heads 15 tracks 150255 trklen 56832 08:35:30.312 00000694 HHC00414I 0:0D14 CKD file T:/HerculesDasdFiles/LDA008: model 3390-9 cyls 10017 heads 15 tracks 150255 trklen 56832 08:35:30.313 00000694 HHC00414I 0:0D15 CKD file T:/HerculesDasdFiles/LDA009: model 3390-9 cyls 10017 heads 15 tracks 150255 trklen 56832 08:35:30.313 00000694 HHC00414I 0:0D16 CKD file T:/HerculesDasdFiles/LDA00A: model 3390-9 cyls 10017 heads 15 tracks 150255 trklen 56832 08:35:30.313 00000694 HHC00414I 0:0A8A CKD file H:/HerculesDasdFiles/a3sys1: model 3390-9 cyls 10017 heads 15 tracks 150255 trklen 56832 08:35:30.314 00000694 HHC00414I 0:0A8B CKD file H:/HerculesDasdFiles/a3cfg1: model 3390-9 cyls 10017 heads 15 tracks 150255 trklen 56832 08:35:30.314 00000694 HHC00414I 0:0A8C CKD file H:/HerculesDasdFiles/a3dis1: model 3390-9 cyls 10017 heads 15 tracks 150255 trklen 56832 08:35:30.314 00000694 HHC00414I 0:0A8D CKD file H:/HerculesDasdFiles/a3dis2: model 3390-9 cyls 10017 heads 15 tracks 150255 trklen 56832 08:35:30.315 00000694 HHC00414I 0:0A8E CKD file H:/HerculesDasdFiles/a3dis3: model 3390-9 cyls 10017 heads 15 tracks 150255 trklen 56832 08:35:30.315 00000694 HHC00414I 0:0A8F CKD file H:/HerculesDasdFiles/a3res1: model 3390-27 cyls 30051 heads 15 tracks 450765 trklen 56832 08:35:30.315 00000694 HHC00414I 0:0A90 CKD file H:/HerculesDasdFiles/a3res2: model 3390-27 cyls 30051 heads 15 tracks 450765 trklen 56832 08:35:30.315 00000694 HHC00414I 0:0AA0 CKD file H:/zos24/a4res2: model 3390-9 cyls 10017 heads 15 tracks 150255 trklen 56832 08:35:30.316 00000694 HHC00414I 0:0AA1 CKD file H:/zos24/a4usr1: model 3390-9 cyls 10017 heads 15 tracks 150255 trklen 56832 08:35:30.316 00000694 HHC00414I 0:0AA2 CKD file H:/zos24/a4uss1: model 3390-9 cyls 10017 heads 15 tracks 150255 trklen 56832 08:35:30.316 00000694 HHC00414I 0:0AA3 CKD file H:/zos24/a4uss2: model 3390-9 cyls 10017 heads 15 tracks 150255 trklen 56832 08:35:30.317 00000694 HHC00414I 0:0AA4 CKD file H:/zos24/a4cfg1: model 3390-9 cyls 10017 heads 15 tracks 150255 trklen 56832 08:35:30.317 00000694 HHC00414I 0:0AA5 CKD file H:/zos24/a4dis1: model 3390-9 cyls 10017 heads 15 tracks 150255 trklen 56832 08:35:30.317 00000694 HHC00414I 0:0AA6 CKD file H:/zos24/a4dis2: model 3390-9 cyls 10017 heads 15 tracks 150255 trklen 56832 08:35:30.317 00000694 HHC00414I 0:0AA7 CKD file H:/zos24/a4dis3: model 3390-9 cyls 10017 heads 15 tracks 150255 trklen 56832 08:35:30.318 00000694 HHC00414I 0:0AAA CKD file H:/zos24/a4sys1: model 3390-9 cyls 10017 heads 15 tracks 150255 trklen 56832 08:35:30.318 00000694 HHC00414I 0:0AAC CKD file H:/zos24/a4prd1: model 3390-9 cyls 10017 heads 15 tracks 150255 trklen 56832 08:35:30.318 00000694 HHC00414I 0:0AAD CKD file H:/zos24/a4prd2: model 3390-9 cyls 10017 heads 15 tracks 150255 trklen 56832 08:35:30.318 00000694 HHC00414I 0:0AAE CKD file H:/zos24/a4prd3: model 3390-9 cyls 10017 heads 15 tracks 150255 trklen 56832 08:35:30.319 00000694 HHC00414I 0:0AAF CKD file H:/zos24/a4res1: model 3390-9 cyls 10017 heads 15 tracks 150255 trklen 56832 08:35:30.319 00000694 HHC00414I 0:0AB0 CKD file H:/zos24/a4prd4: model 3390-9 cyls 10017 heads 15 tracks 150255 trklen 56832 08:35:30.322 00000694 HHC00221I 0:0583 Tape file T:/herculesawstapefiles/000004.aws, type AWS: format type AWS Format tape file 08:35:30.322 00000694 HHC00222I 0:0583 Tape file T:/herculesawstapefiles/000004.aws, type AWS: option awstape accepted 08:35:30.322 00000694 HHC00222I 0:0583 Tape file T:/herculesawstapefiles/000004.aws, type AWS: option maxsizeM accepted 08:35:30.322 00000694 HHC00222I 0:0583 Tape file T:/herculesawstapefiles/000004.aws, type AWS: option eotmargin accepted 08:35:30.322 00000694 HHC00224I 0:0583 Tape file T:/herculesawstapefiles/000004.aws, type AWS: display " NT RDY " 08:35:30.334 00000694 HHC04100I TunTap64.dll version 3.6.2.4906 initiated 08:35:30.586 00000694 HHC04100I TunTap64.dll version 3.6.2.4906 initiated 08:35:30.587 00000694 HHC00901I 0:0E20 LCS: Interface tap0, type TAP opened 08:35:30.588 00000694 HHC00921I CTC: lcs device port 00: tuntap Multicast assist enabled 08:35:30.588 00000694 HHC00935I CTC: lcs device port 00: manual Checksum Offload enabled 08:35:30.588 00000694 HHC01541I HDL: dyngui.dll initiated 08:35:35.427 00000694 HHC02915I client 0 COMM: Connection received 08:35:35.428 00000694 HHC02914I 0:0700 COMM: client 0 negotiations complete; ttype = 'IBM-3278-5-E' 08:35:35.428 00000694 HHC01018I 0:0700 COMM: client 127.0.0.1 devtype 3270: connected 08:35:50.107 00000694 HHC01603I loadparm 0AAA00M1 08:35:50.107 00000694 HHC02204I LOADPARM set to 0AAA00M1 08:35:50.358 00000694 HHC01603I ipl 0A8F 08:35:50.369 00000694 HHC00811I Processor CP00: architecture mode ESA/390 08:35:50.369 00000694 HHC00811I Processor CP01: architecture mode ESA/390 08:35:50.381 00000694 HHC00814I Processor CP00: SIGP Set architecture mode (12) CP00, PARM 00000001: CC 0 08:35:50.381 00000694 HHC00811I Processor CP00: architecture mode z/Arch 08:35:50.391 00000694 HHC00801I Processor CP00: Operand exception code 0015 ilc 4 08:35:50.391 00000694 HHC02324I CP00: PSW=0400200080000000 000000002000017C INST=B2342000 STSCH 0(2) store_subchannel 08:35:50.391 00000694 HHC02326I CP00: V:0000000020012B18:K:06=00000000 00000000 00000000 00000000 ................ 08:35:50.391 00000694 HHC02269I CP00: R0=0000000020012B54 R1=0000000000050000 08:35:50.391 00000694 HHC02269I CP00: R2=0000000020012B18 R3=000000000000002B 08:35:50.391 00000694 HHC02269I CP00: R4=0000000020012B18 R5=0000000000000000 08:35:50.391 00000694 HHC02269I CP00: R6=000000002000F250 R7=0000000000000003 08:35:50.391 00000694 HHC02269I CP00: R8=00000000FFFFFFF9 R9=0000000020012000 08:35:50.391 00000694 HHC02269I CP00: RA=0000000000000005 RB=00000000200007A4 08:35:50.391 00000694 HHC02269I CP00: RC=00000000A0000000 RD=00000000200006EC 08:35:50.391 00000694 HHC02269I CP00: RE=00000000A0000172 RF=00000000FFFFFFF8 08:35:50.391 00000694 HHC02271I CP00: C0=0000000000000200 C1=0000000000004003 08:35:50.391 00000694 HHC02271I CP00: C2=0000000000000000 C3=0000000000000000 08:35:50.391 00000694 HHC02271I CP00: C4=0000000000000000 C5=0000000000000000 08:35:50.391 00000694 HHC02271I CP00: C6=00000000FE000000 C7=0000000000000000 08:35:50.391 00000694 HHC02271I CP00: C8=0000000000000000 C9=0000000000000000 08:35:50.391 00000694 HHC02271I CP00: CA=0000000000000000 CB=0000000000000000 08:35:50.391 00000694 HHC02271I CP00: CC=0000000000000000 CD=0000000000000000 08:35:50.391 00000694 HHC02271I CP00: CE=00000000C2000000 CF=0000000000000000 08:35:50.391 00000694 HHC00801I Processor CP00: Operand exception code 0015 ilc 4 08:35:50.391 00000694 HHC02324I CP00: PSW=0400200080000000 000000002000017C INST=B2342000 STSCH 0(2) store_subchannel 08:35:50.391 00000694 HHC02326I CP00: V:0000000020012B18:K:06=00000000 00000000 00000000 00000000 ................ 08:35:50.391 00000694 HHC02269I CP00: R0=0000000020012B54 R1=0000000000070000 08:35:50.391 00000694 HHC02269I CP00: R2=0000000020012B18 R3=000000000000002B 08:35:50.391 00000694 HHC02269I CP00: R4=0000000020012B18 R5=0000000000000000 08:35:50.391 00000694 HHC02269I CP00: R6=000000002000F250 R7=0000000000000003 08:35:50.391 00000694 HHC02269I CP00: R8=00000000FFFFFFF9 R9=0000000020012000 08:35:50.391 00000694 HHC02269I CP00: RA=0000000000000007 RB=00000000200007A4 08:35:50.391 00000694 HHC02269I CP00: RC=00000000A0000000 RD=00000000200006EC 08:35:50.391 00000694 HHC02269I CP00: RE=00000000A0000172 RF=00000000FFFFFFF8 08:35:50.391 00000694 HHC02271I CP00: C0=0000000000000200 C1=0000000000004003 08:35:50.391 00000694 HHC02271I CP00: C2=0000000000000000 C3=0000000000000000 08:35:50.391 00000694 HHC02271I CP00: C4=0000000000000000 C5=0000000000000000 08:35:50.391 00000694 HHC02271I CP00: C6=00000000FE000000 C7=0000000000000000 08:35:50.391 00000694 HHC02271I CP00: C8=0000000000000000 C9=0000000000000000 08:35:50.391 00000694 HHC02271I CP00: CA=0000000000000000 CB=0000000000000000 08:35:50.391 00000694 HHC02271I CP00: CC=0000000000000000 CD=0000000000000000 08:35:50.391 00000694 HHC02271I CP00: CE=00000000C2000000 CF=0000000000000000 08:35:50.406 00000694 HHC00814I Processor CP00: SIGP Unassigned (14) CP00, PARM 0000000064000000: CC 1 status 00000002 08:35:52.400 00000694 HHC00801I Processor CP00: Specification exception code 0006 ilc 4 08:35:52.400 00000694 HHC02324I CP00: PSW=0404000080000000 0000000000005CAA INST=B2650000 SVS 0,0 set_vector_summary 08:35:52.400 00000694 HHC02326I CP00: V:0000000000000000:K:0E=000A0000 000130E1 00000000 00000000 ................ 08:35:52.400 00000694 HHC02326I CP00: V:0000000000000000:K:0E=000A0000 000130E1 00000000 00000000 ................ 08:35:52.400 00000694 HHC02269I CP00: R0=FFFFFFFF00000000 R1=0000000000000001 08:35:52.400 00000694 HHC02269I CP00: R2=0000000000FD9740 R3=D75B6C54025C36D0 08:35:52.400 00000694 HHC02269I CP00: R4=00000000011D3588 R5=00000000025C36D0 08:35:52.400 00000694 HHC02269I CP00: R6=0000000000FD91E0 R7=0000000000FD91E0 08:35:52.400 00000694 HHC02269I CP00: R8=00000000025C36D0 R9=00000000025C36D0 08:35:52.400 00000694 HHC02269I CP00: RA=0000000000005CAE RB=FFFFFFFF00000100 08:35:52.400 00000694 HHC02269I CP00: RC=00000000000057E0 RD=0000000000005D98 08:35:52.400 00000694 HHC02269I CP00: RE=0000000080005A72 RF=0000000000FD91E0 08:35:52.400 00000694 HHC02271I CP00: C0=00800002CF98EE20 C1=000000007C590007 08:35:52.400 00000694 HHC02271I CP00: C2=000000007FE98700 C3=0000000180000001 08:35:52.400 00000694 HHC02271I CP00: C4=0000000100000001 C5=000000007FE987C0 08:35:52.400 00000694 HHC02271I CP00: C6=00000000FE000000 C7=000000007C590007 08:35:52.400 00000694 HHC02271I CP00: C8=0000000000000000 C9=0000000000000000 08:35:52.400 00000694 HHC02271I CP00: CA=0000000000000000 CB=0000000000000000 08:35:52.400 00000694 HHC02271I CP00: CC=0000000000000000 CD=000000007C590007 08:35:52.400 00000694 HHC02271I CP00: CE=00000000C00FF0C7 CF=0000000000000000 08:35:52.455 00000694 HHC00006I SCLP console interface active 08:35:52.562 00000694 HHC01315I 0:0701 CHAN: ccw 03300001 00000000 08:35:52.562 00000694 HHC01312I 0:0701 CHAN: stat 0200, count 0001 08:35:52.562 00000694 HHC01313I 0:0701 CHAN: sense 40000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 08:35:52.562 00000694 HHC01314I 0:0701 CHAN: sense INTREQ 08:35:52.564 00000694 HHC01315I 0:0702 CHAN: ccw 03300001 00000000 08:35:52.564 00000694 HHC01312I 0:0702 CHAN: stat 0200, count 0001 08:35:52.564 00000694 HHC01313I 0:0702 CHAN: sense 40000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 08:35:52.564 00000694 HHC01314I 0:0702 CHAN: sense INTREQ 08:36:06.354 00000694 HHC00801I Processor CP00: Operation exception code 0001 ilc 2 08:36:06.354 00000694 HHC02324I CP00: PSW=0704000080000000 0000000000000002 INST=000A ????? , ? 08:36:06.354 00000694 HHC02269I CP00: R0=000000007FF9CF00 R1=00000000008FFF88 08:36:06.354 00000694 HHC02269I CP00: R2=0000000000014000 R3=00000000008FD000 08:36:06.354 00000694 HHC02269I CP00: R4=02FC020000FD91E0 R5=0000000000004000 08:36:06.354 00000694 HHC02269I CP00: R6=000000008138C5A8 R7=0000000000FFA530 08:36:06.354 00000694 HHC02269I CP00: R8=000000008424C000 R9=00000000008FD520 08:36:06.354 00000694 HHC02269I CP00: RA=00000000008FFF48 RB=0000000000FB5100 08:36:06.354 00000694 HHC02269I CP00: RC=0000000000FD91E0 RD=9236CF29008FFFB4 08:36:06.354 00000694 HHC02269I CP00: RE=000000008424CAF4 RF=0000000000000000 08:36:06.360 00000694 HHC00809I Processor CP00: disabled wait state 0002000080000000 0000000000009064 08:36:18.863 00000694 HHC01603I exit 08:36:18.916 00000694 HHC01423I Calling termination routines 08:36:18.916 00000694 HHC00101I Thread id 00000620, prio 2, name 'Processor CP00' ended 08:36:18.916 00000694 HHC00811I Processor CP01: architecture mode z/Arch 08:36:18.916 00000694 HHC00101I Thread id 000017d8, prio 2, name 'Processor CP01' ended 08:36:18.916 00000694 HHC00101I Thread id 000020d4, prio 4, name 'console_connect' ended 08:36:18.916 00000694 HHC00417I 0:0D02 CKD file H:/HerculesDasdFiles/LDAV01: cache hits 0, misses 1, waits 0 08:36:18.917 00000694 HHC00417I 0:0D03 CKD file H:/zos24/CFG001: cache hits 111, misses 1391, waits 0 08:36:18.920 00000694 HHC00333I 0:0A94 32/64 size free nbr st reads writes l2reads hits switches 08:36:18.920 00000694 HHC00334I 0:0A94 readaheads misses 08:36:18.920 00000694 HHC00335I 0:0A94 ------------------------------------------------------------------------ 08:36:18.920 00000694 HHC00336I 0:0A94 [] 32 00024308761 004% 0028 0000001 0000000 0000001 0000000 0000001 08:36:18.920 00000694 HHC00337I 0:0A94 0000000 0000001 08:36:18.920 00000694 HHC00338I 0:0A94 H:/HerculesDasdFiles/SPL001 08:36:18.920 00000694 HHC00339I 0:0A94 [0] 32 00024308761 004% 0028 rw 0000001 0000000 0000001 08:36:18.922 00000694 HHC00417I 0:0A95 CKD file H:/HerculesDasdFiles/SPOOL2: cache hits 0, misses 1, waits 0 08:36:18.922 00000694 HHC00333I 0:0A96 32/64 size free nbr st reads writes l2reads hits switches 08:36:18.922 00000694 HHC00334I 0:0A96 readaheads misses 08:36:18.922 00000694 HHC00335I 0:0A96 ------------------------------------------------------------------------ 08:36:18.922 00000694 HHC00336I 0:0A96 [] 32 00553946411 000% 0905 0000001 0000000 0000001 0000000 0000001 08:36:18.922 00000694 HHC00337I 0:0A96 0000000 0000001 08:36:18.922 00000694 HHC00338I 0:0A96 H:/HerculesDasdFiles/LDAV04 08:36:18.923 00000694 HHC00339I 0:0A96 [0] 32 00553946411 000% 0905 rw 0000001 0000000 0000001 08:36:18.925 00000694 HHC00333I 0:0A9A 32/64 size free nbr st reads writes l2reads hits switches 08:36:18.925 00000694 HHC00334I 0:0A9A readaheads misses 08:36:18.925 00000694 HHC00335I 0:0A9A ------------------------------------------------------------------------ 08:36:18.925 00000694 HHC00336I 0:0A9A [] 32 00679942946 000% 0007 0000001 0000000 0000001 0000000 0000001 08:36:18.925 00000694 HHC00337I 0:0A9A 0000000 0000001 08:36:18.925 00000694 HHC00338I 0:0A9A H:/HerculesDasdFiles/LDAV07 08:36:18.925 00000694 HHC00339I 0:0A9A [0] 32 00679942946 000% 0007 rw 0000001 0000000 0000001 08:36:18.927 00000694 HHC00333I 0:0A9B 32/64 size free nbr st reads writes l2reads hits switches 08:36:18.927 00000694 HHC00334I 0:0A9B readaheads misses 08:36:18.927 00000694 HHC00335I 0:0A9B ------------------------------------------------------------------------ 08:36:18.927 00000694 HHC00336I 0:0A9B [] 32 00223323352 000% 0000 0000001 0000000 0000001 0000000 0000001 08:36:18.927 00000694 HHC00337I 0:0A9B 0000000 0000001 08:36:18.927 00000694 HHC00338I 0:0A9B H:/HerculesDasdFiles/LDAV08 08:36:18.927 00000694 HHC00339I 0:0A9B [0] 32 00223323352 000% 0000 rw 0000001 0000000 0000001 08:36:18.929 00000694 HHC00417I 0:0A9D CKD file H:/HerculesDasdFiles/JAIMS1: cache hits 0, misses 1, waits 0 08:36:18.929 00000694 HHC00417I 0:0A9F CKD file H:/HerculesDasdFiles/LDAV05: cache hits 0, misses 1, waits 0 08:36:18.929 00000694 HHC00333I 0:0D0A 32/64 size free nbr st reads writes l2reads hits switches 08:36:18.929 00000694 HHC00334I 0:0D0A readaheads misses 08:36:18.930 00000694 HHC00335I 0:0D0A ------------------------------------------------------------------------ 08:36:18.930 00000694 HHC00336I 0:0D0A [] 32 01922033303 000% 0090 0000001 0000000 0000001 0000000 0000001 08:36:18.930 00000694 HHC00337I 0:0D0A 0000000 0000001 08:36:18.930 00000694 HHC00338I 0:0D0A H:/HerculesDasdFiles/LDA023 08:36:18.930 00000694 HHC00339I 0:0D0A [0] 32 01922033303 000% 0090 rw 0000001 0000000 0000001 08:36:18.932 00000694 HHC00333I 0:0D0B 32/64 size free nbr st reads writes l2reads hits switches 08:36:18.932 00000694 HHC00334I 0:0D0B readaheads misses 08:36:18.932 00000694 HHC00335I 0:0D0B ------------------------------------------------------------------------ 08:36:18.932 00000694 HHC00336I 0:0D0B [] 32 00210216157 000% 0020 0000001 0000000 0000001 0000000 0000001 08:36:18.932 00000694 HHC00337I 0:0D0B 0000000 0000001 08:36:18.932 00000694 HHC00338I 0:0D0B H:/HerculesDasdFiles/LDAV03 08:36:18.932 00000694 HHC00339I 0:0D0B [0] 32 00210216157 000% 0020 rw 0000001 0000000 0000001 08:36:18.934 00000694 HHC00333I 0:0D11 32/64 size free nbr st reads writes l2reads hits switches 08:36:18.934 00000694 HHC00334I 0:0D11 readaheads misses 08:36:18.934 00000694 HHC00335I 0:0D11 ------------------------------------------------------------------------ 08:36:18.934 00000694 HHC00336I 0:0D11 [*] 32 00006615810 015% 0005 0000001 0000000 0000001 0000000 0000001 08:36:18.934 00000694 HHC00337I 0:0D11 0000000 0000001 08:36:18.934 00000694 HHC00338I 0:0D11 H:/HerculesDasdFiles/LDA074 08:36:18.934 00000694 HHC00339I 0:0D11 [0] 32 00006615810 015% 0005 rw 0000001 0000000 0000001 08:36:18.937 00000694 HHC00417I 0:0D12 CKD file T:/HerculesDasdFiles/LDA004: cache hits 0, misses 1, waits 0 08:36:18.937 00000694 HHC00417I 0:0D13 CKD file T:/HerculesDasdFiles/LDA007: cache hits 0, misses 1, waits 0 08:36:18.937 00000694 HHC00417I 0:0D14 CKD file T:/HerculesDasdFiles/LDA008: cache hits 0, misses 1, waits 0 08:36:18.937 00000694 HHC00417I 0:0D15 CKD file T:/HerculesDasdFiles/LDA009: cache hits 0, misses 1, waits 0 08:36:18.937 00000694 HHC00417I 0:0D16 CKD file T:/HerculesDasdFiles/LDA00A: cache hits 0, misses 1, waits 0 08:36:18.937 00000694 HHC00417I 0:0A8A CKD file H:/HerculesDasdFiles/a3sys1: cache hits 0, misses 1, waits 0 08:36:18.937 00000694 HHC00417I 0:0A8B CKD file H:/HerculesDasdFiles/a3cfg1: cache hits 0, misses 1, waits 0 08:36:18.937 00000694 HHC00417I 0:0A8C CKD file H:/HerculesDasdFiles/a3dis1: cache hits 0, misses 1, waits 0 08:36:18.937 00000694 HHC00417I 0:0A8D CKD file H:/HerculesDasdFiles/a3dis2: cache hits 0, misses 1, waits 0 08:36:18.937 00000694 HHC00417I 0:0A8E CKD file H:/HerculesDasdFiles/a3dis3: cache hits 0, misses 1, waits 0 08:36:18.937 00000694 HHC00417I 0:0A8F CKD file H:/HerculesDasdFiles/a3res1: cache hits 4410, misses 486, waits 0 08:36:18.937 00000694 HHC00417I 0:0A90 CKD file H:/HerculesDasdFiles/a3res2: cache hits 0, misses 1, waits 0 08:36:18.938 00000694 HHC00417I 0:0AA0 CKD file H:/zos24/a4res2: cache hits 0, misses 1, waits 0 08:36:18.938 00000694 HHC00417I 0:0AA1 CKD file H:/zos24/a4usr1: cache hits 0, misses 1, waits 0 08:36:18.938 00000694 HHC00417I 0:0AA2 CKD file H:/zos24/a4uss1: cache hits 0, misses 1, waits 0 08:36:18.938 00000694 HHC00417I 0:0AA3 CKD file H:/zos24/a4uss2: cache hits 0, misses 1, waits 0 08:36:18.938 00000694 HHC00417I 0:0AA4 CKD file H:/zos24/a4cfg1: cache hits 37, misses 9, waits 0 08:36:18.938 00000694 HHC00417I 0:0AA5 CKD file H:/zos24/a4dis1: cache hits 0, misses 1, waits 0 08:36:18.938 00000694 HHC00417I 0:0AA6 CKD file H:/zos24/a4dis2: cache hits 0, misses 1, waits 0 08:36:18.938 00000694 HHC00417I 0:0AA7 CKD file H:/zos24/a4dis3: cache hits 0, misses 1, waits 0 08:36:18.938 00000694 HHC00417I 0:0AAA CKD file H:/zos24/a4sys1: cache hits 192, misses 66, waits 0 08:36:18.938 00000694 HHC00417I 0:0AAC CKD file H:/zos24/a4prd1: cache hits 0, misses 1, waits 0 08:36:18.938 00000694 HHC00417I 0:0AAD CKD file H:/zos24/a4prd2: cache hits 0, misses 1, waits 0 08:36:18.938 00000694 HHC00417I 0:0AAE CKD file H:/zos24/a4prd3: cache hits 0, misses 1, waits 0 08:36:18.939 00000694 HHC00417I 0:0AAF CKD file H:/zos24/a4res1: cache hits 11295, misses 2122, waits 0 08:36:18.939 00000694 HHC00417I 0:0AB0 CKD file H:/zos24/a4prd4: cache hits 0, misses 1, waits 0 08:36:18.939 00000694 HHC00201I 0:0583 Tape file T:/herculesawstapefiles/000004.aws, type aws: tape closed 08:36:19.307 00000694 HHC01427I Main storage released 08:36:19.307 00000694 HHC01427I Expanded storage released 08:36:19.307 00000694 HHC01422I Configuration released 08:36:19.321 00000694 HHC01542I HDL: dyngui.dll terminated

@rpinion

Richard Pinion wrote:

With the binary you sent me yesterday, I am able to run 2.4. But, I still can't run with more than one CPU. I get a wait state shortly after IPL: Processor CP00: disabled wait state 0002000080000000 0000000000009064. I'm attaching a file that has my configuration and the Hercules log.

FYI:

Replying to GitHub via email is problematic. Attachments for example do not come through, and I cannot make minor edits to your post. As a result, it is much preferred that you reply directly via the GitHub Issues web page itself instead: "Transactional-Execution Facility design / implementation #263".

Doing so is not a requirement. You can still reply via email if you want. I just personally wish you wouldn't, and would rather reply directly via the github web page itself. But the choice is of course yours.

Attaching a file to your GitHub comment/reply is easy: just drag & drop! (or copy & paste)

Notice at the bottom of the input box where you type in your github comment (reply) there is a dotted line with text below it that says: "Attach files by dragging & dropping, selecting or pasting them.".

So if it's a text file (.txt) or a log file (.log), just drag and drop it into your github comment/reply. Otherwise, convert it to a .zip file first, and then drag and drop the .zip file into your comment.

Thanks.

(The above is is just an FYI for next time. This time I'll go ahead and go to the trouble of trying to extract your config and log files from your email message and inserting them here in my GitHub reply myself, the way I'm hoping you'll start doing so yourself in the future. Note: I'm not yelling or complaining, just informing.)

Okay, I think I see your problem. In your config file it looks like you have volumes from several different systems. A mix of z/OS 2.3 and z/OS 2.4 and some other system.

That by itself is not a problem. That's fine. It's confusing, but fine. Me, personally, I would have created a completely separate, unique, 2.4 config with only 2.4 volumes in it, rather than creating a big confusing mess of a config with volumes from multiple different systems like you did. But then that's just me. To each their own I guess. <shrug>

I strongly suspect however that it was the direct result of your having created a conf with volumes from multiple different systems that caused you to make the mistake you made.

You specified the z/OS 2.4 catalog volume in your LOADPARM, but then you IPLed from the z/OS 2.3 sysres!

08:35:30.315 00000694 HHC00414I 0:0A8F CKD file H:/HerculesDasdFiles/a3res1: model 3390-27 cyls 30051 heads 15 tracks 450765 trklen 56832 
...

08:35:30.318 00000694 HHC00414I 0:0AAA CKD file H:/zos24/a4sys1: model 3390-9 cyls 10017 heads 15 tracks 150255 trklen 56832 
...

08:35:35.428 00000694 HHC02914I 0:0700 COMM: client 0 negotiations complete; ttype = 'IBM-3278-5-E' 
08:35:35.428 00000694 HHC01018I 0:0700 COMM: client 127.0.0.1 devtype 3270: connected 
08:35:50.107 00000694 HHC01603I loadparm 0AAA00M1 
08:35:50.107 00000694 HHC02204I LOADPARM set to 0AAA00M1 
08:35:50.358 00000694 HHC01603I ipl 0A8F 
...
08:36:06.360 00000694 HHC00809I Processor CP00: disabled wait state 0002000080000000 0000000000009064

(Oops!) :)

This is precisely why it's important to always provide as much pertinent information as possible in your problem report. Just writing "It doesn't work for me! I keep getting a disabled wait 9064!" isn't helpful. Your conf and logfile however was helpful.

"How to Ask for Help"

Hope that helps!

Wow, I feel embarrassed about IPL'ing the 2.3 res volume! As to why I have a mixture. I pull down the ADCD from our company's zPDT server, and do my customization under Hercules. Therefore, I need to have access to the 2.3 and 2.4 systems at the same time. Also, I will use the Github procedure for reporting problems. And, thanks for your hard work with the TXN stuff!

Richard Pinion rpinion@netscape.com

-----Original Message----- From: Fish-Git notifications@github.com To: SDL-Hercules-390/hyperion hyperion@noreply.github.com Cc: rpinion rpinion@netscape.com; Mention mention@noreply.github.com Sent: Wed, Jan 22, 2020 4:33 pm Subject: Re: [SDL-Hercules-390/hyperion] Transactional-Execution Facility design / implementation (#263)

@rpinionRichard Pinion wrote: With the binary you sent me yesterday, I am able to run 2.4. But, I still can't run with more than one CPU. I get a wait state shortly after IPL: Processor CP00: disabled wait state 0002000080000000 0000000000009064. I'm attaching a file that has my configuration and the Hercules log. FYI:Replying to GitHub via email is problematic. Attachments for example do not come through, and I cannot make minor edits to your post. As a result, it is much preferred that you reply directly via the GitHub Issues web page itself instead: "Transactional-Execution Facility design / implementation #263".Doing so is not a requirement. You can still reply via email if you want. I just personally wish you wouldn't, and would rather reply directly via the github web page itself. But the choice is of course yours.Attaching a file to your GitHub comment/reply is easy: just drag & drop! (or copy & paste)Notice at the bottom of the input box where you type in your github comment (reply) there is a dotted line with text below it that says: "Attach files by dragging & dropping, selecting or pasting them.".So if it's a text file (.txt) or a log file (.log), just drag and drop it into your github comment/reply. Otherwise, convert it to a .zip file first, and then drag and drop the .zip file into your comment.Thanks.(The above is is just an FYI for next time. This time I'll go ahead and go to the trouble of trying to extract your config and log files from your email message and inserting them here in my GitHub reply myself, the way I'm hoping you'll start doing so yourself in the future. Note: I'm not yelling or complaining, just informing.)

zos24cfg.txt
zos24log.txt Okay, I think I see your problem. In your config file it looks like you have volumes from several different systems. A mix of z/OS 2.3 and z/OS 2.4 and some other system.That by itself is not a problem. That's fine. It's confusing, but fine. Me, personally, I would have created a completely separate, unique, 2.4 config with only 2.4 volumes in it, rather than creating a big confusing mess of a config with volumes from multiple different systems like you did. But then that's just me. To each their own I guess. I strongly suspect however that it was the direct result of your having created a conf with volumes from multiple different systems that caused you to make the mistake you made.You specified the z/OS 2.4 catalog volume in your LOADPARM, but then you IPLed from the z/OS 2.3 sysres!08:35:30.315 00000694 HHC00414I 0:0A8F CKD file H:/HerculesDasdFiles/a3res1: model 3390-27 cyls 30051 heads 15 tracks 450765 trklen 56832 ...

08:35:30.318 00000694 HHC00414I 0:0AAA CKD file H:/zos24/a4sys1: model 3390-9 cyls 10017 heads 15 tracks 150255 trklen 56832 ...

08:35:35.428 00000694 HHC02914I 0:0700 COMM: client 0 negotiations complete; ttype = 'IBM-3278-5-E' 08:35:35.428 00000694 HHC01018I 0:0700 COMM: client 127.0.0.1 devtype 3270: connected 08:35:50.107 00000694 HHC01603I loadparm 0AAA00M1 08:35:50.107 00000694 HHC02204I LOADPARM set to 0AAA00M1 08:35:50.358 00000694 HHC01603I ipl 0A8F ... 08:36:06.360 00000694 HHC00809I Processor CP00: disabled wait state 0002000080000000 0000000000009064 (Oops!) :)This is precisely why it's important to always provide as much pertinent information as possible in your problem report. Just writing "It doesn't work for me! I keep getting a disabled wait 9064!" isn't helpful. Your conf and logfile however was helpful.

"How to Ask for Help" Hope that helps!— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

I'd like to start playing with z/OS 2.4 but have the txf issue.

Is https://github.com/Fish-Git/hyperion-fish-txf available for us civilians, or should I keep my hands off for now? FYI, I'm running OPENsuse linux.

Is https://github.com/Fish-Git/hyperion-fish-txf available for us civilians, or should I keep my hands off for now?

"Fish-Git/hyperion-fish-txf" no longer exists.

It's been transferred to "https://github.com/SDL-Hercules-390/hyperion-txf" instead.

Yes, you can use it if desired, but be aware it's still in the experimental state and might not function correctly. For example, Translation-specification exception code 0012 (PIC 12) occurs continuously (over and over and over) when z/OS 2.4 is used, which may likely be caused by a bug in Hercules, but we don't know that for certain yet. See GitHub Issue #275 for more information including some suggestions for mitigating the problem (e.g. pgmtrace -12).

If such risks are acceptable to you, then by all means, feel free to give it a try.

FYI, I'm running OPENsuse linux.

Host platform is immaterial. Hercules is Hercules is Hercules. If regular non-TXF Hercules runs there, then our experimental txf version should too. The only difference should be the TXF support code, which has absolutely nothing to do with which host platform you're running.

FYI:

All experimental TXF (Transactional-Execution Facility) code has now been merged into current SDL Hyperion as/of 2020-05-17.

Those wishing to try it, must, for the time being, manually enable the facility(s) via the Hercules FACILITY command/control file statement(s) before attempting to use it:

  FACILITY  ENABLE  073_TRANSACT_EXEC
  FACILITY  ENABLE  050_CONSTR_TRANSACT

Once support for the Transactional-Execution Facility has been fully completed, thoroughly tested and officially released, it will then be enabled by default. But until then, it is still considered to be Highly Experimental and the user accepts all risk associated with using it. *`()`**

*`()** For example, there is still a known as-yet-unresolved "PIC 12" issue for z/OS 2.4 guests, which can be temporarily worked around via the Herculespgmtrace -12` command. Refer to GitHub Issue #275 "z/OS 2.4 continuous PIC 12" for more information.

FYI: another excellent resource for understanding how TXF (Transactional-Execution Facility) works is the following Share presentation:

IBM zEnterprise EC12 CPU Facilities SHARE 121, Session 14087, Wednesday, 14 August 2013, 1:30 p.m. Peter Relson (relson@us.ibm.com) Dan Greiner (dgreiner@us.ibm.com)

Direct download URL: https://share.confex.com/share/121/webprogram/Handout/Session14087/s14087%20Session%2014087%20--%20zEC12%20CPU%20Facilities.pdf

The discussion of how the Transactional-Execution Facility works begins on slide 20, but especially on slide 30, and IMO does a very good job of explaining how it all works in very clear easy to understand terms. (slides 20-29 simply provide a justification for its need/use)

FYI: Issue description updated with additional details.

FYI: I have exchanged several emails with Dan Greiner (former IBMer, now retired, and author of the above mentioned "IBM zEnterprise EC12 CPU Facilities" SHARE presentation) regarding SIE and TXF that I would like to share with you (with his explicit permission):

Dear Mr. Greiner,

Your presentation "IBM zEnterprise EC12 CPU Facilities" (SHARE 121, session 14087, given way back in 2013):

https://share.confex.com/share/121/webprogram/Handout/Session14087/s14087%20Session%2014087%20--%20zEC12%20CPU%20Facilities.pdf

I found to be very interesting! Thank you!

I do have some questions however, that I am hoping you can answer for me.

You mentioned on slide 47:

Transaction Diagnostic Block (TDB):

Program-exception conditions:

"For certain SIE interceptions due to program-interruption condition, interception TDB stored at location designated by bytes 488-495 (x'1E8') of the state description."

"For conditions that cause the CPU to leave the interpretive- execution state (called SIE interceptions), an interception TDB is stored at a location designated by the hypervisor (that is, LPAR or z/VM)."

Is the TDB information stored into this field ONLY for program-interruption SIE interceptions? Or for any SIE interception condition? (such as an I/O interrupt or external interrupt, etc)

Also, does it need to be restored before SIE mode is re-entered? That is to say, is it used on both the Start Interpretive Execution instruction (before the guest is dispatched in SIE mode) as well as whenever an exit from SIE mode occurs (such as when an SIE interception condition occurs), or is the field only used when LEAVING SIE mode?

And finally, since you used the phrase "due to program-interruption condition", am I to presume the TDB information that is saved (and restored?) from (to?) to guest, solely the Program Interrupt TDB at the z/Architected low core address ox x'1800'? Is that correct?

Thank you in advance for any enlightenment you can provide on this subject!

-- "Fish" (David B. Trout) Software Development Laboratories http://www.softdevlabs.com mail: fish@softdevlabs.com

Hello David,

I shall be happy to attempt to answer your questions if you will please cease and desist with this “Mr. Greiner” nonsense! 😊

At first, I was confused by your referencing slide 47, since the version of the presentation that I have contains the same slides, but somewhat rearranged. SHARE is infamous for being miserly about their on-line presentations, and only saves PDFs. I’ve included my current PowerPoint file which contains some animations.

IBM zEnterprise EC12 CPU Facilities (original).zip

You ask deep questions … about which I have forgotten much in the past 2¾ years since I retired from IBM. During the development of the transactional-execution (TX) facility, there was a wonderful, multipage table in the internal (IBM-confidential) version of the PoO that addressed exactly what went into the transaction- diagnostic block (TDB) for various conditions. I spent weeks getting the various development groups — particularly z/VM and Millicode — to come to agreement on each condition. Unfortunately, as I am now retired, I no longer have access to the internal goodies. However, in reviewing patent applications for the TX facility, I have refreshed my memory (slightly).

The following link:

United States Patent 8,880,959: "Transaction diagnostic block" (Greiner, et al. November 4, 2014)

should take you to U.S. patent 8,880,959 which addresses all things TDB. Contained therein, about halfway down, you will find the following:

Interception TDB: The 256-byte host real location specified by locations 488-495 of the state description. The interception TDB is stored when an aborted transaction results in a guest program interruption interception (that is, interception code 8). When a transaction is aborted due to other causes, the contents of the interception TDB are unpredictable. The interception TDB is not subject to any protection mechanism.

So, that should answer your first question. The TDB is definitely stored for interceptions resulting from program-exception conditions. For other conditions, no TDB may be stored, a blank TDB may be stored, a TDB containing supermodel’s mobile-phone numbers may be stored, or a TDB may be stored with whatever junk the Millicode engineers left lying around. (If you should discover Claudia Schiffer’s phone number, please advise.)

As far as I recall, the interception TDB has absolutely no bearing whatsoever on entering the interpretive- execution mode (that is, it’s ignored by the SIE instruction). It would be imprecise to say that it’s saved and restored. Rather, when TX is aborted due to an interception occurs due to a program-exception condition, the host program may choose to pass some of that information along to the guest’s TBEGIN-specified TDB or the guest’s program-interruption TDB, depending on whether or not the condition can be filtered. For example, TX may have been aborted due to a host program-exception condition that the host resolves and that the guest either (a) never needs to see or (b) needs to see as a different program-interruption code.

Hope this helps.

Kind regards • Mit freundlichen Grüßen • Sincères salutations • Saludos cordiales • S přátelským pozdravem • Z poważaniem • Cordiali saluti • Cordiais saudações • Met vriendelijke groeten • С уважением • 此致敬礼

Dan Greiner, San José, CA 95125, USA

Hi Dan! (is that better?)

Thank you very much! You are a very nice guy. The information you provided was quite helpful.

I do however have one more question that I'm hoping you might be able to help me with (even though you do not mention it anywhere in your talk).

I happened to notice in IBM's documentation that there is an "Execution Controls" flag bit defined at offset X'0061' into the SIE state description block called "SIEECTX" described simply as:

http://www.vm.ibm.com/pubs/cp710/SIEBK.HTML:
 ...1 ....   SIEECTX    X'10' SIEECTX (03) Transactional
                        Exection (sic)
I was wondering if you could explain what this bit is used for?

I'm presuming it is set by z/VM to request the SIE millicode to behave slightly differently as opposed to when it is not set, but since an explanation of what the flag actually accomplishes is nowhere to be found I am unfortunately left in the dark about it.

Would it be possible for you to maybe shed some light on the subject?

Thanks!

-- "Fish" (David B. Trout) Software Development Laboratories http://www.softdevlabs.com mail: fish@softdevlabs.com

Hello David,

Your salutation was exemplary! (I also answer to “Your Royal Highness”, “Your Royal Lowness”, or “Your Royal Flatulence”.)

Again, memory fails me, and without access to IBM’s SIE architecture documentation, I can only speculate as to the meaning. But the VM document that you reference makes it pretty clear. Execution controls are used by the host to determine whether various facilities are allowed to execute interpretively (that is, without interception), regardless of whether the execution of said facility is done by hardware or by Millicode.

In an interpretive-execution environment, the care and feeding of TX requires a fair amount of involvement by the host … to handle such conditions as TX abort due to a wide variety of interception/interruption conditions. The SIEECTX control determines whether the guest is allowed to execute such instructions as ETNG, TABORT, TBEGIN, TBEGINC, and TEND, or whether attempted execution of these results in an instruction interception. (Note, since TBEGINC is considered to be a separate facility, there might be a separate execution control bit for it, but I didn’t notice any in the web page you cited.)

Of course, ANY modern application would check whether a facility such as TX is installed by issuing a STORE FACILITY LIST EXTENDED (STFLE) instruction before attempted execution of a facility (brief pause for the snickering to subside). A host program will not indicate the presence of facilities it does not support in response to a guest’s STFLE. Of course, there are still troglodytes (such as me) who would attempt execution and expect to be punched on the nose with a PIC-0001 if the instruction isn’t present. SIEECTX is what the host uses to ensure attempted execution of TX instructions are properly.

Consider this scenario … a guest is happily executing on the latest, greatest z15 and attempts to utilize TX. However, the site is running an obsolete (i.e., pre-zEC12) z/VM system which hasn’t a clue about TX. In this case, the host would not set SIEECTX, and attempted guest execution of a TX instruction would result in interception, and the host would slap the guest with a PIC-0001.

Note, as I recall, NONTRANSACTIONAL STORE (NTSTG) may not be subject to SIEECTX since it does not require any host intervention. Thus, NTSTG should execute properly (as a STG) on a machine supporting TX, regardless of whether the host supports it.

Kind regards • Mit freundlichen Grüßen • Sincères salutations • Saludos cordiales • S přátelským pozdravem • Z poważaniem • Cordiali saluti • Cordiais saudações • Met vriendelijke groeten • С уважением • 此致敬礼

Dan Greiner, San José, CA 95125, USA +1 408-835-6353

Hi Dan!

Thank you very much for yet another very friendly and helpful reply!! Much appreciated!

Do I have your permission to share your emails (as well as your Power Point presentation) with others?

p.s. Please call me Fish. All my friends do! I've been using the name Fish for over 40 years now. No one calls me David anymore except my siblings/relatives! It's almost as bad as me calling you Mr. Greiner! :)

-- "Fish" (David B. Trout) Software Development Laboratories http://www.softdevlabs.com mail: fish@softdevlabs.com

Hello Fish,

I suppose there is great joy to be realized in that your family name is not Flounder. 😊

You are welcome to circulate any of my email musings with others (I tend to circulate them to the circular file). As to the PowerPoint file, technically IBM claims copyright to it, but as it is essentially free advertising for IBM, I think you will have no difficulty with circulating it as well. (SHARE also claims copyright to stuff submitted to them, and given the propensity for circulating SHARE junk, it’s essentially public domain.)

Kind regards • Mit freundlichen Grüßen • Sincères salutations • Saludos cordiales • S přátelským pozdravem • Z poważaniem • Cordiali saluti • Cordiais saudações • Met vriendelijke groeten • С уважением • 此致敬礼

Dan Greiner, San José, CA 95125, USA +1 408-835-6353

So there you have it!

We still have some important SIE work to do.

I'll try to get started on it right away but would appreciate those of you familiar/experienced with SIE to please double check my code once it's ready (which I will offer here as a patch for peer review first).

Thanks.

p.s. There's no reason that *I* have to develop the patch either! Any of YOU who are more familiar with SIE could help out by giving it a try yourself! (please?)

FYI: more info: comparison of 6.4 SIE2BK versus 7.1 SIE2BK:

It doesn't look like anything major changed. Just some new Execution Control bytes for some of the new facilities, but other than that it looks like it's the same.

NUT CRACKED!! :))))

I have FINALLY got TXF working! :))))

z/OS 2.4 ADCD works fine natively. z/OS 2.4 ADCD works fine under ADCD z/VM 7.1. z/OS 2.4 ADCD works fine under z/VM 6.4 FrankenVM. *`()`**

z/OS 2.3 ADCD works fine natively. z/OS 2.3 ADCD works fine under ADCD z/VM 7.1. z/OS 2.3 ADCD works fine under z/VM 6.4 FrankenVM.

z/OS 2.1 works fine natively. z/OS 2.1 works fine under ADCD z/VM 7.1. z/OS 2.1 works fine under z/VM 6.4 FrankenVM.

That's all I've tested so far.

I also have a custom z/OS 2.4 and an old z/OS 1.10 too, neither of which I bothered to test, but I'm confident they would probably work just fine too.

Note: I have not done any stress type tests yet (such as IZUANG1/IZUSVR1) nor have I done any long term (long duration) "slowly rotting" type tests that Jürgen has experienced either. I figure I can let you guys do that. :)

I have just pushed to the repository a very long series of commits that fixes current SDL Hyperion so that TXF now seems to work quite well both natively as well as under z/VM. In the next few paragraphs I shall try to comment briefly on each commit in the series to explain what I had to do and why I had to do it in order to get things working. Please bear with me. This will probably be a long post.

The first few of commits are just my usual set of "cosmetic" type changes that I typically make that I needed to get out of the way first, so that later, you can then better "see" the actual coding changes that I had to make:

Okay, now we get into the actual "fix" type changes. The heart of the series of commits that actually changed things so that TXF now works properly:

TRY_OBTAIN_INTLOCK fix: reset intwait on failure

This fix probably had nothing to do with TXF, but given that it is a (minor?) bug being fixed related to INTLOCK code which TXF does use, I figured getting it out of the way now was better than leaving it for later.

The following commit however, is definitely related to TXF:

OBTAIN_MAINLOCK_UNCONDITIONAL and AT_SYNCPOINT fixes

The OBTAIN_MAINLOCK_UNCONDITIONAL macro contained a bug wherein it was coded with regs instead of (_regs) (i.e. it was using the register context pointed to by wherever the 'regs' local variable happened to be pointing to instead of the register context passed as the argument to the macro itself). A very minor bug yes, and probably one that likely was not impacting TXF at all, but again, a bug is a bug is a bug, so why not fix it now instead of later, right?

The AT_SYNCPOINT macro was using the register context passed to it to address the intwait variable, but should technically always ensure that "hostregs" is always being used. (Refer to the OBTAIN_INLOCK macro's associated Interrupt_Lock_Obtained function: the intwait variable is always addressed via hostregs.)

This next one was an interesting one:

Fix virt_to_real function to properly preserve progjmp

Because TXF needs to defer the address translation of an unconstrained transaction's TDB operand until it is actually needing to be used (you can't do it ahead of time like I was originally trying to do! The mainstor address that the TBEGIN instruction's operand translates to at the time the instruction is executed can easily change by the time the TDB actually needing to be filled it due to the page it was originally contained in having been mapped to some other page by the time the abort was detected!), thus requiring the use of the virt_to_real function.

The only problem is, virt_to_real was destroying progjmp! (as well as changing other fields in regs too).

The original comments said a temporary copy of the register context was being used in order to prevent that, but it was obvious that wasn't true. I spent quite a bit of time tracing this back through the commit log via git blame and determined that yes, originally, long ago, it was indeed coded that way, but then somebody broke it (Greg Smith I think?) and didn't bother to change the comments. So it's been broken for a long time. Luckily however, until now, it appears to only have been used by panel commands and not by actual instruction emulation code anywhere, so we've been lucky up until now. But of course as soon as I started trying to use it in TXF code, then then bug finally started biting us. BIG time!

But I think I have it fixed now.

Fix instfetch to use use MADDRL(6) instead of MADDR

This one appears to be fairly minor too and one that probably wasn't biting us in TXF code, but once again, since I wasn't 100% sure of that and since I was fairly certain it was a bonafide bug, I decided to fix it.

For proper TXF cache line conflict detection handling it's important that ALL MADDR type address translations always use MADDRL instead which requires a specific operand length argument. When you use MADDR, the operand length defaults to '1' and may not reflect the operand's actual length. Rather, MADDRL should be used with a proper (correct) operand length value.

New txf_abort_all function for CSP/CSPG handling

As my commit comment explains, using a called function instead serves to eliminate duplicate code and ensures that the exact same processing is being done in both places, making for more reliable Hercules functionality.

This next commit both fixed and tweaked a bunch of little things in transact.c;

TXF: various minor transact.c tweaks and fixes

I'm not going to bother listing nor discussing them all here since there are a lot of them and they are all actually quite minor. If you're interested, refer to the actual commit.

TXF debugging: track/report constrained failure retries

Pretty self explanatory: not only are constrained transaction failures detected and reported (just like unconstrained transaction failures are) just like before, but now we also report each retry attempt too as well as how many attempts it eventually took before it succeeded. (It wasn't in this commit but in a later commit, code was also added to the $test txf command to report how often constrained transactions were being retried.)

OPTION_DEPRECATE_TXF_LASTACC, OPTION_NO_TXF_MADDR_L_ABORT

As my commit message states:

Last acctype not needed to detect instruction fetch.
If abort in txf_maddr_l, use ABORT_RETRY_CC, not ABORT_RETRY_PGMCHK.

Only an arn value of USE_INST_SPACE is actually needed to detect an instruction fetch since ACCTYPE_INSTFETCH is identical to ACC_READ anyway.

And if we need to abort a transaction in the txf_maddr_l function due to fetch or store overflow (i.e. maximum number of allowed storage references exceeded), we shouldn't be throwing a program check but rather just setting a condition code since, according to the architecture, it's classified as only a "transient" (temporary) condition. (see Fig. 5-14 on page 5-102 of SA22-7832-12 z/Arch POPs)

Don't reset instruction fetch constraint if nested constrained

As my commit message explains, yes, constrained transactions cannot be nested, but they can be called from within a currently executing unconstrained transaction, and when that happens, the "constrained" transaction is not constrained. It just becomes another nesting level of the already unconstrained transaction, which means the instruction fetch constraint should NOT be reset.

Fix TXF acctype and conflict checking bugs

This commit is probably THE key commit that fixed the most glaring bug in Bob's original TXF design: due to the way the ACCTYPE_XXXX constants are defined, you simply cannot do "equality" tests against the higher level ACCTYPE_READ, ACCTYPE_WRITE, ACCTYPE_WRITE_SKP constants. Rather, you must do bit tests against the lower level ACC_READ, ACC_WRITE and ACC_CHECK bit constants instead.

For example, doing a if (acctype == ACCTYPE_READ) will fail if acctype has any other bits on besides just ACC_READ (such as the ACC_NOTLB bit, etc), thereby misleading the program into believing, since it's not a read access, it must therefore be a write access (when in fact it is not!). Thus bit tests read/read access must always be performed. The TXF_ACCTYPE, TXF_IS_FETCH_ACCTYPE and TXF_IS_STORE_ACCTYPE macros were thus created to deal with this fact.

After fixing that, I then thought about the actual conflict checking logic that we were doing in txf_maddr_l (wherein if we detected a conflict with a currently transacting CPU we were forcing that CPU's transaction to abort) and concluded that that was very wrong too.

No conflict checking for STORE accesses is needed in txf_maddr_l. Store conflicts will be detected once TEND is eventually reached. Only conflict checking for FETCH accesses (and corresponding aborting) is actually needed in txf_maddr_l. As a result, we were aborting transactions that should never have been aborted and which would have likely correctly succeeded had we not erroneously aborted them. THIS was the most serious of all the bugs and the one that was absolutely killing us! Transactions were being erroneously aborted left and right and as a result, the program (e.g. z/OS) was unable to make any significant progress, leading to excessive spin locks and loops, etc, ultimately bringing the system to its knees.

For a more detailed explanation refer to my block comments in transact.c.

Remove TXF piid/dxc/vxc from program_interrupt

(just a minor fix/tweak)

_TXF_SIE_INTERCEPT txf instructions_

Another KEY commit! All TXF instructions (but especially the TBEGIN and TBEGINC instructions!) must be intercepted by the SIE host (e.g. z/VM) if it requests it. Without this, z/VM doesn't know that its guest is executing a transaction and thus mistakenly believes it is free to dispatch the guest on a completely different CPU should it want to (which I hope you all agree would be absolutely disastrous from a TXF point of view!). Once this change (fix) was implemented I noticed right away that z/VM stopped switching to another CPU and instead dispatched the guest on the same CPU as before. This is probably also why the instruction address constraint was sometimes failing too.

Improve TXF TDB handling

Per the architecture (and as mentioned briefly in the discussion of the virt_to_real change further above), resolution of the TBEGIN instructions's operand-1 TDB address must be deferred until it is actually needed, and if resolution fails, as per the architecture, the TDB is simply not filled it.

But since SIE logic might need the TDB information in order to fill in its "Interception TDB" at sie_exit, we now build both TDBs in an internal REGS struct field so that both TDB types are always available anytime we need them.

(And in case you didn't notice, rather than save the resolved TDB address in a field in REGS, we instead save just the effective address and the base register (arn) so we can reliably resolve it to an accurate/current mainstor address at any later point in time, as per the architecture.)

OPTION_FIX_SIE_ICODE_BUG

Minor fix for what appears to be a bug in the start_interpretive_execution instruction function's handling of the icode (interrupt code) variable. If a longjmp is done anywhere during the start_interpretive_execution processing, the icode value that would end up being used would be wrong since the setjmp that it was doing was never saving the return code from setjmp. As a result, sie_exit would get called with an incorrect/inaccurate interrupt/intercept code value. This commit fixed that.

TXF debugging: abort retry stats; use "$test txf" for report.

(The previously mentioned code to track/report aborted constrained transaction retries.)

TXF SIE fixes

Another important(?) change: this commit implements the architecturally required sie_exit "Interception TDB" mentioned in paragraph 17.20 of IBM Patent 8,880,959 B2 that Dan Greiner mentioned as being needed in one of his emails, which required some handshaking in program_interrupt function's TXF program interrupt filtering logic.

And finally...

_OPTION_TXF_SINGLE_THREAD_

Another very key (very important?) "fix" which forces all constrained transactions to only execute one at a time. As my commit message explains, it was done in order to improve the success rate of constrained transactions by significantly reducing interference from other constrained transactions executing at the same time which would otherwise increase the likelihood of them failing as a result.

Single threading constrained transactions like this may not actually be needed (I never bothered to test without this option enabled since things seemed to work fine with it), but I think it's probably best that we keep it enabled for now. Perhaps in the near future we might be able to implement an alternative technique wherein the locking is dynamically enabled whenever it is determined that it is needed. For example, the PPA (Perform Processor Assist) instruction is designed to provide Transaction-Abort Assist functionality for non-constrained (unconstrained) transactions which is currently coded in Hercules to do absolutely nothing (i.e. provide no assist at all). Perhaps we could set a flag instead to dynamically prevent, for just that one transaction, any other transaction from executing at the same time. And/or maybe we can implement something similar for constrained transactions based on a dynamically calculated current success/failure rate? Just some food for thought.

Anyway, that's it. Sorry for such a long post but I wanted to justify all the changes I had to make and explain them to you so you guys could understand what I did and why. As always, thoughtful feedback, while not required, is certainly welcome.

Thanks for listening.

Let me know how my changes work out for you! As I said in my opening comments, TXF is now working quite well for me, so I'd appreciate you letting me know whether or not they work just as well for you. :)

Take care you guys!

Be well. Stay safe.

*`()`** I don't have an official z/VM 6.4. I only have a z/VM 6.3 whose kernel has been replaced with the one from z/VM 6.4, i.e. system with parts from one system and parts from another sewn together into a Frankenstein monster type of system. Hence, "FrankenVM".

p.s. The URLs (hyperlinks) for the commits in my previous GitHub comment were bad (malformed). I have since edited my comment so that they are now correct, but if you are reading this GitHub comment from a GitHub comment notification email, the links in your email are not going to work. I apologize for that. It would be better if you would read my GitHub comment directly from the GitHub Issues web page instead:

https://github.com/SDL-Hercules-390/hyperion/issues/263#issuecomment-663490435

Thanks.

I don't suppose you have a Win10 prebuilt binary?

Richard Pinion rpinion@netscape.com

-----Original Message----- From: Fish-Git notifications@github.com To: SDL-Hercules-390/hyperion hyperion@noreply.github.com Cc: rpinion rpinion@netscape.com; Mention mention@noreply.github.com Sent: Fri, Jul 24, 2020 7:17 am Subject: Re: [SDL-Hercules-390/hyperion] Transactional-Execution Facility design / implementation (#263)

NUT CRACKED!! :))))I have FINALLY got TXF working! :))))z/OS 2.4 ADCD works fine natively. z/OS 2.4 ADCD works fine under ADCD z/VM 7.1. z/OS 2.4 ADCD works fine under z/VM 6.4 FrankenVM. (*)z/OS 2.3 ADCD works fine natively. z/OS 2.3 ADCD works fine under ADCD z/VM 7.1. z/OS 2.3 ADCD works fine under z/VM 6.4 FrankenVM.z/OS 2.1 works fine natively. z/OS 2.1 works fine under ADCD z/VM 7.1. z/OS 2.1 works fine under z/VM 6.4 FrankenVM.That's all I've tested so far.I also have a custom z/OS 2.4 and an old z/OS 1.10 too, neither of which I bothered to test, but I'm confident they would probably work just fine too.Note: I have not done any stress type tests yet (such as IZUANG1/IZUSVR1) nor have I done any long term (long duration) "slowly rotting" type tests that Jürgen has experienced either. I figure I can let you guys do that. :)I have just pushed to the repository a very long series of commits that fixes current SDL Hyperion so that TXF now seems to work quite well both natively as well as under z/VM. In the next few paragraphs I shall try to comment briefly on each commit in the series to explain what I had to do and why I had to do it in order to get things working. Please bear with me. This will probably be a long post.The first few of commits are just my usual set of "cosmetic" type changes that I typically make that I needed to get out of the way first, so that later, you can then better "see" the actual coding changes that I had to make:

SIE cosmetic renames
Cosmetic: intwait/syncing=bool, PTT msg
Cosmetic rename: MAX_CPU_ENGINES ==> MAX_CPU_ENGS
Cosmetic: HOST.../GUEST... macros, program_interrupt
PTT: widen rc to 64 bits
Mostly cosmetic changes to sie.c
Cosmetic: move TXF_WHY consts to transact.h
Mostly cosmetic: move TXF prog interrupt filtering to transact.c
(additional minor program_interrupt tweaks)
(cosmetic renames)
Enhance TXF tracing messages Okay, now we get into the actual "fix" type changes. The heart of the series of commits that actually changed things so that TXF now works properly:
TRY_OBTAIN_INTLOCK fix: reset intwait on failure This fix probably had nothing to do with TXF, but given that it is a (minor?) bug being fixed related to INTLOCK code which TXF does use, I figured getting it out of the way now was better than leaving it for later. The following commit however, is definitely related to TXF:
OBTAIN_MAINLOCK_UNCONDITIONAL and AT_SYNCPOINT fixes The OBTAIN_MAINLOCK_UNCONDITIONAL macro contained a bug wherein it was coded with regs instead of (_regs) (i.e. it was using the register context pointed to by wherever the 'regs' local variable happened to be pointing to instead of the register context passed as the argument to the macro itself). A very minor bug yes, and probably one that likely was not impacting TXF at all, but again, a bug is a bug is a bug, so why not fix it now instead of later, right?The AT_SYNCPOINT macro was using the register context passed to it to address the intwait variable, but should technically always ensure that "hostregs" is always being used. (Refer to the OBTAIN_INLOCK macro's associated Interrupt_Lock_Obtained function: the intwait variable is always addressed via hostregs.) This next one was an interesting one:
Fix virt_to_real function to properly preserve progjmp Because TXF needs to defer the address translation of an unconstrained transaction's TDB operand until it is actually needing to be used (you can't do it ahead of time like I was originally trying to do! The mainstor address that the TBEGIN instruction's operand translates to at the time the instruction is executed can easily change by the time the TDB actually needing to be filled it due to the page it was originally contained in having been mapped to some other page by the time the abort was detected!), thus requiring the use of the virt_to_real function.The only problem is, virt_to_real was destroying progjmp! (as well as changing other fields in regs too).The original comments said a temporary copy of the register context was being used in order to prevent that, but it was obvious that wasn't true. I spent quite a bit of time tracing this back through the commit log via git blame and determined that yes, originally, long ago, it was indeed coded that way, but then somebody broke it (Greg Smith I think?) and didn't bother to change the comments. So it's been broken for a long time. Luckily however, until now, it appears to only have been used by panel commands and not by actual instruction emulation code anywhere, so we've been lucky up until now. But of course as soon as I started trying to use it in TXF code, then then bug finally started biting us. BIG time!But I think I have it fixed now.
Fix instfetch to use use MADDRL(6) instead of MADDR This one appears to be fairly minor too and one that probably wasn't biting us in TXF code, but once again, since I wasn't 100% sure of that and since I was fairly certain it was a bonafide bug, I decided to fix it. (For proper TXF cache line conflict detection handling it's important that ALL MADDR type address translations always use MADDRL instead which requires a specific operand length argument. When you use MADDR, the operand length defaults to '1' and may not reflect the operand's actual length. Rather, MADDRL should be used with a proper (correct) operand length value.
New txf_abort_all function for CSP/CSPG handling As my commit comment explains, using a called function instead serves to eliminate duplicate code and ensures that the exact same processing is being done in both places, making for more reliable Hercules functionality. This next commit both fixed and tweaked a bunch of little things in transact.c;
TXF: various minor transact.c tweaks and fixes I'm not going to bother listing nor discussing them all here since there are a lot of them and they are all actually quite minor. If you're interested, refer to the actual commit.
TXF debugging: track/report constrained failure retries Pretty self explanatory: not only are constrained transaction failures detected and reported (just like unconstrained transaction failures are) just like before, but now we also report each retry attempt too as well as how many attempts it eventually took before it succeeded. (It wasn't in this commit but in a later commit, code was also added to the $test txf command to report how often constrained transactions were being retried.)
OPTION_DEPRECATE_TXF_LASTACC, OPTION_NO_TXF_MADDR_L_ABORT As my commit message states:
Last acctype not needed to detect instruction fetch.
If abort in txf_maddr_l, use ABORT_RETRY_CC, not ABORT_RETRY_PGMCHK. Only an arn value of USE_INST_SPACE is actually needed to detect an instruction fetch since ACCTYPE_INSTFETCH is identical to ACC_READ anyway.And if we need to abort a transaction in the txf_maddr_l function due to fetch or store overflow (i.e. maximum number of allowed storage references exceeded), we shouldn't be throwing a program check but rather just setting a condition code since, according to the architecture, it's classified as only a "transient" (temporary) condition. (see Fig. 514 on page 5-102 of SA22-7832-12 z/Arch POPs)
Don't reset instruction fetch constraint if nested constrained As my commit message explains, yes, constrained transactions cannot be nested, but they can be called from within a currently executing unconstrained transaction, and when that happens, the "constrained" transaction is not constrained. It just becomes another nesting level of the already unconstrained transaction, which means the instruction fetch constraint should NOT be reset.
Fix TXF acctype and conflict checking bugs This commit is probably THE key commit that fixed the most glaring bug in Bob's original TXF design: due to the way the ACCTYPE_XXXX constants are defined, you simply cannot do "equality" tests against the higher level ACCTYPE_READ, ACCTYPE_WRITE, ACCTYPE_WRITE_SKP constants. Rather, you must do bit tests against the lower level ACC_READ, ACC_WRITE and ACC_CHECK bit constants instead.For example, doing a if (acctype == ACCTYPE_READ) will fail if acctype has any other bits on besides just ACC_READ (such as the ACC_NOTLB bit, etc), thereby misleading the program into believing, since it's not a read access, it must therefore be a write access (when in fact it is not!). Thus bit tests read/read access must always be performed. The TXF_ACCTYPE, TXF_IS_FETCH_ACCTYPE and TXF_IS_STORE_ACCTYPE macros were thus created to deal with this fact.After fixing that, I then thought about the actual conflict checking logic that we were doing in txf_maddr_l (wherein if we detected a conflict with a currently transacting CPU we were forcing that CPU's transaction to abort) and concluded that that was very wrong too.No conflict checking for STORE accesses is needed in txf_maddr_l. Store conflicts will be detected once TEND is eventually reached. Only conflict checking for FETCH accesses (and corresponding aborting) is actually needed in txf_maddr_l. As a result, we were aborting transactions that should never have been aborted and which would have likely correctly succeeded had we not erroneously aborted them. THIS was the most serious of all the bugs and the one that was absolutely killing us! Transactions were being erroneously aborted left and right and as a result, the program (e.g. z/OS) was unable to make any significant progress, leading to excessive spin locks and loops, etc, ultimately bringing the system to its knees.For a more detailed explanation refer to my block comments in transact.c.
Remove TXF piid/dxc/vxc from program_interrupt (just a minor fix/tweak)
TXF_SIE_INTERCEPT txf instructions Another KEY commit! All TXF instructions (but especially the TBEGIN and TBEGINC instructions!) must be intercepted by the SIE host (e.g. z/VM) if it requests it. Within this, z/VM doesn't know that its guest is executing a transaction and thus mistakenly believes it is free to dispatch the guest on a completely different CPU should it want to (which I hope you all agree would be absolutely disastrous from a TXF point of view!). Once this change (fix) was implemented I noticed right away that z/VM stopped switching to another CPU and instead dispatched the guest on the same CPU as before.
Improve TXF TDB handling Per the architecture (and as mentioned briefly in the discussion of the virt_to_real change further above), resolution of the TBEGIN instructions's operand-2 TDB address must be deferred until it is actually needed, and if resolution fails, as per the architecture, the TDB is simply not filled it.But since SIE logic might need the TDB information in order to fill in its "Interception TDB" at sie_exit, we now build both TDBs in an internal REGS struct field so that both TDB types are always available anytime we need them.(And in case you didn't notice, rather than save the resolved TDB address in a field in REGS, we instead save just the effective address and the base register (arn) so we can reliably resolve it to an accurate/current mainstor address at any later point in time, as per the architecture.)
OPTION_FIX_SIE_ICODE_BUG Minor fix for what appears to be a bug in the start_interpretive_execution instruction function's handling of the icode (interrupt code) variable. If a longjmp is done anywhere during the start_interpretive_execution processing, the icode value that would end up being used would be wrong since the setjmp that it was doing was never saving the return code from setjmp. As a result, sie_exit would get called with an incorrect/inaccurate interrupt/intercept code value. This commit fixed that.
TXF debugging: abort retry stats; use "$test txf" for report. (The previously mentioned code to track/report aborted constrained transaction retries.)
TXF SIE fixes Another important(?) change: this commit implements the architecturally required sie_exit "Interception TDB" mentioned in paragraph 17.20 of IBM Patent 8,880,959 B2 that Dan Greiner mentioned as being needed in one of his emails, which required some handshaking in program_interrupt function's TXF program interrupt filtering logic. And finally...
OPTION_TXF_SINGLE_THREAD Another very key (very important?) "fix" which forces all constrained transactions to only execute one at a time. As my commit message explains, it was done in order to improve the success rate of constrained transactions by significantly reducing interference from other constrained transactions executing at the same time which would otherwise increase the likelihood of them failing as a result.Single threading constrained transactions like this may not actually be needed (I never bothered to test without this option enabled since things seemed to work fine with it), but I think it's probably best that we keep it enabled for now. Perhaps in the near future we might be able to implement an alternative technique wherein the locking is dynamically enabled whenever it is determined that it is needed. For example, the PPA (Perform Processor Assist) instruction is designed to provide Transaction-Abort Assist functionality for non-constrained (unconstrained) transactions which is currently coded in Hercules to do absolutely nothing (i.e. provide no assist at all). Perhaps we could set a flag instead to dynamically prevent, for just that one transaction, any other transaction from executing at the same time. And/or maybe we can implement something similar for constrained transactions based on a dynamically calculated current success/failure rate? Just some food for thought. Anyway, that's it. Sorry for such a long post but I wanted to justify all the changes I had to make and explain them to you so you guys could understand what I did and why. As always, thoughtful feedback, while not required, is certainly welcome.Thanks for listening.Let me know how my changes work out for you! As I said in my opening comments, TXF is now working quite well for me, so I'd appreciate you letting me know whether or not they work just as well for you. :)Take care you guys!Be well. Stay safe.(*) I don't have an official z/VM 6.4. I only have a z/VM 6.3 whose kernel has been replaced with the one from z/VM 6.4, i.e. system with parts from one system and parts from another sewn together into a Frankenstein monster type of system. Hence, "FrankenVM".— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

I don't suppose you have a Win10 prebuilt binary?

No. But I will eventually create a new Windows pre-built snapshot for people like you to test with, it just won't be specifically for Windows 10. Rather, it will be built on my Windows 7 system instead which should work fine on all Windows 7 or later Windows system, including Windows 10.

But it's very late and I'm very tired right now and need to get some sleep first. I promise you, one of my very first goals upon waking up will be to create a snapshot for any interested Windows user to test with.

But that's tomorrow. I need to get some sleep! I've been up all night!

Zzzzz.....

OK, thanks!

Richard Pinion rpinion@netscape.com

-----Original Message----- From: Fish-Git notifications@github.com To: SDL-Hercules-390/hyperion hyperion@noreply.github.com Cc: rpinion rpinion@netscape.com; Mention mention@noreply.github.com Sent: Fri, Jul 24, 2020 8:52 am Subject: Re: [SDL-Hercules-390/hyperion] Transactional-Execution Facility design / implementation (#263)

I don't suppose you have a Win10 prebuilt binary? No. But I will eventually create a new Windows pre-built snapshot for people like you to test with, it just won't be specifically for Windows 10. Rather, it will be built on my Windows 7 system instead which should work fine on all Windows 7 or later Windows system, including Windows 10.But it's very late and I'm very tired right now and need to get some sleep first. I promise you, one of my very first goals upon waking up will be to create a snapshot for any interested Windows user to test with.But that's tomorrow. I need to get some sleep! I've been up all night!Zzzzz.....— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

Single threading of constrained transactions is required, at some point. If there are sufficient failures of the constrained transaction, it will ultimately operate under a locking mechanism. So whether it is handled that way initially or later becomes a point of argument. My view when researching TXF was that if constrained transactions would eventually need a lock (single-threading) then Hercules might as well do it up front. I definitely vote on keeping this. Whether we eventually allow an constrained transaction to operate without single-threading is something we can defer to later. Regardless, what we are doing now is going to be required to meet the requirements of constrained transactions. Just my opinion.

*** IMPORTANT! ***

I forgot to also mention that apparently it is also critically(?) important that the CPUMODEL you specify in your Hercules configuration file is an official IBM model number that is known to support the Transactional-Execution Facility! (or at least it appears that is very true for at least z/VM anyway! Not sure about z/OS but I wouldn't doubt it was true for it too)

During my days and weeks of testing I just happened to notice that the model number in my Herc config file for z/VM was set to 2097, which is a z10! (and as far as I know the first model that officially supported TXF was the EC12 model 2827)

As soon as I changed it to a model 2965 (z13s), things started working MUCH better!

There were still many TXF problems that I still had to eventually identify and fix of course (i.e. changing the model number didn't somehow magically fix everything!), but the point is, apparently z/VM (and possibly z/OS too?) are very sensitive to what hardware model they are running on, irrespective of whatever set of facilities the STFLE instruction happens to report as being installed.

I believe Mark more than likely mentioned this a very long time ago but I just forgot about it since, up until now, it didn't seem to make any difference to me in any of my testing. But once I started working on TXF however, I discovered that it apparently makes a huge difference! (well, maybe not huge, but it DOES make a difference!)

QUESTION: given what I just wrote above, I'm wondering how the rest of you feel about possibly adding some rudimentary CPU model number checking logic to our existing Facility support? (e.g. if facility 73 or 50 are enabled then the model number must be 2827 or greater, otherwise it's an error).

I was also thinking of maybe adding, as a courtesy, a bunch of predefined DEFSYMs for CPU model name to model number equivalents (e.g. $(EC12) = "2827", etc) to make it easier on our users to specify the correct model number. We could also add code to translate model numbers to model names too, and report the name of the model at startup (i.e. whenever we report/display the cpu model number in response to processing the CPUMODEL statement, we could, in addition to just displaying the model number like we are now, also display within parentheses after it what model name that particular model number equates to).

What do you think?

Addendum: IBM Processor version codes and SRM constants:

(https://www-01.ibm.com/servers/resourcelink/lib03060.nsf/pages/srmindex?OpenDocument)

1090 = (zPDT?) (not in IBM's list)
2097 = z10
2827 = EC12
2964 = z13
2965 = z13s
3906 = z14
3907 = z14 ZR1
8561 = z15
8562 = z15 T02

New pre-built Windows "EXPERIMENTAL TXF BUILD" of SDL Hyperion uploaded to SoftDevLabs:

HHC01413I Hercules version 4.3.9999.10198-SDL-gbca5d05c (4.3.9999.10198)
HHC01414I (C) Copyright 1999-2020 by Roger Bowler, Jan Jaeger, and others
HHC01417I *** EXPERIMENTAL TXF BUILD ***
HHC01415I Build date: Jul 24 2020 at 12:50:41
HHC01417I Built with: Microsoft Visual Studio 2008 (MSVC 150030729 1)
HHC01417I Build type: Windows MSVC AMD64 host architecture build

Download links/URLs:

Debugging Symbols (http://www.softdevlabs.com/downloads/TXF_81DE2677-0F14-4929-B2AA-A1C9716890A6/Hercules-4.3.9999.10198-SDL-gbca5d05c-x64.PDB.zip)
Executable binaries (http://www.softdevlabs.com/downloads/TXF_81DE2677-0F14-4929-B2AA-A1C9716890A6/Hercules-4.3.9999.10198-SDL-gbca5d05c-x64.zip)

You of course technically only need the second one unless you plan on doing Hercules debugging, in which case you might also want the first one (PDB = "Program Debugging Database") too, but it's really only meant for me to be able to analyze a crash dump should one unfortunately ever occur.

PLEASE REMEMBER that this is still considered to be a HIGHLY EXPERIMENTAL version of Hercules! Support for the Transactional-Execution Facility (TXF) is still known to be incomplete and has only been very lightly tested. It may not function properly. However, this new version DOES seem to operate much more reliably than previous versions.

FYI: some stats from some test runs I did yesterday (output of $test txf command):

z/OS 2.4 native:

+++ acc_read  =    18107475
+++ acc_write =     6917760
+++ acc_check =      536605
+++ acc_notrw =      536605
+++ acc_none  =           0
+++ ctrans    =      258115
+++ 0 retries =      257201  (99.6%)
+++ 1 retries =         789  ( 0.3%)
+++ 2 retries =         103  ( 0.0%)
+++ 3 retries =          13  ( 0.0%)
+++ 4 retries =           7  ( 0.0%)
+++ 5 retries =           0  ( 0.0%)
+++ 6 retries =           0  ( 0.0%)
+++ 7 retries =           1  ( 0.0%)
+++ 8+retries =           1  ( 0.0%)

z/OS 2.4 under z/VM 7.1:

+++ acc_read  =    11899823
+++ acc_write =     4040541
+++ acc_check =      140011
+++ acc_notrw =      140011
+++ acc_none  =           0
+++ ctrans    =      296160
+++ 0 retries =      292095  (98.6%)
+++ 1 retries =        3841  ( 1.3%)
+++ 2 retries =         203  ( 0.1%)
+++ 3 retries =          17  ( 0.0%)
+++ 4 retries =           3  ( 0.0%)
+++ 5 retries =           0  ( 0.0%)
+++ 6 retries =           0  ( 0.0%)
+++ 7 retries =           0  ( 0.0%)
+++ 8+retries =           1  ( 0.0%)

As you can see, constrained transactions are now successfully completing on their first attempt over 99% of the time.

What I think is also interesting is that even with OPTION_TXF_SINGLE_THREAD enabled, some transactions are still failing multiple times before eventually succeeding. I'm not sure why nor am I sure what, if anything, we can do about it (or even whether we should try to do anything about it! Maybe we shouldn't!).

This definitely looks like a major improvement!

z/OS 2.4 now appears to behave identical under z/VM 6.4 as well as natively.

Initial tests using CPUMODEL 1090 were originally still producing the same problems as described under Issues #309 and #310, but after changing to CPUMODEL 2964 and allowing a JES2 queue rebuild, they now no longer happen.

z/OSMF now produces a problem (see Issue #315), but this is using an Unconstrained TBEGIN. It does this reproducibly both natively and under z/VM 6.4 as well. Since I suspected the problem might related to OPTION_TXF_SINGLE_THREAD, I tried a build without that option, but it unfortunately made no difference.

Thanks for all the good work Fish!

Cheers,

This definitely looks like a major improvement!

z/OS 2.4 now appears to behave identical under z/VM 6.4 as well as natively.

Fantastic! Thank you for the confirmation, Peter.

Initial tests using CPUMODEL 1090 were originally still producing the same problems as described under Issues #309 and #310, but after changing to CPUMODEL 2964 and allowing a JES2 queue rebuild, they now no longer happen.

That's also good news!

May I presume that you are going to close both of those Issues now?

z/OSMF now produces a problem (see Issue #315), but this is using an Unconstrained TBEGIN. It does this reproducibly both natively and under z/VM 6.4 as well.

(Ack!) Looks like a serious bug in my program_interrupt logic! I guess I should have tried z/OSMF for myself before having committed my changes! (Bad Fish! Naughty Fish! Bad, bad, naughty, NAUGHTY Fish!)

Let me see if I can reproduce it myself and if I can I'll jump right on it to see what's going on. I obviously farqed something up somewhere. :(

Since I suspected the problem might related to OPTION_TXF_SINGLE_THREAD, I tried a build without that option, but it unfortunately made no difference.

Thanks for that.

Thanks for all the good work Fish!

Cheers,

Thanks. It took a lot of hard work but I think I managed to fix enough problems such that TXF now seems to behave much better than before. It's obvious we still have more work to do on the SIE and unconstrained transactions side of things however (Duh!), but hey, we're slowly getting there!

Anyway, thanks for the report, Peter!

I'll jump on #315 right away.

And just to make it official (on the off chance that he didn't see my latest commit) I would like to both officially and to publicly thank Bob Wood (@rwoodpd) for his fantastic and much appreciated effort in providing Hercules with its original TXF support!

We would not be as far as we are today without your truly Herculean groundwork, Bob!

** THANK YOU!! **

(Re-asking same question again that I asked earlier since I received no response to it yet):

QUESTION: given what I just wrote above, I'm wondering how the rest of you feel about possibly adding some rudimentary CPU model number checking logic to our existing Facility support? (e.g. if facility 73 or 50 are enabled then the model number must be 2827 or greater, otherwise it's an error).

I was also thinking of maybe adding, as a courtesy, a bunch of predefined DEFSYMs for CPU model name to model number equivalents (e.g. $(EC12) = "2827", etc) to make it easier on our users to specify the correct model number. We could also add code to translate model numbers to model names too, and report the name of the model at startup (i.e. whenever we report/display the cpu model number in response to processing the CPUMODEL statement, we could, in addition to just displaying the model number like we are now, also display within parentheses after it what model name that particular model number equates to).

What do you think?

Anyone? Or should we maybe leave Hercules alone and let someone like me put such support into HercGUI instead for example?

What do you guys think?

Based upon your tests, having the correct model # seems to make a big difference. I also suspect this will get worse over time. TXF is tightly coupled to the model. I think it will be a moving target for everyone for awhile, anyway. Yes, some form of interaction with the user is probably wise. I would recommend a simple warning message. There may be times when doing something different particularly for testers or developers would be a good thing. I would not recommend forcing the issue to the extent that the model number is required. This could constrain the future. While you might want to take a different path with your product, that is your call. But for Hercules itself, alerting the user to a "conflict" might be best. MOHarold Grovesteen On Mon, 2020-07-27 at 12:08 -0700, Fish-Git wrote:

(Re-asking same question again that I asked earlier since I received no response to it yet):

QUESTION: given what I just wrote above, I'm wondering how the rest of you feel about possibly adding some rudimentary CPU model number checking logic to our existing Facility support? (e.g. if facility 73 or 50 are enabled then the model number must be 2827 or greater, otherwise it's an error). I was also thinking of maybe adding, as a courtesy, a bunch of predefined DEFSYMs for CPU model name to model number equivalents (e.g. $(EC12) = "2827", etc) to make it easier on our users to specify the correct model number. We could also add code to translate model numbers to model names too, and report the name of the model at startup (i.e. whenever we report/display the cpu model number in response to processing the CPUMODEL statement, we could, in addition to just displaying the model number like we are now, also display within parentheses after it what model name that particular model number equates to). What do you think?

Anyone? Or should we maybe leave Hercules alone and let someone like me put such support into HercGUI instead for example? What do you guys think?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

I like the idea of CPU checking in Hercules Facility support. Predefined DEFSYMs would be a nice touch, though I would probably use the model number.

On July 27, 2020 2:08 PM Fish-Git <notifications@github.com> wrote:

(Re-asking same question again that I asked earlier https://github.com/SDL-Hercules-390/hyperion/issues/263#issuecomment-663729062 since I received no response to it yet):

    > >

    QUESTION: given what I just wrote above, I'm wondering how the rest of you feel about possibly adding some rudimentary CPU model number checking logic to our existing Facility support? (e.g. if facility 73 or 50 are enabled then the model number must be 2827 or greater, otherwise it's an error).

    I was also thinking of maybe adding, as a courtesy, a bunch of predefined DEFSYMs for CPU model name to model number equivalents (e.g. $(EC12) = "2827", etc) to make it easier on our users to specify the correct model number. We could also add code to translate model numbers to model names too, and report the name of the model at startup (i.e. whenever we report/display the cpu model number in response to processing the CPUMODEL statement, we could, in addition to just displaying the model number like we are now, also display within parentheses after it what model name that particular model number equates to).

    What do you think?

>

Anyone? Or should we maybe leave Hercules alone and let someone like me put such support into HercGUI instead for example?

What do you guys think?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/SDL-Hercules-390/hyperion/issues/263#issuecomment-664583569 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ACMWJACFHHS6H6VCDRWKC7TR5XGD3ANCNFSM4JBAT3DA .

I vote for HercGUI.

Richard Pinion rpinion@netscape.com

-----Original Message----- From: Fish-Git notifications@github.com To: SDL-Hercules-390/hyperion hyperion@noreply.github.com Cc: rpinion rpinion@netscape.com; Mention mention@noreply.github.com Sent: Mon, Jul 27, 2020 3:08 pm Subject: Re: [SDL-Hercules-390/hyperion] Transactional-Execution Facility design / implementation (#263)

(Re-asking same question again that I asked earlier since I received no response to it yet): QUESTION: given what I just wrote above, I'm wondering how the rest of you feel about possibly adding some rudimentary CPU model number checking logic to our existing Facility support? (e.g. if facility 73 or 50 are enabled then the model number must be 2827 or greater, otherwise it's an error).I was also thinking of maybe adding, as a courtesy, a bunch of predefined DEFSYMs for CPU model name to model number equivalents (e.g. $(EC12) = "2827", etc) to make it easier on our users to specify the correct model number. We could also add code to translate model numbers to model names too, and report the name of the model at startup (i.e. whenever we report/display the cpu model number in response to processing the CPUMODEL statement, we could, in addition to just displaying the model number like we are now, also display within parentheses after it what model name that particular model number equates to).What do you think? Anyone? Or should we maybe leave Hercules alone and let someone like me put such support into HercGUI instead for example?What do you guys think?— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

Hello,

I picked up today then last Hyperion snapshot.

It works with z/OS 2.4 native PUT2002 applied, but not with z/OS 2.4 native PUT2006 applied.

Here are the symptoms:

HHC00801I Processor CP01: Transaction constraint exception code 0218 ilc 6 TXF_WHY_INSTRADDR                                                                         
HHC02324I CP01: PSW=0404700180000000 0000000001AD9FF0 INST=E56100000008 TBEGINC 0(0),8                 transaction_begin_constrained                                 
HHC02326I CP01: V:0000000000000000:K:0E=000A0000 000130E1 00000000 00000000  ................                                                                        
HHC02326I CP01: V:0000000000000008:K:0E=00000000 00000000 00FD5540 00000000  ........... ....                                                                        
HHC02269I CP01: R0=0000000000000002 R1=0000000005800009                                                                                                              
HHC02269I CP01: R2=0000001000000002 R3=0000000000000001                                                                                                              
HHC02269I CP01: R4=0000000001DD0D00 R5=0000000000000001                                                                                                              
HHC02269I CP01: R6=0000000001DD0D00 R7=0000000005F7C700                                                                                                              
HHC02269I CP01: R8=0000000001DD0D00 R9=FFFFFFFF0000000A                                                                                                              
HHC02269I CP01: RA=0000000000000001 RB=0000000000000001                                                                                                              
HHC02269I CP01: RC=0000000001ADA298 RD=00000000023DB658                                                                                                              
HHC02269I CP01: RE=0000000001AD8382 RF=000000000580000A                                                                                                              
HHC02271I CP01: C0=00800002DF98EE20 C1=00000001FFE18007                                                                                                              
HHC02271I CP01: C2=000000007D6E6540 C3=0000000184400022                                                                                                              
HHC02271I CP01: C4=0000000100010022 C5=000000007EE6A880                                                                                                              
HHC02271I CP01: C6=00000000FE000000 C7=00000001FFE18007                                                                                                              
HHC02271I CP01: C8=0000000000020000 C9=0000000000000000                                                                                                              
HHC02271I CP01: CA=0000000000000000 CB=0000000000000000                                                                                                              
HHC02271I CP01: CC=00000000F992558F CD=00000001FFE18007                                                                                                              
HHC02271I CP01: CE=00000000DF8FEE69 CF=00000000025C7010                                                                                                              
HHC02272I CP01: AR00=00000000 AR01=00000000 AR02=00000000 AR03=00000000                                                                                              
HHC02272I CP01: AR04=01000002 AR05=00000000 AR06=00000000 AR07=01000002                                                                                              
HHC02272I CP01: AR08=00000000 AR09=00000000 AR10=00000000 AR11=01000002                                                                                              
HHC02272I CP01: AR12=00000000 AR13=00000000 AR14=00000000 AR15=00000001

M 4040000 SYSM     20291 12:30:44.84          00000090  IGD300I AN ABEND OCCURRED DURING SMS PROCESSING 292                        
D                                         292 00000090    ABEND SYSTEM CODE=A78 ASID=0022                                          
D                                         292 00000090    COMPONENT NAME=SMS  COMPONENT ID=DF101                                   
D                                         292 00000090    ACTIVE LOAD MODULE  NAME=UNKNOWN  ADDRESS=UNKNOWN                        
D                                         292 00000090    CSECT IN ERROR      DESCRIPTION=UNKNOWN                                  
D                                         292 00000090                        NAME=UNKNOWN  ADDRESS=UNKNOWN  OFFSET=UNKNOWN        
D                                         292 00000090                        ASSEMBLY DATE=UNKNOWN  PTF LEVEL=UNKNOWN             
D                                         292 00000090    PSW AT TIME OF ERROR 070C1000 81570808                                   
D                                         292 00000090    DATA AT PSW 01570802 - 00181610 0A0D18CE 18FB180C                        
D                                         292 00000090    GPR 00-03  84000000  84A78000  7F30C14C  00000003                        
D                                         292 00000090    GPR 04-07  009D8CF0  009F8210  8156B4D0  00FB0E80                        
D                                         292 00000090    GPR 08-11  00000000  00004000  0A30A000  7FFFDC10                        
E                                         292 00000090    GPR 12-15  00004003  7F30C068  04395F60  0000001C

Any ideas?

I picked up today then last Hyperion snapshot.

What is "the last Hyperion snapshot?"

It works with z/OS 2.4 native PUT2002 applied, but not with z/OS 2.4 native PUT2006 applied.

That sounds like a z/OS issue to me, not a Hercules issue. Hercules doesn't have "PUT"s (whatever the heck those are).

Here are the symptoms:

HHC00801I Processor CP01: Transaction constraint exception code 0218 ilc 6 TXF_WHY_INSTRADDR

If Hercules is throwing a Transaction constraint exception, then it is very likely that a Transaction constraint exception is legitimately occurring. You might consider using the Hercules TXF debugging command txf c bad tdb why 80000000 to display the TDB when the exception occurs to confirm the legitimacy of the exception.

M 4040000 SYSM     20291 12:30:44.84          00000090  IGD300I AN ABEND OCCURRED DURING SMS PROCESSING 292
...

This also looks like a z/OS problem.

It's the SDL hyperion snapshot from 10/19/2020 Ok, it could be a z/OS problem, may be a now one. I'll will investigate and let you know Thanks.

Hello, Although the problem was not described in the IBM databases, I still applied the last level of maintenance and the problem disappeared. You were right, it was a z/OS issue. I apologize for the inconvenience

@michelduplant

FYI to you and others out there:

michelduplant wrote:

Fish wrote:

michelduplant wrote:

I picked up today then last Hyperion snapshot.

What is "the last Hyperion snapshot?"

It's the SDL hyperion snapshot from 10/19/2020

That is not helpful.

When someone asks what version of Hercules you are using, they need to know to EXACT version that Hercules itself reports upon startup, e.g.:

HHC00100I Thread id 0000268c, prio 5, name 'impl_thread' started
HHC00100I Thread id 00002f28, prio 4, name 'logger_thread' started
HHC01413I Hercules version 4.3.9999.10267-SDL-g1ba20b46-modified (4.3.9999.10267)
HHC01414I (C) Copyright 1999-2020 by Roger Bowler, Jan Jaeger, and others
HHC01417I ** The SoftDevLabs version of Hercules **
HHC01415I Build date: Oct 24 2020 at 13:33:47
HHC01417I Built with: Microsoft Visual Studio 2008 (MSVC 150030729 1)
HHC01417I Build type: Windows MSVC AMD64 host architecture build
HHC01417I Modes: S/370 ESA/390 z/Arch
HHC01417I Max CPU Engines: 64
HHC01417I Using   shared libraries
HHC01417I Using   Fish threads Threading Model
HHC01417I Using   Error-Checking Mutex Locking Model
HHC01417I With    Shared Devices support
HHC01417I With    Dynamic loading support
HHC01417I With    External GUI support
HHC01417I With    Partial TCP keepalive support
HHC01417I With    IPV6 support
HHC01417I With    HTTP Server support
HHC01417I With    sqrtl support
HHC01417I With    Signal handling
HHC01417I With    Watchdog monitoring
HHC01417I With    CCKD BZIP2 support
HHC01417I With    HET BZIP2 support
HHC01417I With    ZLIB support
HHC01417I With    Regular Expressions support
HHC01417I With    Object REXX support
HHC01417I Without Regina REXX support
HHC01417I With    Automatic Operator support
HHC01417I Without National Language Support
HHC01417I With    CCKD64 Support
HHC01417I With    Transactional-Execution Facility support
HHC01417I With    "Optimized" instructions
HHC01417I With    OPTION_DEPRECATE_AIM
HHC01417I Without OPTION_TXF_SINGLE_THREAD
HHC01417I With    CATCH_SYNC_CPUS
HHC01417I Without FIX_SYNC_CPUS
HHC01417I Machine dependent assists: cmpxchg1 cmpxchg4 cmpxchg8 cmpxchg16 hatomics=msvcIntrinsics
HHC01417I Running on: WIN7 (Windows-6.1.7601 Intel(R) x64) LP=8, Cores=8, CPUs=2
HHC01417I Built with crypto external package version 1.0.0.31-gbf46d03
HHC01417I Built with decNumber external package version 3.68.0.84-g94144c9
HHC01417I Built with SoftFloat external package version 3.5.0.87-gb706677
HHC01417I Built with telnet external package version 1.0.0.48-gb90a708

Specifically, it is message HHC01413I that we are interested in.

Saying "the one built on such-and-such a date" is not helpful. The version you, or someone else, built on a given date could be ANY version, even a very old one. The date that Hercules was built is not helpful.

The exact version string, is helpful.

The exact version string is what tell us what fixes you have and what fixes you may not have. It tells us exactly what code you are running. There is no ambiguity.

Just reporting a date isn't helpful.

I'm not yelling at you or criticizing or chastising you. I'm just trying to inform (teach) you. I'm just trying to help you, so you can help us to help you.

Exact versions are helpful.

Anything else is not.

Thus endeth the lesson. ;-)

OK, I understand, but my messageHHC01413I is less precise than yours:

HHC01413I Hercules version 4.3.9999.0-SDL (4.3.9999.0)

OK, I understand, but my message HHC01413I is less precise than yours:
HHC01413I Hercules version 4.3.9999.0-SDL (4.3.9999.0)

That's because whoever built it for you, did not build it correctly. They built from the source file .zip instead of from a clone of the repository.

Please see:

https://github.com/SDL-Hercules-390/hyperion/issues/321#issuecomment-683435878 (better explanation)
https://github.com/SDL-Hercules-390/hyperion/issues/258#issuecomment-702913053 (okay explanation)

It's important to do a git clone of the Hercules repository, and then build Hercules from that.

Building from the downloadable .zip file does not provide an exact version string. It only provides a very unhelpful "generic" version string. (This is because the downloadable .zip file does not contain git repository's commit hash.)

Building directly from the source code repository however, causes the version string to be constructed to contain the exact git repostiory "hash", which tells us exactly what "version" (what code) you are running.

Whoever built Hercules for you did not build it correctly. A version string of "4.3.9999.0" is not helpful. It does not tell us what actual code you are running. Version 4.3.9999.0 has been in development for almost a year now, and hundreds of commits/changes have been made since development was first started. A version string of "4.3.9999.0" does not tell us which commits (changes/fixes) you have and which ones you don't. It's not helpful.

The only helpful version string is the one that is constructed whenever you build Hercules directly from a clone of the repository.

Hello everyone,

I hope everyone is safe at home. I don't know if I should create an issue or post it here. I'm having trouble running a java utility keytool it gives me this error below on OMVS:

#keytool -printcert -sslserver zsyst.me.com:1443 -J-Dfile.encoding=UTF8 -rfc
CEE3250C The system or user abend S0E0  R=00000018 was issued.                  
         From entry point ZJ9SYM1 at compile unit offset +00000050131F7720 at en
try offset +0000004F993F7418 at address 00000050131F7720.

On Hercules console I have this :

HHC00801I Processor CP01: Transaction constraint exception code 0218 ilc 4 TXF_WHY_TRAN_FLOAT_INSTR
HHC02324I CP01: PSW=0785040180000000 000000000F0490D6 INST=60040B00     STD   0,2816(4,0)            store_float_long
HHC02326I CP01: V:00000050109FB780:K:86=C03DFFFF FFFFFFFF 406F0000 00000000  {....... ?......
HHC02269I CP01: R0=FFFFFFFFFFFFFFA0 R1=000000009FF10478
HHC02269I CP01: R2=00000000109BBB00 R3=000000000000000E
HHC02269I CP01: R4=00000050109FAC80 R5=00000000109CAEB0
HHC02269I CP01: R6=000000009FF104F0 R7=0000000000000000
HHC02269I CP01: R8=00000050D1019C0A R9=0000000000000000
HHC02269I CP01: RA=0000000000000001 RB=0000000000000000
HHC02269I CP01: RC=1091D60000000000 RD=0000000010902500
HHC02269I CP01: RE=000000501A8215EE RF=000000501A8211FA
HHC02271I CP01: C0=00800002DF9CEE20 C1=00000000FCB2C007
HHC02271I CP01: C2=000000002C9FEB40 C3=0000000200C00043
HHC02271I CP01: C4=0000000200000043 C5=000000007EF400C0
HHC02271I CP01: C6=00000000FE000000 C7=00000000FCB2C007
HHC02271I CP01: C8=0000000000000000 C9=0000000000000000
HHC02271I CP01: CA=0000000000000000 CB=0000000000000000
HHC02271I CP01: CC=00000000D7FC32DB CD=00000000FCB2C007
HHC02271I CP01: CE=00000000DF8FEF38 CF=000000007F449010
HHC02270I CP01: FPR0=C03DFFFFFFFFFFFF FPR2=FFFC000000000000
HHC02270I CP01: FPR1=406F000000000000 FPR3=0000000000000000
HHC02270I CP01: FPR4=3F80000000000000 FPR6=0000000000000000
HHC02270I CP01: FPR5=48A26FA080000000 FPR7=0000000000000000
HHC02270I CP01: FPR8=0000000000000000 FP10=0000000000000000
HHC02270I CP01: FPR9=0000000000000000 FP11=0000000000000000
HHC02270I CP01: FP12=0000000000000000 FP14=0000000000000000
HHC02270I CP01: FP13=0000000000000000 FP15=0000000000000000

(and):

HHC00801I Processor CP01: Transaction constraint exception code 0218 ilc 6 TXF_WHY_TRAN_FLOAT_INSTR
HHC02324I CP01: PSW=0785340180000000 000000501A821246 INST=E560D978BE02 TBEGIN 2424(13),-16894        transaction_begin
HHC02326I CP01: V:0000000010902E78:K:8E=01000000 00000001 00000000 0000000B  ................
HHC02326I CP01: V:0000000000000E02:K:0E=0000 00000000 00000000 00000000 0000 ................
HHC02269I CP01: R0=0000000000000016 R1=000000009FF104F0
HHC02269I CP01: R2=00000000109BBB00 R3=000000000000000E
HHC02269I CP01: R4=00000050109FAC80 R5=00000000109CAEB0
HHC02269I CP01: R6=000000009FF104F0 R7=000000009FF14A48
HHC02269I CP01: R8=000000009FF14ED8 R9=0000000000000000
HHC02269I CP01: RA=0000000000000001 RB=0000000000000000
HHC02269I CP01: RC=1091D60000000000 RD=0000000010902500
HHC02269I CP01: RE=000000501A8215EE RF=000000501A8211FA
HHC02271I CP01: C0=00800002DF9CEE20 C1=00000000FCB2C007
HHC02271I CP01: C2=000000002C9FEB40 C3=0000000200C00043
HHC02271I CP01: C4=0000000200000043 C5=000000007EF400C0
HHC02271I CP01: C6=00000000FE000000 C7=00000000FCB2C007
HHC02271I CP01: C8=0000000000000000 C9=0000000000000000
HHC02271I CP01: CA=0000000000000000 CB=0000000000000000
HHC02271I CP01: CC=00000000D7FC32DB CD=00000000FCB2C007
HHC02271I CP01: CE=00000000DF8FEF38 CF=000000007F449010

I'm using a z/OS 2.4 on Hercules version 4.3.9999.0-SDL-g786505e5 (4.3.9999.0) . Please find below the Hercules startup log:

HHC00100I Thread id 00007f24f6ddbc80, prio 5, name 'impl_thread' started
HHC00100I Thread id 00007f24f6cd9700, prio 4, name 'logger_thread' started
HHC01413I Hercules version 4.3.9999.0-SDL-g786505e5 (4.3.9999.0)
HHC01414I (C) Copyright 1999-2020 by Roger Bowler, Jan Jaeger, and others
HHC01417I ** The SoftDevLabs version of Hercules **
HHC01415I Build date: Nov  3 2020 at 11:11:44
HHC01417I Built with: GCC 9.3.0
HHC01417I Build type: GNU/Linux x86_64 host architecture build
HHC01417I Modes: S/370 ESA/390 z/Arch
HHC01417I Max CPU Engines: 128
HHC01417I Using   shared libraries
HHC01417I Using   setresuid() for setting privileges
HHC01417I Using   POSIX threads Threading Model
HHC01417I Using   Error-Checking Mutex Locking Model
HHC01417I With    Shared Devices support
HHC01417I With    Dynamic loading support
HHC01417I With    External GUI support
HHC01417I With    IPV6 support
HHC01417I With    HTTP Server support
HHC01417I With    sqrtl support
HHC01417I With    Signal handling
HHC01417I With    Watchdog monitoring
HHC01417I Without CCKD BZIP2 support
HHC01417I Without HET BZIP2 support
HHC01417I With    ZLIB support
HHC01417I With    Regular Expressions support
HHC01417I Without Object REXX support
HHC01417I Without Regina REXX support
HHC01417I With    Automatic Operator support
HHC01417I Without National Language Support
HHC01417I With    CCKD64 Support
HHC01417I With    Transactional-Execution Facility support
HHC01417I With    "Optimized" instructions
HHC01417I With    OPTION_DEPRECATE_AIM
HHC01417I Without OPTION_TXF_SINGLE_THREAD
HHC01417I Machine dependent assists: cmpxchg1 cmpxchg4 cmpxchg8 cmpxchg16 hatomics=C11
HHC01417I Running on: myvm (Linux-5.4.0-52-generic x86_64) MP=4
HHC01417I Built with crypto external package version 1.0.0.27-ga3e07b5
HHC01417I Built with decNumber external package version 3.68.0.80-gdb5c456
HHC01417I Built with SoftFloat external package version 3.5.0.83-g3da230f
HHC01417I Built with telnet external package version 1.0.0.45-g2d9f219-modified
HHC00018I Hercules is running in elevated mode
HHC00150I Crypto module loaded (C) Copyright 2003-2016 by Bernard van der Helm
HHC00151I Activated facility: Message Security Assist
HHC00151I Activated facility: Message Security Assist Extension 1, 2, 3 and 4
HHC00111I Thread CPU Time IS available (_POSIX_THREAD_CPUTIME=0)
HHC00100I Thread id 00007f24f688b700, prio 2, name 'Processor CP00' started
HHC00100I Thread id 00007f24f678a700, prio 7, name 'timer_thread' started
HHC00811I Processor CP00: architecture mode z/Arch
HHC02204I ARCHLVL        set to z/Arch
HHC00898W Facility( 073_TRANSACT_EXEC ) *Enabled for z/Arch
HHC00007I Previous message from function 'facility_enable_disable' at facility.c(3584)
HHC00898W Facility( 050_CONSTR_TRANSACT ) *Enabled for z/Arch
HHC00007I Previous message from function 'facility_enable_disable' at facility.c(3584)
HHC00898I Facility( 044_PFPO ) Enabled for z/Arch
HHC00891I
HHC00891I                             z/Arch Facility Table
HHC00891I
HHC00891I           SRDC* = Supported, Required, Default, Current, Modified.
HHC00891I
HHC00891I Bit By Bi SRDC* Facility                    Description
HHC00891I --- -- -- ----- --------------------------- ---------------------------------------------------------
HHC00891I
HHC00891I   0 00 80 Y-11  000_N3_INSTR                N3 Instructions are installed
HHC00891I   1 00 40 YY11  001_ZARCH_INSTALLED         z/Architecture architectural mode is installed
HHC00891I   2 00 20 YY11  002_ZARCH_ACTIVE            z/Architecture architectural mode is active
HHC00891I   3 00 10 Y-11  003_DAT_ENHANCE_1           DAT-Enhancement Facility 1
HHC00891I   4 00 08 --00  004_IDTE_SC_SEGTAB          IDTE selective clearing when segment-table invalidated
HHC00891I   5 00 04 --00  005_IDTE_SC_REGTAB          IDTE selective clearing when region-table invalidated
HHC00891I   6 00 02 Y-11  006_ASN_LX_REUSE            ASN-and-LX-Reuse Facility
HHC00891I   7 00 01 Y-11  007_STFL_EXTENDED           Store-Facility-List-Extended Facility
HHC00891I   8 01 80 Y-11  008_EDAT_1                  Enhanced-DAT Facility 1
HHC00891I   9 01 40 Y-11  009_SENSE_RUN_STATUS        Sense-Running-Status Facility
HHC00891I  10 01 20 Y-11  010_CONDITIONAL_SSKE        Conditional-SSKE Facility
HHC00891I  11 01 10 Y-11  011_CONFIG_TOPOLOGY         Configuration-Topology Facility
HHC00891I  13 01 04 Y-11  013_IPTE_RANGE              IPTE-Range Facility
HHC00891I  14 01 02 --00  014_NONQ_KEY_SET            Nonquiescing Key-Setting Facility
HHC00891I  16 02 80 Y-11  016_EXT_TRANSL_2            Extended-Translation Facility 2
HHC00891I  17 02 40 Y-11  017_MSA                     Message-Security Assist
HHC00891I  18 02 20 YY11  018_LONG_DISPL_INST         Long-Displacement Facility
HHC00891I  19 02 10 Y-11  019_LONG_DISPL_HPERF        Long-Displacement Facility Has High Performance
HHC00891I  20 02 08 Y-11  020_HFP_MULT_ADD_SUB        HFP-Multiply-and-Add/Subtract Facility
HHC00891I  21 02 04 Y-11  021_EXTENDED_IMMED          Extended-Immediate Facility
HHC00891I  22 02 02 Y-11  022_EXT_TRANSL_3            Extended-Translation Facility 3
HHC00891I  23 02 01 Y-11  023_HFP_UNNORM_EXT          HFP-Unnormalized-Extensions Facility
HHC00891I  24 03 80 Y-11  024_ETF2_ENHANCEMENT        ETF2-Enhancement Facility
HHC00891I  25 03 40 Y-11  025_STORE_CLOCK_FAST        Store-Clock-Fast Facility
HHC00891I  26 03 20 Y-11  026_PARSING_ENHANCE         Parsing-Enhancement Facility
HHC00891I  27 03 10 Y-11  027_MVCOS                   Move-with-Optional-Specifications Facility
HHC00891I  28 03 08 Y-11  028_TOD_CLOCK_STEER         TOD-Clock-Steering Facility
HHC00891I  30 03 02 Y-11  030_ETF3_ENHANCEMENT        ETF3-Enhancement Facility
HHC00891I  31 03 01 Y-11  031_EXTRACT_CPU_TIME        Extract-CPU-Time Facility
HHC00891I  32 04 80 Y-11  032_CSSF                    Compare-and-Swap-and-Store Facility 1
HHC00891I  33 04 40 Y-11  033_CSSF2                   Compare-and-Swap-and-Store Facility 2
HHC00891I  34 04 20 Y-11  034_GEN_INST_EXTN           General-Instructions-Extension Facility
HHC00891I  35 04 10 Y-11  035_EXECUTE_EXTN            Execute-Extensions Facility
HHC00891I  36 04 08 Y-11  036_ENH_MONITOR             Enhanced-Monitor Facility
HHC00891I  37 04 04 Y-11  037_FP_EXTENSION            Floating-Point-Extension Facility
HHC00891I  38 04 02 --00  038_OP_CMPSC                Order-Preserving-Compression Facility
HHC00891I  40 05 80 Y-11  040_LOAD_PROG_PARAM         Load-Program-Parameter Facility
HHC00891I  41 05 40 Y-11  041_DFP_ROUNDING            Decimal-Floating-Point-Rounding Facility
HHC00891I  41 05 40 Y-11  041_FPR_GR_TRANSFER         FPR-GR-Transfer Facility
HHC00891I  41 05 40 Y-11  041_FPS_ENHANCEMENT         Floating-Point-Support-Enhancement Facility
HHC00891I  41 05 40 Y-11  041_FPS_SIGN_HANDLING       Floating-Point-Support-Sign-Handling Facility
HHC00891I  41 05 40 Y-11  041_IEEE_EXCEPT_SIM         IEEE-Exception-Simulation Facility
HHC00891I  42 05 20 Y-11  042_DFP                     Decimal-Floating-Point Facility
HHC00891I  43 05 10 Y-11  043_DFP_HPERF               Decimal-Floating-Point Facility Has High Performance
HHC00891I  44 05 08 Y-11  044_PFPO                    PFPO (Perform Floating-Point Operation) Facility
HHC00891I  45 05 04 Y-11  045_DISTINCT_OPERANDS       Distinct-Operands Facility
HHC00891I  45 05 04 Y-11  045_FAST_BCR_SERIAL         Fast-BCR-Serialization Facility
HHC00891I  45 05 04 Y-11  045_HIGH_WORD               High-Word Facility
HHC00891I  45 05 04 Y-11  045_INTERLOCKED_ACCESS_1    Interlocked-Access Facility 1
HHC00891I  45 05 04 Y-11  045_LOAD_STORE_ON_COND_1    Load/Store-on-Condition Facility 1
HHC00891I  45 05 04 Y-11  045_POPULATION_COUNT        Population-Count Facility
HHC00891I  47 05 01 Y-11  047_CMPSC_ENH               CMPSC-Enhancement Facility
HHC00891I  48 06 80 Y-11  048_DFP_ZONE_CONV           Decimal-Floating-Point-Zoned-Conversion Facility
HHC00891I  49 06 40 Y-11  049_EXECUTION_HINT          Execution-Hint Facility
HHC00891I  49 06 40 Y-11  049_LOAD_AND_TRAP           Load-and-Trap Facility
HHC00891I  49 06 40 Y-11  049_MISC_INSTR_EXT_1        Miscellaneous-Instruction-Extensions Facility 1
HHC00891I  49 06 40 Y-11  049_PROCESSOR_ASSIST        Processor-Assist Facility
HHC00891W  50 06 20 Y-01* 050_CONSTR_TRANSACT        *Constrained-Transactional-Execution Facility
HHC00007I Previous message from function 'facility_query_all' at facility.c(1253)
HHC00891I  51 06 10 --00  051_LOCAL_TLB_CLEARING      Local-TLB-Clearing Facility
HHC00891I  52 06 08 Y-11  052_INTERLOCKED_ACCESS_2    Interlocked-Access Facility 2
HHC00891I  53 06 04 Y-11  053_LOAD_STORE_ON_COND_2    Load/Store-on-Condition Facility 2
HHC00891I  53 06 04 Y-11  053_LOAD_ZERO_RIGHTMOST     Load-and-Zero-Rightmost-Byte Facility
HHC00891I  54 06 02 --00  054_EE_CMPSC                Entropy-Encoding-Compression Facility
HHC00891I  57 07 40 --00  057_MSA_EXTENSION_5         Message-Security-Assist Extension 5
HHC00891I  58 07 20 --00  058_MISC_INSTR_EXT_2        Miscellaneous-Instruction-Extensions Facility 2
HHC00891I  61 07 04 --00  061_MISC_INSTR_EXT_3        Miscellaneous-Instruction-Extensions Facility 3
HHC00891I  66 08 20 Y-11  066_RES_REF_BITS_MULT       Reset-Reference-Bits-Multiple Facility
HHC00891I  67 08 10 --00  067_CPU_MEAS_COUNTER        CPU-Measurement Counter Facility
HHC00891I  68 08 08 --00  068_CPU_MEAS_SAMPLNG        CPU-Measurement Sampling Facility
HHC00891W  73 09 40 Y-01* 073_TRANSACT_EXEC          *Transactional-Execution Facility
HHC00007I Previous message from function 'facility_query_all' at facility.c(1253)
HHC00891I  74 09 20 --00  074_STORE_HYPER_INFO        Store-Hypervisor-Information Facility
HHC00891I  75 09 10 Y-11  075_ACC_EX_FS_INDIC         Access-Exception-Fetch/Store-Indication Facility
HHC00891I  76 09 08 Y-11  076_MSA_EXTENSION_3         Message-Security-Assist Extension 3
HHC00891I  77 09 04 Y-11  077_MSA_EXTENSION_4         Message-Security-Assist Extension 4
HHC00891I  78 09 02 --00  078_EDAT_2                  Enhanced-DAT Facility 2
HHC00891I  80 0A 80 --00  080_DFP_PACK_CONV           Decimal-Floating-Point-Packed-Conversion Facility
HHC00891I 129 10 40 --00  129_ZVECTOR                 Vector Facility for z/Architecture
HHC00891I 130 10 20 --00  130_INSTR_EXEC_PROT         Instruction-Execution-Protection Facility
HHC00891I 131 10 10 --00  131_SIDE_EFFECT_ACCESS      Side-Effect-Access Facility
HHC00891I 133 10 04 --00  133_GUARDED_STORAGE         Guarded-Storage Facility
HHC00891I 134 10 02 --00  134_ZVECTOR_PACK_DEC        Vector Packed-Decimal Facility
HHC00891I 135 10 01 --00  135_ZVECTOR_ENH_1           Vector-Enhancements Facility 1
HHC00891I 138 11 20 --00  138_CONFIG_ZARCH_MODE       CZAM Facility (Configuration-z/Architecture-Architectural-Mode)
HHC00891I 139 11 10 --00  139_MULTIPLE_EPOCH          Multiple-Epoch Facility
HHC00891I 142 11 02 --00  142_ST_CPU_COUNTER_MULT     Store-CPU-Counter-Multiple Facility
HHC00891I 144 12 80 --00  144_TEST_PEND_EXTERNAL      Test-Pending-External-Interruption Facility
HHC00891I 145 12 40 --00  145_INS_REF_BITS_MULT       Insert-Reference-Bits-Multiple Facility
HHC00891I 146 12 20 --00  146_MSA_EXTENSION_8         Message-Security-Assist Extension 8
HHC00891I 151 12 01 --00  151_DEFLATE_CONV            DEFLATE-Conversion Facility
HHC00891I 155 13 10 --00  155_MSA_EXTENSION_9         Message-Security-Assist Extension 9
HHC00891I 168 15 80 --00  168_ESA390_COMPAT_MODE      ESA/390-Compatability-Mode Facility
HHC00891I 192 18 80 --00  HERC_370_EXTENSION          Hercules S/370 Instruction Extension Facility
HHC00891I 193 18 40 Y-11  HERC_DETECT_PGMINTLOOP      Hercules Detect-Program-Interrupt-Loop Support
HHC00891I 194 18 20 Y-00  HERC_HOST_RESOURCE_ACCESS   Hercules Host Resource Access Support
HHC00891I 195 18 10 --00  HERC_INTERVAL_TIMER         Hercules Interval Timer Support
HHC00891I 196 18 08 Y-11  HERC_LOGICAL_PARTITION      Hercules Logical Partition (LPAR) Support
HHC00891I 197 18 04 YY11  HERC_MOVE_INVERSE           Hercules MVCIN Move Inverse Instruction Support
HHC00891I 198 18 02 Y-11  HERC_MSA_EXTENSION_1        Hercules Message-Security-Assist Extension 1 Support
HHC00891I 199 18 01 Y-11  HERC_MSA_EXTENSION_2        Hercules Message-Security-Assist Extension 2 Support
HHC00891I 200 19 80 Y-00  HERC_PROBSTATE_DIAGF08      Hercules Problem-State Diagnose X'F08' Support
HHC00891I 201 19 40 Y-00  HERC_QDIO_ASSIST            Hercules QDIO-Assist Support
HHC00891I 202 19 20 Y-00  HERC_QDIO_TDD               Hercules QDIO Time-Delayed-Dispatching Support
HHC00891I 203 19 10 Y-11  HERC_QDIO_THININT           Hercules QDIO Thin-Interrupts Support
HHC00891I 204 19 08 Y-11  HERC_QEBSM                  Hercules QDIO Enhanced Buffer-State Management Support
HHC00891I 205 19 04 Y-00  HERC_SIGP_SETARCH_S370      Hercules SIGP Set Architecture S/370 Support
HHC00891I 206 19 02 Y-11  HERC_SVS                    Hercules SVS Set Vector Summary Instruction Support
HHC00891I 207 19 01 Y-00  HERC_VIRTUAL_MACHINE        Hercules Emulate Virtual Machine Support
HHC00891I 208 1A 80 --00  HERC_TCPIP_EXTENSION        Hercules Access Host TCP/IP Stack Through X'75' Instruction
HHC00891I 209 1A 40 --00  HERC_TCPIP_PROB_STATE       Hercules Enable X'75' As Problem State Instruction
HHC00891I
HHC00891I           SRDC* = Supported, Required, Default, Current, Modified.
HHC00891I
HHC02204I CPUSERIAL      set to 032AF8
HHC02204I CPUMODEL       set to 8561
HHC02204I PLANT          set to 02
HHC02204I MODEL          set to hardware(608) capacity(608) perm() temp()
HHC02204I MANUFACTURER   set to IBM
HHC17003I MAIN     storage is 4048M (mainsize); storage is not locked
HHC17003I EXPANDED storage is 0 (xpndsize); storage is not locked
HHC00100I Thread id 00007f24f6a8e700, prio 2, name 'Processor CP01' started
HHC00811I Processor CP01: architecture mode z/Arch
HHC00100I Thread id 00007f24f698d700, prio 2, name 'Processor CP02' started
HHC00811I Processor CP02: architecture mode z/Arch
HHC00100I Thread id 00007f24f6607700, prio 2, name 'Processor CP03' started
HHC00811I Processor CP03: architecture mode z/Arch
HHC00100I Thread id 00007f24f6506700, prio 2, name 'Processor CP04' started
HHC00811I Processor CP04: architecture mode z/Arch
HHC00100I Thread id 00007f24f6405700, prio 2, name 'Processor CP05' started
HHC00811I Processor CP05: architecture mode z/Arch
HHC02204I NUMCPU         set to 6
HHC02204I MAXCPU         set to 9
HHC00827I Processor CP00: engine 00 type 0 set: CP
HHC00827I Processor CP01: engine 01 type 0 set: CP
HHC00827I Processor CP02: engine 02 type 0 set: CP
HHC00827I Processor CP03: engine 03 type 0 set: CP
HHC02204I TZOFFSET       set to +0100
HHC02204I PANRATE        set to FAST
HHC02204I LOADPARM       set to 5038S0M1
HHC02204I LPARNAME       set to SYST
HHC02204I DIAG8CMD       set to ENABLE  NOECHO
HHC02204I PANTITLE       set to Hercules z/OS 2.40 : ipl 50A1 to IPL
HHC00346I cckd opts: comp=-1,compparm=-1,debug=0,freepend=-1,fsync=0,gcint=10,gcparm=4
HHC00346I            linuxnull=0,nosfd=0,nostress=0,ra=9,raq=16,rat=16,trace=64,wr=8
HHC00414I 0:5000 CKD file Z2SRE1.CKD: model 3390-9 cyls 10020 heads 15 tracks 150300 trklen 56832
HHC00100I Thread id 00007f24f62ee700, prio 4, name 'console_connect' started
HHC01024I Waiting for console connections on port 3270

Kind regards,

Abdo

Hi azarrafa!

Posting it here is fine since it's obviously a TXF issue and TXF support is still under development. Just as an FYI: once 4.3 is eventually finished and officially released, then this GitHub Issue would logically be closed and THEN you would need to create a new GitHub Issue for whatever problem you might be experiencing. For now however, since the problem you are experiencing has to do with a new still-under-development feature that this GitHub Issue was specifically created for, it was correct for you to post your problem/question here. Thank you!

As far as your problem is concerned, it appears to be a legitimate transactional constraint violation: Floating Point instructions are not allowed in an unconstrained transaction unless the "Allow Floating-Point Operation (F)" flag was specified in operand-2 of the TBEGIN instruction (which it appears it wasn't). Refer to page 7-402 of SA22-7832-12 zArchitecture Principles of Operation.

So it would appear that the keytool java utility contains a bug in that it is generating a sequence of instructions contained within an unconstrained transaction that violates its own defined constraints! (Oops!)

Bottom line: Hercules appears to be correct. keytool appears to be wrong. Sorry! :(

Addendum: entering the Hercules command txf u bad tdb before doing "keytool" (enter help txf for more information) will display the failing transaction's "Transaction Diagnostic Block" (TDB), which should display "TAC_INSTR (Restricted instruction)" for the TDB's "tac" (Transaction Abort Code) field, confirming that keytool's transaction did indeed violate a transactional constraint.

Thanks Fish for your quick reply. Much appreciated. I will do that.

Hello Fish,

These some instructions that were executed around the error that I copied. I attached the whole log if it helps. Thanks.

23:14:39 HHC17703D TXF: CP05: Failed Outermost Uncons Transaction for TND 1: TAC_EXT = External interruption, why = TXF_WHY_EXT_INT
23:14:39 HHC17709D TXF: CP05: Formatted dump of TDB:
23:14:39 HHC17721D TXF: CP05: Fmt: 1, TND: 1, EAID: 00, DXC/VXC: 00, PIID: 00000000, Flags: (none)
23:14:39 HHC17721D TXF: CP05: TAC:   0x0000000000000002: TAC_EXT = External interruption
23:14:39 HHC17721D TXF: CP05: Token: 0x0000000000000000, ATIA:  0x000000501A40F64C
23:14:39 HHC17721D TXF: CP05: 
23:14:39 HHC17721D TXF: CP05: 000000501A40F64C INST=E560D9783E02 TBEGIN 2424(13),15874         transaction_begin
23:14:39 HHC17721D TXF: CP05: 
23:14:39 HHC17721D TXF: CP05: TEID:  0x000000506CE97000, BEA:   0x000000007CA003B4
23:14:39 HHC17721D TXF: CP05: GR 00: 0x0000000000000016, GR 01: 0x000000009FFCC888
23:14:39 HHC17721D TXF: CP05: GR 02: 0x0000005000000005, GR 03: 0x000000000000000E
23:14:39 HHC17721D TXF: CP05: GR 04: 0x00000050109FDE00, GR 05: 0x000000000F10B1C0
23:14:39 HHC17721D TXF: CP05: GR 06: 0x0000000000000001, GR 07: 0x000000009FFCC868
23:14:39 HHC17721D TXF: CP05: GR 08: 0x000000009FFCE3D8, GR 09: 0x000000009FFCE520
23:14:39 HHC17721D TXF: CP05: GR 10: 0x0000000000000001, GR 11: 0x000000000F174200
23:14:39 HHC17721D TXF: CP05: GR 12: 0x000000009FFCE490, GR 13: 0x000000000F042500
23:14:39 HHC17721D TXF: CP05: GR 14: 0x000000007AF0B908, GR 15: 0x000000501A40F5F6
23:14:39 HHC17722D TXF: CP03: abort_transaction called from external.c:110
23:14:39 HHC17722D TXF: CP05: abort_transaction called from external.c:110
23:14:39 HHC17703D TXF: CP05: Failed Outermost Uncons Transaction for TND 1: TAC_EXT = External interruption, why = TXF_WHY_EXT_INT
23:14:39 HHC17709D TXF: CP05: Formatted dump of TDB:
23:14:39 HHC17721D TXF: CP05: Fmt: 1, TND: 1, EAID: 00, DXC/VXC: 00, PIID: 00000000, Flags: (none)
23:14:39 HHC17721D TXF: CP05: TAC:   0x0000000000000002: TAC_EXT = External interruption
23:14:39 HHC17721D TXF: CP05: Token: 0x0000000000000000, ATIA:  0x000000501A608C3C
23:14:39 HHC17721D TXF: CP05: 
23:14:42 HHC17721D TXF: CP04: TAC:   0x0000000000000002: TAC_EXT = External interruption
23:14:42 HHC17721D TXF: CP04: Token: 0x0000000000000000, ATIA:  0x000000501A608C3C
23:14:42 HHC17721D TXF: CP04: 
23:14:42 HHC17721D TXF: CP04: 000000501A608C3C INST=E560D978FE02 TBEGIN 2424(13),-510          transaction_begin
23:14:42 HHC17721D TXF: CP04: 
23:14:42 HHC17721D TXF: CP04: TEID:  0x0000000000000000, BEA:   0x000000007CA003B4
23:14:42 HHC17721D TXF: CP04: GR 00: 0x0000000000000016, GR 01: 0x000000008002B178
23:14:42 HHC17721D TXF: CP04: GR 02: 0x0000005000000000, GR 03: 0x000000000000000E
23:14:42 HHC17721D TXF: CP04: GR 04: 0x00000050109FA3C0, GR 05: 0x000000000F10AC68
23:14:42 HHC17721D TXF: CP04: GR 06: 0x000000000F042500, GR 07: 0x000000009FFE7DB8
23:14:42 HHC17721D TXF: CP04: GR 08: 0x0100000000000000, GR 09: 0x0000000000000000
23:14:42 HHC17721D TXF: CP04: GR 10: 0x0000005000000001, GR 11: 0x000000007CA1F156
23:14:42 HHC17721D TXF: CP04: GR 12: 0x00000050109FAF48, GR 13: 0x000000000F042500
23:14:42 HHC17721D TXF: CP04: GR 14: 0x000000007AF0B908, GR 15: 0x000000501A608BF6
23:14:42 HHC17722D TXF: CP03: abort_transaction called from external.c:110
23:14:42 HHC17703D TXF: CP03: Failed Outermost Uncons Transaction for TND 1: TAC_EXT = External interruption, why = TXF_WHY_EXT_INT
23:14:42 HHC17709D TXF: CP03: Formatted dump of TDB:
23:14:42 HHC17721D TXF: CP03: Fmt: 1, TND: 1, EAID: 00, DXC/VXC: 00, PIID: 00000000, Flags: (none)
23:14:42 HHC17721D TXF: CP03: TAC:   0x0000000000000002: TAC_EXT = External interruption
23:14:42 HHC17721D TXF: CP03: Token: 0x0000000000000000, ATIA:  0x000000501A608C3C
23:14:42 HHC17721D TXF: CP03: 
23:14:42 HHC17721D TXF: CP03: 000000501A608C3C INST=E560D978FE02 TBEGIN 2424(13),-510          transaction_begin
23:14:42 HHC17721D TXF: CP03: 
23:14:42 HHC17721D TXF: CP03: TEID:  0x0000000000000000, BEA:   0x000000007CA003B4
23:14:42 HHC17721D TXF: CP03: GR 00: 0x0000000000000016, GR 01: 0x000000008002B178
23:14:42 HHC17721D TXF: CP03: GR 02: 0x0000005000000004, GR 03: 0x000000000000000E
23:14:42 HHC17721D TXF: CP03: GR 04: 0x00000050109FA3C0, GR 05: 0x000000000F10AC68
23:14:42 HHC17721D TXF: CP03: GR 06: 0x000000000F042500, GR 07: 0x000000009FFE7DB8
23:14:42 HHC17721D TXF: CP03: GR 08: 0x0100000000000000, GR 09: 0x0000000000000000
23:14:42 HHC17721D TXF: CP03: GR 10: 0x0000005000000001, GR 11: 0x000000007CA1F156
23:14:42 HHC17721D TXF: CP03: GR 12: 0x00000050109FAF48, GR 13: 0x000000000F042500
23:14:42 HHC17721D TXF: CP03: GR 14: 0x000000007AF0B908, GR 15: 0x000000501A608BF6
23:14:42 HHC17722D TXF: CP03: abort_transaction called from external.c:110
23:14:42 HHC17703D TXF: CP03: Failed Outermost Uncons Transaction for TND 1: TAC_EXT = External interruption, why = TXF_WHY_EXT_INT
23:14:42 HHC17709D TXF: CP03: Formatted dump of TDB:
23:14:42 HHC17721D TXF: CP03: Fmt: 1, TND: 1, EAID: 00, DXC/VXC: 00, PIID: 00000000, Flags: (none)
23:14:42 HHC17721D TXF: CP03: TAC:   0x0000000000000002: TAC_EXT = External interruption
23:14:42 HHC17721D TXF: CP03: Token: 0x0000000000000000, ATIA:  0x000000501A608C3C
23:14:42 HHC17721D TXF: CP03: 
23:14:42 HHC17721D TXF: CP03: 000000501A608C3C INST=E560D978FE02 TBEGIN 2424(13),-510          transaction_begin
23:14:42 HHC17721D TXF: CP03: 
23:14:42 HHC17721D TXF: CP03: TEID:  0x0000000000000000, BEA:   0x000000007CA003B4
23:14:42 HHC17721D TXF: CP03: GR 00: 0x0000000000000016, GR 01: 0x000000008002B178
23:14:42 HHC17721D TXF: CP03: GR 02: 0x000000500000000B, GR 03: 0x000000000000000E
23:14:42 HHC17721D TXF: CP03: GR 04: 0x00000050109FA3C0, GR 05: 0x000000000F10AC68
23:14:42 HHC17721D TXF: CP03: GR 06: 0x000000000F042500, GR 07: 0x000000009FFE7DB8
23:14:42 HHC17721D TXF: CP03: GR 08: 0x0100000000000000, GR 09: 0x0000000000000000
23:14:42 HHC17721D TXF: CP03: GR 10: 0x0000005000000001, GR 11: 0x000000007CA1F156
23:14:42 HHC17721D TXF: CP03: GR 12: 0x00000050109FAF48, GR 13: 0x000000000F042500
23:14:42 HHC17721D TXF: CP03: GR 14: 0x000000007AF0B908, GR 15: 0x000000501A608BF6
23:14:42 HHC17722D TXF: CP05: abort_transaction called from external.c:110
23:14:42 HHC17703D TXF: CP05: Failed Outermost Uncons Transaction for TND 1: TAC_EXT = External interruption, why = TXF_WHY_EXT_INT
23:14:42 HHC17709D TXF: CP05: Formatted dump of TDB:
23:14:42 HHC17721D TXF: CP05: Fmt: 1, TND: 1, EAID: 00, DXC/VXC: 00, PIID: 00000000, Flags: (none)
23:14:42 HHC17721D TXF: CP05: TAC:   0x0000000000000002: TAC_EXT = External interruption
23:14:42 HHC17721D TXF: CP05: Token: 0x0000000000000000, ATIA:  0x000000501A608C3C
23:14:42 HHC17721D TXF: CP05: 
23:14:42 HHC17721D TXF: CP05: 000000501A608C3C INST=E560D978FE02 TBEGIN 2424(13),-510          transaction_begin
23:14:42 HHC17721D TXF: CP05: 
23:14:42 HHC17721D TXF: CP05: TEID:  0x000000506D07E000, BEA:   0x000000007CA003B4
23:14:42 HHC17721D TXF: CP05: GR 00: 0x0000000000000016, GR 01: 0x000000008002B178
23:14:42 HHC17721D TXF: CP05: GR 02: 0x0000005000000015, GR 03: 0x000000000000000E
23:14:42 HHC17721D TXF: CP05: GR 04: 0x00000050109FA3C0, GR 05: 0x000000000F10AC68
23:14:42 HHC17721D TXF: CP05: GR 06: 0x000000000F042500, GR 07: 0x000000009FFE7DB8
23:14:42 HHC17721D TXF: CP05: GR 08: 0x0100000000000000, GR 09: 0x0000000000000000
23:14:42 HHC17721D TXF: CP05: GR 10: 0x0000005000000001, GR 11: 0x000000007CA1F156
23:14:42 HHC17721D TXF: CP05: GR 12: 0x00000050109FAF48, GR 13: 0x000000000F042500
23:14:42 HHC17721D TXF: CP05: GR 14: 0x000000007AF0B908, GR 15: 0x000000501A608BF6
23:14:44 HHC17722D TXF: CP03: abort_transaction called from external.c:110
23:14:44 HHC17703D TXF: CP03: Failed Outermost Uncons Transaction for TND 1: TAC_EXT = External interruption, why = TXF_WHY_EXT_INT
23:14:44 HHC17709D TXF: CP03: Formatted dump of TDB:
23:14:44 HHC17721D TXF: CP03: Fmt: 1, TND: 1, EAID: 0B, DXC/VXC: 00, PIID: 00000000, Flags: (none)
23:14:44 HHC17721D TXF: CP03: TAC:   0x0000000000000002: TAC_EXT = External interruption
23:14:44 HHC17721D TXF: CP03: Token: 0x0000000000000000, ATIA:  0x000000501A608C3C
23:14:44 HHC17721D TXF: CP03: 
23:14:44 HHC17721D TXF: CP03: 000000501A608C3C INST=E560D978FE02 TBEGIN 2424(13),-510          transaction_begin
23:14:44 HHC17721D TXF: CP03: 
23:14:44 HHC17721D TXF: CP03: TEID:  0x0000000000000000, BEA:   0x000000007CA003B4
23:14:44 HHC17721D TXF: CP03: GR 00: 0x0000000000000016, GR 01: 0x000000008002B178
23:14:44 HHC17721D TXF: CP03: GR 02: 0x000000500000000E, GR 03: 0x000000000000000E
23:14:44 HHC17721D TXF: CP03: GR 04: 0x00000050109FB1C0, GR 05: 0x000000000F10AC78
23:14:44 HHC17721D TXF: CP03: GR 06: 0x000000000F042500, GR 07: 0x000000009FE77CE8
23:14:44 HHC17721D TXF: CP03: GR 08: 0x0100000000000000, GR 09: 0x0000000000000000
23:14:44 HHC17721D TXF: CP03: GR 10: 0x0000000000000001, GR 11: 0x000000007CA1F156
23:14:44 HHC17721D TXF: CP03: GR 12: 0x00000050109FBD48, GR 13: 0x000000000F042500
23:14:44 HHC17721D TXF: CP03: GR 14: 0x000000007AF0B908, GR 15: 0x000000501A608BF6
23:14:44 HHC17722D TXF: CP03: abort_transaction called from external.c:110
23:14:44 HHC17703D TXF: CP03: Failed Outermost Uncons Transaction for TND 1: TAC_EXT = External interruption, why = TXF_WHY_EXT_INT
23:14:44 HHC17709D TXF: CP03: Formatted dump of TDB:
23:14:44 HHC17721D TXF: CP03: Fmt: 1, TND: 1, EAID: 0B, DXC/VXC: 00, PIID: 00000000, Flags: (none)
23:14:44 HHC17721D TXF: CP03: TAC:   0x0000000000000002: TAC_EXT = External interruption
23:14:44 HHC17721D TXF: CP03: Token: 0x0000000000000000, ATIA:  0x000000501A608C3C
23:14:44 HHC17721D TXF: CP03: 
23:14:44 HHC17721D TXF: CP03: 000000501A608C3C INST=E560D978FE02 TBEGIN 2424(13),-510          transaction_begin
23:14:44 HHC17721D TXF: CP03: 
23:14:44 HHC17721D TXF: CP03: TEID:  0x0000000000000000, BEA:   0x000000007CA003B4
23:14:44 HHC17721D TXF: CP03: GR 00: 0x0000000000000016, GR 01: 0x000000008002B178
23:14:44 HHC17721D TXF: CP03: GR 02: 0x0000005000000012, GR 03: 0x000000000000000E
23:14:44 HHC17721D TXF: CP03: GR 04: 0x00000050109FB1C0, GR 05: 0x000000000F10AC78
23:14:44 HHC17721D TXF: CP03: GR 06: 0x000000000F042500, GR 07: 0x000000009FE77CE8
23:14:44 HHC17721D TXF: CP03: GR 08: 0x0100000000000000, GR 09: 0x0000000000000000
23:14:44 HHC17721D TXF: CP03: GR 10: 0x0000000000000001, GR 11: 0x000000007CA1F156
23:14:44 HHC17721D TXF: CP03: GR 12: 0x00000050109FBD48, GR 13: 0x000000000F042500
23:14:44 HHC17721D TXF: CP03: GR 14: 0x000000007AF0B908, GR 15: 0x000000501A608BF6
23:14:44 HHC17722D TXF: CP03: abort_transaction called from float.c:4337
23:14:44 HHC17703D TXF: CP03: Failed Outermost Uncons Transaction for TND 1: TAC_INSTR = Restricted instruction, why = TXF_WHY_TRAN_FLOAT_INSTR
23:14:44 HHC00801I Processor CP03: Transaction constraint exception code 0218 ilc 4 TXF_WHY_TRAN_FLOAT_INSTR
23:14:44 HHC02324I CP03: PSW=0785040180000000 000000007AF03732 INST=60040B00     STD   0,2816(4,0)            store_float_long
23:14:44 HHC02326I CP03: V:00000050109FBCC0:K:86=C03DFFFF FFFFFFFF 406F0000 00000000  {....... ?......
23:14:44 HHC02269I CP03: R0=0000000000000000 R1=000000008002B178
23:14:44 HHC02269I CP03: R2=0000005000000013 R3=000000000000000E
23:14:44 HHC02269I CP03: R4=00000050109FB1C0 R5=000000000F10AC78
23:14:44 HHC02269I CP03: R6=000000000F042500 R7=000000009FE77CE8
23:14:44 HHC02269I CP03: R8=00000050D1059C0A R9=0000000000000000
23:14:44 HHC02269I CP03: RA=0000000000000001 RB=000000007CA1F156
23:14:44 HHC02269I CP03: RC=00000050109FBD48 RD=000000000F042500
23:14:44 HHC02269I CP03: RE=000000501A609FA0 RF=000000007AF036F0
23:14:44 HHC02271I CP03: C0=00800002DF9CEE20 C1=00000000FCB7C007
23:14:44 HHC02271I CP03: C2=000000001CF9BB40 C3=0000000100C00043
23:14:44 HHC02271I CP03: C4=0000000100000043 C5=000000007EF400C0
23:14:44 HHC02271I CP03: C6=00000000FE000000 C7=00000000FCB7C007
23:14:44 HHC02271I CP03: C8=0000000000000000 C9=0000000000000000
23:14:44 HHC02271I CP03: CA=0000000000000000 CB=0000000000000000
23:14:44 HHC02271I CP03: CC=00000000D7DDBC43 CD=00000000FCB7C007
23:14:44 HHC02271I CP03: CE=00000000DF8FEF38 CF=000000007F44E010
23:14:44 HHC02270I CP03: FPR0=C03DFFFFFFFFFFFF FPR2=FFFC000000000000
23:14:44 HHC02270I CP03: FPR1=406F000000000000 FPR3=0000000000000000
23:14:44 HHC02270I CP03: FPR4=3F80000000000000 FPR6=0000000000000000
23:14:44 HHC02270I CP03: FPR5=48A6EA4000000000 FPR7=0000000000000000
23:14:44 HHC02270I CP03: FPR8=0000000000000000 FP10=0000000000000000
23:14:44 HHC02270I CP03: FPR9=0000000000000000 FP11=0000000000000000
23:14:44 HHC02270I CP03: FP12=0000000000000000 FP14=0000000000000000
23:14:44 HHC02270I CP03: FP13=0000000000000000 FP15=0000000000000000
23:14:44 HHC17709D TXF: CP03: Formatted dump of TDB:
23:14:44 HHC17721D TXF: CP03: Fmt: 1, TND: 1, EAID: 0B, DXC/VXC: 00, PIID: 00040218, Flags: (none)
23:14:44 HHC17721D TXF: CP03: TAC:   0x000000000000000B: TAC_INSTR = Restricted instruction
23:14:44 HHC17721D TXF: CP03: Token: 0x0000000000000000, ATIA:  0x000000007AF03732
23:14:44 HHC17721D TXF: CP03: 
23:14:44 HHC17721D TXF: CP03: Transaction constraint exception code 0218 ilc 4
23:14:44 HHC17721D TXF: CP03: 000000007AF03732 INST=60040B00     STD   0,2816(4,0)            store_float_long
23:14:44 HHC17721D TXF: CP03: 
23:14:44 HHC17721D TXF: CP03: TEID:  0x0000000000000000, BEA:   0x000000007AF0371E
23:14:44 HHC17721D TXF: CP03: GR 00: 0x0000000000000000, GR 01: 0x000000008002B178
23:14:44 HHC17721D TXF: CP03: GR 02: 0x0000005000000013, GR 03: 0x000000000000000E
23:14:44 HHC17721D TXF: CP03: GR 04: 0x00000050109FB1C0, GR 05: 0x000000000F10AC78
23:14:44 HHC17721D TXF: CP03: GR 06: 0x000000000F042500, GR 07: 0x000000009FE77CE8
23:14:44 HHC17721D TXF: CP03: GR 08: 0x00000050D1059C0A, GR 09: 0x0000000000000000
23:14:44 HHC17721D TXF: CP03: GR 10: 0x0000000000000001, GR 11: 0x000000007CA1F156
23:14:44 HHC17721D TXF: CP03: GR 12: 0x00000050109FBD48, GR 13: 0x000000000F042500
23:14:44 HHC17721D TXF: CP03: GR 14: 0x000000501A609FA0, GR 15: 0x000000007AF036F0
23:14:44 HHC00801I Processor CP03: Transaction constraint exception code 0218 ilc 6 TXF_WHY_TRAN_FLOAT_INSTR
23:14:44 HHC02324I CP03: PSW=0785340180000000 000000501A608C3C INST=E560D978FE02 TBEGIN 2424(13),-510          transaction_begin
23:14:44 HHC02326I CP03: V:000000000F042E78:K:8E=01000000 00000001 00000000 0000000B  ................
23:14:44 HHC02326I CP03: V:000000007AF044F2:K:06=0AF0 0004E3ED 00F00024 EB8F4AC0 0024 .0..T..0.....{..
23:14:44 HHC02269I CP03: R0=00000000000000F0 R1=000000008002B178
23:14:44 HHC02269I CP03: R2=0000005000000013 R3=000000000000000E
23:14:44 HHC02269I CP03: R4=00000050109FB1C0 R5=000000000F10AC78
23:14:44 HHC02269I CP03: R6=000000000F042500 R7=000000009FE77CE8
23:14:44 HHC02269I CP03: R8=0100000000000000 R9=0000000000000000
23:14:44 HHC02269I CP03: RA=0000000000000001 RB=000000007CA1F156
23:14:44 HHC02269I CP03: RC=00000050109FBD48 RD=000000000F042500
23:14:44 HHC02269I CP03: RE=000000501A609FA0 RF=000000007AF036F0
23:14:44 HHC02271I CP03: C0=00800002DF9CEE20 C1=00000000FCB7C007
23:14:44 HHC02271I CP03: C2=000000001CF9BB40 C3=0000000100C00043
23:14:44 HHC02271I CP03: C4=0000000100000043 C5=000000007EF400C0
23:14:44 HHC02271I CP03: C6=00000000FE000000 C7=00000000FCB7C007
23:14:44 HHC02271I CP03: C8=0000000000000000 C9=0000000000000000
23:14:44 HHC02271I CP03: CA=0000000000000000 CB=0000000000000000
23:14:44 HHC02271I CP03: CC=00000000D7DDBC43 CD=00000000FCB7C007
23:14:44 HHC02271I CP03: CE=00000000DF8FEF38 CF=000000007F44E010
23:14:44 HHC17722D TXF: CP04: abort_transaction called from external.c:110
23:14:44 HHC17722D TXF: CP00: abort_transaction called from external.c:110
23:14:44 HHC17722D TXF: CP00: abort_transaction called from external.c:110
23:14:44 HHC17722D TXF: CP01: abort_transaction called from external.c:110

@azarrafa,

These some instructions that were executed around the error that I copied. [...]

Which does indeed confirm that the keytool java utility does indeed contain a bug wherein it is violating its own unconstrained transaction's constraint: it's executing a floating-point instruction which its TBEGIN said to not allow!

Where did keytool come from? z/OS? Or is it something that came from somewhere else? Who wrote it? Do we have the source? I realize that fixing buggy guest operating system utilities (tools) is not the responsibility of the Hercules support team, but I'm rather curious as to why it (keytool) would be coded that way! It would seem that whoever wrote it either didn't fully understand how transactions work on z/Architecture, or else just made a simple honest mistake (which any developer will tell you happens all the time).

Do you know? (where keytool came from and whether source for it is available?)

I attached the whole log if it helps.

Ummm... No, actually you didn't. But that's okay since it wouldn't really have helped matters anyway. Your above logfile snippet is confirmation enough.

Hello Fish, it's from IBM it's in JAVA SDK 8 64 bit.

I just tested the command on a z server and it works fine. FYI it's the same z/OS system but on a z server. regards,

Hello Fish, it's from IBM it's in JAVA SDK 8 64 bit.

Is the source code available?

I just tested the command on a z server and it works fine. FYI it's the same z/OS system but on a z server. regards,

Interesting! It would seem then that IBM is violating their own published architecture/rules! If the 'F' flag (Allow Floating Point) is not set in operand-2 of the TBEGIN instruction, then executing an STD instruction (Store Floating Point Long) in that unconstrained transaction is supposed to cause a constraint violation! I find it very unusual (and perplexing!) that such a transaction would for some reason succeed on real iron!

UNLESS of course the transaction being executed on real iron is a completely different one than the one generated by keytool on Hercules, which is the only likely scenario that makes any sense. That is to say, the only logical explanation is that Hercules still has a bug somewhere in its TXF support that is causing keytool to generate an invalid transaction.

I know almost nothing about z/OS azarrafa, (and even less about how to debug things there!), but is there a way to identify and trace the instructions in the transaction(s) that are generated by keytool? (i.e. is there a way to see what instructions are being generated for the problematic [series of? sequence of?] transaction(s)?)

We can do that very easily on Hercules (via the txf and t+ commands) to once again confirm what we are seeing on Hercules, but I would very much like to see the same thing on a real mainframe to see what is different. It might provide a clue as to where Hercules's bug is.

Thanks.

Followup (much lower priority) question(s): does JAVA SDK 8 64 bit come pre-installed in z/OS 2.4 (or 2.4s)? Or is it something you have to install yourself manually?

Would you be willing to provide instructions (off list in private email of course! Not here in this GitHub Issue!) to someone like me (a complete z/OS newbie/noob/idiot) for how they could, on their own, recreate your keytool failure? I would very much like to try and reproduce your problem locally on my own system (so that I can properly look into the problem), but I have almost no experience with z/OS, so you would have to explain things in "baby talk" in order for me to understand.

Would you be willing to do that? (off list of course, not here)

Thanks!

Is the source code available?

With IBM. I don't think so.

Followup (much lower priority) question(s): does JAVA SDK 8 64 bit come pre-installed in z/OS 2.4 (or 2.4s)? Or is it something you have to install yourself manually?

You can order it with z/OS or install it manually

Would you be willing to provide instructions (off list in private email of course! Not here in this GitHub Issue!) to someone like me (a complete z/OS newbie/noob/idiot) for how they could, on their own, recreate your keytool failure? I would very much like to try and reproduce your problem locally on my own system (so that I can properly look into the problem), but I have almost no experience with z/OS, so you would have to explain things in "baby talk" in order for me to understand.

Yes of course any time, I would love that. I will send you a private mail to your softdevlabs email.

WTF?!

Something I only just now noticed!

SA22-7832-12 "zArchitecture Principles of Operation", page 5-97:

Restricted Instructions

When the CPU is in the transactional-execution mode, attempted execution of certain instructions is restricted and causes the transaction to be aborted.

When issued in the constrained transactional-execution mode, attempted execution of restricted instructions may also result in a transaction-constraint program interruption, or may result in execution proceeding as if the transaction was not constrained.

What do the rest of you make of THAT?! How should we be handling this situation?

Or perhaps a better question might be, SHOULD we bother to try and handle this situation?

I say no, but I thought I'd mention it anyway since it's so bizarre. It's so unlike IBM to define something so vaguely.

Or is it??? Hmmmm...

I suppose it could be IBM's attempt to purposely define something so vaguely as to make it virtually impossible for anyone other than themselves (such as the Hercules project for example!) to have any hope of implementing it properly? Who knows! One thing is for certain however: it is rather bizarre! (IMHO)

Upon more closely reviewing the TXF section of Chapter 5 of the POPs (which documents the Transactional-Execution Facility in detail), I'm also noticing several other rather "interesting" statements that might require us to make some needed adjustments to our current implementation, such as:

(page 5-98):

When the CPU is in the transactional-execution mode, it is model dependent whether the following instructions are restricted:

* CIPHER MESSAGE * CIPHER MESSAGE WITH AUTHENTICATION * CIPHER MESSAGE WITH CIPHER FEEDBACK * CIPHER MESSAGE WITH CHAINING * CIPHER MESSAGE WITH COUNTER * CIPHER MESSAGE WITH OUTPUT FEEDBACK * COMPRESSION CALL ...(etc)...

Our current implementation (dyncrpt.c) is currently restricting all crypto instructions. Maybe we should be allowing them all instead?

(page 5-98):

Under certain circumstances, the following instructions may be restricted:

* EXTRACT CPU TIME * EXTRACT PSW * STORE CLOCK * STORE CLOCK EXTENDED * STORE CLOCK FAST

What are the freaking circumstances? They don't say! Once again our current implementation is restricting the above listed instructions. Maybe we should be allowing them instead? *`()`**

(page 5-98):

It is model dependent whether the following instructions are restricted:

* PREFETCH DATA (RELATIVE LONG), when the code in the M1 field is either 6 or 7. * STORE CHARACTERS UNDER MASK (STCMH), when the M3 field is zero and the code in the R1 field is either 6 or 7.

(page 5-99):

Programming Notes:

1. Certain restricted instructions may be allowed in the transactional-execution mode on future processors.

Since they don't bother to define what those restricted instructions are, I guess we'll just have to closely monitor the upcoming future releases of the Principles of Operations manual.

Thoughts?

*`()** _The "keytool" command under OMVS for example, appears to execute theSTCKF` (Store Clock Fast) instruction in an unconstrained transaction, which our current implementation is causing to fail. We should probably be restricting it (and the other instructions they mention) only for constrained transactions, but allowing them for unconstrained? <shrug> Something to think about I guess?_

SDL-Hercules-390 / hyperion

Transactional-Execution Facility design / implementation #263

Hercules Emulator Control file...

Description:

MaxShutdownSecs: 15

LoadUnit:

RCFile:

LogoFile:

IgnoreParseErrors: 0

HercGUI Version: 1.12.9.3467

System parameters

MAXCPU 1

ENGINES CP

NUMCPU 1

Display Terminals

DASD Devices

TAPE Devices

CTC Adapters

** WTF?! **

WTF?!