[hercules-390] Any update on the 4GB cckd file limit?

[[e-mail] [hercules-390]]

Hello


I read the thread talking about the plans for the shift value by Greg Smith. I was wondering if there was anything new on this?


I ask because I have what I call an IPL set (2 IPL volumes, 2 OMVS volumes, 1 DLIB, 1 PTS and 1 SMP) that are all on mod 27. This limitation is really cramping my style. :(


Maybe we need to get together and bribe Greg to up the priority on this? :)


It's really cool to be able to run a MVS operating system on my laptop!


Please, Greg! You're our only hope!


I'll go re-read the shadow file usage but I'm not sure it will solve my problem. (maybe I don't really understand how it works.) If there is an alternative solution to this predicament, would someone be willing to share?


Thanks!

[Mike Stramba [e-mail] [hercules-390]]

If you have enough disk space (who doesn't these days ?) use the
hercules dasdcopy utility to copy the dasd to *uncompressed* volumes.

Mike

Post by ***@yahoo.com [hercules-390]
Hello
I read the thread talking about the plans for the shift value by Greg
Smith. I was wondering if there was anything new on this?
I ask because I have what I call an IPL set (2 IPL volumes, 2 OMVS volumes,
1 DLIB, 1 PTS and 1 SMP) that are all on mod 27. This limitation is really
cramping my style. :(
Maybe we need to get together and bribe Greg to up the priority on this?
:)
It's really cool to be able to run a MVS operating system on my laptop!
Please, Greg! You're our only hope!
I'll go re-read the shadow file usage but I'm not sure it will solve my
problem. (maybe I don't really understand how it works.) If there is an
alternative solution to this predicament, would someone be willing to
share?
Thanks!

[Mike Schwab [e-mail] [hercules-390]]

During the restore, when you hit the limit, you create a shadow file and
restore without replace to get new files. When done with a volume create
another shadow file to lock in the original load.

Post by ***@yahoo.com [hercules-390]
Hello
I read the thread talking about the plans for the shift value by Greg
Smith. I was wondering if there was anything new on this?
I ask because I have what I call an IPL set (2 IPL volumes, 2 OMVS
volumes, 1 DLIB, 1 PTS and 1 SMP) that are all on mod 27. This limitation
is really cramping my style. :(
Maybe we need to get together and bribe Greg to up the priority on this?
:)
It's really cool to be able to run a MVS operating system on my laptop!
Please, Greg! You're our only hope!
I'll go re-read the shadow file usage but I'm not sure it will solve my
problem. (maybe I don't really understand how it works.) If there is an
alternative solution to this predicament, would someone be willing to share?
Thanks!

[Giuseppe Vitillaro [e-mail] [hercules-390]]

Post by ***@yahoo.com [hercules-390]
Hello
I read the thread talking about the plans for the shift value by Greg
Smith. I was wondering if there was anything new on this?
I ask because I have what I call an IPL set (2 IPL volumes, 2 OMVS
volumes, 1 DLIB, 1 PTS and 1 SMP) that are all on mod 27. This
limitation is really cramping my style. :(
Maybe we need to get together and bribe Greg to up the priority on this?
:)
It's really cool to be able to run a MVS operating system on my laptop!
Please, Greg! You're our only hope!
I'll go re-read the shadow file usage but I'm not sure it will solve my
problem. (maybe I don't really understand how it works.) If there is
an alternative solution to this predicament, would someone be willing to
share?

As I normally play with MVS3.8j, which it is not even
able to use a 3390 dasd larger than 2Gb, I never met this
problem, but this thread attracted my attention.

I'm reading the page about it on the hyperion github:

https://github.com/hercules-390/hyperion/issues/35

and it looks the problem is there from a long time,
basically lasting from 2011, before I began to play
with hercules emulator.

I've a question about it.

The 4Gb limit is about the "compressed" CCKD file or about the
"uncompressed" data stored into the CCKD file?

The "shift" solution proposed by the CCKD coder, in principle, doesn't
look complex, but from the comments on the hyperion page, that is probably
plainly FALSE ;-( :

@Fish-Git Fish-Git added bug labels on Aug 23, 2014
@Fish-Git Fish-Git added Enhancement and removed BUG labels on Feb 3, 2015
@Fish-Git Fish-Git added (( STALLED )) and removed In progress... labels on Sep 1, 2015
@Fish-Git Fish-Git removed the Researching... label on Sep 18, 2015

If anyone has some fragment of code which try to add the "shift feature"
to cckd dasd sources, I would be glad to read that fragments, to get an
idea about how complex is the problem.

Peppe.

[Mike Schwab [e-mail] [hercules-390]]

Internally, the Compressed CKD disk uses a 4 byte pointer to each
compressed track. Suggestion is to shift by 8/9/12 bits for a
256/512/4096 byte block. http://www.hercules-390.org/cckddasd.html
On Mon, Oct 1, 2018 at 10:23 AM Giuseppe Vitillaro

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]

Post by ***@yahoo.com [hercules-390]
Hello
I read the thread talking about the plans for the shift value by Greg
Smith. I was wondering if there was anything new on this?
I ask because I have what I call an IPL set (2 IPL volumes, 2 OMVS
volumes, 1 DLIB, 1 PTS and 1 SMP) that are all on mod 27. This
limitation is really cramping my style. :(
Maybe we need to get together and bribe Greg to up the priority on this?
:)
It's really cool to be able to run a MVS operating system on my laptop!
Please, Greg! You're our only hope!
I'll go re-read the shadow file usage but I'm not sure it will solve my
problem. (maybe I don't really understand how it works.) If there is
an alternative solution to this predicament, would someone be willing to
share?

As I normally play with MVS3.8j, which it is not even
able to use a 3390 dasd larger than 2Gb, I never met this
problem, but this thread attracted my attention.
https://github.com/hercules-390/hyperion/issues/35
and it looks the problem is there from a long time,
basically lasting from 2011, before I began to play
with hercules emulator.
I've a question about it.
The 4Gb limit is about the "compressed" CCKD file or about the
"uncompressed" data stored into the CCKD file?
The "shift" solution proposed by the CCKD coder, in principle, doesn't
look complex, but from the comments on the hyperion page, that is probably
@Fish-Git Fish-Git added bug labels on Aug 23, 2014
@Fish-Git Fish-Git added Enhancement and removed BUG labels on Feb 3, 2015
@Fish-Git Fish-Git added (( STALLED )) and removed In progress... labels on Sep 1, 2015
@Fish-Git Fish-Git removed the Researching... label on Sep 18, 2015
If anyone has some fragment of code which try to add the "shift feature"
to cckd dasd sources, I would be glad to read that fragments, to get an
idea about how complex is the problem.
Peppe.
------------------------------------
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
------------------------------------
Yahoo Groups Links

['\'Fish\' (David B. Trout)' [e-mail] [hercules-390]]

Giuseppe Vitillaro wrote:

[...]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]
The "shift" solution proposed by the CCKD coder, in principle,
doesn't look complex, but from the comments on the hyperion page,

Correct. This is one issue where CLEARLY "The devil is in the details". It is a MUCH more complex issue than may at first seem.


[...]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]
If anyone has some fragment of code which try to add the
"shift feature" to cckd dasd sources, I would be glad to
read that fragments, to get an idea about how complex is
the problem.

No such code exists. (Or, more correctly, *I* certainly don't have any such code.)

But all you have to do is take a look at source files "hstructs.h" (line 1630 onward, where various CCKD structs are defined (see e.g. struct CCKD_DEVHDR!!)), "cckdutil.c" (where struct SPCTAB is defined as well as many of the common CCKD routines), "cckddasd.c", a 6000 line source file where the bulk of the CCKD logic is, "ckddasd.c", another 6000 line source where yet more device handler logic lives, and finally, "dasdutil.c", "fbadasd.c" (which also supports compression and is therefore impacted by any change to Hercules compressed dasd logic) and the various CKD/CCKD utility programs (cckdcdsk.c, cckdcomp.c, cckddiag.c, cckdswap.c, dasdcopy.c, dasdinit.c, etc), and you begin to get a feel for the overall scope that this particular project entails.

It's quite vast and fraught with many perils.

I wish good luck to *anyone* willing or interested in taking on this HUGE challenge.

Because you'll definitely need it.

[Giuseppe Vitillaro [e-mail] [hercules-390]]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
[...]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]
The "shift" solution proposed by the CCKD coder, in principle,
doesn't look complex, but from the comments on the hyperion page,

Correct. This is one issue where CLEARLY "The devil is in the details".
It is a MUCH more complex issue than may at first seem.

Did you try the "quick and dirty" solution to have a new,
incompatible, ccdk format where the U32 are simply converted
to U64?

Peppe.

[Giuseppe Vitillaro [e-mail] [hercules-390]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
[...]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]
The "shift" solution proposed by the CCKD coder, in principle,
doesn't look complex, but from the comments on the hyperion page,

Correct. This is one issue where CLEARLY "The devil is in the details".
It is a MUCH more complex issue than may at first seem.

Did you try the "quick and dirty" solution to have a new,
incompatible, ccdk format where the U32 are simply converted
to U64?
Peppe.

My post is a bit imprecise in this shape.

This is what "grep 'U32.*pos" *.c"

cckddasd.c:U32 ppos, pos; /* Free space offsets */
cckddasd.c:U32 ppos; /* Previous free space offset*/
cckddasd.c: cckd->cdevhdr[sfx].free = (U32)fpos;
cckddasd.c: new_l2.pos = (U32)pos;
cckddasd.c: cckd->l1[to_sfx][i] = (U32)pos;
cckddasd.c: if (cckd->l1[sfx][i] == (U32)upos)
cckddasd.c: if (cckd->l1[sfx][j] == (U32)(upos + i)) break;
cckddasd.c: if (l2.pos != (U32)(upos + i))
cckdutil.c:U32 pos; /* Space offset */
cckdutil.c:U32 lopos, hipos; /* low/high file positions */
cckdutil.c: U32 flen, fpos;
cckdutil.c: U32 flen, fpos;
dasdutil.c:U32 cpos = 0; /* Offset into cckd file */

grep in the spinhawk source tree.

Doesn't seem impossible to handle to my eyes.

Peppe.

['\'Fish\' (David B. Trout)' [e-mail] [hercules-390]]

Peppe (Giuseppe Vitillaro) wrote:

[...]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]
This is what "grep 'U32.*pos" *.c"
cckddasd.c:U32 ppos, pos; /* Free space offsets */
cckddasd.c:U32 ppos; /* Previous free space offset*/
cckddasd.c: cckd->cdevhdr[sfx].free = (U32)fpos;
cckddasd.c: new_l2.pos = (U32)pos;
cckddasd.c: cckd->l1[to_sfx][i] = (U32)pos;
cckddasd.c: if (cckd->l1[sfx][i] == (U32)upos)
cckddasd.c: if (cckd->l1[sfx][j] == (U32)(upos + i)) break;
cckddasd.c: if (l2.pos != (U32)(upos + i))
cckdutil.c:U32 pos; /* Space offset */
cckdutil.c:U32 lopos, hipos; /* low/high file positions */
cckdutil.c: U32 flen, fpos;
cckdutil.c: U32 flen, fpos;
dasdutil.c:U32 cpos = 0; /* Offset into cckd file */
grep in the spinhawk source tree.
Doesn't seem impossible to handle to my eyes.

If it's so damn simple then YOU do it!! :))

(And why just "U32.*pos"? You're going to miss a LOT of fields that need to be changed if you only look for that!)

I'm telling you, it's NOT as simple and straightforward as it may at first seem! Trust me. There's a LOT more to it.

And if you don't believe me I heartily invite you or anyone else to try their hand at making the needed changes. Once you get started, you'll begin to see what I'm talking about.

I'll get back to working on it again eventually. I'm just kind of busy with other things right now. But believe me, it's rather high on my list of things to do. It's a priority. It's just going to take a while to complete..

[Joe Monk [e-mail] [hercules-390]]

Hey Peppe,

You forgot dasdinit.c:

U32size = 0; /*Volume size */139
<https://github.com/rbowler/spinhawk/blob/59f0556cfb6c71044b42dbe29c44a9b82971e8cf/dasdinit.c#L139>
U32altsize = 0; /*Alternate cylinders */140
<https://github.com/rbowler/spinhawk/blob/59f0556cfb6c71044b42dbe29c44a9b82971e8cf/dasdinit.c#L140>
U32heads = 0; /*Number of tracks/cylinder */

So when you take those into account, it becomes a lot more interesting the
amount of work to do...

Joe


On Wed, Oct 3, 2018 at 1:01 PM ''Fish' (David B. Trout)'

[...]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]
This is what "grep 'U32.*pos" *.c"
cckddasd.c:U32 ppos, pos; /* Free space offsets */
cckddasd.c:U32 ppos; /* Previous free space offset*/
cckddasd.c: cckd->cdevhdr[sfx].free = (U32)fpos;
cckddasd.c: new_l2.pos = (U32)pos;
cckddasd.c: cckd->l1[to_sfx][i] = (U32)pos;
cckddasd.c: if (cckd->l1[sfx][i] == (U32)upos)
cckddasd.c: if (cckd->l1[sfx][j] == (U32)(upos + i)) break;
cckddasd.c: if (l2.pos != (U32)(upos + i))
cckdutil.c:U32 pos; /* Space offset */
cckdutil.c:U32 lopos, hipos; /* low/high file positions */
cckdutil.c: U32 flen, fpos;
cckdutil.c: U32 flen, fpos;
dasdutil.c:U32 cpos = 0; /* Offset into cckd file */
grep in the spinhawk source tree.
Doesn't seem impossible to handle to my eyes.

If it's so damn simple then YOU do it!! :))
(And why just "U32.*pos"? You're going to miss a LOT of fields that need
to be changed if you only look for that!)
I'm telling you, it's NOT as simple and straightforward as it may at first
seem! Trust me. There's a LOT more to it.
And if you don't believe me I heartily invite you or anyone else to try
their hand at making the needed changes. Once you get started, you'll begin
to see what I'm talking about.
I'll get back to working on it again eventually. I'm just kind of busy
with other things right now. But believe me, it's rather high on my list of
things to do. It's a priority. It's just going to take a while to complete.
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com

['\'Fish\' (David B. Trout)' [e-mail] [hercules-390]]

Post by Joe Monk ***@gmail.com [hercules-390]
Hey Peppe,
U32 size = 0; /*Volume size */
U32 altsize = 0; /*Alternate cylinders */
U32 heads = 0; /*Number of tracks/cylinder */

And what about "int" and "unsigned int" fields that are being used? Or 32-bit constants?

if (cckd->L1tab[sfx][L1idx] == 0xffffffff)
if (cckd->L2tab[l2x].L2_trkoff != 0xffffffff)

etc...

Post by Joe Monk ***@gmail.com [hercules-390]
So when you take those into account, it becomes
a lot more interesting the amount of work to do...

Just like I was saying!

[Giuseppe Vitillaro [e-mail] [hercules-390]]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]

Post by Joe Monk ***@gmail.com [hercules-390]
Hey Peppe,
U32 size = 0; /*Volume size */
U32 altsize = 0; /*Alternate cylinders */
U32 heads = 0; /*Number of tracks/cylinder */

And what about "int" and "unsigned int" fields that are being used? Or 32-bit constants?
if (cckd->L1tab[sfx][L1idx] == 0xffffffff)
if (cckd->L2tab[l2x].L2_trkoff != 0xffffffff)
etc...

Post by Joe Monk ***@gmail.com [hercules-390]
So when you take those into account, it becomes
a lot more interesting the amount of work to do...

Just like I was saying!

I do not claim is easy ;-)

But it looks worthing trying, going for an "incompatible"
new ccdk format, may be easier than implementing the shift.

Isn't it?

Peppe.

['\'Fish\' (David B. Trout)' [e-mail] [hercules-390]]

Peppe (Giuseppe Vitillaro) wrote:

[...]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]
I do not claim is easy ;-)
But it looks worthing trying, going for an
"incompatible" new ccdk format, may be easier
than implementing the shift.
Isn't it?

