コラム：　世間の常識、GSでの非常識

　富士通のメインフレーム(GS21,GS,PRIMEFORCE)の特徴は、ハード・ソフトの信頼性と品質が高いことです。
　オープン化の流れに対応していくこともはちろん重要です。しかし、ハード・ソフトを理解せずに（今の常識かもしれないが）アプリケーション開発を行い、
運用すれば問題が起きるのは当然かもしれません。皆さんが気づいていないようなことを紹介します。

1. データベースはリレーショナル型(RDB)が一番	13. 社会を支える仕事をしている	25. 顧客満足度が低い
2. 技術者は専門家である	14. GS/PFの機能で内部統制できる	26. 【地方自治体の皆様へ】ホストは高い
3. メインフレームは多重処理に強い	15. メインフレームは昔と変わっていない	27. コンサルのありがたい助言
4. パッケージは安心である	16. メインフレームのセキュリティは強い（その２）	28. 機種選定の説明責任
5. 最新のサーバはメインフレームより速い	17. GS/PFの性能トラブルは少なくなった	29. メモリは大きい方がよい
6. メインフレームは信頼性が高い	18. 同じCPU能力なら処理時間は変わらない	30. CPU使用率を評価する
7. キャパシティ管理（性能管理）は重要である	19. 内部統制は概ね問題ない	31. できることからやろう
8. CPU削減のチューニングはむずかしい	20. 内部統制は概ね問題ない（その２）	32. 少し速くてちょっと安い
9. キャパシティオンデマンドサービスはお得だ	21. サイジングする	33. 仮想化(AVM)で性能をコントロールする
10. CPU使用率が100%、やれ大変だ！	22. メインフレーム事業を整理する
11. 技術者は専門家である（その２）	23. 性能データは正しい
12. メインフレームのセキュリティは強い	24. SORTはI/Oバウンドである

● 1. 世間の常識：　データベースはリレーショナル型(RDB)が一番
　富士通製RDBMSはSymfowareといい、ホストからPCまでサポートしている。（GSではSymfoWAREと記述する）
　GSで動作するリレーショナル型データベースとして、1993年頃、当時RDBⅡという名前で出荷が開始した。
　あれから13年、SymfoWARE使いこないしているシステムは多数あるが、一方で、性能トラブルを起こすプロジェクトは無くならない。
　一例として、既存のネットワーク型データベース(NDB)をSymfoWAREに移行するプロジェクトで、必ず起きる問題を以下に記載する。
　　　① CPU使用量は1.5倍以上になる。　　理由：NDBに比べて一つ一つのマクロが重い、SQLの記述が未熟なため
　　　② プログラムのリージョンサイズは3倍以上になる。　　理由：デフォルトでバッファが大きくとられている、元々メモリを多量に使う仕様である
　　　③ I/O回数が10倍以上になることは珍しくない。　　理由：インデックス設計をしなくても動いてしまう
　　　④ 多重処理能力が劣化することがある。　　理由：プログラム動作環境定義(PED)でアクセスモードを指定しなくても動いてしまう
　一番の問題は、①～④をみんなが知らないこと。取り返しのつかない状況になってから問題が表面化し大騒ぎとなる。
　性能はよくならず、CPUレベルアップ、メモリ増設による出費も増える。GSで何でもかんでもSymfoWAREは熟慮が必要である。

　追記：言いっぱなしでは読んで頂いた方に失礼なので...
　　　　　私たちは完成した（完成直前の）システムに対して性能改善の依頼を受けることがほとんどである。その案件のなかで、SymfoWAREまわりの
　　　　　チューニングをすることも多い。全く性能検証をしていないと思われるシステムも多数ある。お客様がシステムの責任者が性能検証に意識が向いて
　　　　　いるかどうか確認するのは次の問いかけで簡単にわかる。
　　　　　　「性能検証で使っているデータとツールを明示してください。」　　即答せず、担当者に確認させてもよい。
　　　　　具体的に４個以上でてこないと危険である。　

　　弊社は、GS/PRIMEFORCEのSymfoWARE（RDBⅡ)で構築したシステムの性能改善のお手伝いをさせて頂いております。
　　ご意見・ご質問等は専用フォームからお願いします。

<< ホームへ

● 2. 世間の常識：　技術者は専門家である
　多くのお客様は技術者を自ら選ぶことはできないし、技術者のスキルレベルも知らされない。
　そんなとき、雑談のなかで次の質問をしてみると、およそ期待できるかどうか判断できる。
　　　① あなた自身が、ユーザとしてGSを使っていますか。
　　　② 本稼動しているGSを最近見たことがありますか。
　　　③ 最近、GSを触ったのはいつですか。
　　　④ あたなのご担当は何ですか。
　紙の上（またはPCやWebの中）の与えられた情報（そもそもユーザ公開すべき情報）を持っているだけで、技術者（Engineer）とは言わない。
　アウトソーシングビジネス拡大も結構だが、「現場」と「中央」との溝を深堀しないよう注意して頂きたい。

　プロジェクトで問題が起きると、現場置き去りで内部調整に時間と工数をかけている様子は昔から変わってませんよね。
　ご意見・ご質問等は専用フォームからお願いします。

<< ホームへ

● 3. 世間の常識：　メインフレームは多重処理に強い
　GS21の900モデル、600モデルならおよそTrueです。
　しかし、多くのお客様が使っている中～小型機がそうでないことは、実際にGSを使っているお客様が一番ご存知でしょう。
　私はメーカの人（担当だろうが役員だろうが）に会うと、必ずこの問題を提起している。このことに気づいている人はほとんでいなし、納得して
くれる人も多くない。ただ、知らなかったことを理由にお客様に間違った情報を伝えるのだけは止めて欲しいので、今後も言い続けるつもりである。
　実際は、サーバよりはちょっと良い程度である。

　「次機種選定コンサル」を行うとこの結果がよく見えます。だから、お客様は納得し、具体的なアクションを考えることができます。
　ご意見・ご質問等は専用フォームからお願いします。

<< ホームへ

