メインフレームのデータセットでは、レコードがデータセットの構成要素の最小単位です。ブロックは、複数のレコードをまとめたものでディスクやテープに記録される際の単位となります。このような関係からレコードは論理レコード、ブロックは物理レコードとも呼ばれます。レコード（論理レコード）の大きさは、デバイスの特性や種類に左右されるものではなく、あくまでもアプリケーション側でどういうデータが必要なのか、といった観点で決めます。アプリケーションが処理に必要とするデータを並べた結果、これだけのサイズになる、ということです。しかし、ブロックの大きさは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ブロック入る上限のサイズがよく使われます。
これらのサイズも今日のz/OSでは計算する必要もなく、BLKSIZEに0を指定してアロケーションすれば、レコード形式、レコード長、デバイスの特性に応じてOSが最適なサイズを設定してくれます。また、ロードモジュールに関しては、z/OSの場合は非PDSEではDFPの最大値である32760がよく使われます。32Kではトラックに1ブロックしか入らないからスペース効率が悪くなるように思えますが、バインダー（リンケージエディター）やIEBCOPYの再ブロッキング機能では、トラックの残りバイト数を見ながらショートブロック（BLKSIZE未満の小さいブロック）を書き出して、トラック・スペースを目一杯使うのでスペース効率は落ちないようになっています。
いずれにせよ今日ではブロックサイズはOSに任せるのが得策です。BLKSIZE=0がサポートされていないOSでは、ディスクのハードウェア・マニュアルに載っているトラックに書き込めるブロックサイズ（物理レコードサイズ）とレコード数の早見表などを参考にしてデータセットのレコード長からブロックサイズを決めて行きます。
ブロックサイズに関しての関連する解説は次のページにも掲載されています。