Well, https://ibmmainframes.com/references/disk.html shows 2311 with 3,625 bytes, 2314 with 7,294, 334x with 8,368, 3330 with 13,030, 2305 with 14,136, 3350 with 19,069, 3375 with 35,616, 3380 with 47,476, 3390 with 56,664.
Devices under 32K handle 32K physical blocks with track overflow. So 6K fits 2311 onto 2 tracks reasonable utilization, fits 2314, 334x on 1 track 1 block reasonable utilization, 3330, 2305 2 blocks per track, 3350 3 blocks, 3375 5 blocks, 3380 7 blocks, 3390 9 blocks. 7K block would fit 3330 2305 with 1 block using just over half the track. I've put together a spreadsheet estimating usage of nKB block sizes on various DASD models. I estimated the gaps as 1% of the track length because I did not find a reference showing interblock gaps. Don't need space for the last gap, so a .99 might hold one more record. Calculating n*TRK/(BLK+8+(2*GAP)) fraction shows the inefficiency of the blocking for the device and the sum of the fraction parts shows the overall inefficiency across all the device types. I'll update with the actual gaps (and max 3380/3390 gap) if someone can find it https://docs.google.com/spreadsheets/d/1cr3zl4k-Rpk449NNIuoqwZ8wV0q5MrkmKg-8jGdEkvM/edit?usp=sharing Would be interesting to test by allocating 1 cylinder on each device and copying records to fill blocks until abend. Say 64 bytes of a card image, 16 records per 1k, 3390 56k so 900 * 64 = 57,600, so 13,500 records would be more than 1 3390 cylinder. On Sat, Jun 15, 2024 at 11:38 PM Paul Edwards <00000676ab6435a5-dmarc-requ...@listserv.ua.edu> wrote: > > Thanks all for your replies. > > > I agree with Binyamin - XMIT format (aka NETDATA format, also transportable > > to VM systems) is fixed-length, > > Being fixed length isn't a selling point to me. zip files aren't > fixed length either. It's actually a non-selling point. > > You can consider that I have a rival format for XMIT (rightly > or wrongly, and I acknowledge in advance that most people > will probably say "wrongly"). > > > no RDW's needed, > > XMIT will indeed have RDWs embedded in the (more complicated > in my opinion) format. XMIT/TERSE just go on top of IEBCOPY and > will include the RDWs and possibly the BDWs from the IEBCOPY > unload RECFM=V(S) dataset. > > It is the RDWs that I add (or ftp adds) that I consider to be simple. > > > and handles executables as well as plain text or object data. > > I use zip for those other things. > > > And there are public domain tools available at the MVS 3.8 level > > to create into and extract from that format. > > They also exist (for decades) to handle the format that I outlined. > > What's new is just pdld. > > > Much easier to process than IEBCOPY unload format. > > 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. > > > current z/OS versions on any supported DASD, regardless of the > > DASD type it originated from. > > Yes, that's what I'm after. It's just a question of what my options > are. E.g. it is possible that I can't make the original DASD 3390 > if I want to restore to an unmodified MVS 3.8J that only supports > 3350. But I may be willing to mandate a modified MVS 3.8J that > has 3390 support added. That's my question, basically. What > options do I have within the parameters specified to achieve > my goal (not someone else's goal)? > > 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. > > BFN. Paul. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