Absolutely. I agree 100%. Implementing the "shift" technique would probably take just as much effort and could actually end up being much more riskier.

Implementing a new incompatible CCKD64 format on the other hand, while probably just as much work (effort), would, IMHO, be much less risky as the shift technique (as the new code could then be compared side-by-side with the existing code to make sure things are being done for the most part the same way). and thus would be the best way to approach to take IMO. That's why I chose it.

[Mike Schwab [e-mail] [hercules-390]]

How about, for purposes of experimenting in hyperon, a 339X device
type that uses the 64 bit byte offset?
It will only emulate 3390 and 3390 EAV (>64K Cylinders) (or later) volumes.
339X-0001, 3, 9, 29 (rounds up to 32k), 59 (rounds down to 64k), 132,
265, 531, 1062 (future sizes of 2124, 4248, 8496, (16992) -G992) gives
you the multiple of 1113 cylinders specified. (adjust to actual IBM
supported maximum size).
On Wed, Oct 3, 2018 at 1:52 PM ''Fish' (David B. Trout)'

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
[...]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]
I do not claim is easy ;-)
But it looks worthing trying, going for an
"incompatible" new ccdk format, may be easier
than implementing the shift.
Isn't it?

Absolutely. I agree 100%. Implementing the "shift" technique would probably take just as much effort and could actually end up being much more riskier.
Implementing a new incompatible CCKD64 format on the other hand, while probably just as much work (effort), would, IMHO, be much less risky as the shift technique (as the new code could then be compared side-by-side with the existing code to make sure things are being done for the most part the same way). and thus would be the best way to approach to take IMO. That's why I chose it.
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
------------------------------------
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
------------------------------------
Yahoo Groups Links

