-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
z/VM 7.2 doesn't work with compressed DASDs #464
Comments
Is your z/VM 7.2 ADCD? Or not? |
Never mind! CONFIRMED! I was able to recreate your problem! It works just fine with UN-compressed dasd (e.g. CKD64), but fails with compressed (e.g. CCKD64) dasd! Very weird! (and very concerning too!!) I will begin looking into this right away, as it clearly indicates a problem in CCKD and/or CCKD64 logic! (Yikes!) |
Well... I wasn't able to recreate your exact problem (I did not experience your z/VM errors, i.e. the In my case, the failure that occurs when compressed dasds are using is a very tight hard CPU loop (checking some bit somewhere) immediately after the "brought online" startup message. When regular (uncompressed) CKD64 dasds are used, no loop occurs and the system comes up just fine. Maybe it's because mine is an ADCD distro? Is yours an ADCD distro too? I'm guessing it's not, and that's probably why our respective failures are different. But that's just a guess. In any case, I'm going to be digging into this problem right away! Top priority! |
Hi Fish, Excuse me for my late reply. I confirm: my z/VM7.2 is an ADCD distribution. The different behaviour you're experiencing is easily explained: If I COLD Start VM, I get all the weird I/O errors on VM console. If I WARM Start VM, I go in a tight loop. Usually ADCD systems have WARM start as a default in System Config file, so you get a tight loop without having any chance to modify. I'm glad you're looking into the problem, since it is very important for me to be able to use compressed DASD. Thank you again! (and BTW: Happy New Year too!) Paul |
Okay, that makes sense. Thanks!
It's important for me too! (And a lot of other Hercules users as well!) And guess what? I FOUND THE BUG! It's late though, so I'll probably commit the fix sometime tomorrow. |
Great! I knew you're one of the smartest guys I ever met - and I met quite a few, having worked in IBM Italy as a System Engineer for about 20 years. But anyhow your performance astonished me. Take it easy.. I know there are 9 hours of difference in time zone between Seattle and Milan (Italy). Just a kind request, if possible. About 10 years ago I was able to perform some mods to Hercules; I remember that I was the first to run z/VM 6.3 in Hercules 3.08 after modifying the code to support topology instructions. (and Roger Bowler was so kind to mention me as a contributor). But now I'm not willing to deal with all the procedure to rebuild Hercules (Git clone and so on); so, please, please, if you can share with me the new (corrected) prebuilt version of Hercules for Windows, I'll be very grateful to you. Regards Paul |
Normally I hate handing out private builds to people, but this might be an exception. I'll see what I can do. But in all honesty, this bug is IMHO serious enough to warrant a 4.4.1 "fix" release. That is to say, even though 4.4.0 was only officially released just 2.5 weeks ago, due to the seriousness of this particular bug, we might need to make a new official release of Hercules: version 4.4.1. But I need to discuss it with my fellow developers first. (How urgent is this fix to you? How long can you comfortably wait for it?) |
Okay, here's the bug and, further below, the patch that fixes it (which I have already committed): In module For some unknown reason, between those two points in the logic flow, the Lines 4861 to 4925 in bf377f6
I managed to eventually track down the problem to a single "rogue" (erroneous/accidental/unintentional) statement in the
(Yep! This bug has been in Hercules for almost 20 years now!) Anyway, the fix was to remove the rogue (erroneous/accidental/unintentional) statement that was resetting Line 864 in bf377f6
and associated functions (the bug existed not only in our CCKD logic but also in our CFBA logic too, and was carried forward into our CCKD64/CFBA64 logic as well). As soon as that is done, everything started working just fine, and z/VM 7.2 came right up, clean as a whistle! Here's the patch which very clearly shows the actual bug and how it was fixed (which, as I said, has already been committed): From: "User Name" <user@example.com>
Date: Tue, 04 Jan 2022 09:54:07 -0800
Subject: [PATCH] Short description
Details of change, perhaps spanning...
...multiple...
...lines.
diff -r -a -x .git -x 'msvc.AMD64.*' -x 'msvc.dllmod.*' -x 'msvc.debug.*' -x '*.suo' -x '*.ncb' -x '*.user' -x '*.htm' -x WORK -x DICTS -x FILES -x 'allTests.*' -x '*.rej' -x '*.orig' -x AutoBuildCount.h -x '*.cmp*' -x '*.comp*' -Nu hyperion-1/cckddasd.c hyperion-0/cckddasd.c
--- hyperion-1/cckddasd.c 2021-03-06 11:03:35.570094100 -0800
+++ hyperion-0/cckddasd.c 2022-01-04 01:12:25.048317400 -0800
@@ -861,7 +861,6 @@
/* read the new track */
dev->bufupd = 0;
- *unitstat = 0;
cache = cckd_read_trk (dev, trk, 0, unitstat);
if (cache < 0)
{
@@ -1046,7 +1045,6 @@
/* Read the new blkgrp */
dev->bufupd = 0;
- *unitstat = 0;
cache = cckd_read_trk (dev, blkgrp, 0, unitstat);
if (cache < 0)
{
diff -r -a -x .git -x 'msvc.AMD64.*' -x 'msvc.dllmod.*' -x 'msvc.debug.*' -x '*.suo' -x '*.ncb' -x '*.user' -x '*.htm' -x WORK -x DICTS -x FILES -x 'allTests.*' -x '*.rej' -x '*.orig' -x AutoBuildCount.h -x '*.cmp*' -x '*.comp*' -Nu hyperion-1/cckddasd64.c hyperion-0/cckddasd64.c
--- hyperion-1/cckddasd64.c 2021-03-02 23:17:47.835962300 -0800
+++ hyperion-0/cckddasd64.c 2022-01-04 01:08:57.708353200 -0800
@@ -621,7 +621,6 @@
/* read the new track */
dev->bufupd = 0;
- *unitstat = 0;
cache = cckd64_read_trk (dev, trk, 0, unitstat);
if (cache < 0)
{
@@ -806,7 +805,6 @@
/* Read the new blkgrp */
dev->bufupd = 0;
- *unitstat = 0;
cache = cckd64_read_trk (dev, blkgrp, 0, unitstat);
if (cache < 0)
{ Here's the same thing as a downloadable patch file: Fixed by commit 120c28b. Closing this issue as resolved. Please let me know if I've missed something and it still doesn't work for you, and I'll gladly reopen it. Thanks. |
Hi Fish, With great efforts I could build the Hyperion corrected version, and... It works like a charm! BTW, I didn't deal with Git, clone and all that crap; I simply downloaded the version 4.4 source and modified by hand the four 'guilty' instructions. Then a makefile and voilà: a perfectly working version. Thanks for all. Now I'm waiting for the future (but not yet scheduled) z/OS 2.5 ADCD.... Paul |
Great! Glad to hear it. Well done! FYI: after virtually zero debate, we have all agreed there will be a new 4.4.1 hot fix release. It should hopefully be ready "very soon" (within days I'm guessing).
Aye. Me too. |
Hi all,
This my environment: Windows 10, Hercules 4.4 pre-built for Windows: Hercules version 4.4.0.10631-SDL-gbf377f63 (4.4.0.10631).
With my great satisfaction I could run z/VM 7.2 under Hercules
(*)
, but ONLY with non-compressed DASDs. If I use compressed DASDs for Page and Spool (I tried both CCKD and CCKD64 formats), I get some nasty errors:(NOTE: These errors appeared only on VM 3270 console. In hercules log, no errors at all.)
Also, z/VM 7.1 with compressed DASDs gave the same kind of errors, but I could 'cure' them with the
PAGING63
IPL option.If I IPL a z/VM 6.3 nucleus with the same DASDs, everything works OK.
I'm aware that starting from z/VM 7.1 there were some modifications in Page and Spool access. It looks to me as though the Hercules compressed DASD logic in some way doesn't support this new kind of access.
(*)
In order to IPL z/VM 7.2, I had to enable the FACILITY bit 55.Regards.
Paul
The text was updated successfully, but these errors were encountered: