★１６． ＷＮＴシステム管理のノウハウ・つづきの話へ
★１７． 当院システムについての職場意見の粗集約・その他へ
Chaos to Cosmso トップペ−ジへ戻る
１．南無サ−バ−神様 お怒りたもうな。
コンピュ−タ−は機械である。機械は必ずいつかは故障する。
サ−バ−も必ずいつかは故障する。
予兆ではないかと思えても、システムダウンがいつ発生するかを想定することは、地震予知同様に困難だ。
システムダウンが発生した場合、どうやって回復させるか、被害を最小限にくいとめられるのか、あわよくば、最小限の故障にとどめられないのか。
ＲＡＩＤ５、リアルタイム・デュプリケ−ト・ハ−ドディスクバックアップ、ＤＡＴテ−プでのバックアップと、とりあえずのデ−タ−復元対策（被害を最小限にくいとめる対策）をとってあるが、部屋の一面全部がガラス窓で直接外気に面している構造のサ−バ−室であるから、万万が一「落雷がサ−バ−室を直撃」したら、こうした対策も無力であろう。
サ−バ−管理では、システムダウンを「できるだけ発生させない」ことが第一の任務であると表向きは期待されているが、しかしそれは「絶対発生させてはならない」に限りなく近い無言の圧力のもとである。
５分以上のシステムの停止が無いように、サ−バ−はクラスタリング構成としているが、サ−バ−の電源が突然なんらかの故障で落ちて、サ−バ−が停止した場合にはたしかにクラスタリングが機能して、バックアップサ−バ−が走り出すけれども、そんな劇的な故障でなかったら、例えばＳＱＬサ−バ−がデッドロック現象の発生とかで機能しなくなった場合（この場合は、ＯＳは生きているのでサ−バ−は機能しているようにみえ、しかしクライアントへのデ−タ−の受け渡しがなくサ−バ−が黙り込んだ状態が発生するはずである）などへ対応できるクラスタリング技術は文献でみても開発途上で、本家のアメリカでもまだ信頼性は低いようだ。
それだけではない、たとえシステムダウンでなくても、例えば医師オ−ダリンクの各ステップが患者さん１人に１０秒ですんでいたのに、なんらかの要因で３分もかかりだしたならば、診療が停止してしまうこととなり、疑似システムダウン状態であり、許されない事態発生である。
つまるところ「南無サ−バ−神様 お怒りたもうな。静まりたまえ−。」と一心不乱に祈祷し、ご機嫌うかがいのお備えをかかさないのがサ−バ−管理業務である。
サ−バ−神様に喜んでいただけるお供えは大容量の増設用メモリ−なんですが、どんどんお供えしたくても、なにせ高価なものですからそんなに度々はできません。
それで常日頃は、ご機嫌うかがいを欠かさず、「バグ退散」「システムダウン退散」と悪霊退散の祈祷、インデックス再構築の祭壇整理などをおこなって備えるしか道がありません。
荒ぶるサ−バ−神「コンパック・プロライアント５０００」様の腹の内を、皆様ご覧ください。
心臓はＰentium-pro 200 が４本で、ＲＡＭはとりあえず３８４Ｍです。
私の人生は、今やこの神様がこの腹の中でなにをお考えになるかで、ふりまわされることとなってしまいました。
実際、病院業務のなかでもこんなに心臓に悪い業務はない。
大袈裟と言われるかもしれないが、巨大なブラックボックス集団を相手の２４時間、睡眠中でも心の隅で緊張しつづけて、心やすまることのない業務である。
ＷｉｎｄｏｗｓＮＴによる病院情報処理システム構築の経過から、スタンドアロンのＩＮＦＯＲＭＩＸでデ−タ−ベ−スを少々いじっていた私がサ−バ−管理者を担当することとなったが、Ｃ／ＳシステムのノウハウもＮＴの基礎知識もなしで（赤本のＮＴマニュアルは一応全Ｐながめましたが・とても理解などできません、はい。）実にあやうい管理者であると自認している。(；+_+；)
兆候などというものは、微妙な判断が求められるが、相談されるソフトハウスだって、院所ごとにハ−ドもメモリ−もクライアント数もアプリもシステム環境が異なるから、ノウハウ蓄積が少々あっても、微妙な問題への確答なんかできるはずもない。
病院内には、スタンドアロンのＷ９５オタクならいるからその相談はできるが、Ｃ／Ｓシステムでは皆無である。
結局、自問自答、所かまわず思わずブツブツ独り言をしてなんらかの結論を導き、とりあえずそれを信じている（暗いな−・アブナイな−）毎日でもある。
その自問自答と、突然発生するアクシデントでの悪戦苦闘やレ・ミゼラブルな現実をここにランダムに採録してみたい。
目次へ
２．パフォ−マンス・モニタ−の怪。天使のお通りだ！
デッドロック？まさかギャベ−ジコレクションではないでしょう？サ−バ−の作動状況を監視する機能として、ＮＴにはパフォ−マンスモニタ−機能がある。
下のグラフはモニタ−画面の一部分であるが、ＳＱＬサ−バ−の作動状況を、とりあえず次の項目で秒単位の連続折れ線グラフにしてモニタリングしている。
どなたか、もっと合理的適正なモニタリング項目設定があったら、教えてください。
Ｃａｃｈｅ Ｈｉｔ Ｒａｔｉｏｎを赤グラフで。
実際の表示はほぼ１００％？のレベルで水平一直線のグラフとなるが、もしメモリ−の異常があれば変動して検出できるのではないだろうかと、あまり根拠の無い期待をかけている。
Ｉ／Ｏ−Ｔｒａｎｓａｃｔｉｏｎｓ／秒を青グラフで。
これは単にトランザクション負荷をみるためで、サ−バ−が仕事していることを確認して安心するためであり、異常に高い値あるいは０となって表示されない状態が続いたら、心配せねばなるまいという位置づけです。
Ｉ／Ｏ−Ｐａｇｅ ｒｅａｄｓ／秒を目立つ黄色で。
実はこれが一番サ−バ−の応答レスポンスにかかわる重大なグラフです。
サ−バ−のメモリ−上にデ−タ−があり、応答レスポンスに全く問題ない場合には、このグラフは、基線０に張り付いたままです。
ところが、メモリ−上にないと、ＣＰＵはハ−ドディスクにある必要なデ−タ−をゴリゴリ（コンパックのＲＡＩＤ５は、ゴ−ゴリゴリゴリとうなるんですよ、ホントに。初めてこの音聞いたときは、故障かとビックリしました。）と読みにいき、とたんにグラフが跳ね上がり、このグラフが基線０に低下することで、砂時計状態で待機していたクライアントに返答されたことになります。
サ−バ−のレスポンスが悪い場合には、このグラフが２０を越えて跳ね上がったままでなかなか低下しません。
Ｉ／Ｏ−Ｓｉｎｇｌｅ Ｐａｇｅ ｗｒｉｔｅｓ／秒を水色で。
これは、ハ−ドディスクに必要なデ−タ−を書きにいっているのか確認用です。
Ｕｓｅｒ Ｃｏｎｎｅｃｔｉｏｎｓを緑色で。
これは、クライアントのサ−バ−への接続傾向のとりあえずの参考という位置づけです。
ですから、黄色のグラフ動向には神経をすり減らされます。（これは少々大げさです。というのは、常日頃は、診療事務課の１３名の職場の責任者ですので、サ−バ−のご機嫌伺いには、システム変更や設定あるいは何らかの問題発生の時にしかまいりませんので。）
めったに無いことですが「サ−バ−からのレスポンスが悪いようだ」などという連絡を受けてパフォ−マンス・モニタ−を観にいったときなどに黄色グラフが２０秒以上も上昇しっぱなしになると、「ひょっとするとインデックスが破損したのではないか」と脇の下がヒヤリとします。
もし、インデックスの再構築実施となれば、クライアントへの応答は停止して、再構築処理をおこなわざるをえませんから、通常業務のない深夜にしかできませんし、この再構築に成功しないかぎり、レスポンス低下から回復できなくなりますから。
ところが、時として赤と緑のグラフ以外のグラフが突然そろって０にストンと落ちる現象がおこる、それも処理の集中している午前の外来の一番忙しい頃に発生することを発見した。
瞬間的に１秒程度でのそろっての急落・急上昇を繰り返し示す場合(グラフは鋭い長い角が何本も生えた様に見えます)と、急落し２０秒程度０の静寂を示したままで突然急上昇を示す(まるで天使のお通りの様です)場合があります。
これって、デッドロックの処理なんでしょうか、まさか単なるバグとは思えませんのでどなたか教えてください。
１０秒もグラフが０基線にフラットに張り付くのを初めて発見した時は「スワ！サ−バ−からの応答が停止した。システムダウンなのか」と一瞬心臓が止まる様なショックをうけましたが、グラフが急に跳ね上がって平常状態となってもしばらくは、立ち直れませんでした。
まさかあのかつての悪名高きギャベ−ジコレクション（私はＭＺ８０Ｂだったので経験ありませんが・シャ−プＢＡＳＩＣはシンプルで好きだったな−。）ではないでしようし。
目次へ
３．サ−バ−メモリ大大増設を決意
１９９８年５月＊日再構築まにあわずインデックスファイルの一部が破損となる（;*_*;)病院会計前は、計算待ちの患者がズラリ。
一瞬、私はブラックホ−ルに吸い込まれていた。
デ−タ−がメモリ上にあるのか、ハ−ドディスク上なのかで、サ−バ−の処理レスポンスは１００倍〜５００倍の差が発生する。
このため、現サ−バ−は医師オ−ダ−処理に関するデ−タ−を優先してメモリ確保しており、医師オ−ダ−のレスポンス低下が発生しないようにして（念じて？）きたが、その他のアプリケ−ションは相互にやりくりをして３８４Ｍのメモリを使用していた。
そうした中で、医事会計については、レスポンス低下とならないように、関係するファイルインデックスのメンテナンスをくりかえす対策をとっていた。
ＷｉｎｄｏｗｓＮＴ３．５１は、多回数のデ−タ−の書き込みや修正のあるファイルのインデックスは安定性が欠けている様だ。（実は、ノウハウ不足でインデックスやメモリ環境設定がまちがっているのかもしれませんが･･････。これは後日の結果論ですが、やはりメモリ不足が、システムの安定を欠く原因でありました。）
昨日までは、快調なレスポンスであったのに、突然朝からハ−ドディスクのベタ読み処理としか考えられない応答レスポンスになることがあり（黄色のグラフが大山脈の造山運動を続け）、その場合にインデックスの再構築をおこなうとレスポンスが回復する現象がかつて発生したため、従来から約１ケ月に１回は、インデックスの再構築をおこなってメンテナンスしてきた。
しかし、医師オ−ダ−処理のデ−タ−量の増大にともない、こうした設定での対応が限界となってきつつあった。
しかも、５月からは、医療費の計算方法が厚生省の医療改悪で変更となり、従来は総合病院は受診した科での当月受診回数が問題であったので科を単位として会計システムを構築していたのに、科にかかわらず当月何回目の受診なのかが問題となってしまったので、急遽プログラムを手直しして、全科の当月受診状況から回数判定をおこなわねばならなくなった。
このため全科の受診デ−タ−を一応なめざるをえず、アプリケ−ションも重くレスポンスも従来より悪くなってしまっていた。
以上の結果、５月からは会計窓口では時に５〜６名に１名程度の割合で処理に２０〜３０秒かかる場合が発生しつつあった。
そしてついに５月＊日には、朝一番から会計処理のみが極端にレスポンス低下をきたし(ゴリゴリゴリゴリと黄色グラフはどこまでも連峰が続き)、会計待ち時間で患者さんに迷惑をかける結果となった。
３日ほど前より順次関連するファイルのインデックス再構築を実施してきつつあったのだが、まにあわなかった。
その瞬間、私が微小ブラックホ−ルに吸い込まれるｱｱ--！というムンク様の悲鳴が、あなたに聞こえませんでしたか。
やっとのことで、ええい！くそ！と、なんとかブラックホ−ルから抜け出して、え！ぬけれるわけがない？。ですから精神エネルギ−を燃え立たせハイになって、ホワイトホ−ルより３次元世界へ立ち戻るわけです。（微小ブラックホ−ル消滅の方法とホワイトホ−ルからの噴出のノウハウについては、英国の天才的理論物理学者ホ−キンス博士まで問い合わせください。）
とりあえず、今夜は会計処理の全インデックスの再構築をする対策をしようと、無理に叱咤激励。
しかし、約１４０台のクライアントＰＣが３８４Ｍのメモリ−にぶらさがり、しかも多様なアブリケ−ションが走ったのでは、サ−バ−も悲鳴をあげたいだろうな。
実際、アプリケ−ションサ−バ−(ＮＴドメインサ−バ−)で、時々走っているアプリ関係のファイルを調べることがあるが、８００本〜９００本が資源オ−プンとなっている。
３８４Ｍが少ないなとは思っても、苦しい病院経営状況では増設が言いにくかった。
単純計算で１クライアントＰＣ当たり３Ｍ以下のサ−バ−メモリでは、これまでまがりなりにもまともに作動してきたのが不思議なことなのかもしれない。（マイクロソフトさん、どんなもんでございましょうかね。あなたのところのマニアルには、こうした場合の判断方法やメルクマ−ルがなにも示されていないんですが。）
というわけで、ついにサ−バ−メモリ大大増設を決断。
え−−い１Ｇ。 ど･う･だ。(^^;)!（病院経営がたとえ赤字でも、断固として稟議書を通すぞと、鬼神のごとき決意である。）
目次へ
４．インデックス再構築するもレスポンス完全復旧ならず、対策に冷や汗どっとあふれる
インデックス再構築をおこなった結果、レスポンスはほぼ復旧した。ほぼ復旧とは、完全にはレスポンス復旧とならなかったからである。
どのアプリか判らないが、１日に２〜５回の率で５分〜１５分程度ゴリゴリとＲＡＩＤ５を読みに行く現象が発生し、パフォ−マンスモニタ−には黄色のグラフが山脈をつくり会計レスポンスダウンが発生。
さらには、１時間も会計処理へまともなレスポンスが帰らない、黄色の大山脈さえも２回発生してしまった。
また、いくつかの処理が重なった場合かとも思われるが、レスポンスに重たさを感じる状態も発生する。
こうしたレスポンスが悪い状態で、どのアプリが震源地なのかドメインサ−バ−で調査してみたが、その時はいつも１００台程度のクライアントＰＣに９００本程度のＥＸＥフアィルやＤＬＬファイルが走っていて、因果関係を特定できない。
仕方ないから、とにかく処理に１分以上かかるアプリの中に問題のアプリが隠れていると考えて、該当する全アプリ抽出をするために、各職場で聞き取り調査をおこなった、と書けばかっこがいいが、実はゴリゴリが始まるとその時間帯で仕事をしている職場でバッチ的な処理をしそうな職場に電話して、クライアントで走っているアプリを教えてもらったり、処理が中止できそうな場合は中止してもらって、サ−バ−への影響を調べるというバタバタ騒ぎの様な調査を冷や汗かきながらおこなうのが実態であるが。
次に、やっぱりあやしそうだなと抽出されたアプリをサ−バ−室のクライアントＰＣで走らせて、１本毎のサ−バ−負荷をパフォ−マンスモニタ−で判定してゆく。
実デ−タ−がないと走らないアプリだらけであるから、日常業務への試験による影響範囲も考慮して、とりあえずテスト可能なアプリをテスト可能な時間帯で順次走らせてみた。
それでも、冷や汗たらたらの調査の甲斐があって、これまで気がつかなかったけれど３本ほどの、ゴリゴリが再現するアプリを発見。(もちろん、まだ調査と試験済みは全アプリの１割にもたっしていない。)
当初のシステム稼働では、メモリ−に読み込まれるデ−タ−は少ない業務アプリに対応するだけで良かったのでゴリゴリ現象が発生しなかったのに、ここまでアプリケ−ションが拡大し複雑化すると、メモリ−環境に影響し、ゴリゴリ現象が発生することとなったとしか考えられない。この推理は正しいのかしら？
しかし、まだ１時間もレスポンスダウンが発生するアプリは特定できていない。
毎日きまりきって法則的に同じ時間帯に発生するなら調査しやすいが、発生日も時間帯もとりあえずランダムである。
どなたか、ＳＱＬserverがどのアプリのクエリ−処理要求でゴリゴリとハ−ドディスクを読んでいるのか解析できて、初心者でも使えるユ−ティリティを知っていたらぜひとも教えていただきたい。
この対策は、たとえメモリ１Ｇ増設するとしても、その前にきちんとしておかないと、いずれまた必ず発生すると考えられるから。
それはそれとして、最後の手段・救いの女神、１Ｇのメモリ−よ早くきてくれ。
目次へ
5．神よ万難辛苦を我に与えたまえ・・・・ああ地獄の１日
ところがその一週間後、間に日曜日をはさんで月曜日、朝一番より再度医事会計レスポンスダウン発生。とにかく会計画面に医師オ−ダ−情報が読み込まれなくなってしまった。
医師オ−ダ−のアプリは、支障なく従来からのレスポンスで作動しているのに、会計はそのオ−ダ−情報の参照取り込みが１患者に５分もかかってしまう。
サ−バ−は、それこそゴリゴリゴリゴリゴリ・・・・・・と黄色グラフの大大山脈が果てしなく続き、トランザクションさえも相対的に低く押さえこまれている。
結局１日中そうした状態で、会計前では患者さんが山をなし、とりあえず薬局からのお薬わたしを先にどんどんすすめるなどの対策を講じた。
原因はどこにあるのか、考えられる全ての場合についての仮説をもとに、ひとつひとつ検証しながら消去法で絞っていくしかない。（ショックで大半の脳味噌はブラックホ−ルに吸い込まれており、残ったわずかの能力を振り絞っての思考は、まともに機能しにくいものです。）
インデックスの再構築は実施したばかりだし、日曜日には大量の月報統計処理をおこなったがなんら支障はなかったし、同時に医事レセプトデ−タ−を過去１年以上さかのぼって患者別にグラフ化する重たいソフトも支障無く動いたし、で、それから後になにかこれまでとは違った障害が発生したことは漠然とわかったが、とりあえずは全く心当たりがなかった。
ひょっとして、といくつかの職場で走っていた重たそうなアプリをみつけては停止させてみたが、回復しない。
医事レセプトデ−タ−会計デ−タ−に少しでも関わるアプリは、全体がとにかく重たくなってレスポンスがかえらない。
メモリ容量に原因あるかとも考えたけれども、医師オ−ダ−のアプリはまともなレスポンスで動くことが確認できて、メモリ−が直接的な原因ではないと判断。
ということで、最終的に、医師オ−ダ−のデ−タ−を会計取り込みする部分のアプリがデ−タ−をまともに読み込めなくなっていると判断。
というところまで、ソフト屋さんとも電話でやりとりし、リモ−トアクセスでの調査もしてもらいながら原因を絞り込む。
とにかく、サ−バ−を停止させたり、調査のためのＳＱＬのクエリ−もあぶなくて投入できないなかでの絞り込みであり、もしこのとりあえずの結論がはずれたら、あすも地獄の１日となるなと、悲壮な気分。
夜９時サ−バ−からのサ−ビスを停止、それからはソフト屋さんの仕事。
医師オ−ダ−のデ−タ−がフォ−マットに誤り無くファイルに落ちているのか。
医事会計アプリのロジックになんらかのバグがあったのではないか。
医事会計アプリが開いて読み込むファイルにデ−タ−のズレ（広い意味でのインデックスエラ−発生）があるのではないか。
徹夜での調査検討とアプリ処理ロジックを段階的に走らせながらの検証が開始された。
明け方近く、医師オ−ダ−の処方をまとめているファイルに障害あるとしか考えられないことが判明。
で急遽、ファイル復旧としたかったのだが、それをしていたら朝からの診療にまにあわないかもしれない。
仕方ない、その障害あるファイルを回避して別のファイルから明示的インデックスで強引に医事会計にデ−タ−を読み込むアプリに書き換えることを決定して、作業開始。
結局朝８時過ぎになってアプリ変更が上がった。
ＩＳＤＮ回線でサ−バ−に新アプリを送り込んでもらい、医事会計アプリを立ち上げなおし、走らせた。
万歳、以前よりも快調なレスボンスでオ−ダ−を読んでくれるぞ。
そのあとも、確認や医事会計アプリ優先処理によるサ−バ−への負荷変動により他アプリへの影響がでたことなどなど・・・も外来医事会計を稼働させながら検証。
他アプリが少々レスポンス低下するという影響もあったが、混乱や困難を招くほどではないので、とりあえずの対策を終えた。
１Ｇのメモリ−くるまでに、ファイル復旧などの最終的な対策をたてようかな−−−、と虚脱して切れそうな神経で病院をあとにした。
それにしても、困っている現場の人が通常とは異なるアプリの作動状況を正確に報告してくれるのではなくて、そこの上司がサ−バ−室へたびたびきてはザラッとした状況（そんなことは聞かなくてもわかっているわい）を言い、どうなんだと問いつめる。
そんなこと答えられるならば、とうのむかしに復旧できているわい、とどなりたい気持ちをぐっとこらえて、彼も患者さんとの応対で頭に血が上っているんだろうと、とにかく言いたいだけ聞いてやる。
その間は、こちらの思考も原因絞り込み作業も中断。
わからんものがごちゃごちゃ口出しすることは、妨害にしかなっていないのに、根が仕事に対する善意なのだろうからと、ストレスを自己コントロ−ルしながら絞り込み検証作業をおこなうのが、一番つらかった。
ああ、神よ 我に万難辛苦を与えたまえ。
目次へ
６．突然動かなくなるＷ９５クライアント、クライアントＯＳもＮＴにすべき
クライアントＰＣはＷ９５をＯＳとしている。しかし、よくまあ不調になって、不調にしてしまって、動かなくなるものである。
サ−バ−へデ−タ−を読みにいって作動中なのに、故障と勘違いして電源スイッチを切ったために、ハ−ドディスクをキズつけてしまうという様な初歩的な故障から、ＬＡＮカ−ドをどうやっても認識しなくなって、Ｗ９５のインスト−ルをやりなおしとなるなど様々である。
アプリケ−ションを多数開きすぎて、メモリ−・オ−バ−でフリ−ズしてしまい「ＣＴＲＬ」＋「ＡＬＴ」／「ＤＥＬ」／「ＤＥＬ」さえもきかなくなって、強制リセット（レジストリ−が壊れるよ−−）などしょっちゅうだ。
でもクライアントＰＣのＲＡＭは３２Ｍしか搭載してないのに、業務アプリを７本〜８本もタスクバ−に常駐させて仕事しているんだから、時にフリ−ズしてあたりまえだ。
１９９７年前半は標準１６Ｍ時代だったんだから倍の３２Ｍに増設して、これだけあれば大丈夫だろうという感覚だったんだけれど、今にしてみれば業務用ＰＣにはＷ９５をＯＳにするならば６４Ｍ以上は絶対必要だと断言できる。（但し９６Ｍ以上積んでもＷ９５はそれ以上のメモリ−処理コントロ−ル能力ないので性能改善には役立たない様です。）
なおＷ９８については１９９９年３月現在で全く使用してないので、なにもレポ−トできません。
ものは試しと１台のＰU３５０ＭＨＺのＰＣだけＮＴワ−クスティションをインスト−ルして１２８ＭのＲＡＭつんで走らせてみたところ、フリ−ズなどという単語がありましたか、というような快調さ。
ＮＴの場合は、メモリ−積めば積むほど性能アップが期待できる。
従って、もしクライアントに投資できる余裕あったならば、ＯＳはＮＴにされることをお薦めしたい。
これも教訓・ノウハウである。
だからしてそりゃまあ、例えば１４０台からの自動車を管理していれば、パンクだとかライトが点灯しないとか毎日なんらかの事故や故障があるだろうから、Ｗ９５の使い方の作法も知らない職員が使ったならば、クライアントＰＣになんらかの不調が毎日２〜５台程度あっても不思議ではないかと、慰めている。
禁止してあるのにゲ−ムをやって、画面設定が６４０Ｘ４８０の２５６色になってもどらなくなってしまったので直してください、などという簡単なものから、サ−バ−にログオンしませんというので調べてみたらハブの電源プラグを抜いてあるとか、セットアップしておいたクライアントのシステム環境レジストリのどこかが書き換えられてしまい、１日かけて調べても原因がわからず、結局インスト−ルからやりなおしとか、動きませんというのでみてみるとｓａｆｅモ−ドでは立ち上がるので、ＳＣＡＮＤＩＳＫをかけてみるとファイルのサイズエラ−やら断片化やら次々に検出され、それらを修正したらなおったりとか････。
ＦＯＲＭＡＴしてもハ−ドディスクにキズがついていれば、その部分でＦＯＲＭＡＴさえもハングしてしまいますが、キズの部分と思われるあたりのみをスリ−ブにしたままでＦＯＲＭＡＴして、再度Ｗ９５のインスト−ルをしてＰＣを生き返らせるとか、ハ−ドディスクが全く認識されないとかＢＩＯＳからおかしいのではないのかといった様な故障でないかぎりは、ＰＣを生き返らせることができるようになった。
ファイルメ−カ−Ｐｒｏというソフトがある。
もともとは、ＭＡＣ上のデタ−ベ−スソフトであるが、最近Ｗ９５でも便利・容易なので医師に使われる様になってきた。
ところが、インスト−ルでのセットアップは注意しないと、通信のＴＣＰ／ＩＰ部分を書き換えてしまう。
医師から「ＰＣが突然ＬＡＮにつながらなくなった」という連絡を受けたのでいってみたら、ファイルメ−カ−Ｐｒｏをセットアップしたという。
ＯＤＢＣ環境も変更されているし、設定しておいたＴＣＰ／ＩＰ値が全部消去されていた。
この場合、Ｗ９５の再インスト−ルは免れたものの、ＬＡＮ環境へのセットアップにはなんやかんやで２時間かかって全部やりなおしとなった。
８太郎も初心者がインスト−ルすると、同じ様な結果をまねく。
診療所から、ＰＣがＬＡＮにつながらないと連絡をうけた。
とりあえず、本院のル−タ−をみたが問題はなさそうだ。
診療所のル−タ−が故障したのかな、と思いながら出かけてみた。
スイッチをいれてＷ９５が立ち上がって、ありゃ８太郎が立ち上がる。
こんな設定にはなっていないはずだ。
コントロ−ルパネルのネットワ−クを開くと、ないはずのダイヤルアップアダフタが設定されている。
ダイアルアップネットワ−クにはＪｕｓｔＮｅｔが設定されている。
これは、８太郎からインタ−ネットでジャストネットに接続しようとして、失敗した残骸である。
診療所と本院は電話回線で接続とはいえデジタル専用線だから、インタ−ネットには接続できないのに、初心者はＴＶなどで電話回線でインタ−ネット接続をしているのをみて、できると思ったらしい。
８太郎の設定しなおしや不要な接続関係のアダプタ外し等をおこない、さあ本院と接続としたが、接続してくれない。
ひょっとして、とル−タ−の電源を入れ直して再度接続、がダメ。
ル−タ−の設定が狂わされたのか？もしそうなら本院に持ってかえって設定やりなおしか、と頭に血がのぼりかけましたが、まてよ、だめでもともとと考え直して本院に連絡して、本院のル−タ−の電源を入れ直してもらいました。
と････こちらのル−タ−も生き返り接続できてしまいました。
あ−良かった・助かった。
皆さん、お願いです。
せめてＷ９５の入門書くらいは読んで、少しは作法を自分で勉強して下さいませ。
そしてクライアントＰＣに勝手に別のソフトをインスト−ルしたり、こっそりゲ−ムしたりしないで下さい。
それでも、少しずつではあるが、故障で呼ばれることはへりつつある。
ル−タ−の件で皆さんへの参考、あの有名なＮＴＴ＊のＳＯＨ＊１２８は、当院のＣ／Ｓシステムではゴミにしかならなかった。（４台も購入したのにデジタル専用線でＷＡＮを構成するという用途には使えなかった。）
ちゃんと仕事をしてくれたのは、ＹＡＭＡＨＡのル−タ−でした。
目次へ
７．ネットワ−ク・プリンタ−の維持は「レ・ミゼラブル」
救世主「ＺＯＴ５１５Ｓ Ｐｒｉｎｔ Ｓｅｒｖｅｒ」は優れもの。医師がどこの部署にいても、オ−ダ−指示記録が患者さんのカルテのある部署へプリント出力されるためには、プリンタ−がネットワ−ク・プリンタ−の設定になっている必要がある。
Ｗ９５でネットワ−クプリンタ−の設定をするのは、少しめんどうだ。
参考のために設定の概略手順をおさらいします。
まず、マイコンピュ−タ−のアイコンからプリンタを開き、「プリンタの追加」で、ネットワ−クプリンタを設定する。
つぎにコントロ−ルパネルからネットワ−クを開き、Ｍｉｃｒｏｓｏｆｔネットワ−ク共有サ−ビスを設定し、ファイルとプリンタ−の共有を設定する。
念のためＴＣＰ／ＩＰのプロパティから バインドにＭｃｒｏｓｏｆｔネットワ−ク共有サ−ビスが設定されていることを確認しておく。
こうした準備の上で、プリンタ−のプロパティから、プリンタ−の共有を設定する。
こうしておくと、プリンタ−が直接接続されているクライアントＰＣ(のTCP/IPのアドレス)上で、ネットワ−クを構成している他のＰＣからでも使うことができるようになる。
どうやって使えるようにするのかというと、１つの方法としては自分のＰＣの画面にあるネットワ−ク・コンピュ−タ−を開く。
接続表示されているＰＣの中から共有して使いたいプリンタ−が接続されているＰＣを選び、ダブルクリックするとプリンタ−が表示される。
表示されたそのプリンタ−をダブルクリックすると、さてこれから自己のＰＣの共有プリンタ−としての設定が開始となり、その作業が済むとやっとプリンタ−が使える様になる。
こうした事前準備のうえで、プリンタ−の調子が良好であること、共有プリンタ−を直接接続してあるＰＣがＬＡＮにきちんと接続できていること、自分の使うＰＣがＬＡＮにきちんと接続できていること、の３者が全て完全でないといけない。
ところが、上に紹介したとおり、しばしばクライアントＰＣが不調になり「プリンタ−が動きません」となる。
共有プリンタ−が直接接続してあるＰＣに不調が発生すると、そのプリンタ−をネットワ−クプリンタ−として共有設定してある全ＰＣから印刷ができなくなる。
医師がオ−ダ−しようという時に「修理すむまで何時間かかるかわかりませんが、待ってください」とはできない。
応急対策用にセットアップしておいたＰＣと不調のＰＣを交換して、とりあえずの急場はしのぐこととなる。
応急対策ＰＣのＴＣＰ／ＩＰのアドレスは、交換前のＰＣとは異なっている。（異なっていないとＬＡＮ接続用にセットアップできない。）
ということで、共有プリンタ−の設定は、ご破産となり、これまでネットワ−クプリンタ−で設定使用していた他の全ＰＣからはプリンタ−が使用できなくなる。
使いたければ、最初へ戻って設定を全てやりなおさなければならない。
１台のネットワ−ク・プリンタ−を１０台程度のＰＣから使用するように設定してあるのはざらにある。
プリンタ−が接続されている院内のＰＣの大半は、ネットワ−ク・プリンタ−の設定となってる。
「故障・不調」＝「レ・ミゼラブル」。
ところがよくしたもので、救世主がちゃんといらっしゃられた。
ＰＣにネットワ−ク・プリンタ−が接続されているから悲劇が発生するのだから、ＬＡＮに直接プリンタ−を接続すれば良い。
プリント・サ−バ−様のご登場であられます。
｢ここにおわしますは、ＺＯＴ５１５Ｓプリント・サ−バ−様であられますぞ｡｣
｢プリンタ−の陰でケ−ブルコネクタ−にちょこんと結合され、１０ベ−スＴのＬＡＮコ−ドが接続されているだけ、大きさもマウスの半分程度であられるが、プリンタ−に用のあるＰＣからは、自分のＰＣにプリンタ−が接続されているかの様にふるまうことを可能にしてくださる、たいへん尊いお方なるぞ。｣
｢頭が高い｣!!「は、は−−」というわけです。
これを設置すると、自分のＰＣが不調で印刷ができなくなっても、他のＰＣやプリンタ−には影響全くなく作動します。
値段も￥１６８００円／１台というわけで、ＰＣへの設定もネットワ−ク・プリンタ−の設定よりは簡単で、今後の活躍が期待できます。
目次へ
８．コンビュ−タ−システム導入の前にやるべきこと、経営の合理化
コンピュ−タ−システム導入で、どの様に合理化が進められたのかと質問される場合が多い。たしかに、それによって進んだ側面もあるが、どうも考え違いをされているのではないだろうか。
一般的には、コンピユ−タ−導入計画は、ややもすればそれが経営環境や労働環境の改善の鍵であるかの様に位置づけられがちですが、それ以前に経営内容改善や労働効率向上などの合理化がコンビュ−タ−システムとは関係なく徹底して実施されているのか、が一番大切なことと思われる。
コンピュ−タ−システムの中心能力は、日常的な人間組織による業務処理システムのうちの情報処理部分についての高速化効率化を実現するにすぎないから、人間組織による業務処理システムが非効率であるのをコンピュ−タ−化で全面的に改善することは不可能である。
ましてや、非効率であることを改善してきた実績から生まれる思想なしにコンピュ−タ−化しても「コンピュ−タ−化によりいっそう効率化していこうという」という問題意識や意欲が生まれず、コンピュ−タ−を全職員が業務に生かして使いこなすなどということは、夢物語になりかねない。
コンピュ−タ−化を推進しようとするならば、まず第一に経営内容改善・労働効率向上などの合理化に、経営幹部も労働組合も避けて通らずに対処する構えと、その面での実績をあげ、職員の思想にする努力が求められると思う。
そうしてこそ、例えば医師オ−ダリングなどの実現の道がひらかれる。
医師オ−ダリングは、率直に言って当初は新たな労働負担を医師に被せる側面が発生する。（慣れるにしたがい労働負荷はもちろん以前よりかなり軽減していますが）
病院全体の情報処理システムの最も合理的かつ効率的な方法が医師オ−ダリングであることが解っていても、全職員の経営努力・労働効率向上の努力の目に見える実績なしには、医師に「よし、全体の効率向上のために、みんなの努力に報いて、ここはしんどくても医師オ−ダリングをやろう」と決意させ奮い立たせることはできないと思う。
「みんなを楽させるためになんで医者だけえらい目をせねばならんのか」となったならば、「クラ−ク入力でいいじゃないか」などと人件費を拡大させる結果となり、経営改善には結びつかない。（もちろん医師オ−ダリングが可能なソフトであることを前提としての議論ですが）
別にこれは医師だけの問題ではなく、コンピュ−タ−化による効率化を実現しようとすれば、業務が楽になる場合もある反面で、逆に従来とは違った新たな業務負荷がいろんな部署で全体の効率化との関係で生まれたり、自分の部署の都合で業務処理してきたやり方がリアルタイム化で通用しなくなり、タイムスケジュ−ルに追われるコンピユ−タ−業務が発生し、かえって労働密度が増強する場合もある。
こうしたことへの熟慮や実績なしに単に「職員の業務負担がコンピユ−タ−化で軽くなれば」「経営効率で大きなメリットがあるのでは」などと漠然と考えてのコンピュ−タ−化は、昨今の医療をとりまく情勢からしても、経営的にも危険きわまりない。
目次へ
９．「仕様」、プロトタイプ方式時代の今は死語に近いんではないでしょうか。
しょうもない「仕様」は、しょうもないシステムにしか結実しない。しょうもある「仕様」？などというものを作成できるのですかね、私にはそんな能力はありません。
システムの「仕様書」を見せてもらえないでしょうかなどと私に問われても、当院システムの「仕様書」はないので見せられない。
でも現在でも例えば、本番稼働に向けてより具体的に仕様をつくりあげて････などと「仕様」という言葉が使われているようだが、かってのコボル言語全盛時代の考え方の「仕様」ということを意味しているのでしたら、これは今のオ−プンシステム時代には適応できないと思えてなりません。
たしかに過去においては、患者番号のインデックスは７ケタを使用し、発番はカルテ庫機器との関係から下２ケタをランダム発番しパリティチェックは････登録画面においては、図のどこそこの部分に･････････などとするいわゆる「仕様」書なるものがシステム能力の確認のために作成され、業者と病院との間での契約項目に含まれました。
それが可能であったのは、例えば従来の医事システムの様に、業務内容が厳密に確立され、担当職員も業務内容に精通し、従って処理できねばならない要件も明確になり・・・などの条件があったからです。
しかし、現在は情勢が大きく変化し、病院業務全般での情報処理システムを構築し全職員がコンピュ−タ−システムを活用することが前提です。（そうしないと効率化できない）
業務の内容も医療をとりまく環境や医療活動の変化発展にともない、変化発展し、各部署間の関係も一定ではありません。
業務の内容もたいへん幅広く多彩に豊かになって、極端に言えば時事刻々と変化しています。
そうしたなかで、コンピュ−タ−についての技術的知識のない職員に「仕様」書をつくらせるのは、不可能ではないでしょうか。
各部署の業務内容や部署間の関連について例外処理も含めて精通し、システム化範疇も判断でき「仕様」書が作成できるなどという病院ＳＥがいるとは考えにくいのですが。
私は、そんな能力ありませんでしたし、「仕様書」を作成している間に、業務環境が変化してしまい、つくりなおしの繰り返しとなるのではありませんか。
現に、当院で稼働しているアプリケ−ションで医療活動に関わる（医事の会計に直接は関わらない）アプリケ−ションは、現場の業務処理の要件が変更となって、機能追加や変更が次々に発生しています。
「仕様」書にこだわっていては、システム化の展望がみえてこないし、不十分な「仕様」書によりシステム構築をおこなったならば、職員に歓迎されない使われないコンピュ−タ−システムになってしまいます。
でも、コンピュ−タ−ソフト業者は、プロトタイプ方式であっても、社内では「仕様書」的な方式で作業をすすめているとは思いますが、ソフト開発会社の都合を病院が請け負う必要もないし、不十分な「仕様書」では悲劇と責任問題しか発生しないでしょう。
ですから、当院のＣ／Ｓ型医師オ−ダリングによる病院情報処理システム構築においては「仕様」書はつくりませんでした。
その代わり、当院の情報処理システムの現状と構築したい新情報処理システムの目的・意義についての説明文書を作成し、この内容については業者とかなり煮詰めた率直な話し合いをおこないました。
システム構築の方法としては、プロトタイプ構築方式でおこなうことをソフト業者と合意しました。
業者のＳＥがシステム化の必要な業務現場にでむき、業務の流れや情報処理の必要な範疇について業務現場で理解し、管理部や現場職員の要望を整理し、プロトタイプをつくりそれを現場にもちこんで説明や試験をおこなってさらに改善し、という課程をくりかえして現在のシステムの到達状況となっています。
ところがそれで終わりではなく、医師処方オ−ダ−は今後さらに８月には注射・検査オ−ダ−へとの発展させ、それにともない関係する様々なシステムも発展変化する予定です。
こうした方法でシステム化をすすめたため、各システムへの職員の熟練度もだれの目にも一定解るため、医事システムの本稼働以降は、毎月１業務システムづつが順次稼働していくかたちで、混乱なく進展しました。
もっとも、外来の医師処方オ−ダ−開始時には、職員で模擬患者６０名をつくり、３０分に４〜５名の診察処方ができるのか、念のためにシミレ−ションもおこないましたが。
ですから管理部も状況掌握は現場長の判断をもとにおこなえばよく、全システム一斉に用意ドンでもないわけですから、システム稼働について合理的な判断がしやすい経過となっていると考えています。
「仕様」書という発想法の過去の世界とは別の、もっと楽なコンピュ−タ−システムの構築方法もあるのです。
目次へ
１０．COMPAQ WindowsNT SQLserver VB4 Windows95 の組み合わせはなぜ
とりあえずの安全パイとして、マイクロソフトに統一「なぜサ−バ−(ハ−ド)をコンパックにされたのですか」と訊かれることがあるが、理由は明快です。
マイクロソフトがＷｉｎｄｏｗｓＮＴを開発・試験する標準プラットフォ−ムにコンパックを使用しているからです。
要するに、システムの安定稼働を考えた場合、少しでも不安要因を排除することが必要です。
つまり、なにかあったとき「ハ−ドとソフトの相性？が悪いのではないか」などといらぬ心配をしなくて済むからです。（ＤＯＳ−Ｖではまともにうごくソフトなのに、ＰＣ９８ではよくコケルなどということもありますから。またＷ９５ではまともに動いていたのに、Ｗ９８にバ−ジョンアップしたとたんにＯＤＢＣエラ−が発生している例もすでにありますし。）
次いで、「デ−タ−ベ−スソフトをかの有名な(処理速度と能力を大宣伝している)オラ＊ルにしなかったのはなぜか」とよく尋ねられる。
これまた理由は明確です。
マイクロソフトのデ−タ−ベ−スソフトのＳＱＬserverが、安定稼働しており、当院の必要とする処理能力はほぼ満たしていると判断できたからです。
有名なソフトハウスほどオラ＊ルを推奨しているようですが、それはアプリケ−ションが組みやすくソフトの生産性が高いからという理由が考えられます。
今は改善されたのかあいかわらずなのか知りませんが、デ−タ−ベ−スソフトの選択をどうするか検討した当時、いろいろ調べてみましたが、ハ−ドディスクのパ−ティション管理・ファイル管理がめんどうだということで敬遠したいなと思っていたのですが、それ以上にどうもＷ−ＮＴとオラ＊ルの組み合わせでは相性が悪いのか、システムダウンの例があちこちの先進例で観られました。
そして、システムダウンの原因の切り分けができず、どちらに責任あるのかなすりあっているようでしたので、組み合わせずにマイクロソフト一本の方が、なにかあってもクリア−につめられると考えたからです。
いろんなレポ−トから判断してみると、米国本土では、金融機関などのピ−キ−かつシビア−なシステムでは、安定性からもＳＹＢＡＳＥがデ−タ−ベ−スソフトのファ−ストチョイスの様でしたが、それを選びたくてもこれ以上予算枠を拡大できませんでした。
もっとも１０年ほど前、当時マイクロソフトのＬＡＮｍａｎｅｇｅｒがＤＯＳ上では重たすぎて悪評ばかりでどうしようもなかった時に、自社の能力では高機能デ−タ−ベ−スソフトを開発できないとマイクロソフトは判断し、ＳＹＢＡＳＥのデ−タ−ベ−スソフトをソ−スコ−ドを含めてまるごと買い取り、それをもとに、ＳＱＬserverを開発してきましたから、Ｗ−ＮＴとＳＹＢＡＳＥの相性が良くて安定しているのは当たり前なのでしょう。
病院情報処理システム構築にあたって、私はＣ／Ｓ型システム構築のノウハウも、安定稼働できるだけの技術能力もなかったので、安全パイの発想でサ−バ−からクライアントまで基本的にマイクロソフトで統一したわけです。
「こうしておけば、もしなにかあってもいざとなったらマイクロソフトに研明させることができるだろう（さて、どれほどマイクロソフトがユ−ザ−サイドから協力してくれるだろうか、ということはとりあえず問わないこととして）」「業務処理能力はとりあえずの必要条件には達するだろう」という判断でした。
目次へ
１１．救いの女神・１Ｇメモリの霊験あらたかなり−
待ちに待った救いの女神１Ｇメモリが到着した。拝みたい方もいらっしゃるでしょうから、女神様のヌ−ド写真（１Ｇのメモリ−写真）は、現像できしだい披露いたしましょう。デジカメがありませんので、はい。(^-~;)
と、できましたので、スキャナで１０２４Ｍ・８枚のメモリの写真を取り込みましたので、とくとご覧ください。
全体ではＫＩＮＧＳＴＯＮ・５１２Ｍが４箱で、サ−バ−とバックアップサ−バ−用である。
サ−バ−のメモリスロットに８枚ずつさして（スロットが堅くてなかなかささらなかった）、スイッチＯＮ！と思いきや、ＯＮできない。
え！どこか故障かとヒヤリ。
あ、そうだ、コンパックのこのサ−バ−は、カバ−をきちんとネジ止めしないと、ＯＮしてくれないのだ。
さすがサ−バ−と妙なところであらためて感心した。
ＲＡＭチェックカウンタ−で、１４４１７９２ＫＢの表示がされた。
感激の１．４４Ｇである。
で、そのうちの１．２ＧをＳＱＬｓｅｒｖｅｒに割り当てた。（これでこれまでの４倍の容量となった。）
さてその霊験であるが、なんと荒ぶるサ−バ−神が静かになられたことよ。
あのゴ−リゴリゴリというＲＡＩＤ５への読み込みがほとんどなくなってしまった。
むしろ、冷却ファンの音と書き込みに行った場合のツァササという音が耳につきだした。
そして、重いトランザクション処理をはしらせてみたら、下の青グラフの様に、ド−ンと走る。
ということで、全体的にレスポンスが改善しましたが、特に医事課で外来患者さんのうちの毎日２００名程度の患者さんに対応していた特別のトランザクション処理の固まりの様なアプリが、従来１名の処理に２分はかかっていたのがなんと５秒程度で終了するのにはビックラこきました。
その処理を担当していた医事課の職員は大ニコニコでしたが、私もこんなに劇的に効果のあるアプリも例外的にはあるのかと信じれないような気持でした。
会計まわりも、スパン・スパン・スパンという感じで、とにかく切れ味よくアプリが業務をこなして快適なレスポンス。 全体に影響を与えていた重たいアプリも、全く安心して走らせることができることを実験して確認。
やれやれ心配事がやっと少し減ったわい、ありがたいことじゃと女神様に感謝感謝。
その後のサ−バ−の調子は極めて安定、パフォ−マンスモニタ−上では、黄色のＲＡＩＤ５からの読み込みグラフは、少々凸凹のある地面とでも表現できるような、Ｘ軸近くをはいまわったグラフとなり、まれにゴリンと１０を越える尖りがみられる状態となりました。
それに対して、緑色の書き込みグラフが、約３秒前後の周期で鋸の歯の様に、２〜３の高さと０を上下する状況となり、これまた従来にない安定した表情が読みとれます。
負荷のかかる外来診療中は、黄色グラフはＸ軸にごく近くにあらわれていますが、むしろＲＡＩＤ５への書き込みの緑色グラフの方が黄色を上回って目立ちます。
７月になって月報統計アプリも走らせてみましたが、きわめて快調（大半がメモリでのトランザクションとなり、ハ−ドディスクからのデ−タ−の読み込み作業が２〜３割程度になったので、処理時間が大幅短縮）。
あわせて発見したことは、ハ−ドディスク・ＲＡＩＤ５からの読み込みが静粛なこと、黄色のグラフが山脈状になってもゴリゴリいわなくなってしまった。
ということは、サ−バ−が相対的にメモリ不足の場合には、デ−タ−の連続的な読み込みができなくて、ゴリゴリゴリと断続的な読み込みアクセスがされていたと想像できます。
そしてあの天使のお通り現象は、とりあえず発生していませんので、デットロックと言うよりはやはりサ−バ−が相対的なメモリ不足のなかで、メモリのゴミ掃除（ガベ−ジコレクション処理）をおこなっていたのではと思っています。
教訓（ノウハウ）ＳＱＬサ−バ−が、ゴリゴリゴリとハ−ドディスクに激しく読み込み処理を繰り返し、レスポンスが低下する現象が発生しだしたら、インデックスの再構築チェックも大切であるが、本質的にはメモリ容量不足に陥っていると考えるべきである。
その際は、思い切って大容量の増設で効果があがった本件を参考にして対処されることをお薦めしたい。
目次へ
１２．ＥＰＳＯＮのＬＰ１７００Ｓはリコ−ル対象だ
欠陥を認めようとしないＥＰＳＯＮの態度は、残念ながら自民党と同じである。プリンタ−についても評価をしますので、皆様の導入の参考にどうぞ。
当院システムでは、京セラＬＳ３５５０高速プリンタ−（レセプト印刷用１６枚／分・２台・導入当時は高速の部類だった）とＥＰＳＯＮのＬＰ８３００が１４台（請求書・領収書・処方箋・諸々報告書）とＬＰ１７００Ｓが２４台（検査説明書・予約券発行はじめ汎用に）とＣＡＮＯＮのＢＪＣ４２０Ｊが３０台（医師のオ−ダ−シ−ル専用）動いています。
プリンタ−の安定稼働は、紙詰まりするかしないかにかかっています。
１分間にＡ４サイズ何枚などというのは、紙詰まりしない場合はという前提でのことで、現場では必ずしも指定のプリンタ−用紙が確実に使用されるということばかりではありませんから。実際はレ−ザ−プリンタ−の紙詰まり除去の処理でしばしば呼ばれます。
トナ−部とか転写部を抜き取ってから、詰まっている紙を取り出すなんてのは簡単な処理で、これは看護婦さんもおこなっています。
実際には焼き付け定着部に折れ重なって紙詰まりして、プリンタ−を分解しないと除去できないという、しまつにおえない紙詰まりがときには発生します。
１７００Ｓは、本当によく焼き付け部に紙詰まりして、取れなくなります。
この場合１０本以上のネジをはずして、分解しないと紙詰まりが取れず、修理に半日（ホントに３〜４時間は必要）かかってしまうし、たいていはそんなに時間ないので、修理依頼せざるをえない。（紙の除去だけで１万円以上とられますので、ばからしいからできるだけ除去修理をするようにしているが。なおどこかのセンサ−が動作不良となってあと残り１ｃｍで排紙完了なのに「排紙部に紙詰まり」のエラ−コ−ドが表示され停止した場合は、どこにセンサ−があるのか技術情報が公開されていないので修理できない。）
焼き付け部に紙詰まり除去処理用のフタがあれば修理が楽なのに、ユ−ザ−が容易にメンテナンスできるように構造を考えてない１７００Ｓはリコ−ル対象の製品と思います。（どちらかといえば購入しない方がよろしい）
教訓 皆さんも購入時には焼き付け部の紙詰まり除去機能もちゃんと調べた方がよいですよ。
８３００は、焼き付け部への紙詰まりはめったにありません（毎日Ａ４を４００〜５００枚使用して、４〜５ケ月に１回程度、焼き付け部へ紙詰まり発生）が、焼き付け部に詰まったら最後、修理に出さないと取れません。（分解は１７００Ｓよりもさらに困難。）
従って、故障時のバックアップ用の８３００を別に購入して準備しておかざるをえません。
こうした欠陥の指摘とリコ−ル要求をＥＰＳＯＮにおこないましたが、言葉たくさんで無内容の返事がきた。
要するに「欠陥」とは認めない「リコ−ル」には応じられない、らしきことが、そこはかとなく"臭う"手紙であった。
「修理の期間は代わりのプリンタ−を貸し出すことも検討する」などと弁明しているが、紙詰まりした時点で業務が遂行できなくなるのだから、そんな弁明はリップサ−ビスそのものでしかない。
明確な反省が見えないＥＰＳＯＮは、参院選でぼろ負けしても反省できない自民党と同じで、これではユ−ザ−に見放されてしまうだろう。
とりあえず、８月に購入するＡ３クラス対応の６台は一番安価なＮＥＣに変えてみようと思っている。
京セラＬＳ３５５０は焼き付け部に紙詰まり発生しても除去用のフタをあけて簡単に取れますので、メンテナンスは一番楽でトナ−も安くお薦めできます。
ＢＪＣ４２０Ｊは、本体の必要空間がとにかく狭くても良いことと、このクラスではブラックインクカ−トリッジが一番大きいことで、狭い診察室でも使えると判断して導入。
それと、ブラックのヘッドのインク詰まりが簡単に対処できることである。
インクカ−トリッジを新品に交換すれば良いのですが、まだインクがいっぱいあって捨てるのがもったいない場合の方法はマニュアルには書いてありませんが、ヘッドが詰まって印字ムラがでた場合、マニュアルによるクリ−ニングでは直らなくても、インクカ−トリッジヘッドを本体からはずして、水をしみこませた柔らかいガ−ゼ等でヘッドを何回か拭いてやると修理できます。
ＥＰＳＯＮのブラックヘッドも本当によく詰まりますが、マニュアルにあるクリ−ニングでの対処で直らなかったら、ヘットにさわれないのでプリンタ−をＥＰＳＯＮに送ってヘッドの交換修理をしてもらうしか方法がありませんので、結局コストが高くなってしまいます。
ただし、紙送り機構はインクジェット方式ではＥＰＳＯＮ（ＭＪ８３０Ｃなど）が一番確実です。
４２０Ｊは、なかなかオ−ダ−シ−ルを上手に紙送りしてくれなくて、診療中の診察室などからプリンタ−が故障だとしょっちゅう呼ばれ、安定して紙送りできるオ−ダ−シ−ルの材質確定までには本当に神経が疲れましたが、目下は快調です。
７月１７日所用で東京へでたので、ついでに秋葉原のＬＡＯＸコンピュ−タ−館でレ−ザ−プリンタ−をみてきた。
京セラだけはおいてなかったので、最近の製品のできぐあいは不明、ＥＰＳＯＮも８４００は、８３００と比べると焼き付け部近くまで手が入れられるようにはなったけれども、もし焼き付け部内に紙詰まり発生した場合には従来より排紙困難となった。
つまり、従来は、別の厚い堅い紙を焼き付け部下部の紙送りへ挟んで、脇の歯車を強引に回転させると、少々の紙詰まりは、押し出して取ることができたけれども、８４００は歯車を回せなくなったので、この簡易排紙法での修理ができなくなった。
もひとつ都合悪いことにトナ−の型式が変更となって、従来の８３００用が使用できなくなってしまったので、トナ−管理が不都合となった。
ＮＥＣやＣＡＮＯＮは紙詰まり対策ができているだろうと一応確認できた。
時間がなかったので、展示してあるのをつついていびっただけで、紙の処理ル−トも想像するしかしかたない部分もある調査であったので、購入する場合には、あなた自身で十分調査が必要ですよ。
目次へ
13．なぜ病院で無線ＬＡＮ！？
なぜ病院で無線ＬＡＮを採用したのかという質問には、２つの側面がある。１つは、性能についてであり、もう１つは電波の医療器械への影響と安全性についてである。
病棟の看護婦詰め所は、かなり狭い。
その狭い詰め所に、１０ＢＡＳＥ−ＴのＬＡＮで３台のデスクトップＰＣを配置したかったのだが、看護部より２台しか承認されなかった。
そのため現在は、１台を医事の病棟担当優先で、もう１台を医師と看護婦で、譲り合いの精神（？）で使用している。
とはいえ、実際には何人もの医師が詰め所でカルテをみながら同時にＰＣへオ−ダ−をせざるをえなくなる。
２台のＰＣのいずれかが空くのを悠長に医師に待ってもらうなんてことはできない。
それで、医師には無線ＬＡＮのノ−トＰＣを１台ずつわたして、詰め所の空いているところのどこからでもオ−ダ−入力ができるようにしたわけである。
無線ＬＡＮの性能は、電波状態が最良の場合で１．６Ｍｂｐｓであるから、実用上は１Ｍｂｐｓ程度、つまり１０ＢＡＳＥの１割の性能と思えばまちがいない。
それで「医師が仕事になるか」ということであるが、仕事にはなります。
ただし、オ−ダリング処理については、軽四でチンタラ走る感覚とでも表現したら雰囲気が伝わるでしょうか、レスポンスの差はでます。
診療所とは６４Ｋｂｐｓのデジタル専用線でＷＡＮ結合していますが、比較にならないほど無線ＬＡＮの方がはるかに快適です。
医師の文書作成業務では、無線ＬＡＮでネットワ−クプリンタ−を活用できるためプリンタ−をノ−トＰＣに接続する必要がないことや、フロッピ−渡しなどということも必要なく、またプリンタ−が文書を出力する性能よりはるかに無線ＬＡＮの性能が良く、（無線電波の届く範囲なら）どこでも作業できるため、極めて快適に業務ができています。
無線ＬＡＮの導入決断においては、展示会などでの調査の他に、無線ＬＡＮがどの範囲で実用になるか関西電気といっしょに病院内で作動試験ができたことで、決断できました。
テレビでも屋根の上のアンテナの向きでゴ−ストがでたり映らなかったりする様に、電波は人間の目に見えないうえに、周囲からの反射や妨害遮蔽の影響など複雑な環境要因で、実用性が左右されますので、導入前の作動試験で無線基地の最良のポイント設定なども必要です。
なお、赤外線通信は、大部屋構造ならまだしも、病院の様に様々な空間に仕切られている施設では、実用にならないので当初から導入検討はしませんでした。
無線ＬＡＮ電波の医療器械への影響と安全性については、よく携帯電話が禁止の病院内で無線ＬＡＮは安全なんですかと問われる。
無線の電波が、医療器械を誤作動させるから、病院で使用するのは危険なのだと、どうも単純に思いこんでいるようである。
実際は、病院内では様々な電波機器が使用されている。
病院内で無線電波を使用しているもっともポピュラ−な機器は、患者の心臓の動きを監視しているテレメ−タ−装置です。
テレメ−タ−は心電計の一種で、心臓の動きにともなう電気信号を患者の身体に接触させた端子で検出し、無線信号で病棟の詰め所等の監視用モニタ−に送信しています。
もっと強い電波の機器としては、例えば手術用の高周波電気メスは、電波で患部を焼き切る装置であり、リハビリの筋肉を暖めて痛みを和らげる装置などは、電子レンジの一種である。
蛍光灯やテレビはもちろん電波がでているし、電気カミソリでも電波はでている等々、電波のでていない電気機器などなにもない。
要するに、他の機器に悪い影響を与えかねない強い電波が出ているかどうかが問題である。
ある空間における電波エネルギ−の強さ・電界強度が強すぎて、他の機器に誤作動をひきおこすかどうかであるが、例えば、違法の高出力ＣＢ無線機を積んだ自動車が近所を通過したときに、テレビの写りがおかしくなったり無線での会話がテレビのスピ−カ−から放送されたり、というような経験はありませんか。
この様な影響が、携帯電話で心臓のペ−スメ−カ−に現れた、ということで問題が大きくなったわけです。
携帯電話とＰＨＳでは、通信機から発信される電波の強度は２０００倍程度の差があり、ＰＨＳの電波で誤作動する医療器械などはまったく無い。
ただ、携帯電話もＰＨＳも外見上見分けがつかないから、病院内では一律に使用禁止（電源スイッチを切る）とするより仕方ない。
さらに、電波といっても、一定のスペクトル幅をもって放射されており、その帯域幅全体平均の電界強度は弱くても、ところがごく狭い帯域のみに集中して、例えば太陽光線の輝線スペクトルの様に、常時放射されていると問題が発生する場合もある。
こうした電波技術の問題とセキュリティ問題（電波ですから、誰でも傍受できるし、妨害もできる）を超微弱電波通信技術と帯域ホッピング技術等でクリア−して、アメリカで開発されたのが無線ＬＡＮである。
アメリカでは病院でどんどん使われているし、当院でも３８台が稼働しているが、何らの誤作動問題も発生していない。
なお、一応は私もアマチュア無線の技師資格を所有しています。
目次へ
１４．ついにハ−ドウエアクラッシュによるサ−バ−ダウン発生
直ちにクラスタリング機能が作動しバックアップサ−バ−が自動起動。従って、スム−スにシステム復旧････のはずであった･･のに･････････アア、危機管理は「船頭多くして船 山に登る」となっていたとは。
有休で韓国に数日間でかけた。（これはこれで収穫あったので、ホ−ムペ−ジのもも太郎伝説の続きとして「温羅のル−ツＳＯＲＡＢＯＲＵを訪ねて」という題でアップロ−ドしています。）
日本国内のどこにいても、やれどれそれが作動しなくなったと追っかけられていたから、ヤレヤレつかの間の自由人と、好奇心（ヤジウマ根性）のままに、韓国を観察してきた。
帰宅してみると２日前にサ−バ−ダウン発生との連絡。
クラスタリングが機能して、バックアップサ−バ−が処理を引き継ぐから、せいぜいシステム停止は１０分以内だろうとたかをくくって連絡をとってみたら、２時間半！も復旧しなかったとのこと。ゲゲゲゲゲ？！である。
そんなバカなと、状況を追跡調査してみると、危機管理が「船頭多くして 船 山に登る」となっていた。
おそまつな危機管理の顛末を教訓にしていただくためにここに恥をしのんで概略の要点を陳述。
1)簡単な経過
朝８時３０分時点では正常稼働していおり、医事会計の処理も快調であった。
ところが９時前ころいくつかの部署で、サ−バ−からの接続が切れ、再接続（ログ・オン）できなくなったが、多数の部署では順調に稼働している現象が発生。
留守を守っていたレスキュ−チ−ムの一員がハブ故障と判断し、ハブの特定と調査を開始して３０分たったころ、突然あちこちがうごかなくなり、障害がサ−バ−ダウンに拡大と判断してサ−バ−室へ急行。
やはり、メインサ−バ−のモニタ−がフリ−ズしていた。
バックアップサ−バ−のモニタ−電源をいれたところ、ＷＮＤＯＷＳ−ＮＴのロゴマ−クが表示された。
とりあえず「ＣＴＲＬ」＋「ＡＬＴ」＋「ＤＥＬ」でログオン、までは正しかったというか、実はそんな必要はなく、Ｗ−ＮＴのロゴマ−クが表示されていることは、バックアップサ−バ−が既に起動し、ダウンしたメインサ−バ−の処理を引き継いでいたのであるが、そうとは考えずに「起動途中で停止している」と思ったとのこと。
それで、ログインしたところ、パスワ−ド入力画面になったので「やっぱり起動処理の途中であろう」と思いこんでしまった。
とりあえず当院のシステムを構築したＣＳＳ社にＴＥＬして電話回線でサ−バ−の稼働状況をリモ−ト調査してもらったところ「サ−バ−は動いています」との結果が返答されたが、その頃サ−バ−室へは「あそこが動かん、ここも動かん」という連絡が集中しはじめ次々と「長」のつく方々がヤイノヤイノと集まりだした。
（実はＣＳＳ社より「動いています」と返事がきた時点で、サ−バ−室のクライアントを再起動してみれば、バックアップサ−バ−によりシステムが復旧していることが判明したのに、「起動途中」と思いこみパニックとなったうえに、ヤイノヤイノと騒ぎが拡大して思考停止となってしまっていた。）
だれかが「バックアップは動いていない」といい「サ−バ−のスイッチを切つて、再立ち上げをすれば良いのだ」といったので、メインサ−バ−とバックアップサ−バ−のスイッチを切って、再起動をかけたとき、バックアップサ−バ−モニタ−の「Ｆ８キ−をおすとスタンバイ」するという表示をみて、Ｆ８キ−を押してしまい「ＩＰアドレスが重複しています」の表示になり、いよいよパニックとなり、相談の結果またもやサ−バ−とバックアップサ−バ−の電源を切った。
「船頭多くして 船 山に登る」とは、このことであろう。
もう一度電源をいれて、再度サ−バ−の稼働状況をＣＳＳ社に電話回線で調査してもらうと「サ−バ−は稼働している、ログファイルでも稼働確認できる」と返事がきたので、先ほどからの再起動を何回かくりかえした経過を伝えたところ「メインサ−バ−のスイッチを切って、バックアップサ−バ−だけで稼働させるよう」指示があったので、メインサ−バ−を切った。
しかしクライアントが作動しないので問い合わせると「クライアントの再起動をしてください」と指示があったので、順次クライアント再起動をおこない、１１時３０頃システムは復旧した。
この頃、別のレスキュ−担当は、配線図をもとに故障したハブを特定し、予備として設置してあったＳＷハブを故障したハブの場所に臨時移設して、１２時には修理を完了した。
2)故障の順番と個所
最初はハブの故障であるが、原因は不明。
ただしハブの設置方法が鉄製の箱の中に蓋をした状態で、２台ずつ積み上げてあるため、放熱に問題あって故障した可能性がある。
そのあとでサ−バ−の４ＣＰＵ（ボ−ド）のうちの３ＣＰＵ（ボ−ド）の死亡事故が発生、原因は不明。
ただし、時間経過から、当日の朝までは、正常であったと思われるので、たまたま４ＣＰＵのうちの３ＣＰＵが（ハブ故障となる前の）クライアントからの処理依頼で作動している最中に、ハブ故障となり、処理へのクライアントからの応答がないままにＣＰＵが異常暴走し、発熱により故障となった可能性は考えられないだろうか。
3)危機管理
今回、復旧が遅れた理由は、自動的にバックアップサ−バ−が起動していたにもかかわらず、それが判断できなかったこと、またその際は各クライアントを再起動すれば障害から回復することにだれも気付かなかったことです。
こうしたことについて、実際の危機管理訓練演習おこなうと全システムの一時的な停止を２回おこなって元に戻すこととなるためその間業務ができなくなるので、これまで実地訓練ができておらず、バックアップサ−バ−が起動した状態についての実際の状況の経験がないので、本当にバックアップサ−バ−が起動されているのか判断ができなくて混乱したことも事実です。
また、危機管理についての体制ではパニックのなかで「船頭多くして 船 山に登る」的に諸説紛々となりＣＳＳ社との打ち合わせとそれによる判断で、順次手順を考慮しながら回復処理をおこなうというプロセスがとれていません。
それでもバックアップサ−バ−体制とバックアップハブ体制をとってあったことが、不幸中の幸いで、これ以上の混乱の拡大を防ぐこととなりました。
4)今後のシステムレスキュ−対策
障害が発生した場合は、レスキュ−責任者にまかせ、周囲があれこれ注文つけて引き回さないことが第一に重要です。
レスキュ−チ−ムの実地教育・訓練として、ＣＳＳ社とも相談のうえ、システムダウンのレスキュ−訓練をおこないます。（このときは、一時的に２回システムが停止し、業務ができなくなりますので、土曜日午後とか日曜日に計画的に実施します）
今回のシステムダウンで、各部署の業務、特に患者さん対応にどの様な支障が発生したのか、その支障を最小限の混乱で乗り切るためには、今後どういった業務対策・代行処置が各部署で必要かまとめます。
全体ではどういった対策が必要なのかまとめ、危機管理マニュアルを作成します。
こうした、全体の対策が有効に機能するのか点検し、訓練するために火災訓練と同様に半年〜１年に１回は、病院全体でのシステムダウン対処訓練を実施します。
目次へ
１５．我がＰＣはデフラグによりハルマゲドン状態
さて、ひきつづきシステム構築はすすめなければならないし、故障したハブの完全修理も必要だし、特にハブの工事は冬１２月にやったので設置場所が夏に温度がどれだけあがるかわからないまま工事してしまったのが致命的弱点であったと反省。病棟の注射や検査や栄養の医師オ−ダリングを軌道にのせるため、とりあえず外来まわりの医師のストレスを少しでも解消しようと、セレロン３００に６４ＭのＲＡＭ積んでＷ９５のＣバ−ジョンをインスト−ルして、ＰＣを配置しようと準備したら、Ｗ９５が終了処理でフリ−ズして正常終了しなくなって、毎回スキャンディスクが走ることとなってしまった。
スタ−トアップを空白にすると、とりあえず正常終了はできるようになった。
ところが試しに実際外来でオ−ダリングのアプリを走らせると、終了処理で時に正常終了せず例の「しばらくお待ち下さい」画面でフリ−ズする。
セレロン３００が悪いのか、Ｗ９５Ｃバ−ジョンが悪いのか、・・・・どうもＣバ−ジョンが悪さをするように思えてならない。
Ｃバ−ジョンはセットアップでＩＥ４．０のセットアップをせざるをえない様になってしまっているが、この４．０が犯人かもしれない。
また、キャノンのプリンタ−ＢＪＣ４２０Ｊもインスト−ル後にプロパティでスプロ−ル機能の詳細を開き「双方向通信をサポ−トしない」を選択しないと、作動しなくなってしまった。
こうした問題を解決しないと先に進めなくなって、目下あらたな苦労を始めている。
やれやれ。
などとしていたら、突然自宅のデスクトップＰＣのＷ９５がクラッシュ！！
原因はデフラグ、作業中に起動したのでじゃまだからと、ついキャンセルした瞬間、ｍｙ−ＰＣはフリ−ズして死んでしまいました。
ディレクトリがメチャメチャでユ−ティリティもデ−タ−も吹っ飛んで私のシステム環境はハルマゲドン状態、それでもとやってみましたがＷ９５の修復セットアップも失敗。
結局ＦＯＲＭＡＴして全部やりなおし。
やれやれ、とりあえず原始時代のＰＣ環境にまではなおったわいと。
ところがＥ−ＭＡＩＬのパスワ−ドエラ−が発生で、いろいろ設定しなおしても直らないしホ−ムペ−ジのアップロ−ドももちろん不可能なので、これはＷ９５かＩＥ４．０１のセットアップをミスッタわいと、再度ＦＯＲＭＡＴからやりなおし。
それでもホ−ムペ−ジは観えるのに、メ−ルはダメ。
そんなバカナ！？、え−いこの際Ｗ９５をＣバ−ジョンにして、ハ−ドディスクも交換してみてやれ、とまたまた徹夜の大作業。
でもメ−ルはそれまでしてもパスワ−ドエラ−でダメ。
と････どうもこれは、我がＰＣが犯人ではなさそうだと、まともに動いてメ−ルも読めているＰＣをかりてメ−ルを試してみると、私のメ−ルパスワ−ドの場合だけエラ−となって読めない。
プロバイダ−のＴＩＫＩＴＩＫＩに連絡して「私のパスワ−ドのデ−タ−が壊れているから修復を」と依頼。
やれこれでなおったわい、と････やっぱりパスワ−ドエラ−。
そんなバカナと再度ＴＩＫＩＴＩＫＩに連絡すると「スワ−ドは壊れていない」の返事。
はは−、これはＴＩＫＩＴＩＫＩのパスワ−ドデ−タ−ベ−スシステムがたぶんインデックスエラ−を内包しているなと思った（なぜかというと、ＩＮＦＯＲＭＩＸなどのデ−タ−ベ−スを操作していた経験から、通常の参照ではデ−タ−が検出表示されるのに、そのデ−タ−を使用してファイル結合処理をするとエラ−となり、調べてみるとインデックスエラ−発生の初期であった、という経験が何回もありました）ので、パスワ−ドの変更を依頼。
そんなこんなで、新しいパスワ−ドで約２週間してやっとメ−ルも読めるようになった。
さあ、これでホ−ムペ−ジへのアップロ−ドも可能となった、と思ってＦＴＰソフトでホ−ムペ−ジの追加更新デ−タ−をＴＩＫＩＴＩＫＩの私のｐｕｂｌｉｃ＿ｈｔｍｌにｕｐｌｏａｄ。
ところが、ｕｐｌｏａｄした内容にホ−ムペ−ジが変わらない。
最終更新日をデ−タ−で表示しているので、更新できたかどうかは、ホ−ムペ−ジを開いたら直ちにわかる。
しかたないのでストレスを我慢しつつ翌日、ホ−ムペ−ジシステムの私の部分が壊れていることをＴＩＫＩＴＩＫＩへ連絡。
「調べてなおします」とのことであったが、１５日午後１１時３０分現在なおっていない。
いつになったら、私のシステムは「まとも」なシステムになるのだろうか、ああ−−−と思いつつｕｐｌｏａｄしたｐｕｂｌｉｃ＿ｈｔｍｌフォルダ−のファイルを調べてみると「なんたるちゃ！、先頭が大文字のファイルと小文字の同名ファイルが同居しているではないか、犯人はこれであったのか」と先頭が大文字のファイルを消去。
つまり私が、私のＰＣが壊れて、ぶっ飛んだホ−ムペ−ジファイルをなんとか復旧させたのであるが、先頭を大文字にするというミスを犯していたのであった。
今回はｔｉｋｉｔｉｋｉは悪くなかった。
実は、我がデスクトップＰＣがブッ飛んでしまった時、なんたることかＰ−２００の我がノ−トＰＣも故障発生。
前日まで快調だったのに、電源を入れても「ＰＩＰＩ！」と鳴るのみで、全く起動しなくなった。
結局６４ＭのＲＡＭのうちの１枚３２Ｍがダメになっていた。（ノ−トのＲＡＭは値段が高いのに････）
泣きっ面に蜂、悪いときには悪いことが重なる、だれかが私に呪いでもかけているんではなかろうか。
★★★みなさんデフラグは絶対起動しないように★★★これが今回の教訓です。
さて、当院システム稼働して１年２ケ月たった現在、処方のみ病棟・外来のオ−ダリングが稼働していますが、病棟での注射・検査・栄養などのオ−ダリングシステム稼働を前にして、一定の全病院的な総括をおこなったのでその報告をします。
また、最近ＴＦＴ１４インチ（１７インチＴＶ相当）の液晶モニタ−、飯山電気製とメルコ製を計１２台導入したので、その比較報告などを順次紹介する予定。
つづく