[Mike Schwab [e-mail] [hercules-390]]

Oh, and 3390-0002 rounds down to 32k tracks and 3390-0004 rounds down
to 64K tracks for MVS.

Post by Mike Schwab ***@gmail.com [hercules-390]
How about, for purposes of experimenting in hyperon, a 339X device
type that uses the 64 bit byte offset?
It will only emulate 3390 and 3390 EAV (>64K Cylinders) (or later) volumes.
339X-0001, 3, 9, 29 (rounds up to 32k), 59 (rounds down to 64k), 132,
265, 531, 1062 (future sizes of 2124, 4248, 8496, (16992) -G992) gives
you the multiple of 1113 cylinders specified. (adjust to actual IBM
supported maximum size).
On Wed, Oct 3, 2018 at 1:52 PM ''Fish' (David B. Trout)'

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
[...]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]
I do not claim is easy ;-)
But it looks worthing trying, going for an
"incompatible" new ccdk format, may be easier
than implementing the shift.
Isn't it?

Absolutely. I agree 100%. Implementing the "shift" technique would probably take just as much effort and could actually end up being much more riskier.
Implementing a new incompatible CCKD64 format on the other hand, while probably just as much work (effort), would, IMHO, be much less risky as the shift technique (as the new code could then be compared side-by-side with the existing code to make sure things are being done for the most part the same way). and thus would be the best way to approach to take IMO. That's why I chose it.
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
------------------------------------
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
------------------------------------
Yahoo Groups Links

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

