Open jphartmann opened 7 years ago
Enrico has this test failing on 32-bit MAC with the PSW that you load when the condition code is not zero on the initial SIO.
I temporarily experienced the same thing myself during initial testing on my Windows 7 x64 VMware virtual machine, but only for the "S/370 HET tape BSF into Load Point" test; the "S/370 AWS tape BSF into Load Point" test would always run clean.
The cause is simply the Hercules you are using (testing with) was built without ZLIB support, which is the compression method that was used to create the hetbsf.het
file with that the test is using. To resolve the problem you simply need to rebuild Hercules with ZLIB support.
We should probably consider devising some means for tests to be able to determine whether the Hercules being tested was built WITH
or WITHOUT
a given build option (optional feature). Then the HET test previously mentioned could check that condition and react appropriately, perhaps even skipping the test altogether.
I haven't quite figured out how to do that yet, but I believe it's something we should strongly consider implementing. As it stands today we know we have at least one test that is presuming support for a given Hercules optional feature (build option) which may not always exist for all users, which is not good. Got any ideas regarding how to implement such a thing?
You definitely need to retry on CC 1, CSW stored.
I disagree. Under normal circumstances, yes, I would agree. But in this particular case the I/O should always succeed (and if it doesn't (such as in the current case), then simply retrying the I/O won't help resolve the situation at all; it will continue to fail).
Can you run Harold's ASMA? If so, it would make things a lot easier for you.
I know. I'm anxious to get back to playing with it again myself. It's just that too many other things keep jumping ahead of it.
More information:
Here's an excerpt from the Hercules log for the failing HET test:
[...]
HHC01417I Without CCKD BZIP2 support
HHC01417I Without HET BZIP2 support
HHC01417I Without ZLIB support
HHC01417I Without Regular Expressions support
HHC01417I With Object REXX support
HHC01417I Without Regina REXX support
[...]
HHC02336I Script 1: test: test starting
HHC02339I Script 1: test: duration limit: 0.500000 seconds
HHC02228I restart key pressed
HHC02333I Script 1: test: running...
HHC01335I 0:0590 CHAN: synchronous I/O ccw addr 00000400
HHC01315I 0:0590 CHAN: ccw 07000000 60000000
HHC01334I 0:0590 CHAN: asynchronous I/O ccw addr 00000400
HHC01315I 0:0590 CHAN: ccw 07000000 60000000
HHC01312I 0:0590 CHAN: stat 0C00, count 0000
HHC01315I 0:0590 CHAN: ccw 04000500 60000002
HHC01312I 0:0590 CHAN: stat 0C00, count 0000=>0048 ..
HHC01315I 0:0590 CHAN: ccw 02000508 60000004
HHC00204E 0:0590 Tape file ../hercules-extpkg-0/tests/hetbsf.het, type het: error in function het_read(), offset 0x0000000000000001: Het error 'Unknown compression method': 'No error'
HHC00007I Previous message from function 'read_het' at hettape.c(203)
HHC01312I 0:0590 CHAN: stat 0E00, count 0004=>0048D3F1 ..L1
HHC01313I 0:0590 CHAN: sense 084000C0 00C00300 00000000 00800100 010000FF FF000000 00000000 00000000
HHC01314I 0:0590 CHAN: sense DCK ITF
HHC01316I 0:0590 CHAN: csw 00, stat 0E00, count 0004, ccw 000418
HHC00809I Processor CP00: disabled wait state 000A0000 00EEEEEE
HHC02334I Script 1: test: test ended
As you can see, message HHC00204E
identifies the cause: Unknown compression method
.
Rebuilding Hercules with ZLIB support resolves the problem.
Surprised it gives a Data Check... Shouldn't it a an Equipment Check ?
--Ivan
On 11/17/2016 5:38 PM, Fish-Git wrote:
More information:
Here;s an excerpt from the Hercules log for the failing HET test:
|[...] HHC01417I Without CCKD BZIP2 support HHC01417I Without HET BZIP2 support HHC01417I Without ZLIB support HHC01417I Without Regular Expressions support HHC01417I With Object REXX support HHC01417I Without Regina REXX support [...] HHC02336I Script 1: test: test starting HHC02339I Script 1: test: duration limit: 0.500000 seconds HHC02228I restart key pressed HHC02333I Script 1: test: running... HHC01335I 0:0590 CHAN: synchronous I/O ccw addr 00000400 HHC01315I 0:0590 CHAN: ccw 07000000 60000000 HHC01334I 0:0590 CHAN: asynchronous I/O ccw addr 00000400 HHC01315I 0:0590 CHAN: ccw 07000000 60000000 HHC01312I 0:0590 CHAN: stat 0C00, count 0000 HHC01315I 0:0590 CHAN: ccw 04000500 60000002 HHC01312I 0:0590 CHAN: stat 0C00, count 0000=>0048 .. HHC01315I 0:0590 CHAN: ccw 02000508 60000004 HHC00204E 0:0590 Tape file ../hercules-extpkg-0/tests/hetbsf.het, type het: error in function het_read(), offset 0x0000000000000001: Het error 'Unknown compression method': 'No error' HHC00007I Previous message from function 'read_het' at hettape.c(203) HHC01312I 0:0590 CHAN: stat 0E00, count 0004=>0048D3F1 ..L1 HHC01313I 0:0590 CHAN: sense 084000C0 00C00300 00000000 00800100 010000FF FF000000 00000000 00000000 HHC01314I 0:0590 CHAN: sense DCK ITF HHC01316I 0:0590 CHAN: csw 00, stat 0E00, count 0004, ccw 000418 HHC00809I Processor CP00: disabled wait state 000A0000 00EEEEEE HHC02334I Script 1: test: test ended |
As you can see, message |HHC00204E| identifies the cause: |Unknown compression method'|.
Rebuilding Hercules with ZLIB support resolves the problem.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/hercules-390/hyperion/issues/166#issuecomment-261297867, or mute the thread https://github.com/notifications/unsubscribe-auth/ABjMW_BMcv23hZXDDAYFCYoGyZ-Dr42rks5q_ILzgaJpZM4KukU1.
Surprised it gives a Data Check... Shouldn't it a an Equipment Check ?
A Data Check seems reasonable to me in this situation. An Equipment Check implies something is wrong with the equipment (tape drive) which is not the case here. Rather, the data on the tape simply couldn't be read. Thus Data Check. <shrug>
Of course then too there's the argument that since it is the tape drive(?) (controller?) that is responsible(?) for decompressing whatever compressed data may happen to be recorded on the media, that failure to do so would indeed be classified as a failure on the part of that particular piece of equipment. Thus an Equipment Check would be more appropriate.
As for me, I admit I'm not that knowledgeable about (experienced with) such things so I can't really say other than what I've already said: to me, a Data Check seems reasonable and proper in this case.
But I readily admit I could be very wrong about that and stand to be corrected by someone more knowledgeable/experienced (skilled) in such issues.
Enrico has this test failing on 32-bit MAC with the PSW that you load when the condition code is not zero on the initial SIO.
Perhaps the test for device present is a bit too hamfisted:
You definitely need to retry on CC 1, CSW stored. Looping on channel busy is a bit more problematical since you might loop forever.
I forget whether 370 I/O does clear device, but perhaps some kind of reset might be possible.
At least for problem determination it would be very nice if you could load a different wait state for the three cases.
Can you run Harold's ASMA? If so, it would make things a lot easier for you. You can still modify the PSWs in the .tst file.