On Sat, Jun 15, 2024 at 11:37:59PM -0500, Paul Edwards wrote: > I don't consider it to be easier, but that's one of the "eyes of > the beholder" thing. I'm curious as to why you think IEBCOPY > unload format is difficult to process. That's the exact problem > IMO. And the other things are layered on top of IEBCOPY > unload anyway. > > > If your "pdld" tool > > The tool is a linker btw. "ld" is from Unix. > > > can just create the executable format into a one-member, BLKSIZE=6144 > > PDS on any kind of DASD that supports that block size (i.e., just replace > > the IEWL part),
> 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? > 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. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
