Dummy Sections Ch.7 pp

Why Use DSECTs ? DSECTs don’t really exist – they are like virtual devices, they are just a set of labels DSECTs can relocate around your program, they are just empty shells dependent on a register Used for repetitive processing Used to block or deblock records Used to give structure to a section of memory

16 bytes 25 Repeating fields Example of Repetitive Processing Note the USING & LA 8,INVSTOR near the top of the code to the right. In a sense, R8 has been established as the location counter for the area of memory of 400 bytes called INVSTOR and the USING provides addressing to the first 16 bytes with variable symbols rather than having to count bytes. INVSTOR contains 25 repeating fields all of which look like the structure of the DSECT. Currently the shell of the DSECT which has no memory locations of its own is sitting atop the first 25 bytes of INVSTOR providing symbol access to that area. When done, bump the contents of R8 by 25 bytes and you are now able to gain access to the next 25 bytes of INVSTOR symbolically. Add 25 bytes to the contents of R8, and you can easily access the next 25 bytes of INVSTOR, and so forth, creating a BCT loop with R9 adding INVQTY each time through. Return to your regular program by coding another CSECT.

Blocking / Deblocking Tape Unblocked 1000-byte Records Blocked 1000-byte Records (4:1) ¾ inch bpi 2/3 4:1

On the precious slide, we saw that unblocked data (on tape) seems to waste most of the tape. Most of the tape was “yellow” space and there was no attempt to create the diagram to scale. This wasted space was caused by the start-up and stop time needed to actually record or read the data on the tape. This does not happen with disk or electronic devices such as flash drives. To read or write data on tape, the tape must pass through the read/write heads at a certain speed. It tales about 3/8” from start to “at speed” and it takes about the same amount of time to stop the tape. That totals about 3/4” and as you can also see in the diagram, 1000-byte records take up about 1/6” – very loosely. This is not efficient use of the device. The 3/4” gap can hold about 4.5 records. On the other hand, blocking records appears to be much more efficient. Again, the diagram is not to scale, but there appears to be more “red” space than “yellow” space. This is not really the case since we already know that a gap can contain about 4.5 records and our example is blocked 4 logical records together into a single physical record. So why not make the tape just one huge physical records with however many records there are all blocked into a single record? This would make the best use of the storage space on the tape. Well, as in everything dealing with computer processing, there are trade-offs. For example, to read or write to any storage device, you are moving the data as a large chunk (a physical block) to or from memory. How much memory would be required to read the block in? That’s right, the size of the physical record. Can your computer afford that much memory? Probably not. So a major trade-off is memory capacity. The best solution is some sort of compromise between unblocked records and one large block. What a surprise! Many studies have been made to guess-timate the MOST efficient blocking factor. For our purposes, let’s just say the most efficient blocking is 4-to-1, as in the second section of tape in the previous slide. Going through all the calculations is not part of the purpose of this class. Besides, tape is probably not your first choice of a storage device to use on your PC. It is, however, fairly popular on mainframe computers. It’s cheap and you can store lots of data on it regardless of the chosen blocksize. It’s very slow, compared to other disk-type or electronic storage, so it makes a good choice device for archiving data. HOWEVER, you can still choose to block records on any type of storage device, even though there is not the problem of gaps. Recall that whatever is the makeup of a physical record is what is transferred between the device and memory. So if you have sufficient memory on your computer, it is probably a good idea to block records anyway. So what is the trade-off? Performing I/O tends to be a mechanical operation, taking forever in terms of memory speeds. When records are blocked, it may take a little bit longer to transfer the records, but you do that-many fewer I/O operations and passing through the operating system’s I/O processing routines that many fewer times, so your saving is your processor. Your program may be using logical I/O (GET/PUT), but in our example, every 3 out of 4 GETs would obtain the record already in memory and not trigger an I/O to the device, so YOUR program would run faster as well. This is what using Assembler language is all about – being able to create the MOST efficient programs. Using DSECTs is what gets you there.

Example of Block/Deblock Records To my knowledge, this is not an option using PC/370, but is most certainly a true mainframe option. Notice the “aqua-colored DCB. In particular, notice the MACRF parameter, which is requesting “GL” – GET in the LOCATE mode. We will always be using GM – GET in the MOVE mode, which always delivers a logical record, regardless of record blocking. Locate-mode delivers the entire block, but not directly into our program. The block is “fetched” into a buffer provided to the operating system. Each request for a logical record (GET) the next logical record is obtained, but rather than placing the record into our buffer, GET returns the operating system buffer location in Reg 1. This mode always uses a DSECT. In the highlighted LR instruction, the contents of Reg 1 (address of logical record following GET) is moved to Reg 4 and Reg 4 is used as the “base” register for the DSECT. Note: the USING statement for Reg 4 above the GET. Notice also that the records are blocked 5-to-1 – LRECL and BLKSIZE in the DCB. RECFM also has ‘FB’ for fixed-length records and blocked.

End of DSECTs Presentation