Using a build from a contemporary (2022/04/03) fork of this project/develop, I've noticed some discrepancies and defects:
The octet following the model number octet (0x90 for 3390) is (kind of) used by ckddasd to represent the ordering of split volumes. IBM alcckd uses some other values: 0x03 for older DASD, 0x04 for more recently built files. Meaning yet to be divined.
The 16 bit high cylinder value as defined by ckddasd is replaced by 2 32 bit cylinder count values at the same starting offset for alcckd generated dasd. Not sure why 2 yet, but that's the observation. These larger cylinder values overlap the ckddasd defined serial number field. Old pre-EAS versions of alcckd also use 32 bit cylinder numbers although the high order halfword is 0.
Large EAS images, (say a virtual 3390-128 where there are 128*1113 cylinders) cannot be opened by Hercules due to in-code assumptions that cylinder values are containable within 16 bits and the resulting incorrect calculations.
What's the project philosophy for these types of incompatibilities; perhaps CCKDDASD would be an alternative; but I personally have more disk space than processor time. I plan on making changes to eliminate these issues (at least for my use), would there be any interest by others? If so, I'll get them up into my fork and create a pull request.
Using a build from a contemporary (2022/04/03) fork of this project/develop, I've noticed some discrepancies and defects:
What's the project philosophy for these types of incompatibilities; perhaps CCKDDASD would be an alternative; but I personally have more disk space than processor time. I plan on making changes to eliminate these issues (at least for my use), would there be any interest by others? If so, I'll get them up into my fork and create a pull request.