On Sat, 15 Jun 2024 23:30:13 -0700, Michael Stein <[email protected]> wrote:
>> Well that's basically my question - "any kind of DASD". I had an idea >> that maybe I should use a 2314 so that there is only one block per >> track. Someone told me elsewhere that I can't use VIO regardless - >> you can't have a VIO PDS - I haven't confirmed that with a test yet. > >Can't you just use whatever disk is handy but specify BLKSIZE for the >output PDS thus limiting the largest block the link editor will write? Sure - that's a given regardless. What I'm discussing is a theoretical/abstract disk - perhaps not that theoretical because a 2314 does that for real - that has 1 block per track. Possibly ideally it would have 1 track per cylinder too. >> With regards to the other question about DEB - it's not me who wants >> a DEB - it's the IEBCOPY format that requires it to be there. Well - puts >> it there, anyway - I don't know if it is actually used in the load process >> such that I can put junk values there. > >The directory entries of the PDS have TTRs which point to the member data. >You need to convert these TTRs into absolute disk addresses to figure >out which data belongs to that member. This takes the DEB extents as >well as the device dependent number of tracks per cylinder. Ok, I haven't deciphered that in practice yet, nor have I got an "abstract device" locked in yet. E.g. given that there is only one member in my PDS, I didn't expect the geometry to be relevant as I expect the data to start at the same spot. But testing has shown that the DEB changes when I make the executable bigger. I now have one bit of data though - VIO does in fact work. That doesn't necessarily mean I should be using it, but there's a good chance it is ideal. I'm still not familiar with the internals though. But even with VIO I am seeing 0x4a change here: Small executable: [kerravon@paul-pinebook vs3]$ hexdump ../vs2/exe.txt 0 0x60 000000 00380000 00CA6D0F 02004800 0000C000 .8....m...H..... 000010 00004814 3050200B 00004A7D 0230001E ..H.0P ...J}.0.. 000020 4B36010B 52080200 00000000 00000000 K6..R........... 000030 00000000 00000000 01180000 01000000 ................ 000040 FF000000 8F0B6644 049480E8 5094B330 ......fD....P..0 000050 00000001 000000A0 001D12C0 00000000 ................ ... Large executable: [kerravon@paul-pinebook vs3]$ hexdump exe.txt 0 0x60 000000 00380000 00CA6D0F 02004800 0000C000 .8....m...H..... 000010 00004814 3050200B 00004A7D 0230001E ..H.0P ...J}.0.. 000020 4B36010B 52080200 00000000 00000000 K6..R........... 000030 00000000 00000000 01180000 01000000 ................ 000040 FF000000 8F0B6644 049460E8 509490F0 ......fD..`.P... 000050 00000001 000000A0 001D12C0 00000000 ................ ... I need to know whether the maths required to calculate that 0x60 vs 0x80 is simpler/more abstract/more portable than relying on real spinning disks that may not have existed (or may have been removed) in some arbitrary version of MVS, past or future. Note that neither me nor the pdld author know what a DEB is, so it will be me who researches that. We can no longer use hardcoded values (or maybe we can?), because the values change, so we need to figure out what is happening. And if the calculations for VIO are simpler, then that's what I would like to research.. Thanks. Paul. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
