I think it will depend on what is creating the LBI file IDCMAS does not support LBI. Running two sets of JCL: The first set used IEBGENER with an output blocksize of 65520. The resulting tape actually had a blocksize of 65520. The same input data set using IDCAMS Repro with an output BLKSIZE specified as 65520, however, results in the output Blksize of 32720. Answer
The problem has to do with the BLKSIZE. In the z/OS DFSMS Access Method Services for Catalogs manual (Document Number SC26-7394-03) it states in section 30.1 REPRO Parameters. REPRO cannot be used if source or target tape data set has a BLKSIZE larger than 32760 bytes. Your RYO needs to check some bits for LBI and then handle it. The large block interface (LBI) lets your program |handle much larger blocks with BSAM or QSAM. On the current level of the system you can use LBI with BSAM, BPAM, and QSAM for any kind of data set except unit record or a TSO/E terminal. Currently blocks of more than 32 760 bytes are supported only on tape, dummy |data sets, and BSAM UNIX files. You request LBI by coding a BLKSIZE value, even 0, in the DCBE macro or by turning on the DCBEULBI bit before completion of the DCB OPEN exit. Coding BLKSIZE causes the bit to be on. It is best if this bit is on before you issue the OPEN macro. That lets OPEN merge a large block size into the DCBE. Your DCB OPEN exit can test bit DCBESLBI to learn if the access method supports LBI. If your program did not request unlike attributes processing (by turning on bit DCBOFPPC) before issuing OPEN, then DCBESLBI being on means that all the data sets in the concatenation support LBI. If your program requested unlike attributes processing before OPEN, then DCBESLBI being on each time that the system calls your DCB OPEN exit or JFCBE exit means only that the next data set supports LBI. After the exit, OPEN leaves DCBESLBI on only if DCBEULBI also is on. Your exit routine can change DCBEULBI. Never change DCBESLBI. I know you probably know this. So this is just for anyone searching this topic. Lizette -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Skip Robinson Sent: Wednesday, August 21, 2013 8:53 AM To: [email protected] Subject: Large BLKSIZE We're having ongoing 'discussions' with our tape vendor over through-put performance. Vendor is suggesting that we should be using modern man-size blocks like 256K. I did some simple testing yesterday to satisfy myself that--whatever it might take to super-size our tape file blocks--simply adding BLKSIZE=some-large-number to a DD card will not cause the creation of very large blocks. After running such a job with an existing RYO program, the resulting BLKSIZE was in fact 32K. No error messages, just no big blocks. Am I right in asserting that, whatever benefit we might derive from uber-blocks, we cannot get there by fiddling with JCL? . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
