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.
Robert Sample wrote: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?
Thanks,
Anuj
Disclaimer: My comments on this website are my own and do not represent the opinions or suggestions of any other person or business entity, in any way.
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.
Thanks Robert. Having you around always gives a point or two to learn.
Thanks,
Anuj
Disclaimer: My comments on this website are my own and do not represent the opinions or suggestions of any other person or business entity, in any way.
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.