search

hercules-390 / hyperion

Hercules 390
Other
248 stars 67 forks source link

VTAM IST446I I/O ERROR on VSE/ESA #161

Open magnum41br opened 7 years ago

magnum41br commented 7 years ago

I am running Hercules version 4.0.0.8650-gb130229 (4.0.0.8650) under Windows 10 pro. My guest system is VM/ESA 2.4 with VSE/ESA 2.4. VSE is running under VM. After having VTAM and CICS up, I opened a new TN3270 session using VM "201" local term. Next I dialed Vse (DIAL VSE) and get the Vtam menu screen on VSE terminal "200". As I select option "A" (Cics) nothing happens in this screen, but got the following Vtam error message in the VSE console:

F3 0003 IST446I I/O ERROR 200, OTHER HARDWARE ERROR, 06,0C00,00.

To temporarely fix that I went back to Hercules V.3.12, where every thing is running fine, with no errors.

I am attaching my Hercules Configuration File and a Hercules Log File containing a Trace (t+201) issued just before DIAL VSE.

Thanks. -Nelson Forni

Hercules Logfile.001.txt VMESAIB.conf.txt

Editor's note:

For those trying to follow this issue, the problem was originally reported in the Hercules H390-DOSVS group, where a few back and forth exchanges between myself and Nelson first occurred. It was in the H390-DOSVS group that it was discovered he was using a very old (2 years!) version of Hyperion. It was only when the problem remained after trying again using a more current version of Hyperion that this GitHub issue was then created:

jphartmann commented 7 years ago

In message 446, are the numbers CCW opcode 06 (read modified), CSW status (Channel end and device end), and sense byte (no error detected)?

Please pull the latest Hyperion. In the latest commit, Fish has fixed one of the bugs he introduced somewhere along the line.

If you have TCP/IP on VM, you could also try to point your TN3270 client at VM's port 23 and see if that works.

If you still have trouble we need to know which TN3270 client you are using.

magnum41br commented 7 years ago

Yes, message 446 always shows this way.

I just picked up the latest Hercules version to produce my GitHub isse.

Sorry, I don't have Vtam in VM.

My TN3270 is Cryptoterm V 2.0. But I also tryed ws3270, Pcomm3270 and a TN3270E emulator (Ability), and the problem still remains using Hercules 4.0.

With Hercules 3.12 I don't have any problems, no matter what TN3270 I am using.

Thanks. -Nelson

jphartmann commented 7 years ago

I built the latest Hyperion before I wrote my missive above. It announces:

Hercules version 4.0.0.8652-g2f77b99 (4.0.0.8652)

So it looks like you are missing a commit or two.

magnum41br commented 7 years ago

Please, let me clarify. I received an email from Fish about 3 hours ago asking to redo the test using the Hercules version contained in this address: http://www.softdevlabs.com/hyperion#prebuilt

Is this out of date? If so, please let me know where to find the latest version. Thanks. -Nelson

jphartmann commented 7 years ago

If you are speaking with Fish, do as he asks. I'll get out of the loop.

Fish-Git commented 7 years ago

I built the latest Hyperion before I wrote my missive above. It announces: Hercules version 4.0.0.8652-g2f77b99 (4.0.0.8652) So it looks like you are missing a commit or two.

Of the two commits he is missing, one was purely cosmetic (comment tweak) and the other was a tweak to address the Linux __builtin_unreachable issue which does not apply to him since he's using Windows, so the version he's using is fine. It's the most current/recent prebuilt Windows version there is.

I'm looking at the CCW trace now and am seeing some things I find to be unusual that may well be related to the problem. I will get back to you after I do some more research.

Thank you for your cooperation thus far, Nelson. I really appreciate it. I promise you we will get to the bottom of whatever is going on and get it fixed for you.

p.s. to @dasdman : I may need your help with this one! Please take a look at sequence 10:44:31.935 to 10:45:41.250, especially the following:

10:44:31.937 00001338 HHC01315I 0:0201 CHAN: ccw 06800120 1D9D9D7F
10:44:31.937 00001338 HHC01312I 0:0201 CHAN: stat 0C00, count 0120=>7DD6E811 D6E78140 40404040 40404040 'OY.OXa
10:44:31.937 00001338 HHC01315I 0:0201 CHAN: ccw 06107FFF 00001000
10:44:31.938 00001338 HHC01312I 0:0201 CHAN: stat 0C00, count 7FFF
10:44:31.938 00001338 HHC01317I 0:0201 CHAN: scsw 00C04007, stat 0C00, count 7FFF, ccw 1FCF8F48

