Downloads

CBT
Top 10 Files
Updates
Overflow
JES3
JES2
CBT249 & Older
UCLAmail
Xmit Manager
MVS 3.8J
VM/370 R6
OS/360
OS/VS1
PDS 8.5
Linux/390
MVT Mods
Fish's Herc Tools
PC Tools
AWSTAPE
DSS-FDR Format
AWS Format

Information

Order CDROM
Newsletter
FAQ
Links
Mail & Newsgroups
Fun
Features 
Steve Samson
Contribute files
Freebies
Linking to CBT site
Advertising here
Complaints
Workbench
Cross Links

Contact Us

Buy Gear

cbt-tape on
Yahoo Groups

Large tape block size

DFA
You need to test the DFA only if you need to know of the availability of LBI (large block interface) before issuing an OPEN macro. In general that is not necessary. The DCBE section below describes an easier way to adapt to the presence or lack of LBI support. It will run on any level of the system.

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.

DEVTYPE Macro

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:

DCBE
To use LBI, your program must supply a DCBE macro with a certain bit set.

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)

Contents

A number that can be greater than 32760 that indicates the block length, in bytes. Interpretation of the number depends on the associated record format in Field 3, as follows:

Format F

Maximum block length (must be a multiple of the logical record length in Field 5). If field 12 (which means "blocked") contains a blank, then this field is also the minimum block length.

Format V

Maximum block length (including the 4-byte length field in the blocks)

Format U - Maximum block length

The system can determine the optimum block size when creating tape data sets. For more information see OS/390 DFSMS: Using Data Sets.

Processing

Used when field 4, the Block Length field, contains zeros. The number in the label is converted to binary and merged with appropriate fields in the JFCB, SWA, DCB, and DCBE. The merging process is the same as that for the record format code in field 3 of this label. If the maximum block length is 32760 or less, the OPEN and EOV routines write it in field 4 and not this field. On input, the OPEN and EOV routines accept small or large values in the Large Block Length field.

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:
? 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 reblocking. 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 unlabelled tape and IBM also recommends using IBM or ISO/ANSI labelled 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 meaningfull 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:

13(D) BITSTRING		DFAFEAT6	FEATURES BYTE 6
	1111 ....	DFACPSDB	COPYSDB VALUE IN DEVSUPxx IN PARMLIB. SYSTEM LEVEL DEFAULT FOR THE SDB OPTION OF IEBGENER AND OTHER COPYING PROGRAMS..
	0001 ....	DFACPSNO	COPYSDB = NO
	0010 ....	DFACPSYE	COPYSDB = YES
	0010 ....	DFACPSSM	COPYSDB = SMALL (SAME AS COPYSDB = YES)
	0011 ....	DFACPSIN	COPYSDB = INPUT
	0100 ....	DFACPSLA	COPYSDB = LARGE

Copyright © 2000,2002 cbttape.org   All rights reserved.
All trademarks are properties of their respective owners.