search

SDL-Hercules-390 / hyperion

The SDL Hercules 4.x Hyperion version of the System/370, ESA/390, and z/Architecture Emulator
Other
237 stars 89 forks source link

CCKDDIAG needs to provide support for shadow files #633

Closed Fish-Git closed 5 months ago

Fish-Git commented 6 months ago

The format of the cckddiag utility's command line is currently: cckddiag [options] file, where "file" is the name of the input CCKD/CFBA dasd image file. In other words, you can only do a cckddiag on either a base compressed image or on one of its shadow files, but not both together. That is to say, the utility does not currently support any sf= shadow file argument.

Given the huge advantage of using shadow files, for this particular utility not not support them is an incredibly annoying disadvantage.

If I wanted to, say, display a specific track that didn't happen to exist in the base image but was updated (written to) at some point in time in one of the many shadow files I happened to have for that volume, I would have to do a cckddiag on each of the individual shadow files starting with the most current one, and work my way downward until I found to most recent shadow file with that particular track on it, which needless to say would be a royal PITA.

Or worse, say the base image did have that track, but an update to that track also exists in one or more of its shadow files. If one did a cckddiag on the base image, it would display incorrect results. The results it would display would be outdated. It would be current. So once again, a backward search of the shadow files would need to be done.

Other utilities such as dasdls support shadow files (via the sf=xxxx... option), so IMO cckddiag should to!

This GitHub Issue is simply a reminder that we need to add such support to cckddiag.

I will of course try to do so myself when I find the time, but of course there's nothing stopping anyone else from taking on this (minor? trivial?) challenge either!  (hint! hint!)   ;-)

Fish-Git commented 5 months ago

After further consideration I have decided to withdraw this change request.

Upon reviewing the code, it appears this utility was purposely designed/written to perform its diagnostic functions on only the specific image file specified, with that file being either a base image OR a shadow file. Upon reflection this makes perfect sense. The utility is not designed (was not written) to e.g. dump a given track for a given dasd volume, but rather to perform diagnostic functions on a given specific dasd image file.

For example, given a base dasd image and its associated shadow files -- which taken together comprise the dasd volume -- in order to debug a theoretical problem in CCKD code for example, it's important to be able to determine which image file(s) contain the track in question and which do not. Adding "support for shadow files" as requested, would make it impossible to do so, as transparent shadow file support would completely mask where (i.e. from which image file) the track in question was actually being retrieved from.

So I am withdrawing my original change request and am closing this GitHub Issue as "(WON'T FIX)".