「メインフレーム・コンピューター」で遊ぼうこんな時代に今さらメインフレーム・コンピューターに取り組むハメになったみんなが助けあうサイトです。RSSWordPress.orgコスパのいい社内システムの作り方メインフレームを扱っていると、軽い開発やメンテナンスにリソースを割けない、しかし、BPCも考えねば。解決策のひとつがクラウドにおくFileMakerです。コンソーシアム」設立のお知らせブロードリッジ、IBMと提携しハイブリッド・クラウド戦略を加速。Comment印刷用ページの表示ブロックサイズ(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では、ディスクのハードウェア・マニュアルに載っているトラックに書き込めるブロックサイズ(物理レコードサイズ)とレコード数の早見表などを参考に、データセットのレコード長からブロックサイズを決めて行きます。ブロックサイズに関しての関連する解説は次のページにも掲載されています。