● 4. 世間の常識：　パッケージは安心である
　本来は定義が必要な言葉をわざと使った。パッケージなのか素材（部品）なのか？　安心とは何なのか？
　10年以上昔の話しだが、病院向けパッケージで特定のファイルがボトルネックになり処理が遅延する問題が多発した。一言でいうと設計チョンボで
あった。（もちろん今は問題ない）
　今はCPUもI/Oも速くなったので、以前のように目に見える遅延は少なくなった。その反面、無駄にCPUやI/Oを使っても測定しなければわからない。
この状況を私は「性能品質が悪い」と呼んでいる。具体的には次の２つの事象がある。
　　　①プログラムロジック上、無駄なテーブルサーチや有限ループをしている
　　　②無駄なSQLを発行している、処理が冗長している
　性能品質の悪い素材を流用してパッケージや新しい素材を作ったらどうなるか。自分の担当のところしかテストはしないし、問題が起きてもそれは
素材の問題だと責任転嫁する。そもそも測定しなければ問題も発覚しない。こんなことが起きていないか確認して欲しい。

　「性能診断サービス」では、独自に開発した性能品質の見える化を実現し、性能品質の悪いジョブまで落とし込むことができます。
　特にパッケージのバージョンアップを予定されているお客様にはくれぐれもご留意頂きたいと思います。
　ご意見・ご質問等は専用フォームからお願いします。

<< ホームへ

● 5. 世間の常識：　最新のサーバはメインフレームより速い
　間違ってはいない。幼稚なたとえだが、飛行機(サ)は新幹線(メ)より速いと言っているに似ている。最高速度（900Km/hと300Km/h)は利用者に
とって大きな問題ではない。トータルの時間、コスト、安全性、環境へのやさしさ等々の要因が関与してくる。
　メインフレームの大きな問題は、新幹線(メ)の料金を払っているのに、在来線並のシステムがとても多いことである。なぜ、クレームがあがらないのか？
理由は２つ考えられる。①お客様も技術者もその遅さに慣れてしまった、②新幹線に乗ったことがないので今の遅さがわかない。
　どうすれば遅いことに気づくことができるか。a)新幹線を知っている第三者に見てもらうか、b)自分自身が知っている遅い乗り物、例えば自転車(PC)
よりも遅いのは素直におかしいと思うことである。
　後者は冗談でなくよくある話しで、例えばPCより数倍遅いファイル転送などゴロゴロしている。転送能力＝転送量／転送時間を比較すればおかしい
ことは一目でわかるはずである。こんなときは技術者に相談するより私どもに相談して頂いた方が前向きに改善案が出てくると思う。
　話しを元に戻す。5時間のバッチ処理がサーバに移行したら0.5時間になったような事例をよく聞く。とてもすばらしい性能である。
　これを私なりに解釈すると、メインフレームが本来の新幹線レベルのスピードが2.5～3時間で、のぞみレベルにチューニングすると1.5～2時間、0.5時間
に到達するのは極めて正直難しいだろう。サーバはデータをメモリに展開してCPUをブンブン回すのだから仕方ない。あとは、信頼性、運用性、リカバリの
しやすさ、多重走行性（(3)で強くないと言っているが）が勝負である。

　今使っているメインフレームは遅すぎるのではないかと疑問に思っているお客様の相談にのっています。
　ご意見・ご質問等は専用フォームからお願いします。

<< ホームへ

● 6. 世間の常識：　メインフレームは信頼性が高い
　正確に言うと、「信頼性が高いシステムもある」、「信頼性が高いシステムを構築することができる」。「オープンサーバよりも相対的に信頼性が高い」。
　「信頼性が高い」を、安定したサービスを継続して提供しかつ障害時迅速に復旧する仕組みができていると定義すると、信頼性の高くないシステムは
本当に多いですね。
　玄関や窓に頑丈なカギをつけても、カギをかけないで留守にしたら意味がないでしょ。
　トイレと玄関のカギを交換したら意味がないでしょ。

　稼動中のシステムを動かなくするのは簡単です。
　昔よりもハード障害が減った、ハード性能が向上したので偶然うまく動いているだけかもしれません。
　例えばDISKが壊れたとき、本当にリカバリができますか。バックアップの取り忘れとかありませんよね。

（2009年8月11日追加）
　未だにあります。
　・データベースのバックアップをとっていないシステム。
　・更新後ログファイルをバックアップしていないシステム。
　・AIMを初期化モードで起動しているシステム。

<< ホームへ

● 7. 世間の常識：　キャパシティ管理（性能管理）は重要である
（2006年10月14日修正）
　断言します。ほとんどのメインフレームシステムではキャパシティ管理（性能管理）は不要です。
　そもそも管理って何なんでしょう。自分の管理もできない管理職ほど、管理、管理といいますが...
　日々、性能データを採取して、月末にグラフを作るのは管理でも何でもありません。現象に対してありきたりのコメントをしても、そこから気づきや行動が
伴わなければ意味がありません。
　では、何もしなくてよいのか？　ほとんどのシステムは何もせずに運用してますね。その結果、お客様には以下のような見えない影響が出ています。
　　・無駄な資源への投資
　　・遅すぎるサービスに慣らされてしまっている体質
　　・復旧不能な障害発生までのカウントダウン
　ではどうすればよいのか。年に数回、「第三者」に性能を見てもらうのが一番です。
　そのためには、性能評価プロセスの「①測る化」はできないといけません。
　弊社のコンサルティングを受けなくても、性能評価できる「第三者」かつ「２名」であればOKです。ただし、担当SEと全く違う事業部のSEがいですね。
　このちょっとした手間だけで、上にあげた根本的な問題が表面化してくるでしょう。
　ちなみに、私どもは、性能評価プロセスに従い、PDCAサイクルを回している状態を管理と言ってます。

　魂の入っていないキャパシティ管理なんで何の役にもたちません。今一度見つめなおしてください。

　ただし、アウトソーシングしているシステムは別です。プロが運用しているんだから、プロの視点で日々管理しているでしょう。それでお金貰っているの
ですから。今度、「アウトソーサは性能管理ができているかチェックシート」を作ります。お楽しみに。

<< ホームへ

