Large tape block size"Wayne Rhoten/San Jose/IBM" <firstname.lastname@example.org>
Mon, 7 Aug 2000 11:54:17 -0600
Test the CVT word named CVTDFA for being non-zero. If it is zero, you are running on a system that is prior to MVS/XA DFP 2.1.0, which was delivered around 1985. In fact on a very ancient system such as MVT, the CVT might not be long enough. You will have to figure how to know whether the CVT is long enough. According to the Release 21.7 edition of OS/360 System Control Blocks, the CVT was only X'114' bytes. You would want to test the byte at CVTDCB first. The PCP bit in CVTDCB probably means you are running on CMS on VM.
CVTDFA is at offset X'4C0' and the older name was CVTCKRAS. The field never got used for the original purpose and had been zero for a number of years. I think we set that word to point to the DFA before anyone got around to defining the name CVTDFA.
If the CVT is long enough and CVTDFA is non-zero, then it points to the DFA, data facilities area.
The DFA has always been at least X'30' bytes long. In OS/390 2.10 in September 2000, it was lengthened. There is a two-byte length field. The area is mapped by the IHADFA macro, which has been in SYS1.MACLIB since DFP 2.1.0. The IHADFA macro and its fields are documented in the various incarnations of DFSMSdfp Advanced Services.
In DFSMS/MVS 1.1.0 the four-byte field DFARELS was added. Prior to that release it had always been four bytes of binary zeroes. If DFARELS contains the value of X'02020A00' or greater, then you are on OS/390 DFSMS 2.10 or later. The first byte being X'02' signifies that you are running on a DFSMS level that came as an inseparable part of OS/390. That is after the DFSMS/MVS product, which could still run with MVS/ESA SP 5.2.2. The other three bytes signify Version 2, Release 10, Modification Level 0.
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.
Another way to test before OPEN whether OPEN supports LBI for the data set
is to issue the DEVTYPE macro. It is documented in DFSMS Advanced
Services. Code the INFOLIST parameter on the DEVTYPE macro and point to
another instance of the macro with INFO=AMCAP. This is one form of DEVTYPE
parameter list pointing to another form of parameter list. The main
parameter list has several variable fields, including the address and
length of the area to receive the information. The receiving area must be
at least 32 bytes long. You do not have to initialize that area. If you
are running on any release of DFSMS/MVS, the system is supposed to clear
the 32 bytes to binary zeroes even if it does not know what to put in it.
In other words you can assemble INFO=AMCAP only on OS/390 2.10 or later but
it should reliably set the 32 bytes when running as early as DFSMS/MVS
1.1.0. Unfortunately if you execute DEVTYPE with the INFO parameter with any value on an earlier level of the system, it may fail.
In OS/390 R10 or later, DEVTYPE will set the 32 bytes as follows:
Code the DCBE= parameter on the DCB macro to point to an instance of the DCBE. Note that the DCB must be below the 16 MB line but the DCBE optionally can be above the 16 MB line even if your program is running in AMODE 24.
Code a DCBE macro with the BLKSIZE= parameter. The DCBE macro was first shipped in DFSMS/MVS 1.1.0, which came out about 1993. It did not support the BLKSIZE macro until OS/390 DFSMS 2.10, which is available in September 2000. During that time all DCBE macros are the same length. The new fields were zero in prior releases.
When you code DCBE= on the DCB macro, it causes the first word in the DCB to point to the indicated area and it causes two bits, named DCBH0 and DCBH1 to be on. They are at offset X'20' in the DCB in a byte named DCBHIAR, DCBBFALN and DCBBFTEK. If you want your DCBE to be in dynamic storage, you do not have to code the DCBE= parameter. Instead your program can turn on these two bits and store the DCBE address in the first DCB word, which is named DCBDCBE. If either of the two bits is off, then the first DCB word has a meaning only for BPAM or when using BSAM or QSAM to access a partitioned data set member. In that case the first DCB word is called DCBRELAD. If both bits are on, then the content and meaning of that old DCB word is defined in a DCBE word called DCBERELA.
(Historical note: If either of DCBH0 or DCBH1 is on but not both, it means that the user has coded the obsolete HIARCHY parameter on the DCB macro or on the DD statement. The valid values are 0 and 1. Probably JCL no longer accepts it. HIARCHY=1 means that you are requesting that OPEN get access method buffers from hierarchy 1 storage, which was slower, cheaper memory. It was in a separate box, called IBM Large Core Storage. The memory was ferrite core. The IBM product type number apparently was 2361 and it was obsolete by the early seventies. This type of memory was never supported on any OS/VS1, OS/VS2 or later system. Note that the concept of slower and faster, but not cheaper, memory is an innovation of the NUMA-Q architecture, which uses Intel processors and is owned by IBM.)
To request LBI, large block interface, you must code BLKSIZE=nnnn on the DCBE macro. This causes the value that you code to be in a word in the DCBE expansion and a bit, DCBEULBI, to be on. If you code BLKSIZE=0, the word will still be zero but the bit will be on to show that you coded BLKSIZE and want LBI.
Before OPEN calls your optional DCB OPEN exit routine, it turns on another bit, DCBESLBI, if the access method supports LBI for that data set. OPEN turns off that bit if the access method does not suport LBI for that data set. At that time (in your DCB OPEN exit routine), the setting of DCBESLBI has nothing to do with whether the user's bit DCBEULBI, is on. At that time, its sole purpose is to tell the user's DCB OPEN exit routine whether the system supports LBI for that data set. If DCBESLBI is off at that time, it means either that the data set does not support LBI or you are running on a down level system.
That downlevel system might not even have recognized the DCBE. There is another DCBE bit that tells whether OPEN recognized the DCBE (and supports AMODE 31). It is DCBEMD31. For most disk, tape, subsystem, spooled and dummy data sets, it has been turned on since DFSMS/MVS 1.1.0. This bit has been documented for this purpose since that release and the whole DCBE has been an intended programming interface but its fields were not documented until DFSMS/MVS 1.5. This was an oversight. The fields are described in Appendix A in DFSMS Macro Instructions for Data Sets. For all OS/390 manuals, see http://www.s390.ibm.com/os390/bkserv and select a release.
Before OPEN calls the DCB OPEN exit routine, it does not care about the value of the DCBEULBI bit. After the exit routine, OPEN tests DCBEULBI and it sets DCBESLBI for a new meaning. If DCBEULBI is on and OPEN earlier turned on DCBESLBI, then OPEN leaves DCBESLBI on. If DCBEULBI is off, OPEN turns DCBESLBI off. That means that after the exit, DCBESLBI is a reliable means to learn whether (1) the user requested LBI and (2) the system supports LBI for this data set. (Therefore LBI is in effect until CLOSE.)
Tape Label Changes
The following statement applies to the old, five-character block size field in the IBM standard label 2: "If the block length field contains zeros, then there is a large block interface block length. See field 17, Large Block Length." This applies to the HDR2, EOV2 and EOF2 labels.
The last ten bytes of the same label previously were reserved and now are defined as this:
17--Large Block Length (10 bytes)
The system can determine the optimum block size when creating tape data sets. For more information see OS/390 DFSMS: Using Data Sets.
System-Determined Block Size with LBI
If you are using LBI when you open a tape data set for output and you take advantage of OPEN determining a block size, OPEN normally will calculate a value that exceeds 32760 bytes. This means that the reading program must be able to handle large blocks. No program, except possibly for an EXCP program, can read such a tape on OS/390 before 2.10. There is no way for OPEN to know what programs or operating system will be used to read the tape.
If you want OPEN to determine the block size and you want to use LBI, here
are some considerations:
Copyright © 2000,2002 cbttape.org All rights reserved.