BLOCK CONTAINS 0 RECORDS.

[Nick Jones]

Hi,

Please consider the below code:

Code: Select all

FD INPUT-FILE 
RECORDING MODE F 
LABEL RECORDS ARE STANDARD 
BLOCK CONTAINS 0 RECORDS 
DATA RECORD IS IN-REC. 

In above the statement BLOCK CONTAINS is used along with the RECORD CONTAINS statement - is it used to calculate the block size, by the Program?

I've been told that based on these details the data read is optimized, I'm confused - how is that optimized?

Could someone help me here to understand the concept of BLOCK SIZE we use in COBOL programs and the one we use in JCL at DCB?

Thanks

[Robert Sample]

The answer actually is complicated. When JCL references a file, where does z/OS get the DCB data (record length and block size in particular)? The answer to THIS question is that z/OS uses a specific hierarchy to find DCB data:
1. The program
2. The JCL
3. The data set
Any values not found in the program will be searched in the JCL; any not found in the program and JCL will be discovered by looking at the actual data set characteristics. If you code BLOCK CONTAINS 10 RECORDS in your program, then the block size is 10 times the record length -- period. If you are using 100-byte fixed length records, that gives you a block size of 1000 bytes. The most efficient block size, however, depends upon the device being used (3380 disks are most efficient with a block size no larger than 23476 bytes; 3390 devices with a block size no larger than 27998 bytes, and tapes with a block size of 32760).

BLOCK CONTAINS 0 RECORDS tells the operating system, therefore, that the program is not going to provide the block size, allowing either the JCL or the actual data set to provide the block size. This allows changes from 3380 to 3390 to tape to occur with only a JCL change rather than having to recompile the program with a new BLOCK CONTAINS clause every time.

[Anuj Dhawan]

BLOCK CONTAINS 0 RECORDS tells the operating system, therefore, that the program is not going to provide the block size, allowing either the JCL or the actual data set to provide the block size. This allows changes from 3380 to 3390 to tape to occur with only a JCL change rather than having to recompile the program with a new BLOCK CONTAINS clause every time.

Does that mean if for DASD pools, (for example) a shop start using 3390 instead of 3380 - JCLs might need change? I think, this will be applicable only when BLKSIZE is hard-coded to some specific value in JCL?

[Robert Sample]

If the JCL is coded to use 23440 block size for a data set with LRECL=80, then changing the pool DASD from 3380 to 3390 would indicate a change in the block size in the JCL to use 27920; otherwise, the data set would be using more tracks than needed.

[Anuj Dhawan]

Thanks Robert. Having you around always gives a point or two to learn.

[Nick Jones]

Thanks Robert.

Should not we just leave this clause and let the system decide the BLKSIZE?

[Robert Sample]

It is HIGHLY recommended these days to use BLOCK CONTAINS 0 RECORDS. However, there are thousands if not millions of existing programs that have the block size hard-coded in the program. If the program is being modified, making the BLOCK CONTAINS 0 RECORDS change would be easy. However, if that is all that needs to be changed then it is probably not worth the effort of pulling the production code into test, changing, then promoting the code back into production.

[Nick Jones]

Thanks Robert.