I can't be sure but to me that almost looks like the CCW format is changing from Format-1 to Format-0 midstream! (i.e. 107FFF looks like a buffer address and 1000 looks like an I/O amount!!)

Which, if true, would certainly explain the behavior from the user's point of view (the 10 being interpreted as a 'Skip' CCW flag resulting in the 7FFF residual).

Thanks.

Fish-Git commented 7 years ago

@magnum41br : can you share your VM DIRECT directory entry statements with us for your VSE/ESA guest? What VM options do you have defined for it, etc?

@ivan-w, @jphartmann, @g4ugm : I seem to recall there being some restrictions regarding running e.g. VSE guests under VM with respect to CCW translation, but can't remember what those restrictions/suggestions might be. Can any of you recall what they were? What manual are they in?

Fish-Git commented 7 years ago

@magnum41br : have you tried DEDICATING one or more of your display devices to your VSE/ESA guest so that DIAL is not needed? And then specifying that device address in your tn3270 client? (e.g. "IBM-3278-2-E@0201") Does that work any better?

magnum41br commented 7 years ago

Please see attached the two VM directory entries that I have used. When this problem started I was using the "Old Entry", and tried to change to the "Current Entry" to see if I could fix the problem. I am currently using "Current Entry". Thanks. -Nelson

Current.Vse.Dir.Entry.txt Old.Vse.Dir.Entry.txt

magnum41br commented 7 years ago

OK. just ran the new test and there was no problem. The Vtam menu screen came up with no errors. Here is the sequence: 1- Changed the VM Directory Entry, dedicating real 201 to virtual 200 of VSE. 2- Disabled graf 201 (DISA 201), 3- Logged VSE in real graf 200 (real 201 remains dedicated to VSE), 4- Issued "t+201" in the Hercules Console, 5- Opened a new TN3270 session, which assumed real graf 201, and the Vtam menu screen came up! (no need to change the TN3270 client address) 6 - Selected option "A" (DBDCCICS)

Also, there is no Vtam problem when I start VSE in native mode (without VM).

Please see attached current Hercules Config file, VM Directory entry and last Hercules Log file.

Please let me know what else I could do. I will be more than happy to help. -Nelson

Current.Vse.Dir.Entry.txt Hercules Logfile.001.txt VMESAIB.conf.txt

jphartmann commented 7 years ago

I'd suggest doing the steps above, but omitting #4, the trace. It could well be that the trace has slowed the device enough for the problem to go away.

If it is still good, then there is something in CP's handling of a dialled console that upsets the TN3270 server.

If it hangs, please use the netstat command to see what state the session is in.

magnum41br commented 7 years ago

The test above has been rebuilt, without step 4. It ran with no problem. I was able to reach the DBDCCICS screen. Please see Hercules log file attached. Thanks. -Nelson Hercules Logfile.001.txt

Fish-Git commented 7 years ago

@jphartmann :

If it is still good, then there is something in CP's handling of a dialled console that upsets the TN3270 server.

Huh? What tn3270 server? Surely you cannot be referring to Hyperion's tn3270 server!

@magnum41br :

OK. just ran the new test and there was no problem. The Vtam menu screen came up with no errors [...] 1- Changed the VM Directory Entry, dedicating real 201 to virtual 200 of VSE. [...] 5- Opened a new TN3270 session, which assumed real graf 201, and the Vtam menu screen came up! (no need to change the TN3270 client address) [...] Please see attached current Hercules Config file, VM Directory entry and last Hercules Log file.

Nelson, unfortunately your test is invalid. I wanted you to perform the test using Hyperion 4.0. According to your attached log file you did your test using Hercules 3.12 (which we already know works fine).

Please let me know what else I could do. I will be more than happy to help.

In summary, the two tests I would like you to do are:

The first test above is the correction to the test you've already done, but you did it using the wrong Hercules.

The second test above is a new test I would like you to do. I want to compare the original Hyperion ccw trace you did earlier with this new Hercules 3.12's ccw trace.