● 8. 世間の常識：　CPU削減のチューニングはむずかしい
　10年以上前は言ってました。本当にむずかしかった。今では実は３つの意味があります。
　　・スキルも業務知識もないからできない。
　　・CPUをたくさん使ってくれた方が色々とありがたい。
　　・CPU削減の意味がわかっていない。
　2004年に執筆した論文をコメントと一緒に掲載しています。これを読んで頂けると、今何が起きているのかがわかります。
　　（注）論文はメンバー専用ページに移動しました。次回の論文にも事例あります。　メンバー登録は無料です。　⇒　説明｜登録フォーム
　だから、私はCPU削減にこだわり、お客様やSEさんのチューニングのお手伝いをしています。
　見える化するために、CPU/IO頻度分析という手法も開発しました。（次々回の論文で発表）
　CPU/IO頻度というのは、CPUとI/Oのバランスを意味し、正常値は20～40になるように設定している。
　　　20以下　　I/O頻度が高い（やせすぎ）
　　　20～40　　正常
　　　40以上　　CPU頻度が高い（太りすぎ）
　　　80以上　　CPUループ（肥満）
　CPU頻度が高い（太りすぎな）システムは、専門家のアドバイスを受けて適切なCPU削減（ダイエット）できるのです。
　肥満は本人が気づいていないから怖い。
　実際にCPUが削減すると、お客さん本当にびっくりして、大喜びしてくれます。

　この肥満プログラムをマイグレーションしてサーバで動かしたって性能出るわけありません。今のうちに問題をつぶしておいた方が後々楽ですよ。
　ご意見・ご質問等は専用フォームからお願いします。

<< ホームへ

● 9. 世間の常識：　キャパシティオンデマンドサービスはお得だ
　余分なCPUをあらかじめ搭載しておき、必要となったときに使った分だけ課金される方式をCoD(Capacity on Demand)といいます。IBMのメイン
フレームSystem z9をはじめ、オフコンのi5にも提供されているサービスです。たとえに話しに「置き薬」を使う人もいます。
　月末や年末の重い処理のときだけCPUを追加すれば、過剰投資をせずにとてもお得な気がします。
　現在、富士通のメインフレームにはこの機能はありませんが、今後どうなるかわからないので少し考えてみましょう。

　まず、コスト面から損益分岐点はどこにあるか。メーカの営業戦略によりますが、30～50日程度でないでしょうか。
　このとき、ユーザは月に2～3日の特異日を正確に把握している必要があります。
　あなたの担当しているシステムで考えてみてください。私の経験からいうと、業務のピークとシステムのピークにはタイムラグがあり同一日でないことが
よくあります。また、システムは、業務とかけ離れたところでピークになっているケースもここ数年よくあります。
　即ち、システムを継続的に見える化し、自らピークをコントロールする必要がある、これってまさにキャパシティ管理です。

　キャパシティ管理していないシステムでは、キャパシティオンデマンドサービスを効果的に使うことはむずかしい、また余計に費用が増える可能性も
あります。さらに、キャパシティ管理の費用もかかってしまいます。
　余程特異な業務でない限り、適切な能力のCPUを選択し、工夫して運用し、無駄使いは解消していくほうが重要だと考えます。

　いらなくなったCPUを返却できるサービスを提供してください。IBMも多分やってません。是非ともお願いします。

<< ホームへ

● 10. 世間の常識：　CPU使用率が100%、やれ大変だ！
　性能の研修会でこんな質問を出して、隣の人とペアワークをしてもらったことがあります。一緒に考えてみてください。
　　・状況：あなたはＡシステムの責任者です。今、ＡシステムのCPU使用率が100%になった、との報告を部下から受けました。
　　・質問：あなたはどう判断し、どんなアクションをとりますか

　アクションは驚くほどバラバラです。およそ以下の６つに分類できます。
　　　①事実確認　･･･　本当に100%なのか、いつも100%なのか
　　　②影響確認　･･･　業務への影響は
　　　③善悪判断　･･･　100%は良いことだ／大変だ／120%なのか
　　　④原因確認　･･･　原因はわかっているのか、データはとったっか
　　　⑤ルール遵守　･･･　XXさんに報告したか
　　　⑥対処　　　　･･･　CPU増強だ！
　当たり前と思っていることでさえ、みんな違った判断することを感じてもらうワークでした。

　ここでは①を更に細かく、
　　・何分間100%なのか。
　この事象を認識するには、
　　・CPU使用率の推移グラフの横軸（時系列）は何分間隔が最適なのか？
　　・10年前1時間間隔だったのが、今も1時間間隔でよいのか？

　論理的に説明するのはけっこうやっかいですよ（興味がある人は考えてみてください。）。私は10分間隔を基準にしています。
　そのシステムで動いているバッチジョブがカギを握ると思います。
　メインフレームはCPU使用率が100%でもちゃんと動きます（→論理的に説明のつく動き方をする）。すばらしい！
　反面、CPUループに信じられないほど無頓着になっている。。。

<< ホームへ

● 11. 世間の常識：　技術者は専門家である（その２）
　某社の運用部門に出したメールの一部です。なんの返事も返ってこないので皆さんにご紹介します。表題との関係はご想像にお任せします。

●もしも、７月から状況が改善していないなら...
　今後の最悪のシナリオは、仮想記憶不足をトリガーにしたシステム停止
　などの問題が発生し、業務に影響を与え、ある一部門に責任が押し付け
　られ集中砲火を浴びるケースです。
　私自身、この手の場面には何度も立ち合ってきましたが、肉体的にも
　精神的にも悲惨としか言いようがありません。
　このシナリオだけは避けなけばいけないと強く思っています。

●仮想記憶問題の本質
　表面的な仮想記憶不足はシステムパラメタを変更すれば解決できます。
　しかし、担当者に変更を指示してもそれだけでは解決になりません。
　なぜなら、
　　①仮想記憶問題やそのチューニングはシステム全体に影響を及す。
　　②多くの人は仮想記憶管理をよく理解しておらず極力触れたくない。
　　③仮想記憶問題は表面化した現象であり、根の深い問題が潜んでいる
　　　ケースが多い。
　①～③のサポートが重要なのですが、現場を知らないほとんどの人は
　わかっていません。

●実はよくある話しである
　現実は、誰も助けてくれず、当事者の方が頑張るしかありません。
　（当事者がいないケースもありますが...）
　適切な判断、正確な作業をして欲しいので、私たちはノウハウを公開し、
　依頼があれば相談にのっています。これが私の使命だと思ってます。
　（昔、自分のまわりにはこういう先輩がいました。）

　その気になれば1晩で解決することが、3ヶ月経っても何も改善しない。悲しいことですが性能問題の一面です。
　いずれ業種間格差についてもコメントします。
　ご意見・ご質問等は専用フォームからお願いします。

