Re: Bytes in a 3390 track
Yes, in OS/360, but if you use COPYMOD instead of COPY then IEBCOPY reblocks appropriately to optimize packing. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Leonard D Woren [ibm-main...@ldworen.net] Sent: Wednesday, November 23, 2022 7:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Bytes in a 3390 track Long ago I had a theory regarding blksize=32K load module libraries that I could demonstrate on paper but never attempted to demonstrate for real due to the amount of work involved. Consider that the linkage editor writes however much program text as fits on the rest of the track. IEBCOPY to a new data set copies members in membername order, not physical order from the original data set. It is theoretically possible to construct a degenerate case where due to the above, the IEBCOPY'd data set will actually take _more_ space than the original! You could have two members originally linked to different areas of the original PDS, decently utilizing 32K blocks. Now you IEBCOPY the data set and those two members end up one following one another in the target, and the second member's 32K block doesn't fit after the first member's 32K block, and the short noise blocks in load modules come nowhere close to using up that space. So in certain degenerate cases, you could waste maybe 1/3 of the space when IEBCOPYing a blksize=32K load module library. I suspect that some number a bit below half track is optimum to allow for the small overhead blocks plus 2 long text blocks. OTOH, why isn't everybody using PDSEs instead of wasting brain power on this? /Leonard Mike Schwab wrote on 11/23/2022 10:22 AM: [...] > 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 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 on behalf of >> Paul Gorlinsky >> 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% >> overhe
Re: Bytes in a 3390 track
On Wed, 23 Nov 2022 16:56:42 -0800, Leonard D Woren wrote: >You could have two members originally linked to different >areas of the original PDS, decently utilizing 32K blocks. Now you >IEBCOPY the data set and those two members end up one following one >another in the target, and the second member's 32K block doesn't fit >after the first member's 32K block, Except that IEBCOPY also knows about splitting TXT records, and it will do so to maximize track usage. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bytes in a 3390 track
On Fri, 25 Nov 2022 12:12:36 -0800, Leonard D Woren wrote: > >I've long wondered why. And in the 1980s (I think), IBM actually had >a disk for s370 which was FBA, but only supported by DOS/VS. > 3310 and 3370. Also supported by VM/SP. (Certain models of 3370 could also attach to System/38) 3375 was the CKD flavor of 3370. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bytes in a 3390 track - reason for the question
Paul Schuster wrote on 11/24/2022 11:13 PM: TRKCALC knows everything. Second best, I dug up this exec from the 1990s that should get it right: /* Rexx */ Parse Arg kl dl . "XPROC 2 KL DL DEBUG" If dl = "" Then Do Say "Usage: BLK3390 keylen datalen [DEBUG]" Exit 2 End c = 10 If kl = 0 Then k = 0 Else Do kn = DivRU( kl+6, 232 ) k = 9 + DivRU( kl+6*kn+6, 34 ) End dn = DivRU( dl+6, 232 ) d = 9 + DivRU( dl+6*dn+6, 34 ) blks = 1729%(c+k+d) If debug = "DEBUG" Then Say 'C' c', K' k', D' d Say blks "blocks with keylen" kl "and datalen" dl "fit on a 3390." Exit /*/ DivRU: /* divide and round UP */ Return (Arg(1)+Arg(2)-1)%Arg(2) /Leonard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bytes in a 3390 track
Seymour J Metz wrote on 11/25/2022 6:23 AM: You have 80 terabytes? At least. You can get there pretty fast with 10 and 12 TB disks, in pairs for backup purposes. But the pressure is on to switch to Linux because I'm just about out of drive letters on Windows, and I already have some disks with no drive letters using Windows mount points. One reason is IBM's refusal to accept and implement the SHARE requirement to support FBA in MVS for both access methods and IPL. I've long wondered why. And in the 1980s (I think), IBM actually had a disk for s370 which was FBA, but only supported by DOS/VS. I'd also ask why IBM didn't provide ACB/RPL support for all access methods, with compatibility and reverse compatibility interfaces as necessary, such as were present in OS/VS1 and VSE. I'd also like to know why. If they had done that, a lot of changes (such as the DCBE kludge) to non-VSAM access methods for 31 bit support would have been unnecessary because ACBs are 31 bit clean. It's a shame that IBM dropped TSS; moving it to FBA would have been a piece of cake. The grand irony of course is that VSAM and its cousins (Linear, PAGE, PDSE, ZFS) use FBA layered on top of CKD emulated on FBA. Surely I'm not the only one who thinks this is nuts? /Leonard -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Leonard D Woren [ibm-main...@ldworen.net] Sent: Wednesday, November 23, 2022 8:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Bytes in a 3390 track True. Yet... why is space still such a big deal on mainframes? I have almost as much disk space connected to my primary PC as 10,000 3390-9 would hold. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bytes in a 3390 track
As someone who has delved deeply into this subject for different reasons, and without "inside" knowledge, here's what I have learned or intuited: 1. Logical volumes are entirely self-contained (think of them as files), allocated from the arrays with all required space needed to hold metadata, including the count and key fields associated with every track allocated to the volume. 2. The CK fields appear to be located within the logical track construct. This does not preclude the existence of other constructs to make key and ID searches go faster. I speculate that such constructs do exist. Why? Because that's what I would do. 3. For thinly-provisioned volumes, space is allocated on WRITE-type operations and is released on ERASE-type operations. Space is managed in chunks that are implementation dependent, not on the architecture, though for DS8K, I think it's 1113 cylinders at a time (3390 mod 1 size). 4. While the architecture allows R0 data to be more than 8 bytes, it's not a good idea. There are too many things that "know" R0 is 8 bytes. 5. The space calculation capacity factors and the algorithm to use are returned by the device via Read Device Characteristics (RDC). You have to go to the book to get the algorithm details. 6. Unformatted track capacity is a useless number to sysprogs. 7. The best utilization of the device is when you have just one user record on the track (R1), and that record is 56664 bytes. 8. READ FULL TRACK and WRITE FULL TRACK operations are very specialized operations typically used only by programs that are archiving/restoring data. 9. "Nobody cares about this stuff, Alan. Don't you have something more important you should be doing?" I have a program that gathers capacity data. Here's output for a 100-cylinder minidisk. The only thing that changes based on cylinder count is the total capacity value: Capacity formula: 2 Capacity factors F1-F6: 34 19 9 6 116 6 HA + R0 length: 1428 Track length: 58786 Max R0 length: 57326 Max R1 length: 56664 (architected) Unformatted device capacity: 84.1 MB Formatted device capacity (4K blocks): 70.3 MB Formatted device capacity (56664 block): 81.1 MB Regards, Alan Altmark IBM z/VM Engineer and Consultant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bytes in a 3390 track
On 11/23/2022 5:19 PM, Leonard D Woren wrote: It's time to use this brainpower for better things than optimizing the arrangement of angels on a pinhead. Just throw more hardware at it and move on. We have standardized on a mixture of Mod-27 and Mod-216 volumes for all of our SMS-managed data. It's pretty much worry free compared to the micro-management we used to do with Mod-3s and Mod-9s. .-- VTOC Summary Information ---. | MVS60 . : MVSEV0 | | Command ===> | | | | Unit . . : 3390 Free Space | | | | VTOC Data Total Tracks Cyls | | Tracks . : 540 Size . . : 913,978 60,883 | | %Used . . : 6 Largest . : 392,055 26,137 | | Free DSCBS: 25,614 Free | | Extents . : 248 | | | | Volume Data Track Managed Tracks Cyls | | Tracks . : 3,606,120 Size . . : 471,718 31,399 | | %Used . : 74 Largest . : 392,055 26,137 | | Trks/Cyls: 15 Free | | F1=Help F2=Split F3=Exit F9=Swap F12=Cancel | '-- VTOC Summary Information ---' -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bytes in a 3390 track
You have 80 terabytes? One reason is IBM's refusal to accept and implement the SHARE requirement to support FBA in MVS for both access methods and IPL. However, IBM did add new DD parameters to allow the OS to do some of the calculations for the user.. Even with that, however, there would still have been issues of guarantied space and locality of reference. I'd also ask why IBM didn't provide ACB/RPL support for all access methods, with compatibility and reverse compatibility interfaces as necessary, such as were present in OS/VS1 and VSE. It's a shame that IBM dropped TSS; moving it to FBA would have been a piece of cake. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Leonard D Woren [ibm-main...@ldworen.net] Sent: Wednesday, November 23, 2022 8:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Bytes in a 3390 track True. Yet... why is space still such a big deal on mainframes? I have almost as much disk space connected to my primary PC as 10,000 3390-9 would hold. Seeing a 3390 with 150,000 free cylinders does take some getting used to. It's time to use this brainpower for better things than optimizing the arrangement of angels on a pinhead. Just throw more hardware at it and move on. A 4 TB disk is the equivalent of almost 5,000,000 3390 cylinders, or 500 3390-9s. How much DASD can you add in the disk array for the price (salary) of one additional storage management person? /Leonard Seymour J Metz wrote on 11/23/2022 3:20 PM: > With essentially all z DASD being cached these days, a lot of the efficiency > issues no longer apply, leaving space as more dominant. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > -- 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
Re: Bytes in a 3390 track
No, but the controller does. When the access method uses Locate and Define Extent, the controller pulls full tracks into the cache. There's also a a/OS authorized service for accessing SCSI DASD via FCP; I believe that works by sector, but, again, the controller does things behind the scenes to make it more efficient. -- 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 8:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Bytes in a 3390 track Not sure when it changed (at least a decade ago), I think the mainframe reads and writes full tracks at a time anymore. On Wed, Nov 23, 2022 at 7:01 PM Michael Oujesky wrote: > > Actually, if you are doing sequential processing, zEDC is perhaps the > best as it "write"s full-tracks, regardless of the BLKSIZE > specified. With zEDC, the BLKSIZE is just the size of data passed > to/from the application and no longer the physical data "written" to disk. > > Michael > > At 12:14 PM 11/23/2022, Mike Schwab wrote: > > >If you are doing sequential reads and writes, half track is the best > >you can do. If you are random reading small records, I.E. 80 byte, > >400 bytes, 2000 bytes; then smaller blocks lead to less I/O per > >record, since you aren't using most of the data read, and the larger > >the block the less you use. VSAM use a 4K physical record unless > >you specify a very large CI size. > > > >On Wed, Nov 23, 2022 at 11:56 AM Paul Gorlinsky > >wrote: > > > > > > Short block more efficient? Elaborate please. Space utilization > > and efficient are not necessarily the same. Latency issues vary a > > lot depending on the exact box being used for DASD. DS6K v DS8K. > > DS8K with rotating v solid-state ... > > > > > > QSAM v BPAM v BSAM v etc... > > > > > > General guidelines ... > > > > > > -- > > > 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 -- 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
Re: Bytes in a 3390 track - reason for the question
TRKCALC knows everything. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bytes in a 3390 track - reason for the question
i was just getting ready to say this same thing. The 3390 reference shows that for a 3120 byte block, only 15 blocks fit on a track, with a 16% space waste. Your best bet is to use TRKCALC... https://www.ibm.com/docs/en/zos/2.4.0?topic=instructions-performing-track-calculations-trkcalc-macro Joe On Thu, Nov 24, 2022 at 11:25 AM Joel C. Ewing wrote: > Subtracting the logical blocksize from either of those capacity numbers > as you describe will not give correct results for blocks per track. The > only accurate way to determine how many blocks will fit on a 3390 track > is to use the formulas from the 3390 Reference Summary (mentioned in > previous post) to compute the number of 34-byte cells required to write > the block and see if enough of the 1729 cells in the track remain. For > fixed-sized blocks of length requiring "x" cells, the number of blocks > per track would be floor(1729/x) . > > Alternatively, there is a table in the 3390 Reference Summary on page > 12 showing the minimum and maximum block sizes vs number of blocks per > track. It only has 86 rows (a blocksize of 1 byte only gets you 86 > usable bytes per track!), so you could store the Min, Max, and Records > columns of that entire table in a program and look up any blocksize to > see which which row min/max includes that blocksize and extract the > blocks/track from the Records row of the table. > > If your object is to report how much resource the datasets are > consuming, then tracks allocated makes the most sense. > > If your object is to report how much useful data is in the dataset, then > the blocksize becomes potentially useful. If you can get the > last-track-used you can compute the number of actual blocks in the > dataset within an accuracy of blocks-per-track - 1. > > The actual useful data per track vs best-case usage might also be useful > if a sub-optimal blocksize has been chosen. > > Joel C Ewing > > On 11/24/22 10:14, John Gateley wrote: > > The reason for asking the question about bytes on a track is that I am > writing programs to report on all disk datasets. > > The first program looks at all on-line disk packs and extracts all > format 1, 3, 8 and 9 DSCBs while also providing a summary of space > available/used on each disk (similar to VTOC on CBT file 112). > > The second program produces information for all datasets. If the > secondary allocation is in blocks then that means the primary was also and > I want to output the allocation like this BLK(00060,00020). > > To do this I subtract the block size from 56664 repeatedly until the > remainder is less than the block size which gives me the number of blocks > in a track, multiply this by the primary allocation in tracks should give > me the figure I want. > > Except it doesn't. > > > > For the format 1 DSCB below ISPF 3;4 reports BLK(00060,00020) and my > program BLK(00072,00020). > > With a blocksize of 3120 there are 18 blocks per track and 4 tracks are > in use. 3 of them must be full so that gives 54 blocks meaning there are > only 6 on the final track. > > > > The dataset is not extended format, PDSE, HFS or VSAM so I think I need > to look at DS1TRBAL, I subtracted 32266 from 56664 and worked out how many > blocks would fit, I get 7 not 6. > > > > Alternatively, if I use 55996 I get 17 blocks per track meaning there > are 9 on the last track and I get 7. > > > > I'm obviously missing something, and I am hoping someone can tell me > what? > > > > DS1DSNAM DSN1.SRCLIB.DATA > > DS1FMTID 1 > > DS1DSSN DB2C06 > > DS1VOLSQ 0001 > > DS1CREDT 78003A > > DS1EXPDT 00 > > DS1NOEPV 01 > > DS1NOBDB 00 > > DS1FLAG1 00 > > DS1SYSCD IBMOSVS2 > > DS1REFD 7A0148 > > DS1SMSFG 80 > > DS1SCXTF 80 > > DS1SCXTV 0FA04000 > > DS1DSORG 0200 > > DS1RECFM 90 > > DS1OPTCD 00 > > DS1BLKL 0C30 > > DS1LRECL 0050 > > DS1KEYL 00 > > DS1RKP > > DS1DSIND 80 > > DS1SCAL1 50 > > DS1SCAL3 14 > > DS1LSTAR 15 > > DS1TRBAL 7E0A32266 > > DS1TTTHI 00 > > DS1EXT1 010C000B000C000E > > DS1EXT2 > > DS1EXT3 > > DS1PTRDS 00 > > > > Data Set Name . . . . : DSN1.SRCLIB.DATA > > > > General Data Current Allocation > > Management class . . :Allocated blocks . : 60 > > Storage class . . . :Allocated extents . : 1 > >Volume serial . . . : DB2C06 Maximum dir. blocks : 20 > >Device type . . . . : 3390 > > Data class . . . . . : > >Organization . . . : POCurrent Utilization > >Record format . . . : FB Used blocks . . . . : 7 > >Record length . . . : 80 Used extents . . . : 1 > >Block size . . . . : 3120 Used dir. blocks . : 1 > >1st extent blocks . : 60 Number of members . : 0 > >Secondary blocks . : 20 > >Data set name type : PDS Dates > >Data set encryption : NO
Re: Bytes in a 3390 track - reason for the question
Subtracting the logical blocksize from either of those capacity numbers as you describe will not give correct results for blocks per track. The only accurate way to determine how many blocks will fit on a 3390 track is to use the formulas from the 3390 Reference Summary (mentioned in previous post) to compute the number of 34-byte cells required to write the block and see if enough of the 1729 cells in the track remain. For fixed-sized blocks of length requiring "x" cells, the number of blocks per track would be floor(1729/x) . Alternatively, there is a table in the 3390 Reference Summary on page 12 showing the minimum and maximum block sizes vs number of blocks per track. It only has 86 rows (a blocksize of 1 byte only gets you 86 usable bytes per track!), so you could store the Min, Max, and Records columns of that entire table in a program and look up any blocksize to see which which row min/max includes that blocksize and extract the blocks/track from the Records row of the table. If your object is to report how much resource the datasets are consuming, then tracks allocated makes the most sense. If your object is to report how much useful data is in the dataset, then the blocksize becomes potentially useful. If you can get the last-track-used you can compute the number of actual blocks in the dataset within an accuracy of blocks-per-track - 1. The actual useful data per track vs best-case usage might also be useful if a sub-optimal blocksize has been chosen. Joel C Ewing On 11/24/22 10:14, John Gateley wrote: The reason for asking the question about bytes on a track is that I am writing programs to report on all disk datasets. The first program looks at all on-line disk packs and extracts all format 1, 3, 8 and 9 DSCBs while also providing a summary of space available/used on each disk (similar to VTOC on CBT file 112). The second program produces information for all datasets. If the secondary allocation is in blocks then that means the primary was also and I want to output the allocation like this BLK(00060,00020). To do this I subtract the block size from 56664 repeatedly until the remainder is less than the block size which gives me the number of blocks in a track, multiply this by the primary allocation in tracks should give me the figure I want. Except it doesn't. For the format 1 DSCB below ISPF 3;4 reports BLK(00060,00020) and my program BLK(00072,00020). With a blocksize of 3120 there are 18 blocks per track and 4 tracks are in use. 3 of them must be full so that gives 54 blocks meaning there are only 6 on the final track. The dataset is not extended format, PDSE, HFS or VSAM so I think I need to look at DS1TRBAL, I subtracted 32266 from 56664 and worked out how many blocks would fit, I get 7 not 6. Alternatively, if I use 55996 I get 17 blocks per track meaning there are 9 on the last track and I get 7. I'm obviously missing something, and I am hoping someone can tell me what? DS1DSNAM DSN1.SRCLIB.DATA DS1FMTID 1 DS1DSSN DB2C06 DS1VOLSQ 0001 DS1CREDT 78003A DS1EXPDT 00 DS1NOEPV 01 DS1NOBDB 00 DS1FLAG1 00 DS1SYSCD IBMOSVS2 DS1REFD 7A0148 DS1SMSFG 80 DS1SCXTF 80 DS1SCXTV 0FA04000 DS1DSORG 0200 DS1RECFM 90 DS1OPTCD 00 DS1BLKL 0C30 DS1LRECL 0050 DS1KEYL 00 DS1RKP DS1DSIND 80 DS1SCAL1 50 DS1SCAL3 14 DS1LSTAR 15 DS1TRBAL 7E0A32266 DS1TTTHI 00 DS1EXT1 010C000B000C000E DS1EXT2 DS1EXT3 DS1PTRDS 00 Data Set Name . . . . : DSN1.SRCLIB.DATA General Data Current Allocation Management class . . :Allocated blocks . : 60 Storage class . . . :Allocated extents . : 1 Volume serial . . . : DB2C06 Maximum dir. blocks : 20 Device type . . . . : 3390 Data class . . . . . : Organization . . . : POCurrent Utilization Record format . . . : FB Used blocks . . . . : 7 Record length . . . : 80 Used extents . . . : 1 Block size . . . . : 3120 Used dir. blocks . : 1 1st extent blocks . : 60 Number of members . : 0 Secondary blocks . : 20 Data set name type : PDS Dates Data set encryption : NO Creation date . . . : 2020/02/27 Referenced date . . : 2022/11/24 Expiration date . . : ***None*** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Joel C. Ewing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu
Re: Bytes in a 3390 track - reason for the question
You're missing an allowance for an inter-block gap. On Thu, 24 Nov 2022 at 16:14, John Gateley wrote: > The reason for asking the question about bytes on a track is that I am > writing programs to report on all disk datasets. > The first program looks at all on-line disk packs and extracts all format > 1, 3, 8 and 9 DSCBs while also providing a summary of space available/used > on each disk (similar to VTOC on CBT file 112). > The second program produces information for all datasets. If the secondary > allocation is in blocks then that means the primary was also and I want to > output the allocation like this BLK(00060,00020). > To do this I subtract the block size from 56664 repeatedly until the > remainder is less than the block size which gives me the number of blocks > in a track, multiply this by the primary allocation in tracks should give > me the figure I want. > Except it doesn't. > > For the format 1 DSCB below ISPF 3;4 reports BLK(00060,00020) and my > program BLK(00072,00020). > With a blocksize of 3120 there are 18 blocks per track and 4 tracks are in > use. 3 of them must be full so that gives 54 blocks meaning there are only > 6 on the final track. > > The dataset is not extended format, PDSE, HFS or VSAM so I think I need to > look at DS1TRBAL, I subtracted 32266 from 56664 and worked out how many > blocks would fit, I get 7 not 6. > > Alternatively, if I use 55996 I get 17 blocks per track meaning there are > 9 on the last track and I get 7. > > I'm obviously missing something, and I am hoping someone can tell me what? > > DS1DSNAM DSN1.SRCLIB.DATA > DS1FMTID 1 > DS1DSSN DB2C06 > DS1VOLSQ 0001 > DS1CREDT 78003A > DS1EXPDT 00 > DS1NOEPV 01 > DS1NOBDB 00 > DS1FLAG1 00 > DS1SYSCD IBMOSVS2 > DS1REFD 7A0148 > DS1SMSFG 80 > DS1SCXTF 80 > DS1SCXTV 0FA04000 > DS1DSORG 0200 > DS1RECFM 90 > DS1OPTCD 00 > DS1BLKL 0C30 > DS1LRECL 0050 > DS1KEYL 00 > DS1RKP > DS1DSIND 80 > DS1SCAL1 50 > DS1SCAL3 14 > DS1LSTAR 15 > DS1TRBAL 7E0A32266 > DS1TTTHI 00 > DS1EXT1 010C000B000C000E > DS1EXT2 > DS1EXT3 > DS1PTRDS 00 > > Data Set Name . . . . : DSN1.SRCLIB.DATA > > General Data Current Allocation > Management class . . :Allocated blocks . : 60 > Storage class . . . :Allocated extents . : 1 > Volume serial . . . : DB2C06 Maximum dir. blocks : 20 > Device type . . . . : 3390 > Data class . . . . . : > Organization . . . : POCurrent Utilization > Record format . . . : FB Used blocks . . . . : 7 > Record length . . . : 80 Used extents . . . : 1 > Block size . . . . : 3120 Used dir. blocks . : 1 > 1st extent blocks . : 60 Number of members . : 0 > Secondary blocks . : 20 > Data set name type : PDS Dates > Data set encryption : NO Creation date . . . : 2020/02/27 >Referenced date . . : 2022/11/24 >Expiration date . . : ***None*** > > -- > 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
Re: Bytes in a 3390 track
But even if they do that under the covers at the track level, I would expect the DS8K boxes to still allocate/reserve total physical space for each emulated DASD unit under the worst case assumption that every track might be fully utilized. Unless advertised as a more restricted version of 3390, It would be a poor emulation from a mainframer's viewpoint if your DASD subsystem could have a write to a virtual drive fail from lack of physical backup storage because someone actually figured out a useful application that would load up all drives with one max full-track record per track as permitted by the architecture definition. The old and long-withdrawn IBM 9393 RAMAC Virtual Array storage subsystem was was an interesting beast that didn't have fixed track mapping -- every new emulated track written went to a different place in the backstore with previous version of the track deleted. There was even handshaking between MVS and the RAMAC subsystem when a dataset was deleted so that emulated tracks associated a deleted dataset could be deleted from the backstore even before the track was re-used. Very efficient on physical subsystem storage, but also had some peculiar performance characteristics -- multitrack sequential writes could be faster than multi-track sequential reads -- And it was possible to get special alerts indicating the backstore occupancy was getting too high. Joel C Ewing On 11/24/22 09:46, Paul Gorlinsky wrote: Switching from "real" 3380s & 3390s to the emulated 3380s & 3390s has been an evolutionary path. For example, with the P370 and its derivatives, each DASD unit was implemented as a single file on the hosting PC; AWSDISK. Hercules implemented the same file structure and later added a compressed version with track updates stored in a new file that could be later reorganized back into the base. I would guess that the DS8K boxes today got a lot smarter and implemented the track data or even track record data as separate objects managed by a volume TOC mechanism; which facilities all the DS8K enhancements of volume cloning, fast copy, check pointing, versioning, etc. "Sparse type" file systems are also more common today. So individual dataset space is not a big issue. You have to think at the enterprise level. However, the individual still needs to allocate their datasets correctly to satisfy the OS ... or for the zOS people, get an X37 abend processor... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Joel C. Ewing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Bytes in a 3390 track - reason for the question
The reason for asking the question about bytes on a track is that I am writing programs to report on all disk datasets. The first program looks at all on-line disk packs and extracts all format 1, 3, 8 and 9 DSCBs while also providing a summary of space available/used on each disk (similar to VTOC on CBT file 112). The second program produces information for all datasets. If the secondary allocation is in blocks then that means the primary was also and I want to output the allocation like this BLK(00060,00020). To do this I subtract the block size from 56664 repeatedly until the remainder is less than the block size which gives me the number of blocks in a track, multiply this by the primary allocation in tracks should give me the figure I want. Except it doesn't. For the format 1 DSCB below ISPF 3;4 reports BLK(00060,00020) and my program BLK(00072,00020). With a blocksize of 3120 there are 18 blocks per track and 4 tracks are in use. 3 of them must be full so that gives 54 blocks meaning there are only 6 on the final track. The dataset is not extended format, PDSE, HFS or VSAM so I think I need to look at DS1TRBAL, I subtracted 32266 from 56664 and worked out how many blocks would fit, I get 7 not 6. Alternatively, if I use 55996 I get 17 blocks per track meaning there are 9 on the last track and I get 7. I'm obviously missing something, and I am hoping someone can tell me what? DS1DSNAM DSN1.SRCLIB.DATA DS1FMTID 1 DS1DSSN DB2C06 DS1VOLSQ 0001 DS1CREDT 78003A DS1EXPDT 00 DS1NOEPV 01 DS1NOBDB 00 DS1FLAG1 00 DS1SYSCD IBMOSVS2 DS1REFD 7A0148 DS1SMSFG 80 DS1SCXTF 80 DS1SCXTV 0FA04000 DS1DSORG 0200 DS1RECFM 90 DS1OPTCD 00 DS1BLKL 0C30 DS1LRECL 0050 DS1KEYL 00 DS1RKP DS1DSIND 80 DS1SCAL1 50 DS1SCAL3 14 DS1LSTAR 15 DS1TRBAL 7E0A32266 DS1TTTHI 00 DS1EXT1 010C000B000C000E DS1EXT2 DS1EXT3 DS1PTRDS 00 Data Set Name . . . . : DSN1.SRCLIB.DATA General Data Current Allocation Management class . . :Allocated blocks . : 60 Storage class . . . :Allocated extents . : 1 Volume serial . . . : DB2C06 Maximum dir. blocks : 20 Device type . . . . : 3390 Data class . . . . . : Organization . . . : POCurrent Utilization Record format . . . : FB Used blocks . . . . : 7 Record length . . . : 80 Used extents . . . : 1 Block size . . . . : 3120 Used dir. blocks . : 1 1st extent blocks . : 60 Number of members . : 0 Secondary blocks . : 20 Data set name type : PDS Dates Data set encryption : NO Creation date . . . : 2020/02/27 Referenced date . . : 2022/11/24 Expiration date . . : ***None*** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bytes in a 3390 track
Switching from "real" 3380s & 3390s to the emulated 3380s & 3390s has been an evolutionary path. For example, with the P370 and its derivatives, each DASD unit was implemented as a single file on the hosting PC; AWSDISK. Hercules implemented the same file structure and later added a compressed version with track updates stored in a new file that could be later reorganized back into the base. I would guess that the DS8K boxes today got a lot smarter and implemented the track data or even track record data as separate objects managed by a volume TOC mechanism; which facilities all the DS8K enhancements of volume cloning, fast copy, check pointing, versioning, etc. "Sparse type" file systems are also more common today. So individual dataset space is not a big issue. You have to think at the enterprise level. However, the individual still needs to allocate their datasets correctly to satisfy the OS ... or for the zOS people, get an X37 abend processor... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bytes in a 3390 track
On 11/23/2022 5:19 PM, Mike Schwab wrote: Not sure when it changed (at least a decade ago), I think the mainframe reads and writes full tracks at a time anymore. In a modern DASD subsystem, all operations are full track: read, write or replicate. However, the mainframe itself (as defined by the IBM Z CPC running z/OS et al) does no such thing. There are DASD I/O opcodes that allow you to read or write a track at a time (for example RTD and WTD), but the use of such opcodes is by no means the norm. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bytes in a 3390 track
As a thought exercise... Is it possible to make zOS, storage controllers, etc. just lie to the requesting application. App or JCL DD: Give me space for 'x' records, with a blocksize of 'y', exactly! storage: Ok (but not really, I'll do what's best for myself!) I know it already lies/emulates to some extent (about 3390, track, cylinder, etc.).. is it not possible (and desirable) to do away with specifying things in terms of tracks & cylinders? There are products that change allocation real-time, in-line... can this be done at the storage controller level, while allowing some simplification in zOS? - KB --- Original Message --- On Thursday, November 24th, 2022 at 6:49 AM, Leonard D Woren wrote: > True. > > Yet... why is space still such a big deal on mainframes? I have > almost as much disk space connected to my primary PC as 10,000 3390-9 > would hold. > > Seeing a 3390 with 150,000 free cylinders does take some getting used to. > > It's time to use this brainpower for better things than optimizing the > arrangement of angels on a pinhead. Just throw more hardware at it > and move on. A 4 TB disk is the equivalent of almost 5,000,000 3390 > cylinders, or 500 3390-9s. How much DASD can you add in the disk > array for the price (salary) of one additional storage management person? > > /Leonard > > > Seymour J Metz wrote on 11/23/2022 3:20 PM: > > > With essentially all z DASD being cached these days, a lot of the > > efficiency issues no longer apply, leaving space as more dominant. > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > > > -- > 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
Re: Bytes in a 3390 track
DUCK YES, Sri, DUCK YES!. I am here for this excellent content. - KB --- Original Message --- On Thursday, November 24th, 2022 at 12:59 AM, Sri h Kolusu wrote: > > > How do I calculate the amount of space a dataset needs? > > > A 3390-n device has a capacity of 56,664 bytes per track, of which 55,996 > bytes are accessible by applications programmers. The largest blocksize you > can define is 32,760, which is good for tapes,but it is mere waste on DASD, > as 55,996 - 32760 = 23,236 bytes left over, and because tracks can't be > shared between other files, that leftover space would just be wasted. So, > 55,996/2 = 27,998, which is half-track blocking, the most space-efficient > blocksize to use on 3390's.If you have 3380 device types in your shop, the > maximum half-track blocksize is 23,476. > > To calculate the most efficient blocksize to use: Optimal blocksize = > INTEGER(half-track-blocksize/LRECL)*LRECL > > Assuming LRECL=500, so the optimal blocksize will be > > Integer(27,998/500) is 55 > > 55 multiplied by lrecl(500) gives you 27500 which is the optimum blksize. > > On a 3390, the best blocksize for a QSAM (Queued Sequential Access Mode) file > of record length 500 is 27,500.This will allow 55 records per block, or 110 > records per track, or 1650 records per cylinder (cylinders are 15 tracks). > > Assuming your volume of records e is 10,000, you can fit that data in less > than 7 cylinders(10,000/1650 = 6.06 rounded to 7) > > We allocate the primary space as 7 cylinders. Now the secondary space > allocation is 20% of primary space which in this case is 7 * 0.2 = 1.4 > rounded to 2 > > So, your space allocation for a dataset of lrecl 500 and a volume of 10,000 > records would be > > SPACE=(CYL,(7,2),RLSE) > > Thanks, > Kolusu > > > -- > 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
Re: Bytes in a 3390 track
Thats why we have storage groups, 64K cyl volumes with 56GB, and EAV volumes up to 1TB so far, 220TB possible but not implemented.. On Wed, Nov 23, 2022 at 7:20 PM Leonard D Woren wrote: > > True. > > Yet... why is space still such a big deal on mainframes? I have > almost as much disk space connected to my primary PC as 10,000 3390-9 > would hold. > > Seeing a 3390 with 150,000 free cylinders does take some getting used to. > > It's time to use this brainpower for better things than optimizing the > arrangement of angels on a pinhead. Just throw more hardware at it > and move on. A 4 TB disk is the equivalent of almost 5,000,000 3390 > cylinders, or 500 3390-9s. How much DASD can you add in the disk > array for the price (salary) of one additional storage management person? > > /Leonard > > > Seymour J Metz wrote on 11/23/2022 3:20 PM: > > With essentially all z DASD being cached these days, a lot of the > > efficiency issues no longer apply, leaving space as more dominant. > > > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > > > > -- > 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
Re: Bytes in a 3390 track
On Wed, 23 Nov 2022 17:19:40 -0800, Leonard D Woren wrote: >True. > >Yet... why is space still such a big deal on mainframes? I have >almost as much disk space connected to my primary PC as 10,000 3390-9 >would hold. > >Seeing a 3390 with 150,000 free cylinders does take some getting used to. > >It's time to use this brainpower for better things than optimizing the >arrangement of angels on a pinhead. Just throw more hardware at it >and move on. A 4 TB disk is the equivalent of almost 5,000,000 3390 >cylinders, or 500 3390-9s. How much DASD can you add in the disk >array for the price (salary) of one additional storage management person? > >/Leonard > > >Seyuour J Metz wrote on 11/23/2022 3:20 PM: >> With essentially all z DASD being cached these days, a lot of the efficiency >> issues no longer apply, leaving space as more dominant. >> >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 Reminds me of an ad in a printed magazine many years ago, (yes that long ago :-)> ). A management type person is in the ad saying: "Yes, I know that disk space is cheap. Let me know when it's free!" Still true today. -- Dale R. Smith -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bytes in a 3390 track
On Wed, 23 Nov 2022 at 20:20, Mike Schwab wrote: > Not sure when it changed (at least a decade ago), I think the > mainframe reads and writes full tracks at a time anymore. > Positive anymore! Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bytes in a 3390 track
Not sure when it changed (at least a decade ago), I think the mainframe reads and writes full tracks at a time anymore. On Wed, Nov 23, 2022 at 7:01 PM Michael Oujesky wrote: > > Actually, if you are doing sequential processing, zEDC is perhaps the > best as it "write"s full-tracks, regardless of the BLKSIZE > specified. With zEDC, the BLKSIZE is just the size of data passed > to/from the application and no longer the physical data "written" to disk. > > Michael > > At 12:14 PM 11/23/2022, Mike Schwab wrote: > > >If you are doing sequential reads and writes, half track is the best > >you can do. If you are random reading small records, I.E. 80 byte, > >400 bytes, 2000 bytes; then smaller blocks lead to less I/O per > >record, since you aren't using most of the data read, and the larger > >the block the less you use. VSAM use a 4K physical record unless > >you specify a very large CI size. > > > >On Wed, Nov 23, 2022 at 11:56 AM Paul Gorlinsky > >wrote: > > > > > > Short block more efficient? Elaborate please. Space utilization > > and efficient are not necessarily the same. Latency issues vary a > > lot depending on the exact box being used for DASD. DS6K v DS8K. > > DS8K with rotating v solid-state ... > > > > > > QSAM v BPAM v BSAM v etc... > > > > > > General guidelines ... > > > > > > -- > > > 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 -- 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
Re: Bytes in a 3390 track
True. Yet... why is space still such a big deal on mainframes? I have almost as much disk space connected to my primary PC as 10,000 3390-9 would hold. Seeing a 3390 with 150,000 free cylinders does take some getting used to. It's time to use this brainpower for better things than optimizing the arrangement of angels on a pinhead. Just throw more hardware at it and move on. A 4 TB disk is the equivalent of almost 5,000,000 3390 cylinders, or 500 3390-9s. How much DASD can you add in the disk array for the price (salary) of one additional storage management person? /Leonard Seymour J Metz wrote on 11/23/2022 3:20 PM: With essentially all z DASD being cached these days, a lot of the efficiency issues no longer apply, leaving space as more dominant. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bytes in a 3390 track
Actually, if you are doing sequential processing, zEDC is perhaps the best as it "write"s full-tracks, regardless of the BLKSIZE specified. With zEDC, the BLKSIZE is just the size of data passed to/from the application and no longer the physical data "written" to disk. Michael At 12:14 PM 11/23/2022, Mike Schwab wrote: If you are doing sequential reads and writes, half track is the best you can do. If you are random reading small records, I.E. 80 byte, 400 bytes, 2000 bytes; then smaller blocks lead to less I/O per record, since you aren't using most of the data read, and the larger the block the less you use. VSAM use a 4K physical record unless you specify a very large CI size. On Wed, Nov 23, 2022 at 11:56 AM Paul Gorlinsky wrote: > > Short block more efficient? Elaborate please. Space utilization and efficient are not necessarily the same. Latency issues vary a lot depending on the exact box being used for DASD. DS6K v DS8K. DS8K with rotating v solid-state ... > > QSAM v BPAM v BSAM v etc... > > General guidelines ... > > -- > 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
Re: Bytes in a 3390 track
Long ago I had a theory regarding blksize=32K load module libraries that I could demonstrate on paper but never attempted to demonstrate for real due to the amount of work involved. Consider that the linkage editor writes however much program text as fits on the rest of the track. IEBCOPY to a new data set copies members in membername order, not physical order from the original data set. It is theoretically possible to construct a degenerate case where due to the above, the IEBCOPY'd data set will actually take _more_ space than the original! You could have two members originally linked to different areas of the original PDS, decently utilizing 32K blocks. Now you IEBCOPY the data set and those two members end up one following one another in the target, and the second member's 32K block doesn't fit after the first member's 32K block, and the short noise blocks in load modules come nowhere close to using up that space. So in certain degenerate cases, you could waste maybe 1/3 of the space when IEBCOPYing a blksize=32K load module library. I suspect that some number a bit below half track is optimum to allow for the small overhead blocks plus 2 long text blocks. OTOH, why isn't everybody using PDSEs instead of wasting brain power on this? /Leonard Mike Schwab wrote on 11/23/2022 10:22 AM: [...] 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 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 on behalf of Paul Gorlinsky 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
Re: [EXTERNAL] Re: Bytes in a 3390 track
On 11/23/2022 12:31 PM, Pommier, Rex wrote: Hi Tom, yes and no. :-) No, it isn't true on the physical back end because all the disk is emulated on top of FBA architectures and especially with thin provisioning, only actually used tracks are really used. However, from a z/OS perspective yes the space is still wasted because it is still allocated in cylinders and tracks, and from a z/OS point of view if I have BLKSIZE=32760 RECFM=FB, z/OS can't do anything with the remaining space. I think even with thin provisioning, the backing is at the extent level (usually 21 cylinders). What happens or doesn't happen at the end of a track changes nothing... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bytes in a 3390 track
With essentially all z DASD being cached these days, a lot of the efficiency issues no longer apply, leaving space as more dominant. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gorlinsky [p...@atsmigrations.com] Sent: Wednesday, November 23, 2022 12:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Bytes in a 3390 track Short block more efficient? Elaborate please. Space utilization and efficient are not necessarily the same. Latency issues vary a lot depending on the exact box being used for DASD. DS6K v DS8K. DS8K with rotating v solid-state ... QSAM v BPAM v BSAM v etc... General guidelines ... -- 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
Re: Bytes in a 3390 track
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 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 on behalf of > Paul Gorlinsky > 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
Re: Bytes in a 3390 track
The space calculations are in terms of the virtual 3390 presented to the channel, and haven't changed since Old Man Noach cornered the market in Gopher wood. How the underlying hardware deals with it depnds on the box. In general, half track is most efficient except for load modules, where short blocks can pad out the track. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tom Brennan [t...@tombrennansoftware.com] Sent: Wednesday, November 23, 2022 3:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Bytes in a 3390 track > but it is mere waste on DASD, as 55,996 - 32760 = 23,236 bytes left > over, and because tracks can't be shared between other files Great overview, but is the note above still true with modern DS8000 boxes? It's just hard for me to imagine 3390 emulation logic holding that 23K hostage. On 11/23/2022 11:29 AM, Sri h Kolusu wrote: >>> How do I calculate the amount of space a dataset needs? > > A 3390-n device has a capacity of 56,664 bytes per track, of which 55,996 > bytes are accessible by applications programmers. The largest blocksize you > can define is 32,760, which is good for tapes,but it is mere waste on DASD, > as 55,996 - 32760 = 23,236 bytes left over, and because tracks can't be > shared between other files, that leftover space would just be wasted. So, > 55,996/2 = 27,998, which is half-track blocking, the most space-efficient > blocksize to use on 3390's.If you have 3380 device types in your shop, the > maximum half-track blocksize is 23,476. > > To calculate the most efficient blocksize to use: Optimal blocksize = > INTEGER(half-track-blocksize/LRECL)*LRECL > > Assuming LRECL=500, so the optimal blocksize will be > > Integer(27,998/500) is 55 > > 55 multiplied by lrecl(500) gives you 27500 which is the optimum blksize. > > On a 3390, the best blocksize for a QSAM (Queued Sequential Access Mode) file > of record length 500 is 27,500.This will allow 55 records per block, or 110 > records per track, or 1650 records per cylinder (cylinders are 15 tracks). > > Assuming your volume of records e is 10,000, you can fit that data in less > than 7 cylinders(10,000/1650 = 6.06 rounded to 7) > > We allocate the primary space as 7 cylinders. Now the secondary space > allocation is 20% of primary space which in this case is 7 * 0.2 = 1.4 > rounded to 2 > > So, your space allocation for a dataset of lrecl 500 and a volume of 10,000 > records would be > > SPACE=(CYL,(7,2),RLSE) > > Thanks, > Kolusu > > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: Bytes in a 3390 track
If the application uses TRUNC appropriately then you can still fill the track. Normally, however, a 32K block size on DASD is only used for load modules, which have RECFM=U. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Pommier, Rex [rpomm...@sfgmembers.com] Sent: Wednesday, November 23, 2022 3:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: Bytes in a 3390 track Hi Tom, yes and no. :-) No, it isn't true on the physical back end because all the disk is emulated on top of FBA architectures and especially with thin provisioning, only actually used tracks are really used. However, from a z/OS perspective yes the space is still wasted because it is still allocated in cylinders and tracks, and from a z/OS point of view if I have BLKSIZE=32760 RECFM=FB, z/OS can't do anything with the remaining space. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: Wednesday, November 23, 2022 2:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Bytes in a 3390 track > but it is mere waste on DASD, as 55,996 - 32760 = 23,236 bytes left > over, > and because tracks can't be shared between other files Great overview, but is the note above still true with modern DS8000 boxes? It's just hard for me to imagine 3390 emulation logic holding that 23K hostage. On 11/23/2022 11:29 AM, Sri h Kolusu wrote: >>> How do I calculate the amount of space a dataset needs? > > A 3390-n device has a capacity of 56,664 bytes per track, of which 55,996 > bytes are accessible by applications programmers. The largest blocksize you > can define is 32,760, which is good for tapes,but it is mere waste on DASD, > as 55,996 - 32760 = 23,236 bytes left over, and because tracks can't be > shared between other files, that leftover space would just be wasted. So, > 55,996/2 = 27,998, which is half-track blocking, the most space-efficient > blocksize to use on 3390's.If you have 3380 device types in your shop, the > maximum half-track blocksize is 23,476. > > To calculate the most efficient blocksize to use: Optimal blocksize = > INTEGER(half-track-blocksize/LRECL)*LRECL > > Assuming LRECL=500, so the optimal blocksize will be > > Integer(27,998/500) is 55 > > 55 multiplied by lrecl(500) gives you 27500 which is the optimum blksize. > > On a 3390, the best blocksize for a QSAM (Queued Sequential Access Mode) file > of record length 500 is 27,500.This will allow 55 records per block, or 110 > records per track, or 1650 records per cylinder (cylinders are 15 tracks). > > Assuming your volume of records e is 10,000, you can fit that data in > less than 7 cylinders(10,000/1650 = 6.06 rounded to 7) > > We allocate the primary space as 7 cylinders. Now the secondary space > allocation is 20% of primary space which in this case is 7 * 0.2 = 1.4 > rounded to 2 > > So, your space allocation for a dataset of lrecl 500 and a volume of > 10,000 records would be > > SPACE=(CYL,(7,2),RLSE) > > Thanks, > Kolusu > > > -- > 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 -- The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- 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
Re: [EXTERNAL] Re: Bytes in a 3390 track
Thanks! That clears things up. On 11/23/2022 12:31 PM, Pommier, Rex wrote: Hi Tom, yes and no. :-) No, it isn't true on the physical back end because all the disk is emulated on top of FBA architectures and especially with thin provisioning, only actually used tracks are really used. However, from a z/OS perspective yes the space is still wasted because it is still allocated in cylinders and tracks, and from a z/OS point of view if I have BLKSIZE=32760 RECFM=FB, z/OS can't do anything with the remaining space. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: Wednesday, November 23, 2022 2:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Bytes in a 3390 track > but it is mere waste on DASD, as 55,996 - 32760 = 23,236 bytes left > over, and because tracks can't be shared between other files Great overview, but is the note above still true with modern DS8000 boxes? It's just hard for me to imagine 3390 emulation logic holding that 23K hostage. On 11/23/2022 11:29 AM, Sri h Kolusu wrote: How do I calculate the amount of space a dataset needs? A 3390-n device has a capacity of 56,664 bytes per track, of which 55,996 bytes are accessible by applications programmers. The largest blocksize you can define is 32,760, which is good for tapes,but it is mere waste on DASD, as 55,996 - 32760 = 23,236 bytes left over, and because tracks can't be shared between other files, that leftover space would just be wasted. So, 55,996/2 = 27,998, which is half-track blocking, the most space-efficient blocksize to use on 3390's.If you have 3380 device types in your shop, the maximum half-track blocksize is 23,476. To calculate the most efficient blocksize to use: Optimal blocksize = INTEGER(half-track-blocksize/LRECL)*LRECL Assuming LRECL=500, so the optimal blocksize will be Integer(27,998/500) is 55 55 multiplied by lrecl(500) gives you 27500 which is the optimum blksize. On a 3390, the best blocksize for a QSAM (Queued Sequential Access Mode) file of record length 500 is 27,500.This will allow 55 records per block, or 110 records per track, or 1650 records per cylinder (cylinders are 15 tracks). Assuming your volume of records e is 10,000, you can fit that data in less than 7 cylinders(10,000/1650 = 6.06 rounded to 7) We allocate the primary space as 7 cylinders. Now the secondary space allocation is 20% of primary space which in this case is 7 * 0.2 = 1.4 rounded to 2 So, your space allocation for a dataset of lrecl 500 and a volume of 10,000 records would be SPACE=(CYL,(7,2),RLSE) Thanks, Kolusu -- 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 -- The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- 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
Re: Bytes in a 3390 track
>> Great overview, but is the note above still true with modern DS8000 boxes? >> It's just hard for me to imagine 3390 emulation logic holding that 23K >> hostage. Tom, As other have mentioned on z/OS it is still valid. Run this JCL and look at the allocation . I used the example of LRECL=500 and optimal blocksize =27500 and max blocksize could be 32500 //STEP0100 EXEC PGM=SORT //SYSOUT DD SYSOUT=* //SORTIN DD * ABC //B27500 DD DSN=, //DISP=(NEW,CATLG,DELETE), //SPACE=(CYL,(7,2),RLSE) //B32500 DD DSN=, //DISP=(NEW,CATLG,DELETE), //SPACE=(CYL,(7,2),RLSE),BLKSIZE=32500 //SYSINDD * OPTION COPY OUTFIL FNAMES=B27500,REPEAT=1,BUILD=(500C'A') OUTFIL FNAMES=B32500,REPEAT=1,BUILD=(500C'B') /* The result is --- Command - Enter "/" to select actionTracks %Used XT --- KOLUSU.CREATE.BLKSIZE.OF27500 105 86 1 KOLUSU.CREATE.BLKSIZE.OF32500 165 93 3 Thanks, Kolusu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bytes in a 3390 track
On Wed, 23 Nov 2022 at 15:17, Tom Brennan wrote: > > but it is mere waste on DASD, as 55,996 - 32760 = 23,236 bytes left > > over, and because tracks can't be shared between other files > > Great overview, but is the note above still true with modern DS8000 > boxes? It's just hard for me to imagine 3390 emulation logic holding > that 23K hostage. > Yes and no. Doubtless at the storage box level that space is not wasted. The box will surely take advantage of what it knows about unused 3390 track space to gain efficiencies in space and time for backups, copies, compression, and so on. But z/OS knows nothing about any of that, and the space is still unusable at the architected 3390 level. So your allocation will fill up when the 3390 space, however virtual it may be in reality, is full. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: Bytes in a 3390 track
Hi Tom, yes and no. :-) No, it isn't true on the physical back end because all the disk is emulated on top of FBA architectures and especially with thin provisioning, only actually used tracks are really used. However, from a z/OS perspective yes the space is still wasted because it is still allocated in cylinders and tracks, and from a z/OS point of view if I have BLKSIZE=32760 RECFM=FB, z/OS can't do anything with the remaining space. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: Wednesday, November 23, 2022 2:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Bytes in a 3390 track > but it is mere waste on DASD, as 55,996 - 32760 = 23,236 bytes left > over, > and because tracks can't be shared between other files Great overview, but is the note above still true with modern DS8000 boxes? It's just hard for me to imagine 3390 emulation logic holding that 23K hostage. On 11/23/2022 11:29 AM, Sri h Kolusu wrote: >>> How do I calculate the amount of space a dataset needs? > > A 3390-n device has a capacity of 56,664 bytes per track, of which 55,996 > bytes are accessible by applications programmers. The largest blocksize you > can define is 32,760, which is good for tapes,but it is mere waste on DASD, > as 55,996 - 32760 = 23,236 bytes left over, and because tracks can't be > shared between other files, that leftover space would just be wasted. So, > 55,996/2 = 27,998, which is half-track blocking, the most space-efficient > blocksize to use on 3390's.If you have 3380 device types in your shop, the > maximum half-track blocksize is 23,476. > > To calculate the most efficient blocksize to use: Optimal blocksize = > INTEGER(half-track-blocksize/LRECL)*LRECL > > Assuming LRECL=500, so the optimal blocksize will be > > Integer(27,998/500) is 55 > > 55 multiplied by lrecl(500) gives you 27500 which is the optimum blksize. > > On a 3390, the best blocksize for a QSAM (Queued Sequential Access Mode) file > of record length 500 is 27,500.This will allow 55 records per block, or 110 > records per track, or 1650 records per cylinder (cylinders are 15 tracks). > > Assuming your volume of records e is 10,000, you can fit that data in > less than 7 cylinders(10,000/1650 = 6.06 rounded to 7) > > We allocate the primary space as 7 cylinders. Now the secondary space > allocation is 20% of primary space which in this case is 7 * 0.2 = 1.4 > rounded to 2 > > So, your space allocation for a dataset of lrecl 500 and a volume of > 10,000 records would be > > SPACE=(CYL,(7,2),RLSE) > > Thanks, > Kolusu > > > -- > 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 -- The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bytes in a 3390 track
> but it is mere waste on DASD, as 55,996 - 32760 = 23,236 bytes left > over, and because tracks can't be shared between other files Great overview, but is the note above still true with modern DS8000 boxes? It's just hard for me to imagine 3390 emulation logic holding that 23K hostage. On 11/23/2022 11:29 AM, Sri h Kolusu wrote: How do I calculate the amount of space a dataset needs? A 3390-n device has a capacity of 56,664 bytes per track, of which 55,996 bytes are accessible by applications programmers. The largest blocksize you can define is 32,760, which is good for tapes,but it is mere waste on DASD, as 55,996 - 32760 = 23,236 bytes left over, and because tracks can't be shared between other files, that leftover space would just be wasted. So, 55,996/2 = 27,998, which is half-track blocking, the most space-efficient blocksize to use on 3390's.If you have 3380 device types in your shop, the maximum half-track blocksize is 23,476. To calculate the most efficient blocksize to use: Optimal blocksize = INTEGER(half-track-blocksize/LRECL)*LRECL Assuming LRECL=500, so the optimal blocksize will be Integer(27,998/500) is 55 55 multiplied by lrecl(500) gives you 27500 which is the optimum blksize. On a 3390, the best blocksize for a QSAM (Queued Sequential Access Mode) file of record length 500 is 27,500.This will allow 55 records per block, or 110 records per track, or 1650 records per cylinder (cylinders are 15 tracks). Assuming your volume of records e is 10,000, you can fit that data in less than 7 cylinders(10,000/1650 = 6.06 rounded to 7) We allocate the primary space as 7 cylinders. Now the secondary space allocation is 20% of primary space which in this case is 7 * 0.2 = 1.4 rounded to 2 So, your space allocation for a dataset of lrecl 500 and a volume of 10,000 records would be SPACE=(CYL,(7,2),RLSE) Thanks, Kolusu -- 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
Re: Bytes in a 3390 track
Or just code: SPACE=(500,(10,2),RLSE), AVGREC=K and let the system calculate how many tracks it needs. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Sri h Kolusu Sent: Wednesday, November 23, 2022 1:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Bytes in a 3390 track >> How do I calculate the amount of space a dataset needs? A 3390-n device has a capacity of 56,664 bytes per track, of which 55,996 bytes are accessible by applications programmers. The largest blocksize you can define is 32,760, which is good for tapes,but it is mere waste on DASD, as 55,996 - 32760 = 23,236 bytes left over, and because tracks can't be shared between other files, that leftover space would just be wasted. So, 55,996/2 = 27,998, which is half-track blocking, the most space-efficient blocksize to use on 3390's.If you have 3380 device types in your shop, the maximum half-track blocksize is 23,476. To calculate the most efficient blocksize to use: Optimal blocksize = INTEGER(half-track-blocksize/LRECL)*LRECL Assuming LRECL=500, so the optimal blocksize will be Integer(27,998/500) is 55 55 multiplied by lrecl(500) gives you 27500 which is the optimum blksize. On a 3390, the best blocksize for a QSAM (Queued Sequential Access Mode) file of record length 500 is 27,500.This will allow 55 records per block, or 110 records per track, or 1650 records per cylinder (cylinders are 15 tracks). Assuming your volume of records e is 10,000, you can fit that data in less than 7 cylinders(10,000/1650 = 6.06 rounded to 7) We allocate the primary space as 7 cylinders. Now the secondary space allocation is 20% of primary space which in this case is 7 * 0.2 = 1.4 rounded to 2 So, your space allocation for a dataset of lrecl 500 and a volume of 10,000 records would be SPACE=(CYL,(7,2),RLSE) Thanks, Kolusu -- 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
Re: Bytes in a 3390 track
>> How do I calculate the amount of space a dataset needs? A 3390-n device has a capacity of 56,664 bytes per track, of which 55,996 bytes are accessible by applications programmers. The largest blocksize you can define is 32,760, which is good for tapes,but it is mere waste on DASD, as 55,996 - 32760 = 23,236 bytes left over, and because tracks can't be shared between other files, that leftover space would just be wasted. So, 55,996/2 = 27,998, which is half-track blocking, the most space-efficient blocksize to use on 3390's.If you have 3380 device types in your shop, the maximum half-track blocksize is 23,476. To calculate the most efficient blocksize to use: Optimal blocksize = INTEGER(half-track-blocksize/LRECL)*LRECL Assuming LRECL=500, so the optimal blocksize will be Integer(27,998/500) is 55 55 multiplied by lrecl(500) gives you 27500 which is the optimum blksize. On a 3390, the best blocksize for a QSAM (Queued Sequential Access Mode) file of record length 500 is 27,500.This will allow 55 records per block, or 110 records per track, or 1650 records per cylinder (cylinders are 15 tracks). Assuming your volume of records e is 10,000, you can fit that data in less than 7 cylinders(10,000/1650 = 6.06 rounded to 7) We allocate the primary space as 7 cylinders. Now the secondary space allocation is 20% of primary space which in this case is 7 * 0.2 = 1.4 rounded to 2 So, your space allocation for a dataset of lrecl 500 and a volume of 10,000 records would be SPACE=(CYL,(7,2),RLSE) Thanks, Kolusu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bytes in a 3390 track
Multiply record size by number of records to calculate size. Divide by 50,000 for number of tracks, or divide by 800,000 for a firm estimate to 500,000 for a rough estimate for number of cylinders. If you won't need additional space, code RLSE to release unused cylinders / tracks. On Wed, Nov 23, 2022 at 12:31 PM Paul Gorlinsky wrote: > > Needless to say... it really depends on the question that is being asked. > > How do I calculate the amount of space a dataset needs? > > Don't use IBM's 56664 track space number for anything but a sales thing? > > The 3390 DASD under normal use, do not have 56664 bytes per track available. > > -- > 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
Re: Bytes in a 3390 track
Needless to say... it really depends on the question that is being asked. How do I calculate the amount of space a dataset needs? Don't use IBM's 56664 track space number for anything but a sales thing? The 3390 DASD under normal use, do not have 56664 bytes per track available. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 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 on behalf of > Paul Gorlinsky > 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
Re: Bytes in a 3390 track
If you are doing sequential reads and writes, half track is the best you can do. If you are random reading small records, I.E. 80 byte, 400 bytes, 2000 bytes; then smaller blocks lead to less I/O per record, since you aren't using most of the data read, and the larger the block the less you use. VSAM use a 4K physical record unless you specify a very large CI size. On Wed, Nov 23, 2022 at 11:56 AM Paul Gorlinsky wrote: > > Short block more efficient? Elaborate please. Space utilization and efficient > are not necessarily the same. Latency issues vary a lot depending on the > exact box being used for DASD. DS6K v DS8K. DS8K with rotating v solid-state > ... > > QSAM v BPAM v BSAM v etc... > > General guidelines ... > > -- > 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
Re: Bytes in a 3390 track
Short block more efficient? Elaborate please. Space utilization and efficient are not necessarily the same. Latency issues vary a lot depending on the exact box being used for DASD. DS6K v DS8K. DS8K with rotating v solid-state ... QSAM v BPAM v BSAM v etc... General guidelines ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bytes in a 3390 track
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 on behalf of Paul Gorlinsky 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
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
Re: Bytes in a 3390 track
Thank you very much for that comprehensive explanation. John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bytes in a 3390 track
See page 10 of the 3390 Reference Summary, manual GX26-4577, which can be found online. The physical records per track calculation is complex because the physical space (or emulated space) is divided into 1729 cells of 34 bytes each (the source of the 58,786 value), allocation is in by cells, is separately allocated for Count, Key and Data (CKD) portions of each physical record, and includes cells between records and the parts of records. The physical space taken by the entire record depends on the Key Length KL (possibly 0) and the Record Length (RL). The number of cells required for a physical records is given by C + K + D, where C= 10 If KL =0, then K = 0; otherwise K = 9 + ceil( (KL + (6 x ceil( (KL + 6)/232 ) + 6) / 34 ) D = 9 + ceil( (DL + (6 x ceil( (DL + 6)/232 ) + 6) / 34 ) where ceil ( x) rounds x upward to an integer value if x is not an integer. The 1729 max cells already excludes space for a standard R0 record, which appears to occupy 20 additional cells on each track. Maximum usable bytes per track occurs when a single record is written per track with no Key field. The above formula limits the max size of that record to 56,664 bytes, which is the origin of that value. Standard I/O places a limitation of 32 KiB on the size of a record, which means the maximum usable capacity with those access methods is 2 physical records per track. The above formulas limit the max record size for 2 records per track to 27,998 or 55,996 usable bytes per track. That's where your third value comes from. Joel C. Ewing On 11/23/22 07:42, John Gateley wrote: Hello On all the disk volumes I have looked at, the format 4 DSCB field DS4DEVTK (device track length) has the value 58786. All the IBM documentation says that there are 56664 bytes in a track on a 3390 drive. At this link https://www.lascon.co.uk/hwd-3390-disks.php reference is made to 55996 usable bytes out of 56664 per track. Is there some 'magic' formula that converts the value in DS4DEVTK to either 56664 or 55996, or should I just ignore DS4DEVTK? Thanks John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Joel C. Ewing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bytes in a 3390 track
Thanks Steve. I did not know about the standard record 0, now that I do it makes sense. John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bytes in a 3390 track
58786 is the number of bytes available on the raw track. 56664 is what's left after the standard Record 0, which is present on every track of a volume formatted for z/OS use. I don't know about other OSes, and I don't recall seeing the 55996 figure before. The old 3390 Reference Summary is available on bitsavers, and maybe some more complete documentation. sas On Wed, Nov 23, 2022 at 7:42 AM John Gateley wrote: > Hello > > On all the disk volumes I have looked at, the format 4 DSCB field DS4DEVTK > (device track length) has the value 58786. > All the IBM documentation says that there are 56664 bytes in a track on a > 3390 drive. > At this link https://www.lascon.co.uk/hwd-3390-disks.php reference is > made to 55996 usable bytes out of 56664 per track. > > Is there some 'magic' formula that converts the value in DS4DEVTK to > either 56664 or 55996, or should I just ignore DS4DEVTK? > > Thanks > John > > -- > 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
Bytes in a 3390 track
Hello On all the disk volumes I have looked at, the format 4 DSCB field DS4DEVTK (device track length) has the value 58786. All the IBM documentation says that there are 56664 bytes in a track on a 3390 drive. At this link https://www.lascon.co.uk/hwd-3390-disks.php reference is made to 55996 usable bytes out of 56664 per track. Is there some 'magic' formula that converts the value in DS4DEVTK to either 56664 or 55996, or should I just ignore DS4DEVTK? Thanks John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
