「メインフレーム・コンピューター」で遊ぼうこんな時代に今さらメインフレーム・コンピューターに取り組むハメになったみんなが助けあうサイトです。RSSWordPress.orgコスパのいい社内システムの作り方メインフレームを扱っていると、軽い開発やメンテナンスにリソースを割けない、しかし、BPCも考えねば。解決策のひとつがクラウドにおくFileMakerです。コンソーシアム」設立のお知らせブロードリッジ、IBMと提携しハイブリッド・クラウド戦略を加速。Comment印刷用ページの表示データセットのI/O効率を上げる(続き)VSAMデータセットのCIバッファーを増やす(ランダム・アクセス)VSAM/KSDSデータセットBUFNI別100,000レコード検索処理時間KSDSのキーによるランダム・アクセスにおいて、INDEXコンポーネントのアクセス・バッファー数のみを増やしてみた場合の例です。グラフはバッファー数と実行時間および発行されたI/O回数と使用されたリージョン内メモリーサイズを示しています。実行時間はVSAMがデフォルトで設定するCIサイズ(18432バイト)でデフォルトのINDEXバッファー数(1個)の実行時間を1とした場合の、相対数値です。ランダム・アクセスではシーケンシャル・アクセスほどバッファー数増加の効果は出ません。左のグラフ(CIサイズ512バイト:INDEXレベル3)の例では、インデックス・バッファー数が4になったところで効果が頭打ちになっており、右のグラフ(CIサイズ2048バイト:INDEXレベル2)の例では、インデックス・バッファー数が2になったところで効果が頭打ちになっています。適切なインデックス・バッファーの数はINDEXレベルと大きな関係があり、INDEXレベルが大きければそれだけ索引レコードのアクセス回数が増えるので、インデックス・バッファーが多いと索引部のI/O回数は削減されます。何とかできないか、という感じです。ランダム性が高いほどDATAコンポーネントのバッファーは増やさない方がいいです。一度にいくつものデータCIを繋げて読んでも、結局使われずに捨てられるだけです。個々のI/O時間(データの転送時間)は長くなるので、逆に実行時間が増えてしまうことにもなります。INDEXコンポーネントのバッファー数の変更は、JCLのDDステートメントにAMPパラメーターでBUFNIを追加することで行うことができます。AMP='BUFNI=4'BUFNIあるいはBUFNDパラメーターではなく、BUFSPパラメーターでバッファー数ではなく、バッファーの大きさで指定することもできます。KSDSの場合、INDEXのバッファーが多く獲られるかDATAのバッファーが多く獲られるかは、プログラムがデータセットをOPENした際にデータセットをどのようにアクセス(シーケンシャル・アクセスなのかランダム・アクセスなのか)するかで変わります。DYNAMICのようにどちらのアクセスも可能にするようなOPENをすると、シーケンシャル・アクセスに適したバッファー割り振りがされてしまうため、その状態でランダム・アクセスを行うと、逆に実行パフォーマンスが低下しかねません。ランダム・アクセスすることがわかっていてもプログラムが両刀使いできるように作られている場合はBUFNIで明示的にINDEXバッファーを増やす方が確実です。