<< ホームへ

● 12. 世間の常識：　メインフレームのセキュリティは強い
　性能とセキュリティにはとても密な関係があります。ひとつ事例を紹介します。
　　a. 30分くらい前からAIF端末が異常に遅いことにAさんが気づいた。
　　b. SEのBさんは連絡を受け、コンソールからDISPLAYコマンドを数回叩いたところ、CPU使用率が100%であることがわかった。
　　ｃ. 特定のオンラインジョブがCPUのほとんどを使い続けておりループしているようだと判断し、お客様と業務担当に状況を伝え対応を協議した。
　　d. 原因調査のためメモリダンプを取得し、その後ループしているジョブを強制終了させた。
　　e. 運用マニュアルに従い、オンラインジョブの再起動を行う。暫くの間、異常動作をしないか監視をした。（当日は問題なし）
　　f. （数日後）メモリダンプを調査した結果、ループしているSQL文が判明した。
　　g. 業務担当にアプリケーションの調査を依頼したら、プログラムが特定できないという答えが返ってきた。
　
　性能トラブルの調査をしていると、このプログラムの動きがこんな風に（不要なDBを頻繁にアクセスしている等）おかしいと指摘することがあります。
　業務担当に伝えても、どのプログラムだかわからないと言われることがよくあります。
　もちろん、どの端末から処理されたかもわからない。何をやっているかもわからない。
　個人情報や財務情報のデータベースだったらどうするんでしょうね。
　これって、大量の費用と期間をかけてRACFを導入しても何も解決できませんから。。。

　ご意見・ご質問等は専用フォームからお願いします。

<< ホームへ

● 13. 世間の常識：　社会を支える仕事をしている？
　2006年11月20日日経新聞　第二部【全面広告】P.5下就職FORUM08の特別協賛企業の広告より抜粋します。
　・～社会全体を支えるビジネスをしています。「富士通が止まれば社会が止まる」と言っても過言ではないでしょう。。
　　⇒　まず最初に、本文すべてが他人ごとです。責任ある人が適切なチェックと担当者への指導をしてください。
　　　　一年前、自らが社会を止めたのを覚えてますか。日々どれだけ社会を止めているのか把握するプロセスはできていますか。
　　　　そもそも、富士通が止まっても社会は微動ともしないITインフラを提供しないといけないのではないでしょうか。
　・～当社に求められる責任は重く、社員には高いパフォーマンスが求められています。
　　⇒　あくまで「求められている」のですね。パフォーマンスは、それを測定し見える化しないと改善もできません。
　・～「新たなことにチャレンジする」といった姿勢を尊重するDNA(社風)を持つ会社です。
　　⇒　。。。　　　せめて、The FUJITSU Wayを引用するとかできないものでしょうか。
　・私たちと一緒に、社会を支える仕事をしませんか？
　　⇒　この文の終わりは「？」ってのが全てを語ってますね。

　新入社員のためにも、お客様のためにも、社会を支えている強い責任感を持って仕事をしてくださるようお願いいたします。

　ご意見・ご質問等は専用フォームからお願いします。

<< ホームへ

● 14. 世間の常識：　GS/PFの機能で内部統制できる
　弊社では昨年後半からGS/PF向け内部統制コンサルティングを一部開始し、お客様共通である多くの問題が見えてきました。
　fujitsu.comでも、昨年12月28日に「グローバルサーバにおける内部統制の支援機能」がようやく登録されています。
　ここで一番大切な部分は注意書きの部分ににあります。以下、一部抜粋します。
　　　「これらの機能を利用することで、すべてを順守できるようになるものではないことに留意ください。」(p.1)
　　　「本資料の内容は、現時点における展開の方向性を示していますので、状況に応じて、断りなく変更する可能性がありますのでご了承ください。」(p.4)
　支援機能は全然十分でないし（実際にその通り）、機能強化もコミットできないよ言ってます。これがベースラインになります。
　p.3～4は、今ある機能でこの程度のことならできそうだよ、と読むと丁度よい加減になります。

　さて、お客様に留意して頂きたいこと。
　　・今すぐ始めないと2008年4月に間に合わない。今現在、統制がとれていたかが監査対象となる。どのお客様も統制がとれていないのが現実。
　　・まず、ブラックボックス化しているGS/PFを見える化し、システム全体の現状、問題を把握をする。
　　　例）　財務関係のデータベースに、実際にどれだけのジョブがどうやってアクセスしているか把握していますか？
　　・RACF（セキュリティ支援のソフトウェア）に過大な期待をしてはいけない。（機能、導入費用・期間、運用、サポートSE）

　ご意見・ご質問等は専用フォームからお願いします。

<< ホームへ

● 15. 世間の常識：　メインフレームは昔と変わっていない
　実際、20年以上変わっていないものもたくさんあります。しかし、ここ数年でメインフレームの動きは大きく変わっています。
　現場から離れた部長さんが「メインフレームなんか昔からこう動くんだ」と言う動き方は多分今はしません。
　例えば、あるお客様で10年前と今、環境がどう変わったのか紹介します。

	10年前	現在　（カッコ内は10年前との性能比）
CPU	GS8400/10、メモリ128MB	GS21 400/10N（2倍強)、メモリ1GB(容量8倍、性能はほぼ同等)
DASD	F6427（ディスクキャッシュ付き)	ETERNUS6000(20倍)
データベース	NDB	NDBからSymfoWARE(0.5倍･･･？)へ
リージョンサイズ	1～5MB	最大10MB以上も
アプリの性能品質	良	CPU頻度が高い、CPU使用量が多い傾向へ
変わってないもの	***	１０年前から動いている業務アプリ、OSとシステムパラメタ

　①CPU性能に比べてDASD性能が約10倍良くなった。
　　　⇒　処理時間はI/O性能よりもCPU性能の影響を受けるようになる
　②搭載メモリ容量が大きくなり、ページングが起きなくなった。
　　　⇒　ほとんどオンメモリで動作し、多重度制限は不要になる
　③データベースは、しっかりした設計が必要なNDBから、適当に動くSymfoWAREになった。
　　　⇒　たいした処理でないのに、CPUだけはよく使う

