MVS TOOLS AND TRICKS OF THE TRADE October 1990 Sam Golob MVS Systems Programmer sbgolob@cbttape.org MAPXA AND BLKDISK: TWO USEFUL TSO COMMANDS This month, I'd like to start with a quote from one of the MVS "heavies" of all time (until the present). Howard Gilbert, who usually works at Yale University, also gives an excellent week-long course on MVS internals. Anyone who has the remotest chance of being able to take Howard's course (which is managed by CSR of Avon, CT) should jump at it. He's tremendously knowledgeable, and he's a good speaker besides. Howard starts his course with an "inspired" statement. Anyone with any experience will not doubt how amazingly true this statement is. It's so true, that people in our business forget that it's probably the single most important statement to know, for anyone dealing with the MVS Operating System (and perhaps other IBM operating systems). Howard's statement is the following: "It is impossible to understand the MVS Operating System through logic. IBM started with the designing of the OS/360 Operating Systems, and proceeded with the maxim of: 'If it ain't broke, don't fix it.' IBM people would only rewrite code that it was deemed necessary to rewrite. Thus, the development of MVS has been an EVOLUTIONARY PROCESS, and the only way one can really understand MVS is through a knowledge of its HISTORY. So why is IBM is driven to change things? MAINLY BY THE NEEDS OF ITS BIGGEST CUSTOMERS." See why Howard's course is so good? Just try and find an IBMer who'll come out and say that! IBM people seem usually constrained to be talking about ONLY WHAT THE COMPANY IS SELLING NOW. The problem is that "an adequate understanding of what's now" only comes from "an understanding of what was". That's why I feel that "the fifteen year plus" people have an extra jump on everyone else in this business, and everybody else had better make it their business to have long conversations with those folks. (Also, SAVE OLD MANUALS!) Our current topic will thus be more personal in format than most. It will deal with two useful TSO commands that were written by two "old timers" who are my close friends. I have gained a tremendous amount of "MVS facts and lore" from both of these people, much of which comes out to all of you when it's appropriate for the current topic. Jeff Broido's "MAPXA" and "MAPSP" commands map the overall layout of virtual storage in XA and non-XA MVS systems, respectively. Bruce Leland's "BLKDISK" program, which is also known by its aliases, "BLK3350", "BLK3380", "BLK3375", and now "BLK3390", helps the user effortlessly calculate efficient blocking factors for disk space utilization. I'll explain and illustrate these programs as this month's topic. MAPXA. I well remember when MAPXA was written. Jeff and I were working as systems programmers for a big bank in New York. When XA first came out, our shop (a large one) was one of the earlier shops to convert to it. We had three 3081's then, and XA was brought up on one machine on December 31, 1983 (to save on taxes. Sound familiar?) Production was first run on that machine about two weeks later. The XA machine ran in a JES3 complex as a local, together with the other two machines which ran MVS/370 in parallel for several more months, until all the user software could be cut over. We were having some mysterious problems with VSAM GETMAINs (minus corresponding FREEMAINs) filling up CSA at that time. Sometimes we had to IPL twice a day because of the condition. Jeff, consulting as a "resident expert", had to diagnose the cause of this problem as one of his duties. Jeff was brand new to XA then, but he is "long in his knowledge of history", and he is an extremely fast and avid learner. Jeff said that he "picked up XA coding differences from the conversion notebook in an hour on the train", going home from work one day. In the process of charting what was happening in CSA, Jeff decided that it'd be fun and useful to map all of XA virtual storage out. He wrote his MAPXA program completely from scratch, helped only by the IBM manuals on XA coding and structure, and by his previous system 370 and 360 coding experience. Within a week after the one XA machine was in production, on January 24, 1984, Jeff had MAPXA up and working. I have heard from many friends and acquaintances that they are grateful to be able to use MAPXA on their current systems till today. MAPXA (and MAPSP) can be found with a collection of Jeff's other programs, on File 423 of the CBT MVS Tape. It has been on the CBT tape since version 249, dated July 5, 1985, with no subsequent revisions. After having successfully written MAPXA, Jeff wrote a non-XA mapping command called "MAPSP", so that we could have a corresponding look at the virtual storage configuration in our two non-XA machines. Now please look at Figure One to see the output of the MAPXA TSO command. Notice first that virtual storage under XA is divided into two areas which generally "mirror" each other. The "reflection point" is the 16-megabyte address location which is denoted by HEX '00FFFFFF', the upper limit of 24-bit addressing. Jeff has cutely referred to this important point of demarcation as "THE LINE". (This is familiar to most of us, but I'm including some talk about it for completeness. I'll go on a little more about the topic, so everyone can be involved in the discussions that follow.) We must discuss "extended byte addressing" itself, and also idea of "which system areas occupy which addresses"--both under XA, and under old MVS/370 non-XA systems. First, we shall cover the concept of: "What is extended byte addressing?" "Addressing" refers to virtual storage byte locations within computer storage. There are virtual "byte addresses" that are numbered (in hexadecimal) from zero upward. Before the "extended addressing" made possible by XA (extended architecture), the upper limit of addressable virtual storage was 16 megabytes, since the 370-type hardware was incapable of using address locations larger than this. At the time that OS/360 architecture was new, the quantity of 16 megabytes of processor storage was deemed impossibly large. Even though the general purpose registers (which held the address quantities) were four bytes (or 32 bits) in length, and capable of holding many more addressing locations, the low order three bytes were then deemed to have enough addressing room for anyone's programs and data. The high-order byte of the general purpose registers was used by programs for storage of flags, and for other things besides virtual storage addressing locations. Three bytes of hexadecimal numbers contain 24 bits, which in turn can represent 16 megabytes of different address numbers. Under pressure from its largest users (remember Howard Gilbert's maxim), IBM was forced around 1980, to start redesigning its 370 system hardware to use 31 bits of the registers as byte addresses. This would then allow addressing locations of greater than 16 megabytes in the registers. Problem was, that many programs then (and still) running, depended on using the high-order byte of general purpose registers for flag bits and for other types of data. IBM, following the other part of "Howard's rule" (not rewriting old code unless necessary) was forced to design a "dual mode of execution". This would allow old programs to run "the old way", treating addresses as being 24-bits long. It would also allow new programs to run "the new way", treating addresses as being 31-bits long, as defined by its new "extended" architecture. So, according to this evolutionary principle, we were stuck with two ways of running programs on IBM hardware. These are AMODE 24 (24-bit addressing), AMODE 31 (31-bit addressing) and also AMODE ANY (the program does its own switching of modes, so it doesn't matter how it started executing). Programs and data using storage addresses of less than 16 megabytes ONLY, are said to RUN BELOW THE LINE. Programs which are written to use larger addresses also, are said to RUN ABOVE THE LINE. SYSTEM ROUTINES as well as USER ROUTINES can be written to run either way. Please just notice, that STORAGE BELOW THE LINE IS PRECIOUS. There isn't that much of it. We need this storage to run old-style programs, and also CCWs (channel command words) that are used to do I/O to peripheral devices. IBM has been writing much of its system code to run above the line lately. This frees up storage that is below the line for private use by user programs. Storage that is available BELOW THE LINE for private programs to use, is said to be "THE PRIVATE REGION". Storage ABOVE THE LINE for private programs to use, is said to be "EXTENDED PRIVATE" storage. Virtual storage areas where system programs reside, are forbidden for unrestricted private use. They are considered common storage regions which can serve all users, but which can not "easily" be modified by them. The different common regions are NUCLEUS, which contains the "guts" of MVS, PSA (protected low-storage addresses), the various "LPA" regions which contain single copies of commonly used programs, CSA (usable common storage), and SQA (system queue area, which is a special type of common storage across address spaces). Now look at the Figure Two (MAPSP) display. In non-XA systems, there is only one copy of each type of address region. But the XA systems (see Figure One) have TWO copies of each type of region--one below the line, and one above the line (called "extended" or "E"). In XA, the NUCLEUS region straddles the line, and all other regions have a part "above", separated from a corresponding part "below". I have several more things to say before we leave the topic of storage region maps. Note that in MAPXA, Jeff calculates the percent of CSA storage now being used. This is because he needed the program originally to diagnose a condition of CSA becoming filled unnecessarily. Note also that MAPSP calculates the percent of storage currently being used in the SQA region. That was also necessary for the diagnosis of some problem conditions. Often, we can merely use the MAPSP or MAPXA programs just to give us an idea of how much private region size we can safely run below the line. They are also extremely important in diagnosis, enabling us to determine what type of storage is represented IN OUR SYSTEM by any given storage address. I used MAPSP once to determine that we were defining too much CSA in our IEASYS00 member of SYS1.PARMLIB. I cut the CSA amount down, and was easily able to obtain another "meg" of private region below the line. I'm sure that you can also find new ways for these programs to help you at your own shop. THE BLKDISK PROGRAM (BLK3350, BLK3380, BLK3390, etc.). Calculating disk space allocations is one of the "necessary inconveniences" of MVS. IBM came up with the idea of System Managed Storage, much in response to the known difficulty of allocating proper amounts of disk space on the various disk devices. However, even if your shop uses System Managed Storage, a system programmer must still be knowledgeable about how disk space allocations are dependent upon disk device geometry. First, not all space is managed by SMS. Second, SMS must be carefully PLANNED for. Let's discuss the problems. We all know, for example, that a 3350 disk device has a maximum blocksize of 19,069 bytes per track, and that there are 30 tracks per cylinder. We also know that a 3380 disk device has a maximum blocksize of 47,476 bytes per track and there are 15 tracks per cylinder. Most of us have had experience with these disk drives. It is still difficult to remember these numbers. Worse, when trying to calculate the number of blocks per track on any device, one must also know the number of "bytes" occupied by an INTERBLOCK GAP (the space in-between two data blocks on a track). Records that have KEYS separate from their DATA, create even more complication in the matter. Most people "solve" the problems by just experimenting with test files, to see "what fits". We see that this stuff is not fun, but it is very necessary to do in an MVS environment. Efficient use of disk space is a part of any programmer's capacity planning. However, under the usual conditions, actual disk space optimization is very difficult for a normal programmer to achieve. There have been a number of proposed solutions that I know of personally. One of my former colleagues devised a SAS program hooked to a CLIST, that calculated disk capacities for the various disk devices. The setup was helpful to him, but it was not for everyone. First, the prompts were cumbersome to learn. Second, that setup was useless to me because our shop doesn't have the SAS product. Finally, the program ran rather slowly. Probably most of you know of such home-grown solutions for disk calculation, and most of them probably exhibit similar disadvantages. So now, I'll tell you of a fully-implemented ASSEMBLER program called "BLKDISK" that runs at "assembler" speed. It does all kinds of disk calculations in useful ways that we'll describe. If you are a user of the fabulous "PDS" product (CBT tape files 182, 296 and 112), or a user of its vendor-supported extension "PDS/E", BLKDISK will return its output to a PDS(/E) View Log, where it is available to be printed out or written to a dataset for further manipulation. BLKDISK is found on File 296 of the CBT MVS Tape. Since BLKDISK was written by my friend Bruce Leland, I'd like to include some personal trivia about it. Bruce wrote BLKDISK to solve the same problems we all have to solve about disk space. People in his shop were using (in his words) "really lousy blocksizes", and he wanted to clean up the situation. Bruce wrote the original version (which has the same output) in PL/I at the very beginning of 1978, just for 3330 disks. In August 1982, he converted the program to assembler language, because "it ran very slow" in PL/I. Bruce provided device support for most of the "old" devices, and he added support for the new ones as they went on the market. The very latest version on the newest CBT tapes has 3390 support, as well as support for all the other devices. BLKDISK is a public-domain TSO command, and has been available on the CBT tape since Version 204 (November 14, 1982). How does BLKDISK work? BLKDISK provides device support through its ALIASES. The BLKDISK program, after it is assembled, can be linkedited with aliases: BLK23051, BLK23052, BLK2314, BLK3330, BLK33301, BLK3340, BLK3350, BLK3375, BLK3380 and BLK3390. The alias under which BLKDISK is invoked, determines which device size numbers are used. These are taken from a device parameter table that is coded in the program. To use BLKDISK, we invoke one of the aliases as a TSO command. For example: BLK3380 80 NUMBER(5000) BLKSIZE(3120) The output will appear similar to the upper table in Figure Four. However the allocation instructions for 5000 80-byte records with a block size of 3120 will read: FOR BLKSIZE 3,120 AND 5,000 RECORDS, ALLOCATE: 129 BLOCKS, 10 TRACKS, OR 1 CYLINDERS This is simple to use, neat, quick, and handy. Note that half-track blocking is "RECOMMENDED" by Bruce, for reasons enumerated in the tutorial included with the program. I've shown a full tutorial on how to use the BLKDISK aliases in Figure Three. Figure Three is the TSO HELP member for BLK3380, and similar syntax is used for all the other device types. I have included three extra figures to illustrate BLKDISK operation. These are Figures Five, Six and Seven, in addition to Figure Four. The reason for that is the useful reference information displayed by the TRACKCAP parameter. For each device, the TRACKCAP parameter displays a table showing the LARGEST NUMBER OF BYTES IN A BLOCK, THAT WILL FIT "n" BLOCKS TO A TRACK. For example, on a 3380 device, 23476 bytes in a block is the largest block that will fit 2 blocks to a track. Similarly on a 3350 device, the largest block that will fit 5 blocks to a track, is 3665 bytes. These tables are so handy, that I've included them for you to keep for your reference later. You may find it useful to have a copy of them posted at your desk. Please read the BLKDISK tutorial and spend time looking at the illustrations. Having this program installed and running, will help your shop greatly. At the very least, you can substantiate your own recommendations for block sizes, and all the other programmers can benefit too. Hope these programs help you. See you next month. * * * * * * * * * * * * * * * * * * * * * * * FIGURE ONE. Illustration of the MAPXA TSO Command from Jeff Broido. (Written January 1984.) Note his "cute" characterization of the "16-meg" address. AREA START END LEN. (K) %FULL -------------- ---------- ---------- ----------- ----- E-PRIVATE 02100000 7FFFFFFF 2,063,360 -- E-CSA 01D58000 020FFFFF 3,744 -- E-MLPA 01D4B000 01D57FFF 52 -- E-FLPA 01D47000 01D4AFFF 16 -- E-PLPA 01A22000 01D46FFF 3,220 -- E-SQA 011D2000 01A21FFF 8,512 -- E-NUC (R/W) 01164000 011D1FFF 440 -- E-NUC (R/O) 01000000 01163FFF 1,424 -- -------------------------------------------------------------- THE LINE. NUC (R/O) 00FE3000 00FFFFFF 116 -- NUC (R/W) 00FC1000 00FE2FFF 136 -- SQA 00F21000 00FC0FFF 640 -- PLPA 00D83000 00F20FFF 1,656 -- FLPA 00D81000 00D82FFF 8 -- MLPA 00D72000 00D80FFF 60 -- CSA 00B00000 00D71FFF 2,504 24 PRIVATE 00001000 00AFFFFF 11,260 -- PSA 00000000 00000FFF 4 -- * * * * * * * * * * * * * * * * * * * * * * * FIGURE TWO. Illustration of the MAPSP TSO Command from Jeff Broido. (Written January 1984.) AREA START END LENGTH (K) %FULL ------------ ------ ------ ---------- ----- SQA F90000 FFFFFF 448 71 PLPA B1F000 F8FFFF 4,548 -- MLPA/BLDL AC8000 B1EFFF 348 -- SYSGEN PSA AC7000 AC7FFF 4 -- CSA 910000 AC6FFF 1,756 -- V=R (IF ANY) 114000 153FFF 256 -- PRIVATE 110000 90FFFF 8,192 -- NUCLEUS 001000 10FFFF 1,084 -- PSA 000000 000FFF 4 -- * * * * * * * * * * * * * * * * * * * * * * * FIGURE THREE. TSO HELP Member for the BLK3380 call to the BLKDISK command. This member illustrates how to use BLKDISK to find out disk allocation information on a 3380 disk device. Similar syntax is used to call BLKxxxx, where xxxx denotes another model of disk device. xxxx may be a 3330, 3340, 3350, 3375, 3380, or 3390 device. )F FUNCTION - THE BLK3380 COMMAND COMPUTES AN OPTIMAL BLOCKSIZE FOR A DATA SET TO BE PLACED ON A 3380 DISK PACK. THE PROGRAM OUTPUT INCLUDES THE FOLLOWING REPORTS: 1. A SUMMARY BLOCKSIZE REPORT FOR THE GIVEN LRECL AND KEY LENGTH WHICH INCLUDES THE RECOMMENDED BLOCKSIZE TO USE. 2. A RECOMMENDED DATA SET SPACE ALLOCATION. 3. A OPTIONAL TRACK CAPACITY REPORT FOR THE PROVIDED KEY LENGTH. THE RECOMMENDED BLOCKSIZE VALUE IS FOR DATA SETS IN WHICH THE PREDOMINANT ACCESS IS SEQUENTIAL; FOR DATA SETS WHERE RANDOM ACCESS TIME IS CRITICAL OR THE USUAL ACCESS IS RANDOM, A SMALL BLOCKSIZE (500-2000 BYTES) SHOULD PROBABLY BE USED. THE RECOMMENDED BLOCKSIZE WILL USUALLY TEND TO BE NEAR A HALF-TRACK FIGURE AS THIS IS CONSIDERED TO BE THE MOST EFFICIENT IN TERMS OF THE TRADE-OFFS AMONG BUFFER SIZE, SECONDARY STORAGE REQUIREMENTS, CHANNEL USE, NUMBER OF INPUT/OUTPUTS AND OVERALL PROCESSING TIME. THIS FIGURE IS ONLY A GENERAL GUIDE; FOR MAXIMAL EFFICIENCY CONSIDERING OTHER FACTORS, STUDY THE GENERATED BLOCKSIZE SUMMARY REPORT OR A TRACK CAPACITY REPORT. THE PROGRAM'S RECOMMENDATIONS ASSUME A FAIRLY LARGE AMOUNT OF DATA IS TO BE STORED; DATA SETS WHICH OCCUPY ONLY A FEW TRACKS SHOULD PROBABLY BE PLACED IN PARTITIONED DATA SETS. IN CASES WHERE THIS IS NOT FEASIBLE, THE USE OF A SMALL BLOCKSIZE (2400 - 4000 BYTES) MAY BE A GOOD ALTERNATIVE PRACTICE. )X SYNTAX - BLK3380 'LRECL' KEYLENGTH('INTEGER') TRACKCAP / NOTRACKCAP BLKSIZE('INTEGER') NUMBER('INTEGER') / RECORDS('INTEGER') VERIFY REQUIRED - LRECL DEFAULTS - KEYLENGTH(0), NOTRACKCAP, BLKSIZE(RECOMMENDED VALUE), NUMBER(100000) )O OPERANDS - 'LRECL' - THE LOGICAL RECORD LENGTH OF THE DATA WHICH IS TO BE PLACED IN THE DATA SET. ))KEYLENGTH('INTEGER') - THE KEY LENGTH, IN BYTES, OF THE KEYS TO BE USED IN THE DATA SET. THE MAXIMUM LEGAL KEY LENGTH IS 255. ))TRACKCAP - SPECIFIES THAT A TRACK CAPACITY REPORT IS TO BE PROVIDED FOR THE DEVICE USING THE SPECIFIED (OR DEFAULT) KEY LENGTH. NOTE THAT A TRACK CAPACITY REPORT IS ALSO PROVIDED IF NOTRACKCAP IS NOT SPECIFIED AND LRECL EXCEEDS THE MAXIMUM BLOCKSIZE FOR A TRACK OR BLKSIZE EXCEEDS THE MAXIMUM BLOCKSIZE FOR A TRACK. ))NOTRACKCAP - SPECIFIES THAT A TRACK CAPACITY REPORT IS NOT DESIRED. ))BLKSIZE('INTEGER') - THE BLOCKSIZE TO USE FOR THE ALLOCATION COMPUTATION; IF BLKSIZE IS NOT ENTERED (OR ZERO IS ENTERED), THE PROGRAM'S RECOMMENDED BLOCKSIZE WILL BE USED. ))NUMBER('INTEGER') - THE NUMBER OF LOGICAL RECORDS THAT WILL BE IN THE DATA SET. ))RECORDS('INTEGER') - THE NUMBER OF LOGICAL RECORDS THAT WILL BE IN THE DATA SET. ))VERIFY - SPECIFIES THAT THE MVS "TRKCALC" ROUTINE IS TO BE USED TO VERIFY TRACK CAPACITY CALCULATIONS. IF VERIFY IS USED, THE NUMBER OF CALLS TO "TRKCALC" TO DETERMINE A TRACK CAPACITY TABLE IS OUTPUT AT THE END OF THE OUTPUT. NOTE: WITH VERIFY ON, A MINIMUM OF 34 CALLS IS REQUIRED TO DETERMINE A TRACK CAPACITY TABLE; OTHERWISE A MINIMUM OF 17 CALLS IS REQUIRED TO DETERMINE THE TRACK CAPACITY TABLE. ** N O T E ** - VERIFY NOT CURRENTLY SUPPORTED FOR 3390. * * * * * * * * * * * * * * * * * * * * * * * FIGURE FOUR. Illustration of the BLK3380 TSO Command, invoked to show disk space usage on a 3380 device. Various block size scenarios are displayed in the upper table, enabling the user to graphically see the disk space utilization by the different block sizes. The Track Capacity Table for 3380 devices is shown as the lower table of the illustration. blk3380 80 trackcap 3380 BLOCKSIZE SUMMARY; LRECL=80 KEY LENGTH=0 BLOCKSIZE BLOCKS/TRACK LRECLS/TRACK UTILIZATION --------- ------------ ------------ ----------- 80 83 83 14.0% 2,480 16 496 83.6% 2,640 15 495 83.4% 2,880 14 504 84.9% 3,120 13 507 85.4% 3,440 12 516 86.9% 3,840 11 528 89.0% 4,240 10 530 89.3% 4,800 9 540 91.0% 5,440 8 544 91.7% 6,320 7 553 93.2% 7,440 6 558 94.0% 9,040 5 565 95.2% 11,440 4 572 96.4% 15,440 3 579 97.6% RECOMMENDED-->23,440 2 586 98.7% 32,720 1 409 68.9% FOR BLKSIZE 23,440 AND 100,000 RECORDS, ALLOCATE: 342 BLOCKS, 171 TRACKS, OR 12 CYLINDERS 3380 TRACK CAPACITY; KEY LENGTH=0 BLOCKS/TRACK BLKSIZE BYTES/TRACK UTILIZATION ------------ ------- ----------- ----------- 1 47,476 47,476 100.0% 2 23,476 46,952 98.9% 3 15,476 46,428 97.8% 4 11,476 45,904 96.7% 5 9,076 45,380 95.6% 6 7,476 44,856 94.5% 7 6,356 44,492 93.7% 8 5,492 43,936 92.5% 9 4,820 43,380 91.4% 10 4,276 42,760 90.1% 11 3,860 42,460 89.4% 12 3,476 41,712 87.9% 13 3,188 41,444 87.3% 14 2,932 41,048 86.5% 15 2,676 40,140 84.5% 16 2,484 39,744 83.7% DEVICE SUMMARY: MAX BLOCKSIZE=47,476 TRACKS=13,275 BYTES=630,243,900 NOCYLS=885 TRKS/CYL=15 TRKSIZE=47,968 DSCB/TRK=53 PDS/TRK=46 * * * * * * * * * * * * * * * * * * * * * * * FIGURE FIVE. Illustration of the BLK3390 TSO Command, invoked to show disk space usage on a 3390 device. Various block size scenarios are displayed in the upper table, enabling the user to graphically see the disk space utilization by the different block sizes. The Track Capacity Table for 3390 devices is shown as the lower table of the illustration. blk3390 80 trackcap 3390 BLOCKSIZE SUMMARY; LRECL=80 KEY LENGTH=0 BLOCKSIZE BLOCKS/TRACK LRECLS/TRACK UTILIZATION --------- ------------ ------------ ----------- 80 78 78 11.0% 2,880 16 576 81.3% 3,120 15 585 82.6% 3,440 14 602 85.0% 3,760 13 611 86.3% 4,080 12 612 86.4% 4,560 11 627 88.5% 5,040 10 630 88.9% 5,680 9 639 90.2% 6,480 8 648 91.5% 7,520 7 658 92.9% 8,880 6 666 94.0% 10,720 5 670 94.6% 13,680 4 684 96.6% 18,400 3 690 97.4% RECOMMENDED-->27,920 2 698 98.5% 32,720 1 409 57.7% FOR BLKSIZE 27,920 AND 100,000 RECORDS, ALLOCATE: 287 BLOCKS, 144 TRACKS, OR 10 CYLINDERS 3390 TRACK CAPACITY; KEY LENGTH=0 BLOCKS/TRACK BLKSIZE BYTES/TRACK UTILIZATION ------------ ------- ----------- ----------- 1 56,664 56,664 100.0% 2 27,998 55,996 98.8% 3 18,452 55,356 97.7% 4 13,682 54,728 96.6% 5 10,796 53,980 95.3% 6 8,906 53,436 94.3% 7 7,548 52,836 93.2% 8 6,518 52,144 92.0% 9 5,726 51,534 90.9% 10 5,064 50,640 89.4% 11 4,566 50,226 88.6% 12 4,136 49,632 87.6% 13 3,768 48,984 86.4% 14 3,440 48,160 85.0% 15 3,174 47,610 84.0% 16 2,942 47,072 83.1% DEVICE SUMMARY: MAX BLOCKSIZE=56,664 TRACKS=16,695 BYTES=946,005,480 NOCYLS=1,113 TRKS/CYL=15 TRKSIZE=58,786 DSCB/TRK=50 PDS/TRK=45 * * * * * * * * * * * * * * * * * * * * * * * FIGURE SIX. Illustration of the BLK3350 TSO Command, invoked to show disk space usage on a 3350 device. Various block size scenarios are displayed in the upper table, enabling the user to graphically see the disk space utilization by the different block sizes. The Track Capacity Table for 3350 devices is shown as the lower table of the illustration. blk3350 80 trackcap 3350 BLOCKSIZE SUMMARY; LRECL=80 KEY LENGTH=0 BLOCKSIZE BLOCKS/TRACK LRECLS/TRACK UTILIZATION --------- ------------ ------------ ----------- 80 72 72 30.2% 960 16 192 80.5% 1,040 15 195 81.8% 1,120 14 196 82.2% 1,280 13 208 87.3% 1,360 12 204 85.6% 1,520 11 209 87.7% 1,680 10 210 88.1% 1,920 9 216 90.6% 2,160 8 216 90.6% 2,560 7 224 94.0% 2,960 6 222 93.1% 3,600 5 225 94.4% 4,560 4 228 95.7% 6,160 3 231 96.9% RECOMMENDED--> 9,440 2 236 99.0% 19,040 1 238 99.8% FOR BLKSIZE 9,440 AND 100,000 RECORDS, ALLOCATE: 848 BLOCKS, 424 TRACKS, OR 15 CYLINDERS 3350 TRACK CAPACITY; KEY LENGTH=0 BLOCKS/TRACK BLKSIZE BYTES/TRACK UTILIZATION ------------ ------- ----------- ----------- 1 19,069 19,069 100.0% 2 9,442 18,884 99.0% 3 6,233 18,699 98.1% 4 4,628 18,512 97.1% 5 3,665 18,325 96.1% 6 3,024 18,144 95.1% 7 2,565 17,955 94.2% 8 2,221 17,768 93.2% 9 1,954 17,586 92.2% 10 1,740 17,400 91.2% 11 1,565 17,215 90.3% 12 1,419 17,028 89.3% 13 1,296 16,848 88.4% 14 1,190 16,660 87.4% 15 1,098 16,470 86.4% 16 1,018 16,288 85.4% DEVICE SUMMARY: MAX BLOCKSIZE=19,069 TRACKS=16,650 BYTES=317,498,850 NOCYLS=555 TRKS/CYL=30 TRKSIZE=19,254 DSCB/TRK=47 PDS/TRK=36 * * * * * * * * * * * * * * * * * * * * * * * FIGURE SEVEN. Illustration of the BLK3375 TSO Command, invoked to show disk space usage on a 3375 device. Various block size scenarios are displayed in the upper table, enabling the user to graphically see the disk space utilization by the different block sizes. The Track Capacity Table for 3375 devices is shown as the lower table of the illustration. blk3375 80 trackcap 3375 BLOCKSIZE SUMMARY; LRECL=80 KEY LENGTH=0 BLOCKSIZE BLOCKS/TRACK LRECLS/TRACK UTILIZATION --------- ------------ ------------ ----------- 80 75 75 16.8% 1,840 16 368 82.7% 2,000 15 375 84.2% 2,160 14 378 84.9% 2,320 13 377 84.7% 2,560 12 384 86.3% 2,880 11 396 88.9% 3,200 10 400 89.8% 3,600 9 405 91.0% 4,080 8 408 91.6% 4,720 7 413 92.8% 5,600 6 420 94.3% 6,800 5 425 95.5% 8,560 4 428 96.1% 11,600 3 435 97.7% RECOMMENDED-->17,600 2 440 98.8% 32,720 1 409 91.9% FOR BLKSIZE 17,600 AND 100,000 RECORDS, ALLOCATE: 455 BLOCKS, 228 TRACKS, OR 19 CYLINDERS 3375 TRACK CAPACITY; KEY LENGTH=0 BLOCKS/TRACK BLKSIZE BYTES/TRACK UTILIZATION ------------ ------- ----------- ----------- 1 35,616 35,616 100.0% 2 17,600 35,200 98.8% 3 11,616 34,848 97.8% 4 8,608 34,432 96.7% 5 6,816 34,080 95.7% 6 5,600 33,600 94.3% 7 4,736 33,152 93.1% 8 4,096 32,768 92.0% 9 3,616 32,544 91.4% 10 3,200 32,000 89.8% 11 2,880 31,680 88.9% 12 2,592 31,104 87.3% 13 2,368 30,784 86.4% 14 2,176 30,464 85.5% 15 2,016 30,240 84.9% 16 1,856 29,696 83.4% DEVICE SUMMARY: MAX BLOCKSIZE=35,616 TRACKS=11,508 BYTES=409,868,928 NOCYLS=959 TRKS/CYL=12 TRKSIZE=36,000 DSCB/TRK=51 PDS/TRK=43