[Giuseppe Vitillaro [e-mail] [hercules-390]]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
[...]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]
I do not claim is easy ;-)
But it looks worthing trying, going for an
"incompatible" new ccdk format, may be easier
than implementing the shift.
Isn't it?

Absolutely. I agree 100%. Implementing the "shift" technique would
probably take just as much effort and could actually end up being much
more riskier.
Implementing a new incompatible CCKD64 format on the other hand, while
probably just as much work (effort), would, IMHO, be much less risky as
the shift technique (as the new code could then be compared side-by-side
with the existing code to make sure things are being done for the most
part the same way). and thus would be the best way to approach to take
IMO. That's why I chose it.

Yep ;-)

As soon as I've a "free week slot" (I hate to be stopped
while I'm munching a problem) I'll try to play a bit with
the cckd code.

I bet I'll "crash" on the same problems you met,
but, at least, I hope to gain some insights
of the picture.

Thanks David.

Peppe.

[Giuseppe Vitillaro [e-mail] [hercules-390]]

Post by Joe Monk ***@gmail.com [hercules-390]
Hey Peppe,
U32size = 0; /*Volume size */139
<https://github.com/rbowler/spinhawk/blob/59f0556cfb6c71044b42dbe29c44a9b82971e8cf/dasdinit.c#L139>
U32altsize = 0; /*Alternate cylinders */140
<https://github.com/rbowler/spinhawk/blob/59f0556cfb6c71044b42dbe29c44a9b82971e8cf/dasdinit.c#L140>
U32heads = 0; /*Number of tracks/cylinder */
So when you take those into account, it becomes a lot more interesting the
amount of work to do...
Joe