　CPU・I/O・メモリ性能のバランスが崩れ、10年前のシステムパラメタはさすがに合わなくなってきています。
　どうなるか...　　資源に余裕がなければ、運用上非効率に動きます。

　ご意見・ご質問等は専用フォームからお願いします。

<< ホームへ

● 16. 世間の常識：　メインフレームはセキュリティが強い（その２）
　このページを読んでくださる良識あるあなたに質問します。「御社のメインフレーム、セキュリティに自信がありますか。」
　　昔のID残ってませんよね。
　　業務アプリを経由せずに、データベースさわれませんよね。
　　ジョブを勝手に実行できませんよね。
　　　　・・・
　　　　･･･
　確かに、メインフレームにアクセスできる人は少ないでしょう。しかし、端末さえ使えれば、どんなことができるかは想像がつくと思います。
　
　メインフレームはブラックボックス化していたでは言い訳になりません。
　リスクを明確にし、より信頼性の高いシステムに変えるのは今です。
　智恵を出せば、メインフレームはもっと賢く使えます。

　ご意見・ご質問等は専用フォームからお願いします。

<< ホームへ

● 17. 世間の常識：　GS/PFの性能トラブルは少なくなった
　統計をとっている訳ではありませんが、知人と話しをしても性能トラブルの件数は減っているようです。
　なぜでしょう？　考えられる要因。
　　業務開発などのイベントが少ない、ハードの性能がよくなった、OSが改善された。
　少しひねくれて考えると。
　　性能トラブルに気づいていない。遅いのに慣れてしまている。

　性能トラブルが無くなっていないのも事実です。問題なのは、同じ原因で起きること、問題解決が長期化すること。
　私は2005年から性能品質の低下を訴え、論文でも常に紹介しています。
　しかし、当事者の耳にはなかなか届きません。そして前回の過ちを忘れた頃、また同様のトラブルが起きています。

　余りにもおかしいと思ったら、第三者に話しを聞いてもらってください。
　私たちも、GS/PF性能アドバイザーというe-mailによる無料相談窓口を開いています。お客様もSEさんお困ったことがあれば利用してください。
　みんなの智恵を出すことが重要です。

　ご意見・ご質問等は専用フォームからお願いします。

<< ホームへ

● 18. 世間の常識：　同じCPU能力なら処理時間は変わらない
　さて、問題です。今使っているGSシリーズを最新かつ同じCPU能力のGS21に移行しました。周辺機器はそのままです。
　業務の処理時間はどうなるでしょう？　①同じ、②速くなる、③その他

　答えは③です。業務の特性により処理時間は変わってきます。
　私は今までの経験からお客様に、2割速くなって、2割遅くなって、6割はほとんど同じ、とお伝えしています。
　遅くなるってどのくらい遅くなるのか？　20～30%処理時間が遅延しても驚きません。逆にある処理が20～30%速くなっても普通です。
　一番の原因はメモリアクセス性能の違いです。

　このリスクを考えてみましょう。リスクを発生可能性×影響度に分解します。
　発生可能性を小さくするには、CPU能力1.2～1.3倍のCPUを導入するのが一番簡単。しかし、お客様の費用（特にソフト）が増加します。
　今まで色んな理由をつけてこの方法を進めてきたが、さすがに今は風当たりが強くなってきた。
　
　という次に影響度を考えます。これは業務なので一概に言えませんが、重要なのは、
　　・影響度が小さい業務は、遅延時間が許容範囲内ならよしとする。（受容）
　　・影響度の大きい業務は、遅くならないように手をうつ。（低減）
　ことです。そのためには現状の見える化が必要不可欠になります。特に「性能品質の悪い」プログラムは注意してください。
（誰だってできることです。私たちのコンサルは速いのがとりえです。）

　よく、I/Oバウンドの処理はCPU時間が延びても影響は少ないと言う人がいますが、非常に不正確かつ無責任な言い方です。
　どの処理がI/Oバウンドなのでしょう？　その処理を調べてみると、実はCPUバウンドで動いていることがよくあります。

　ご意見・ご質問等は専用フォームからお願いします。

<< ホームへ

● 19. 世間の常識：　内部統制は概ね問題ない
　最近、私はメインフレーム上に構築されたシステムをあえて「統制レス」、「セキュリティレス」と呼んでいます。
　お客さん、SEさん、またメーカの幹部にも早く気づいて欲しいので。
　あなたが担当されているシステムは概ね問題ないかもしれない。しかし、他の多くの上場企業や自治体のシステムはそう言わざるを得ません。
　初めてのお客様でも現場に行けば一目でわかります。
　現場を知っている皆さんならなんとなく気になってますよね。
　誰が悪い訳ではありません。メインフレームは限られた人しか使えないシステムだったので、システム上の統制やセキュリティは構築しなくれもよい時代
だったのです。時代が急に変わったので、見える化して改善しなければいけなくなっただけなのです。
　頑丈な統制システム、セキュリティシステムは不要です。（★重要★）
　まずは、悪いことができない必要最低限の仕掛けと、悪いことをしたらバレちゃうよって仕掛けを作ってみんなに宣言すればよいだけなのです。

　問題が起きて、社長が「何も知らなかった」、「全て○○に任せていたない」って言ったらどうします？

　一番心配なのは、数百のシステム全てを私たちがお手伝いすることはできないこととSEがいないことですね。
　（早いもの勝ちなのか力関係になるのか...　言っておきましたからね）

　ご意見・ご質問等は専用フォームからお願いします。

<< ホームへ

● 20. 世間の常識：　内部統制は概ね問題ない（その２）
　不運にも、GS/PFが内部統制の対象となってしまったら。

　普段、何台のTSS/AIF端末がLOGONされていますか。（何しているの？）
　一日に約何本のジョブが実行されていますか。
　ジョブの命名規約は守られていますか。管理者不明のジョブをチェックしていますか。
　ロードモジュールはどのライブラリにあり、いつ更新されたかわかりますか。

　わかっている部分の運用のフローを作り、それをチェックしたって合っているのは当然です。

　ジョブの棚卸は必ずやってください。情報はSMF（課金情報）にロギングされています。
　監査人のかたも大変でしょうが、SMFは監査ログとしても基本中の基本です。しっかり勉強してください。

　ご意見・ご質問等は専用フォームからお願いします。

<< ホームへ

