开云体育

On Tue, Jan 21, 2025 at 4:19?AM Andrew via groups.io
<AndrewRandham@...> wrote:

I've amended CCKDDU64 to cater for 3390's larger than model 27's. It's not pretty, but it seems to do the job.
I've dumped a model-54 that has datasets allocated at cylinders higher than 32760, checked it with cckdcdsk64, attached it to Hercules and all appears good.
I've also dumped a Model-9 with the updated and the previous CCKDDU64. A binary comparison comes up clean, except for cdh_vrm in the ckd device header - the version of CCKDDU64 was updated to 0.3.2.
Where can I place the updated source? Also, would anyone need a load module?

Andrew

--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

Andrew wrote:

I've amended CCKDDU64 to cater for 3390's larger than model
27's. It's not pretty, but it seems to do the job. I've dumped
a model-54 that has datasets allocated at cylinders higher
than 32760, checked it with cckdcdsk64, attached it to Hercules
and all appears good.

FAN-F**KING-TASTIC!! :)))

THANK YOU, Andrew!

I can't begin to thank you enough for your effort! You are a true Herculean in my book! :)

I've also dumped a Model-9 with the updated and the previous
CCKDDU64. A binary comparison comes up clean, except for cdh_vrm
in the ckd device header - the version of CCKDDU64 was updated
to 0.3.2.

Well that's not right.

The "cdh_vrm" field in the CKD/CCKD dasd device header is the version of the Hercules CKD/CCKD device's file format, not the version of the program that happened to create that particular dasd image file. That sounds like yet another bug (albeit a minor/cosmetic one) in both CCKDDUMP and CCKDDU64 that needs to be fixed.

Where can I place the updated source?

Please send it directly to me so I can be sure to get the fixed version it into Hercules.

Also, would anyone need a load module?

I guess I'll be needing that too. And the object code too.

So.... if we can get the program version bug fixed in both CCKDDUMP and CCKDDU64, then I would need a copy of the updated/fixed source code for both, as well as the updated/fixed object code for both , *AND* the updated/fixed load library module (linked executable?) for both as well. (Is that asking too much?)

I suppose if you can just send me the updated/fixed source code for each, I can try to create the object code and load library for each myself. But given my inexperience with z/OS, I'd rather not have to do that as I might only end up screwing something up, and I definitely *don't* want to do that after all of your hard work.

So, at the risk of pushing my luck, would I be asking too much if you could take care of this last little bit for me Andrew? I'd *really* appreciate it!

Thanks!

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

Mike Schwab wrote:

Andrew wrote:

[...]

Where can I place the updated source? Also, would anyone
need a load module?

*ONLY* if someone is in dire *immediate* need for it right now.

Otherwise, I'd much rather wait until the "cckddump-cckdload.zip" file in Herc's 'util' subdirectory is first updated with the final *official* new/fixed version. Then and *only* then would I feel comfortable with someone then uploading it (or any part of it) to the group's Files area.