And please sure to set HercGUI's preferred executables directory to the correct Hercules before starting each test this time!  ;-)

Thanks!

magnum41br commented 7 years ago

Damm! My fault again! I am attaching the two log files. Test#1 - Failed ( Hyperion 4.0 +Dedicate 201 + with trace) Test#2 - Success (Hercules 3.12 + Special 201 + with trace) Thanks. -Nelson

Hercules 3.12 - Special - with trace - Logfile.txt Hyperion 4.0 - Dedicate - with trace - Logfile.txt

jphartmann commented 7 years ago

Yes, I am referring to console.c. As you ought to remember it is also giving me grief.

Fish-Git commented 7 years ago

Yes, I am referring to console.c. As you ought to remember it is also giving me grief.

((sigh))   John, John, John...   :-(

It cannot possibly be Hyperion's telnet server.

In case you forgot his problem occurs with a TWO YEAR OLD VERSION OF HYPERION (2014).

Hyperion's new libtelnet code was only added to Hyperion in APRIL OF THIS YEAR (2016).

The problem that Nelson is experiencing has ABSOLUTELY NOTHING TO DO WITH HYPERION'S TELNET CODE.

The most likely suspect is the many architectural compliance changes made to Hyperion over the past several year, such as the changes Mark made to the way STIDP is handled depending on what your LPARNUM value is set to.

Or it could be Hyperion's new channel subsystem enhancements to more closely match the architecture. The old channel code (that Hercules 3.12 is still using) doesn't conform to the architecture as closely as Hyperion's does. It's fast and loose. Hyperion's however is in much closer compliance thanks to the hard work done by Mark.

Stop blaming libtelnet.

John:

Please see my apology further below! I forgot that you probably weren't aware of the 2-year old test that Nelson did earlier, so your suspicion that it might be libtelnet was actually quite justified from your point of view! My apologies for snapping at you.

magnum41br commented 7 years ago

Gentlemen, I can easylly live with this problem. Please do not change your priorities because of it, or let it disturb your work. I can always goback to 3.12. Even using Hyperion 4.0 the problem does not exist when I user VSE in native mode (without VM). I would like to continue helping with the tests anyway. Please count on me. -Nelson.

Fish-Git commented 7 years ago

Test#1 - Failed ( Hyperion 4.0 +Dedicate 201 + with trace) Test#2 - Success (Hercules 3.12 + Special 201 + with trace)

Thank you, Nelson!   That helps a lot.

Comparing the 3.12 "Special 201" log with the current 4.0 "Special 201" log I can see right away there appears to be a bug in Hyperion's channel logic.

Hercules 3.12 is presenting SCSW status 0C40 (Incorrect Length) upon pressing enter after the dial (which breaks the CCW chain, forcing VM/ESA to build a new channel program), whereas Hyperion isn't. Hyperion's intermediate status is 0C00 (normal) causing it to go on to the next CCW in the chain, leading to the problem (most likely that Format-0 CCW that I mentioned earlier).

So it very much looks like either:

If I had to guess I would say it's the former: the bug is in Hyperion's code, not 3.12's (based purely on a very quick comparison of the two logs and the fact that it works fine with 3.12 but not with 4.0).

At least that's my preliminary conclusion anyway. I will of course have to contact @dasdman for help on this one to either confirm or deny my suspicion and for help with locating and fixing the bug if it ends up I'm right.

In the mean time I'm going to try coding a simple test case that can hopefully reproduce what I suspect is the problem: missing incorrect length interrupt. I've been wanting to get back up to speed with the latest version of Harold's excellent SATK (Stand-alone Tool Kit) anyway, and this is as good a reason as any for doing so!

Fish-Git commented 7 years ago

@dasdman (and any others interested in helping us figure out what's going on):

Here are the log file sequences that seem to just jump out at me. (The actual log files themselves are attached below)

I've renamed the log files from the original names Nelson gave them only so I could more easily keep things straight. (It's important to compare the right two log files with one another. We don't want to be wasting time/effort by comparing apples to oranges.)

Hyperion 4.0 (SPECIAL):

10:44:31.932 00001338 HHC01305I 0:0201 CHAN: attention
10:44:31.934 00001338 HHC01317I 0:0201 CHAN: scsw 00C00011, stat 8000, count 0000, ccw 00000000
10:44:31.934 00001338 HHC01318I 0:0201 CHAN: test I/O: cc=0
**********************************************************************************************************
10:44:31.935 00001338 HHC01315I 0:0201 CHAN: ccw 0B600001 1F741000
10:44:31.936 00001338 HHC01312I 0:0201 CHAN: stat 0C00, count 0001
10:44:31.936 00001338 HHC01315I 0:0201 CHAN: ccw 08000000 1FCF8018
----------------------------------------------------------------------------------------------------------
10:44:31.936 00001338 HHC01315I 0:0201 CHAN: ccw 06800103 1D9D9C24
10:44:31.936 00001338 HHC01312I 0:0201 CHAN: stat 0C00, count 00B4=>7DD6E811 D6E78140 40404040 40404040 'OY.OXa
----------------------------------------------------------------------------------------------------------
10:44:31.937 00001338 HHC01315I 0:0201 CHAN: ccw 08000000 1FCF8F38
10:44:31.937 00001338 HHC01315I 0:0201 CHAN: ccw 06800120 1D9D9D7F
10:44:31.937 00001338 HHC01312I 0:0201 CHAN: stat 0C00, count 0120=>7DD6E811 D6E78140 40404040 40404040 'OY.OXa
----------------------------------------------------------------------------------------------------------
10:44:31.937 00001338 HHC01315I 0:0201 CHAN: ccw 06107FFF 00001000
10:44:31.938 00001338 HHC01312I 0:0201 CHAN: stat 0C00, count 7FFF
10:44:31.938 00001338 HHC01317I 0:0201 CHAN: scsw 00C04007, stat 0C00, count 7FFF, ccw 1FCF8F48
10:44:31.938 00001338 HHC01318I 0:0201 CHAN: test I/O: cc=0
**********************************************************************************************************

Spinhawk 3.12 (SPECIAL):

13:46:37.664 0000084C HHCCP066I DEV0201: attention
13:46:37.665 0000084C HHCCP050I 0201:SCSW=00000011 Stat=8000 Count=0000  CCW=00000000
**********************************************************************************************************
13:46:37.666 0000084C HHCCP048I 0201:CCW=0B600001 1F74E000=>000A0000 00000000 00000000 00000000 ................
13:46:37.667 0000084C HHCCP075I 0201:Stat=0C00 Count=0001
13:46:37.667 0000084C HHCCP048I 0201:CCW=08000000 1FCF9C78=>06800103 1D9AFC24 08000000 1FCF90C8 ...............H
----------------------------------------------------------------------------------------------------------
13:46:37.667 0000084C HHCCP048I 0201:CCW=06800103 1D9AFC24=>FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ................
13:46:37.667 0000084C HHCCP075I 0201:Stat=0C40 Count=00B4 =>7DD6E811 D6E7C140 40404040 40404040 'OY.OXA
----------------------------------------------------------------------------------------------------------
13:46:37.667 0000084C HHCCP050I 0201:SCSW=00C04017 Stat=0C40 Count=00B4  CCW=1FCF9C80
**********************************************************************************************************

Hyperion 4.0 (DEDICATE):

13:35:20.032 00000C08 HHC01305I 0:0201 CHAN: attention
13:35:20.033 00000C08 HHC01317I 0:0201 CHAN: scsw 00C00011, stat 8000, count 0000, ccw 00000000
13:35:20.033 00000C08 HHC01318I 0:0201 CHAN: test I/O: cc=0
**********************************************************************************************************
13:35:20.036 00000C08 HHC01315I 0:0201 CHAN: ccw 0B600001 1F9CF000
13:35:20.036 00000C08 HHC01312I 0:0201 CHAN: stat 0C00, count 0001
13:35:20.036 00000C08 HHC01315I 0:0201 CHAN: ccw 08000000 1BFAAE88
----------------------------------------------------------------------------------------------------------
13:35:20.036 00000C08 HHC01315I 0:0201 CHAN: ccw 06800103 1D73FC24
13:35:20.037 00000C08 HHC01312I 0:0201 CHAN: stat 0C00, count 00B4=>7DD6E811 D6E7C140 40404040 40404040 'OY.OXA
----------------------------------------------------------------------------------------------------------
13:35:20.037 00000C08 HHC01315I 0:0201 CHAN: ccw 08000000 1BFAADD8
13:35:20.037 00000C08 HHC01315I 0:0201 CHAN: ccw 06800120 1D73FD7F
13:35:20.037 00000C08 HHC01312I 0:0201 CHAN: stat 0C00, count 0120=>7DD6E811 D6E7C140 40404040 40404040 'OY.OXA
----------------------------------------------------------------------------------------------------------
13:35:20.037 00000C08 HHC01315I 0:0201 CHAN: ccw 06107FFF 00001000
13:35:20.038 00000C08 HHC01312I 0:0201 CHAN: stat 0C00, count 7FFF
----------------------------------------------------------------------------------------------------------
13:35:20.038 00000C08 HHC01317I 0:0201 CHAN: scsw 00C04007, stat 0C00, count 7FFF, ccw 1BFAADE8
13:35:20.038 00000C08 HHC01318I 0:0201 CHAN: test I/O: cc=0
**********************************************************************************************************

Spinhawk 3.12 (DEDICATE):

08:44:46.025 00001804 HHCCP066I DEV0201: attention
08:44:46.025 00001804 HHCCP050I 0201:SCSW=00000011 Stat=8000 Count=0000  CCW=00000000
**********************************************************************************************************
08:44:46.029 00001804 HHCCP048I 0201:CCW=0B600001 1F744000=>000A0000 00000000 00000000 00000000 ................
08:44:46.030 00001804 HHCCP075I 0201:Stat=0C00 Count=0001
08:44:46.030 00001804 HHCCP048I 0201:CCW=08000000 1FDA5018=>06800103 1D9C9D9C 08000000 1FDA5178 ................
----------------------------------------------------------------------------------------------------------
08:44:46.030 00001804 HHCCP048I 0201:CCW=06800103 1D9C9D9C=>00000010 C11DF0E5 E3D4E4E2 E2E3C211 ....A.0VTMUSSTB.
08:44:46.030 00001804 HHCCP075I 0201:Stat=0C40 Count=00B4 =>7DD6E811 D6E7C140 40404040 40404040 'OY.OXA
----------------------------------------------------------------------------------------------------------
08:44:46.030 00001804 HHCCP050I 0201:SCSW=00C04017 Stat=0C40 Count=00B4  CCW=1FDA5020
**********************************************************************************************************

 

Now as I said, I may be zeroing in on the wrong thing. What I'm seeing (what I've excerpted above) may not be a/the problem. I don't know. But to me it just doesn't look right! (And it's the first difference in behavior between the two different versions of Hercules that I could find.)

With that said, please notice in each of the above sequences how the 06800103 CCW is treated: Hercules 3.12 throws an Incorrect Length error whereas Hyperion 4.0 does not.

Why?

Who's right and who's wrong?

I'm presuming Hyperion is wrong since it fails there whereas on spinhawk it doesn't, but I'm not 100% certain of even that. My gut instinct tells me Hyperion is wrong, but I couldn't find any public documents that describes how CCW option flags (SLI, CD, CC, etc) should be handled with respect to TIC (Transfer In Channel) CCWs.

Notice that the questionable 06800103 CCW is always reached via a preceding TIC that branches from a starting CCW that specifies both CC and SLI. It appears Hyperion is continuing to honor the original SLI when I'm thinking it probably shouldn't.

I could find no documentation anywhere that clearly states how CCW flags should be handled with respect to channel programs that branch via TIC from one CCW to another, but given that SLI is a CCW flag, the name alone implies that it should pertain only to the CCW it was specified on and not be "carried forward" to the next CCW in the chain. That's why I suspect it's a bug in channel.c.

Are there such things as "sticky" CCW flags that remain in effect from one CCW to the next?

Anyway, the full log files (with my file names and breakout edits) are attached below.

Hercules 3.12 Dedicate with trace Logfile.txt Hercules 3.12 Special with trace Logfile.txt Hyperion 4.0 Dedicate with trace Logfile.txt Hyperion 4.0 Special with trace Logfile.txt VM-ESA.conf.txt VM-VSE-DIRECT-DEDICATE.txt VM-VSE-DIRECT-SPECIAL.txt

Any help you or anyone else could provide on this issue would be greatly appreciated.

Thanks.

Fish-Git commented 7 years ago

@jphartmann:

In case you forgot his problem occurs with a TWO YEAR OLD VERSION OF HYPERION (2014) [...] Stop blaming libtelnet.

My sincerest apologies to you John!

I had forgotten that you probably weren't involved in the original email exchange for this issue that took place in the H390-DOSVS group before this issue was created.

Thus my reaction to you accusing my telnet change was uncalled for. You weren't aware at the time that the problem also occurred the same way with the much older version of Hyperion. Thus from your point of view it very much did look like it was probably telnet's fault!

The same misunderstanding occurred with @dasdman when he made the same accusation in an offline email to me.

I hereby publicly apologize to both of you!

To ensure no possibility of future misunderstandings or confusion, I have added an "Editors Note" to the beginning of this issue to provide others with a bit of background, making them aware of the same-problem-occurs-with-a-2-year-old-version-of-Hyperion issue.

Thanks

(and again, my apologies!)

magnum41br commented 7 years ago

Yes, message 446 always shows this way.

I just picked up the latest Hercules version to produce my GitHub isse.

Sorry, I don't have Vtam in VM.

My TN3270 is Cryptoterm V 2.0. But I also tryed ws3270, Pcomm3270 and a TN3270E emulator (Ability), and the problem still remains using Hercules 4.0.

With Hercules 3.12 I don't have any problems, no matter what TN3270 I am using.

Thanks. -Nelson

On Fri, Oct 21, 2016 at 11:37 AM, John P. Hartmann <notifications@github.com

wrote:

In message 446, are the numbers CCW opcode 06 (read modified), CSW status (Channel end and device end), and sense byte (no error detected)?

Please pull the latest Hyperion. In the latest commit, Fish has fixed one of the bugs he introduced somewhere along the line.

If you have TCP/IP on VM, you could also try to point your TN3270 client at VM's port 23 and see if that works.

If you still have trouble we need to know which TN3270 client you are using.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/hercules-390/hyperion/issues/161#issuecomment-255378871, or mute the thread https://github.com/notifications/unsubscribe-auth/AV6p7sAWvt5sIUG2-JZT4e2DixyoRPOLks5q2MA3gaJpZM4KdMbh .

Fish-Git commented 7 years ago

@magnum41br :

While working on a completely different unrelated problem for someone else I believe I may have found the cause to your (this) problem too.

But before I get your hopes up, I'd like to prove it, if possible.

Are you capable of building Hercules for yourself? Do you have Visual Studio installed? If so, then I can send you a patch that introduces a new tracing command that I'd like you to use (enable) before trying your test again.

Otherwise, do I need to send you my pre-built test version instead? Send me your email address and I'll send it to you.

It will not fix your problem, but it should provide me with enough information to determine whether or not the problem is what I suspect it is.

Thanks!

my email address is fish at softdevlabs.com

magnum41br commented 7 years ago

Hello Fish, I do not have Visual Studio installed. So here is my email: nelson.forni@gmail.com

Thanks. -\nelson

On Sun, Jul 23, 2017 at 1:02 PM, Fish-Git notifications@github.com wrote:

@magnum41br https://github.com/magnum41br :

While working on a completely different unrelated problem for someone else I believe I may have found the cause to your (this) problem too.

But before I get your hopes up, I'd like to prove it, if possible.

Are you capable of building Hercules for yourself? Do you have Visual Studio installed? If so, then I can send you a patch that introduces a new tracing command that I'd like you to use (enable) before trying your test again.

Otherwise, do I need to send you my pre-built test version instead? Send me your email address and I'll send it to you.

It will not fix your problem, but it should provide me with enough information to determine whether or not the problem is what I suspect it is.

Thanks!

my email address is fish at softdevlabs.com

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hercules-390/hyperion/issues/161#issuecomment-317263345, or mute the thread https://github.com/notifications/unsubscribe-auth/AV6p7rTzXSjq1XWRalEYdaX0eOxLMTqQks5sQ26igaJpZM4KdMbh .

Fish-Git commented 7 years ago

This is now fixed in SoftDevLabs Fish-Git/Hyperion by commit f7bee13f10d645d8ec24ab64bd4b30a8b35ec289.

I will be creating a new downloadable pre-built Windows snapshot "soon" (probably within the next month or so, possibly sooner), so if you need the fix right away you'll have to download (clone) the repository and build Hercules for yourself.

Thanks.

magnum41br commented 7 years ago

I will wait for the snapshot. Many Thanks!