● 21. 世間の常識：　サイジングする
　諸事情により、今お使いのGS/PFをリプレースする必要があり、費用対効果の高いマシンを選択したいお客様へ

　よい方法をお教えします。
　サイジングをしましょう。
　現状の稼動状況を分析して、CPUの能力見積り、必要なメモリ量の見積りをしましょう。　⇒　参考：有賀式－性能評価手法
　GS/PFから性能見積り、サイジングという言葉は無くなっています。
　パソコンじゃないので、無駄なCPUやメモリを積むのはやめましょう。

　それだけです。
　CPUの大きさにもよりますが、半数以上のお客様では、1～2ランクは下げられるでしょう。
　本当か？　　数日分のPDL/PDAを見ればおよそわかります。　⇒　参考：PDL/PDAについて
　主な原因
　　・稼動率が低い　（オープン系サーバも同様の傾向あり）
　　・一部のプログラムが多量の資源を使っている
　　・採用していた指標値が不適切だった

　SEさんにやらせても、ご自身でやってもかまいません。　⇒　参考：PDLの見方
　SEさんができない確立＝大　ってことは承知してください。（現場のSEさんも実は困っています）　　そんなときは、
　メンバ登録（無料）をすると、無料でPDAを見てフィードバックしています。　⇒　メンバ登録　　メンバー登録について

　ハードの値引きで妥協するお客様もいらっしゃいますが...　⇒　参考：メインフレームのコスト削減術
　お時間があれば、これも参考にしてください。　⇒　メインフレームの運用コストを削減する

　なぜ、サイジングしなくなったか？　　サイジングをしないことを常識にすれば、色んなメリットがありそうですね。

　ご意見・ご質問等は専用フォームからお願いします。

<< ホームへ

● 22. 世間の常識：　メインフレーム事業を整理する
　日経コンピュータ2007年4月16日号に富士通社長のインタビューが掲載されています。
　インタビューの最後でメインフレームについて語っています。（以下２行、抜粋）

　　メインフレームは少しずつ整理していきます。そうは言っても、メインフレーム上で動作しているお客様のアプリケーションが現実にある。
　　ハードに価値がなくても、アプリケーションを使い続けるインフラを提供することがお客様の価値につながっているので、そこは大事に考えていきます。

　この文面のままに発言されたとは思いませんが...　自社のコア商品を価値がないと言い切るのは恐れ入ります。
　私は、富士通はメインフレームの会社だと思ってますし、そのメインフレームに魅力を感じ、新しい価値を創出しようとしています。
　少しずつ整理をしていく...の意味を、2007年6月8日の富士通経営方針説明会の内容を参考にして想像してみます。
　参考として、課題としてシステムプラットフォーム事業の健全化があり、質疑応答では、サーバの種類を1/3にするとも言及しています。　(*a)

　　（想像１）メインフレームは売らず、されど無くさず。　（何もせずに入ってくるソフト使用料を確保しながら、開発費、販管費等を大幅にカットする。）
　　　　　　　おいしいソフト使用料がある限り、メインフレームは止められないでしょう。
　　　　　　　月額平均100万/台（実際はこの数倍？）としても、年間360億円以上が丸々営業利益になります。（ハード・ソフトの保守費用は別。）
　　（想像２）プロジェクトが走っているので、2009年頃予定の次期エンハンスは計画通り行うが、それ以降は計画なし。
　　　　　　　ソフトも継続して機能強化すると言ってますが、使ってもらえる機能を開発してくれればありがたいのにね...
　　（想像３）技術者確保が難しいので、メインフレームを使った新規（大規模）プロジェクトは受けない。
　　　　　　　 PRIMEQUEST XSPオープン化専用モデルは、（想像１）無くさずの手段で、既存資産を動かすだけが前提。
　こんな感じでいかがでしょう。

　この状況（想像）で、お客様はどうすればよいか一度考えてみてください。ご意見お待ちしています。
　今、メインフレームを使っているのは必ず強みになります。

*a　日経itproによると、ハード不振の原因は、①PRIMEQUESTの不振、②PRIMERGYの苦戦、③SPARC Enterpriseの出遅れ　

　ご意見・ご質問等は専用フォームからお願いします。

<< ホームへ

● 23. 世間の常識：　性能データは正しい
　性能データは思っているほど正確でないことがあります。
　そのため、私たちはできるだけ複数のデータを使って評価することで、矛盾しているデータを見つける努力をしています。簡単に分類すると
　　　○およそ信用してよいデータ
　　　△誤差の大きいデータ
　　　×信用してはいけないデータ
　となります。これは、データの採取方法やシステム環境によっても変わってくるので細心の注意を払う必要があります。
　特に、性能データを編集するツール（製品）の結果は信用しやすい傾向があります。

　データの使い方は２つに分類できます。
　　・性能データを使って、見えていない事実を追求していく。（仮説検証型）
　　・性能データを使って、想定された結論に誘導していく。
　状況によっては、後者は不適切な手法となります。（もちろんデータ改ざんなどの違法は許されません）。

　同じデータを使っているのに、全く違う結論を導くことがよくあります。
　データの評価をするのに、状況にマッチしていない、根拠のない指標値が使われたら全く意味がなくなってしまいます。
　これも非常に多いケースです。

　性能データを生かすも殺すも、かなりの部分が人に依存しているのが実態です。

　ご意見・ご質問等は専用フォームからお願いします。

<< ホームへ

● 24. 世間の常識：　SORTはI/Oバウンドである
　I/Oバウンドとは、CPUよりもI/Oの頻度が高い処理のことをいう。（←→CPUバウンド）。
　一見、SORTはI/Oバウンドで正しいように思えるが、これは10年以上昔のシステムである。今ではSORTのCPU使用量は、バッチ処理の2割前後を占めている。
　MSPのSORT V12、XSPのSORT-EXは、処理時間短縮のために大きなテーブルをメモリに作り、CPUをブンブン回そうとする。
（更に、IN,OUTのI/Oも効率がよくなっている）

　処理時間の内訳（10年前）

I/O	IN	OUT	WK	処理時間はI/O
CPU		（待ち）				CPU占有率が低い

　処理時間の内訳（現状）

I/O	IN	OUT	WK		処理時間はCPU＋CPU待ちかI/Oの遅い方
CPU		（待ち）	CPU占有率が高い

