ブロックサイズ（BLKSIZE）
ブロックサイズ（BLKSIZE）
メインフレームのデータセットでは、レコードがデータセットの構成要素の最小単位です。ブロックは、複数のレコードをまとめたもので、ディスクやテープに記録される際の単位となります。レコードの大きさは、デバイスの特性や種類に左右されるものではなく、あくまでもアプリケーション側でどういうデータが必要なのか、といった観点で決めます。アプリケーションが処理に必要とするデータを並べた結果、これだけのサイズになる、ということです。しかしブロックの大きさは、I/O処理のパフォーマンスや資源の効率といった観点で決まり、時にはデバイスの特性にも左右されました。
昔は仮想であっても使えるメモリー量は今ほどではなく、MVS/XAより前のMVSでは16MBが上限でアプリケーションがREGIONに指定できるのも数MBでしたし、ディスクのトラックも十数KB程度しかない機種もありました。また今のように3390型ディスクだけでなく、トラック長の異なる複数の機種を接続して使うことも多かったのです。
そうした背景もあって、適切なブロックサイズを算出するための考え方はさまざまでした。大きければメモリーを食うし、小さければパフォーマンスが落ちます。またディスクのスペース効率にも影響するため、さまざまな機種でもフィットするようなブロックサイズが使われました。例えば、ロードモジュール・ライブラリーなどでよく使われた6447バイトや19069バイト、80バイト・レコードのJCLやソース・プログラム・データセットなどに使われた3120バイトなどがあります。3120バイトは現在でもTSOのTRANSMITコマンドなどでも使われます。6447や19069など奇数でずいぶん半端だとも思いますが、これは昔の3330ディスクの1トラックに2ブロック入れられる上限サイズであったり、3350ディスクのトラックにフィットする上限サイズであったりでした。
現在では仮想メモリーの量も増え、またI/Oバッファーも31ビット領域に獲得できるようになり（MSPを除く）、SAMデータセットやPDSデータセットにおいてはブロックサイズは大きいほどよい、という考え方に変わってきました。とはいえ上限である32760バイトまで増やしてしまうとディスクへの格納効率は落ちるので、ディスクの1トラックに2ブロック入る上限のサイズがよく使われます。
これらのサイズも今では計算する必要もなく（MVSの場合）、BLKSIZEに0を指定してアロケーションすれば、レコード形式、レコード長、デバイスの特性に応じてOSが最適なサイズを設定してくれます。またロードモジュールに関しては、MVSの場合、非PDSEではDFPの最大値である32760がよく使われます。32Kではトラックに1ブロックしか入らないからスペース効率が悪くなるように思えますが、バインダー（リンケージエディター）やIEBCOPYの再ブロッキング機能は、トラックの残りバイト数を見ながらショートブロック（BLKSIZE未満の小さいブロック）を書き出してトラック・スペースを目一杯使うのでスペース効率は落ちないようになっています。
いずれにせよ現在ではブロックサイズはOSに任せるのが得策です。BLKSIZE=0がサポートされていないOSでは、ディスクのハードウェア・マニュアルに載っているトラックに書き込めるブロックサイズ（物理レコードサイズ）とレコード数の早見表などを参考に、データセットのレコード長からブロックサイズを決めて行きます。
ブロックサイズに関しての関連する解説は次のページにも掲載されています。