(I don't like having unofficial, *partially* fixed versions of Hercules code floating around out there.)

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

Andrew wrote:

Fish wrote:

Andrew wrote:

[...]

The "cdh_vrm" field in the CKD/CCKD dasd device header is
the version of the Hercules CKD/CCKD device's file format,
not the version of the program that happened to create that
particular dasd image file. That sounds like yet another bug
(albeit a minor/cosmetic one) in both CCKDDUMP and CCKDDU64
that needs to be fixed.

What is the CKD/CCKD device's file format?

0.3.1:



Just like .PDF files have a file format version and HTML files have a file format version, so do Hercules compressed dasds too. When the compressed dasd file format was originally being developed, it went through several different variations. It finally settled at the current format, version 0.3.1.

THAT is the version that should be placed into the CCKD device header.

The version of the CCKDDUMP and CCKDDU64 *programs* is a completely different thing.

Since this is going to be an updated fixed version of the original versions, I would suggest using something like version 1.2. Or maybe 1.0.2. The point is, when CCKDDUMP and CCKDDU64 start up, they should report their OWN version separately from the CCKD file format version they were written for. E.g:

CCKDDUMP version 1.0.2 (written for CCKD file format 0.3.1) starting...
CCKDDU64 version 1.0.2 (written for CCKD64 file format 0.3.1) starting...


Or maybe two separate messages might be clearer:

CCKDDUMP version 1.0.2 starting...
Written for CCKD file format 0.3.1

CCKDDU64 version 1.0.2 starting...
Written for CCKD64 file format 0.3.1


I'll let you decide how you want to handle that.

Where can I place the updated source?

Please send it directly to me so I can be sure to get the fixed
version it into Hercules.

To your email address?

Any one of: "fish" at infidels.org, "fish_david_b_trout" at comcast.net, "fish" at softdevlabs.com, or "david.b.trout" at gmail.com. Take your pick.

The infidels one I've had the longest. It was created probably 20+ years ago (possibly longer!) as a "permanent" email address. Email sent there just forwards it to my current ISP's account. If I ever switch to another ISP, I simply notify infidels.org, and they begin forwarding my mail to my new ISP. That's what makes it permanent.

(I got tired of notifying all my friends and family and business contacts about my new email address whenever I would switch ISPs, so I just purchased a permanent one that was guaranteed to always be valid.)

The comcast one is my current ISP account. The softdevlabs one is of course my official business account, and the gmail one is, well, my gmail account!

I guess these days a gmail address is probably about as permanent of an email address as you can get, so I guess that one would probably be the best one to use. But really, choose any one you want. They all end up getting to me one way or the other.

(I know, I know: WAY more information that you actually needed. But I like being thorough. Bad habit. So sue me.)


[...]

Yes, I can take care of that. I'd like to get confirmation
from Brian and/or Jay, or anyone else for that matter, that
the modifications work in their environments, before sending
out the final src, obj and load.

10-4. Wise decision. I will await the final version.

Thanks again, Andrew. MUCH appreciated buddy!

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

Brian Westerman wrote:

They transferred to my PC okay, and I added them to my config
file and they all came up fine. I had copied two 3390-27 (RES
and DLIB volumes) to a 3390-54 and transferred the 3390-27's
with the older CCKDDU64 and then the 3390-54s and another copy
of the 3390-27s volumes with the newer CCKDDU64 all 6 volumes
work perfectly fine.

FAN-F'ing-TASTIC! I am very glad to hear that, Brian!

Andrew? You did a fantastic job, my friend! THANK YOU!

Let me know when you're finished with the final version reporting issue, and I'll be sure your updates make it into the next version of Hercules.


[...]

I'm not sure who fixed the code, but I would like to thank you
for doing it. Great job!

It was Andrew. I don't know his real name since he never told us what it was. If he would let us know however, I will make sure that it's added to our list of Herculeans!

*


That is, if it's okay with you, Andrew? Yes?

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

Instead of a fixed L1 size, can this calculation be incorporated into
the program to dynamically ask for the correct size buffer for the
number of cylinders / tracks in the particular DCB? Since this is
larger than 4K, I assume one base register to the start will handle
any size volume? If not, at least document the calculation in
comments. Maybe check for reaching the buffer limit?

On Mon, Jan 20, 2025 at 2:18?AM Andrew via groups.io
<AndrewRandham@...> wrote:

I believe I know where/why it's going wrong with anything greater than 3390-27. In my test with a 3390-54, the size of the L1TAB needed for 982800 tracks is 30720. Adding the 1024 bytes for the header gives 31744 bytes. CCKDDU64 does not seem to deal with this, when this first record is greater the the lrecl/blksize of 16384, and it looks like the rewrite table gets corrupted.

I did use #MSG to assist in debugging, but could not use too many of them as it caused base register addressability to fail due to the increase in csect length.

Now looking at how to correct this........

Andrew

--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?