　I/Oバウンドではないでしょう。

　ご意見・ご質問等は専用フォームからお願いします。

<< ホームへ

● 25. 世間の常識：　顧客満足度が低い
　日経コンピュータ（2007/8/20号）で、恒例の顧客満足度調査が特集されており、メインフレーム(p.55)では今年も安定した５位（最下位）をキープしています。
　メーカ間の比較は雑誌にお任せするとして、お客様はどこに不満をもっているか考えてみます。
　富士通の中で点数が悪いもの
　　（2007年）　1. 保守サービスの料金、2. ハードの価格、3. 拡張性、4. 情報提供力
　　（2006年）　1. サービスの料金、2. 製品の将来性、3. ハードの価格、4. アプリケーション開発の生産性　　　（分類は違う）
　両年１位の日本ユニシスは上の順位でみると、(2007年)　1→2→4→3、(2006年)　1→3→2→4　なので類似しています。
　なお、有効回答数は、富士通(2007年)159、(2006年)256、日本ユニシス(2007年)69、(2006年)101に激減しています。（理由？）

　どのメーカがずば抜けて良く、どのメーカがとことんダメということでなく、メインフレーム業界全体の問題のような気がします。

　富士通のメインフレームが、お客様に高い価値を提供するためにすべきこと。
　サービスの料金については見積りの透明性を期待するとともに、第三者が検証する仕組みがあればよいと考えています。
　ハード価格が高いのは、大きすぎるマシンを導入する（マシンの稼動率が低い）ことが原因の一つです。

　製品の将来性や開発生産性は弱点だと思いますが、ハード・ソフトだけでなくサポートの信頼性を高めるとともに、タイムリーな情報公開・透明性がお客様の
信頼や満足度を高めることにつながると考えています。

　将来的にサポート力を高めていくため、富士通メインフレームの設計や運用を担当してきた技術者を募集しようと考えています。
　詳細がきまりしだいホームページで告知いたします。今すぐにでも手をあげたい方は専用フォームからご連絡ください。

　ご意見・ご質問等は専用フォームからお願いします。

<< ホームへ

● 26. 世間の常識：　【地方自治体の皆様へ】ホストは高い
　富士通総研のホームページにこんなレポートがありました。
　（政令指定都市A市における情報システム最適化コンサルティング、2007年9月26日　より一部転記します）
　　・・・ホストの経常経費内訳の分析を行った結果、全体の53%がハードウェアリース料であることがわかりました。
　　この結果を踏まえて、A市に対して、保有するホストコンピュータをオープンシステム化し､ハードウェアリース料の削減を目指すことをCSF（重要成功要因）とした
　　提案を行いました。
　　試算の結果、ハードウェアリース料のみで年間3.7億円以上の費用削減効果と、オープンシステム化のための再構築費用（またはマイグレーション費用）と
　　データ移行費用を加味しても、最短では6年での投資の回収を想定することができました。

　以下、一般論です。富士通総研のコンサルティングに対するコメントではありませんのでご注意ください。
　ホストコンピュータの経費が高いことが事実だとすると、その理由には以下のものが考えられます。
　ご契約のコンサルティング会社がいれば、きちんと検証しているのか確認してください。
　　①　本番機、開発機、テスト機を統合せず、複数台で運用している。
　　②　よくあるケースですが、必要以上に大きなCPUを導入している。即ち、CPUの稼動率が低い。（無駄なメモリ搭載もよくある）
　　　　　※ホストコンピュータの一番の強みは、CPU使用率が90～100%でも問題なく運用できることである。
　仮にCPUの稼働率が高いとき、
　　③　これもよくあるケースですが、業務アプリケーションの性能品質が悪い。（プログラムのできが悪く、CPUを無駄に使っている）
　　　　　※これは、CPU/IO頻度分析を行うと一目でわかります。
　　④　関係のないプログラムが動いてCPUの負荷率を高めている。
　　　　　※あってはいけないことですが、性能データを検証すればすぐに判明する。

　オープンシステムにマイグレーションする以上にコストメリットは出る可能性は大です。
　「ホストは高い」のではなく、「高いホストを使っている」だけではないでしょうか。

　システムの現状分析>>性能診断サービス、　CPUのグレードを下げたときの予測>>次機種選定コンサル
　ご意見・ご質問等は専用フォームからお願いします。

<< ホームへ

● 27. 世間の常識：　コンサルのありがたい助言
　内部統制や情報システムの最適化の案件で、コンサルの方々は専門外であるメインフレームについてもりっぱな助言をしなければなりません。
　コンサルが、富士通のメインフレームに詳しいか、ただの素人かを簡単に見分ける方法です。
　　　システムのぜい弱性を簡潔に指摘できること
　セキュリティ監査とか話しをむずかしくしてはいけません。これはわかっていない証拠です。面白いですよ、お試しあれ。

　ご意見・ご質問等は専用フォームからお願いします。

<< ホームへ

● 28. 世間の常識：　機種選定の説明責任
　メインフレームを導入する際、メーカはお客様のに対し、機種選定の説明責任を果たせますか？　果たしているでしょうか？
　自治体であれば住民に対し、このメインフレームを適切に利用している旨の説明責任を果たしているでしょうか？

　どうして現状分析をせずに、機種選定ができるのか。
　どうして使っていない高価なメモリやソフトを再契約するのか。
　どうしてレスポンスが遅い、資源を食いすぎるパッケージを我慢して使い続けるのか。
　外見だけコストをかけて二重化しても、実はリカバリが効かないシステムでよいのか。

　問題が発覚したら調査委員会を作って、再発防止策を発表すればよいのか。
　貧乏くじを引いた人が頭を下げればそれで済むのか。

　一般の人がわからない、情報が公開されていないメインフレームだからこと、透明化する必要があると考えます。
　これができるのが富士通のメインフレームです。

　ご意見・ご質問等は専用フォームからお願いします。

<< ホームへ

● 29. 世間の常識：　メモリは大きい方がよい
　PCでもメモリを1GB以上搭載する今、メインフレームで1GBにしましょうと言われても違和感を感じないかもしれません。
　PCのメモリは数万円程度でしょうが、メインフレームでは2桁は違うでしょう。
　MSPやXSPでは必要以上のメモリを搭載しても何にも使えません。ただ、使われないメモリが存在するだけです。
　逆に、実メモリを管理する仮想空間（共通域）が増えるだけ無駄とも言えます。
　中小型機では標準搭載のメモリ量や増設単位が大きくなっているため、必要以上にメモリが搭載されているケースがよくあります。
　メモリはよくわからないから、とりあえず積んでおけっていうのはよくないですね。