Mmm ...

U32 size = 0; /* Volume size */
U32 altsize = 0; /* Alternate cylinders */


Sure this is not the number of cylinders of the volume?

It doesn't look like a position to be translated,
from the comments?

Peppe.

[Mike Schwab [e-mail] [hercules-390]]

Those would be filled in from the devices or the initializing commands.
On Wed, Oct 3, 2018 at 1:14 PM Giuseppe Vitillaro

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]

Post by Joe Monk ***@gmail.com [hercules-390]
Hey Peppe,
U32size = 0; /*Volume size */139
<https://github.com/rbowler/spinhawk/blob/59f0556cfb6c71044b42dbe29c44a9b82971e8cf/dasdinit.c#L139>
U32altsize = 0; /*Alternate cylinders */140
<https://github.com/rbowler/spinhawk/blob/59f0556cfb6c71044b42dbe29c44a9b82971e8cf/dasdinit.c#L140>
U32heads = 0; /*Number of tracks/cylinder */
So when you take those into account, it becomes a lot more interesting the
amount of work to do...
Joe

Mmm ...
U32 size = 0; /* Volume size */
U32 altsize = 0; /* Alternate cylinders */
Sure this is not the number of cylinders of the volume?
It doesn't look like a position to be translated,
from the comments?
Peppe.
------------------------------------
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
------------------------------------
Yahoo Groups Links

