Directory is DL=256, KL=8; that affects space calculations, although normally it makes little practical difference.
For PDSE everything is CI formatted. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Mike Schwab [mike.a.sch...@gmail.com] Sent: Wednesday, November 23, 2022 1:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Bytes in a 3390 track @ Format of a PDS. N records of K8 Block256 for the directory plus an end of file marker. Adding or removing members involves rewriting the entire directory, member entry update in place is possible but not guaranteed. Text PDSs have members that are FB or VB blocks up to the block size until the member ends. When creating short blocks to fill the balance of the track are often created. Load module PDSs have members with a symbol dictionary in text and blocked together to start, then repeating a very short block then the program machine code in multiples of 1K to the blocksize or fill the rest of the track if less until the load module is complete. When adding or updating the data is added to the end of the dataset. When updating or deleting a member the references to the space previously used is removed but can’t be reused. Eventually you compress the PDS in place. The program reads the directory, determines where unreferenced space is, then moves up the next block to the unreferenced space. The COPY command doesn’t reblock the data, so if you have a 31K empty space but the next block is 32K, you don’t use that space. COPYMOD does reblock, but may not be used very often. So, a research idea is to write a program that reads the C part of each CKD record, and calculate a fake R255 for the Key/Blocksize that could fill the track. K8/D256 would be the directory blocks, K0/Dx would be text, K0/Dnk would be program code. Counts of each key / block size in a dataset would give insight to that dataset or collection of text datasets and collection of load module datasets. Experiments to help determine optimal blocksizes would be to create a test library with 32K blocksize, copy with reblock into the test library, analyze blocksizes, delete first member, compress in place, reanalyze blocksize especially the unused space at end of track. Repeat until empty. Reduce by 1K, repeat with copy with reblocking, analyzing, deleting, compressing until empty. My predictions of what could be optimal is a 4K blocksize. And VSAM and PDSE datasets usually use this physical block size. And might have advantages in the I/O occurring in a single frame. On Wed, Nov 23, 2022 at 11:35 AM Seymour J Metz <sme...@gmu.edu> wrote: > > No, sometimes a smaller block size is more efficient. Also, a 32K block size > doesn't mean that all blocks are 32K; both the linkage editor and IEBCOPY can > write short blocks to pad out a track. > > ________________________________________ > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of > Paul Gorlinsky <p...@atsmigrations.com> > Sent: Wednesday, November 23, 2022 12:14 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Bytes in a 3390 track > > John, The simple view is that with DASD, the bigger the block as a multiple > of the track size, the more data you can store on a track. > > It almost like an IBG on the older tapes. > > Best allocation or space calc is to use 1/2 track if possible, for QSAM, and > PDSs. For PDSEs using 32760 is fine because I believe they like linear VSAM > files with 4K blocks. > > Remember for DASD, the maximum block size ( physical record ) is 32760. But > this means on a 3390 you waste about 24K per track. Where as, using something > near 27998 or less, you will get 2 blocks per track with about 1% overhead. > > It looks like PDSEs have about 13% overhead per track assuming a 4K (PAGE) > track record size ... BUT no compression needs.. > > For the most part, let the OS handle the allocation by using BLKSIZE=0 where > you can. It will calc the optimized track record size ( blksize ) for the > specific device, including tapes. > > Do not expect 100% track utilization with MVS/VSE/VM ... > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