　ご意見・ご質問等は専用フォームからお願いします。

<< ホームへ

● 30. 世間の常識：　CPU使用率を評価する
　性能評価では当たり前のようにCPU使用率を評価します。これは本当に正しいのでしょうか？
　例えば、プロジェクトの「予算消化率」（実績÷予算）で考えます。
　　- 気がついたら、今月で予算消化率が90%を超えたので20%の追加予算を要求する。
　　- プロジェクト全体で効率化を進め予算を20%余らせてプロジェクトを完了したら、次の予算は一律20%カットされた。
　どちらも納得しないでしょう。普通は、実績の妥当性、予算（見積り）の妥当性、プロジェクトやマネジメントに問題がないか等評価しますよね。

　CPUだって同じです。CPU使用量（率ではない）の妥当性を最初に評価すべきです。そして、見積りはどうだったのか、予期していなかったイベント等あったのかを
　検証します。従来の慣習で・・・は許されず、説明責任も発生すると考えます。
　GSメタボ診断を行うと、CPUの使い方の問題もはっきりと見えてきます。
　　CPU使用率が著しく低い → 見積りに問題があった可能性がある
　　CPU使用率が著しく高い → そもそも問題なのか、問題でないのか

　CPU使用率の指標値っていったい何の意味があるのでしょう？

　ご意見・ご質問等は専用フォームからお願いします。

<< ホームへ

● 31. 世間の常識：　できることからやろう
　0の状態から半歩でも前進するために「できることからやろう」と号令をかけることはあります。
　しかし、限られた時間内で成果を出すためには、漠然とできることをやっても目標は達成できません。
　できることからやると、やっていることが目的化する傾向があります。無意味のないことならまだしも、逆効果のことをやっている可能性さえあります。
　これが悪化すると、どこかの国の偉い人のように自分は頑張っていると主張し、結果が出ない言い訳に智恵を絞りはじめます。

　性能改善のシーンでは、知っている人なら1時間で解決することも、知らない人は1ヶ月調査しても解決しないことはザラにあります。
　森を見ず、枝葉のチューニングをやっている事例も多々あります。
　問題の本質をとらえ、短時間で最も成果を出すアプローチが必要です。知っている人に聞くことが大切です。
　「できることからやる」といったコメントには注意しましょう。

　ご意見・ご質問等は専用フォームからお願いします。

● 32. 世間の常識：　少し速くてちょっと安い
　CPUのリプレース時期になると、CPU性能が少し良くなって、お値段は今よりちょっと安くなるマシンを勧められたことはありませんか。
　この裏には、現状分析とか面倒くさいことはやめましょうという想いが込められている気がします。

　CPU性能と業務処理の性能（レスポンス、スループット）の関係は、システムによって千差万別であり単純なものではありません。
　CPU処理は速くなっても、メモリアクセス処理が遅くなることはよくあります。遅くなったメモリアクセスをカバーするためにキャッシュの大きさで調節しています。
　CPU処理×メモリアクセス処理の平均値をとってCPU性能と言っていますから、CPU性能１→１への移行は遅くなる業務処理はかなり存在します。
　全ての業務処理を遅くしないためには、CPU処理を良くしなければならず、CPU性能は1.3倍前後にはなってきます。
　これを移行パスなどと言っています。
　CPU性能が少し良くなる＝移行パス以上なら問題ないのですが、1.2倍くらいだと遅くなる業務処理が出でも不思議ではありません。

　メインフレームで処理する業務量や処理件数が減ってきている今、移行パスどおりにCPUを大きくしていくとメタボ化が進んでいきます。
　1.3×1.3＝1.69、1.3×1.3×1.3＝2.179　　業務が減っているのにCPUは２倍以上、CPUの稼働率が低くなり（外の）メタボ化進行していきます。
　どうでもいいプログラムがCPUを使っていて、CPU使用率が高く見えること非常によくあります。これを内のメタボ化と言っています。
　メタボ診断を行うと、「少し速くてちょっと安い」オファーを受け入れるか、いやダイエットすべきかお客様が判断することができます。

　ご意見・ご質問等は専用フォームからお願いします。

<< ホームへ

● 33. 世間の常識：　仮想化(AVM)で性能をコントロールする
　問：次のシステムＡ×Ｂ、Ａ×Ｃで、ジョブをシングル走行させたとき、処理能力、処理性能、CPU時間を比較してください。
　　前提条件：　いずれもGS21で、メモリ容量、I/O環境は同じとする。
　　システムＡ：　100MIPSのCPUで、AVMを使ってCPUを30%割り当てる（上限指定ありAUTO）。ここでは、AVMのオーバヘッドは無視する。
　　システムＢ：　30MIPSのCPUをネイティブで使用する。
　　システムＣ：　システムＡのCPU割り当てを40%にする。

　回答：
　　Ａ×Ｂ：　処理能力はＡ＝Ｂ、処理性能はＡ（速い）≧Ｂ、CPU時間はＡ（大きい）≧Ｂ
　　Ａ×Ｃ：　処理能力はＡ＞Ｃ　（Ａ×３／４＝Ｃ）、処理性能はＡ≒Ｃ、CPU時間はＡ＝Ｃ
　CPU割り当てで処理能力はコントロールできますが、処理性能はコントロールできません。これは私の研究結果でメーカは認識していません。
　昔、AVM配下のI/Oが遅れて処理性能がＡ（遅い）＜Ｂとなる性能トラブルがありましたがこれは解消されているものとします。
　多重度が上がって、CPU負荷率が高くなると能力と性能が近似してきます。
　AVM配下とネイティブでは動きが意外と異なります。

　ご意見・ご質問等は専用フォームからお願いします。

<< ホームへ

2006年8月作成、2008年7月更新
株式会社アイビスインターナショナル
代表取締役　有賀　光浩

株式会社アイビスインターナショナル　134-0003 東京都江戸川区春江町4-17-12

コラム： 世間の常識、GSでの非常識

コラム：　世間の常識、GSでの非常識