> Did I miss the announcement that block sizes greater than 32K are supported? What > release was that? > > -- > Tom Marchant
Okay a slight clarification. 32K is the largest I know of for full track blocking on DASD. Not sure about EAVs or Tape. The discussion of Full Track Blocking revolves around the architecture of the DASD. And of course that is changing with EAVs and TAPE. Some of the older dataset technologies do not handle greater than 32K very well. So for most discussions, a 32K Blocksize might be considered default. Now, there is the LBI (Large Block Interface) that can change that process. If you are running on OS/390 2.10 or later, then you know that BSAM, BPAM and QSAM support LBI on disk, tape, spooled, subsystem and dummy data sets So if you want OPEN to determine the block size and you want to use LBI, here are some considerations: You might assume that the user of the writing program will take advantage of the new BLKSZLIM keyword on the DD statement (or dynamic allocation), to limit the block size. The minimum value that the user can code is 32760. That value of 32760 also is the IBM-provided system default value for BLKSZLIM. The system programmer can change the system default by setting the TAPEBLKSZLIM keyword in the DEVSUPxx member of SYS1.PARMLIB.. Coding BLKSZLIM=32760 will ensure the tape will be readable by non-LBI programs. Note that with fixed-length records the BLKSZLIM value does not have to be a multiple of LRECL. This is because BLKSZLIM is only a limit on the BLKSIZE value that OPEN will calculate. A reason that someone might want to limit block size to less than the device maximum is that the user might want to copy the tape to another device type without relocking. The other device might have a smaller block size limit. You might assume that the user of the program will code the BLKSIZE parameter to force an appropriate maximum block size for the data set. This requires the user to know the maximum block size supported by the device. If you code BLKSIZE, it overrides any value of BLKSZLIM for the same DD statement. If the device does not support blocks as large as the coded BLKSIZE value, OPEN will issue an ABEND unless you are using EXCP, in which case the device might cause a problem. IBM recommends letting OPEN calculate a block size if feasible. It is not feasible with unlabeled tape and IBM also recommends using IBM or ISO/ANSI labeled tape. The latter type of tape does not support blocks longer than 32760 bytes. Instead of relying on the BLKSZLIM or BLKSIZE keywords, you might want to implement an option for the program. IEBGENER and ICEGENER have such options. The purpose of the option might be to tell the program whether to use LBI. Note that calling the option something "LBI=YES" will not be meaningful for most users. You might want to choose for your program to take advantage of the system-level default for copying programs. IEBGENER and ICEGENER do that. They test a DFA field that contains the system-level default for the SDB keyword for IEBGENER. To prevent OPEN from calculating a block size that exceeds 32760, the easiest way is not to request LBI. In other words, do not turn on DCBEULBI. These are the values in the DFA: So when I stated full track blocking, I was thinking (though I did not specify it) 32K. Or the maximum number of LRECLs that fit in a 32K Blocksize. I round to 32760 for the following discussion though 32K is 32767 (doing this from memory) For example, an LRECL of 80 would be 32760/80 or 32720 An LRECL of 133 would be 32760/133 or 32718 Sorry for the confusion. I kept the discussion around 32k blocks rather than looking at the new technology that many shops are NOT using at this time. Lizette ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