[Joe Monk [e-mail] [hercules-390]]

If the cylinder is now 64 bits, and the track is now 64 bits, that affects
all the translations right?

Joe

Post by Joe Monk ***@gmail.com [hercules-390]

Post by Joe Monk ***@gmail.com [hercules-390]
Hey Peppe,
U32size = 0; /*Volume size */139
<

https://github.com/rbowler/spinhawk/blob/59f0556cfb6c71044b42dbe29c44a9b82971e8cf/dasdinit.c#L139

Post by Joe Monk ***@gmail.com [hercules-390]
U32altsize = 0; /*Alternate cylinders */140
<

https://github.com/rbowler/spinhawk/blob/59f0556cfb6c71044b42dbe29c44a9b82971e8cf/dasdinit.c#L140

Post by Joe Monk ***@gmail.com [hercules-390]
U32heads = 0; /*Number of tracks/cylinder */
So when you take those into account, it becomes a lot more interesting

the

Post by Joe Monk ***@gmail.com [hercules-390]
amount of work to do...
Joe

Mmm ...
U32 size = 0; /* Volume size */
U32 altsize = 0; /* Alternate cylinders */
Sure this is not the number of cylinders of the volume?
It doesn't look like a position to be translated,
from the comments?
Peppe.

[Mike Schwab [e-mail] [hercules-390]]

No. That is part of the 3390 specs. This is the byte offset within the
FBA disk underling the CCKD dasd storage. The 3390 EAV actually wraps the
upper 12 bits of the cylinder number into the track number.

Post by Joe Monk ***@gmail.com [hercules-390]
If the cylinder is now 64 bits, and the track is now 64 bits, that affects
all the translations right?
Joe

Post by Joe Monk ***@gmail.com [hercules-390]

Post by Joe Monk ***@gmail.com [hercules-390]
Hey Peppe,
U32size = 0; /*Volume size */139
<

https://github.com/rbowler/spinhawk/blob/59f0556cfb6c71044b42dbe29c44a9b82971e8cf/dasdinit.c#L139

Post by Joe Monk ***@gmail.com [hercules-390]
U32altsize = 0; /*Alternate cylinders */140
<

https://github.com/rbowler/spinhawk/blob/59f0556cfb6c71044b42dbe29c44a9b82971e8cf/dasdinit.c#L140

Post by Joe Monk ***@gmail.com [hercules-390]
U32heads = 0; /*Number of tracks/cylinder */
So when you take those into account, it becomes a lot more interesting

the

Post by Joe Monk ***@gmail.com [hercules-390]
amount of work to do...
Joe

Mmm ...
U32 size = 0; /* Volume size */
U32 altsize = 0; /* Alternate cylinders */
Sure this is not the number of cylinders of the volume?
It doesn't look like a position to be translated,
from the comments?
Peppe.

['\'Fish\' (David B. Trout)' [e-mail] [hercules-390]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]

[...]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]
The "shift" solution proposed by the CCKD coder, in
principle, doesn't look complex, but from the comments
on the hyperion page, that is probably plainly FALSE ;-(

Correct. This is one issue where CLEARLY "The devil is in
the details". It is a MUCH more complex issue than may
at first seem.

Did you try the "quick and dirty" solution to have a new,
incompatible, ccdk format where the U32 are simply converted
to U64?

Yes, that is the general idea I *was* (past tense) working on when I got distracted with other things. But was I said, it's not nearly as simple as changing all U32 references to U64. There's much more to it. You need to look at how each field is being used. You need to examine ALL of the affected code. There are various presumptions regarding field widths and struct sizes being made in the code in more than a few places, and that is the "devil in the detail" I am referring to. I'm telling you, it is NOT as simple as it may at first seem! Trust me! If it were so simple it would have been done a long time ago!