I think you can safely try this out yourself. Little stub program, one input, one output, give it a compile. Try leaving it out altogether, including with a realistic value, an unrealistic value and with 0 (zero).
Any clean compiles you get, you can run and see what happens.
What results you get, from compiles and run, you can compare to the manuals (Language Ref and Prog Guide) and ensure that you've understood everything. Note, you've missed at least one other thing which is not influenced by BLOCKSIZE when coded.
From my perspective, whenever creating a new qsam file, specify BLOCK CONTAINS 0. This provides flexability that would not be obvious running an experiment or 2 (even if you had a mainframe available).
But the question could be as follows: does it make sense to specify this clause for input file?
Yes, it does. If the code specifiec block contains, it must match what is actually in the input file. Specifying zero eliminates this. _________________ Have a good one
However, for the input file, I wondered, as I always "copy" from another program, all my inputs do have "BLOCK CONTAINS 0". But, I've just tried with "BLOCK CONTAINS 2" for a dataset (FB) that contains more than two records per block, and the system quite happily read all the data in all the blocks.
I suspect, which is why I suggested looking at AWO, that the BLOCK CONTAINS may only be relevant for output where blocks don't already exist. If you look in the Prog. Guide for BLOCK0, it does say "Use BLOCK0 to change the compiler default for QSAM files from unblocked to blocked (as if BLOCK CONTAINS 0 were specified) and thus gain the benefit of system-determined blocking for output files."
I just ran with BLOCK CONTAINS 500 for my input (ie greater than the QSAM limit when multiplied together) and it ran the same. Omitting it, specifying 0, 2 and 500 all give the same processing for input.
Specifying 500 for my output, compiled clean but got IEC141I 013-20 at run-time, although the message text for that doesn't seem to cover what I've done (a blocksize of in the Cobol program of 40,000), but it is too late now to see if I bloopered something else
Well, in conclusion according to your explanations we can say that it is relevant to mention BLOCK CONTAINS 0 as much as possible for output QSAM files but it is not necessary for inputs. Nevertheless in this last case, if you want to use the BLOCK CONTAINS clause you should use it with 0 to be sure it matches with the blocking that has been already used.
For inputs I think the BLOCK CONTAINS is syntax-checked but not actually used at all. I'd like to find something specific in the manuals on that
I think I will change from using BLOCK CONTAINS 0 for inputs, to not specifying it at all,where local standards permit, once I can confirm that.
For outputs, I can't think of any reason not to always specify BLOCK CONTAINS 0. If there is a specific blocking requirement, it can always be done in the JCL and changed without having to recompile if/when that becomes necessary.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum