コンピュータ環境 (2005/02)

最初の書き込みへ

基本の環境はこちら

2005年01月の環境
2005年03月の環境
戻る


時系列・環境の変遷


 

2005/02/28 (Monday)
VB6 の すごい 泥縄プログラミング

 日曜日、いい天気で晴れ上がり絶好のプログラミング日よりということでパソコンに向かってプログラムの仕様追加など試みました。

 二時間くらい格闘しました。

 仕入れのプログラムで、売り値を仕入値から計算しているのですが、ときどき恣意的に売り値を変更する必要があり、また計算要素の入力ミスがあると売り値が不当な値になることもありで、今は入力時にはわからない売り値をその場で表示して修正できるようにしようとか思ったのですが…

 なにしろ5年前に書いてからほとんど使うだけで内容は放置状態ですからもう完全に忘れ果てているわ仕様書はないわソースの読解能力はがた落ちだわという三重苦の環境でわかったことは、
・売り値はマスタに登録している
・売り値のメンテはトランザクションの入力画面でやりたい
ということ。つまりは、現在はトランザクションの更新しかしていないタイミングで、新たにマスタの更新もしないといけなくなったみたいで。

 この予期しない事態にパニックに陥り、時間が押してきたのでそれまでプロジェクトをいっぺんも保存していなかったのを幸いご和算にしてしまいました。

 後から落ちついて考えれば、トランザクションの更新タイミングで SQL 一行足すだけのことなのですが、まだまだ病気から快復していないと見え、その時はマジどうしたらいいのか分からなくなってしまったのでした。

 まーそれにしても、ではマスタの更新タイミングで売り値の処理はどうなっているかというと、0のままで更新していますし。

 今のところ、一体どのタイミングでマスタの売り値のフィールドを計算して更新しているのかさっぱり分かっていません。ひどいものだ。

2005/02/25 (Friday)
MODEM ボードの すごい 接続・郵便局の すごい 国際郵便事情

MODEM ボードの すごい 接続

 Morgan le Fay を組みなおしてから、電話も MODEM も外線につながらない事態が続いていました。

 それほど実害ないとか思って放置していましたが、ここで作業していると居間の電話が呼び出していても気がつかないために、何度かトラブルが発生、また、通信販売の申し込みも M$ FAX に送信できないのでいったん印刷して居間の FAX で送信しなくてはいけないと、不自由も感じていました。

 先程一念発起して、電源投入前に筐体を開けて、電話線を接続したままの状態で MODEM ボードを抜去、状態を確認したところ、外線・電話機への接続線ともに、上下逆さまにむりやりつっこんでありました。

 きっと、せまい場所でよく確認せずにやったのでしょう。まあそれだけで無事復旧しました。

郵便局の すごい 国際郵便事情

 話しはがらりと変わりますが、裏で手伝っている国際通販がらみで興味深いことが判明したので書いておきます。

 あるお客さんに、立て続けに航空郵便を3件送りました。
 2/11, 2/16, 2/19 です。まあいろいろあってのことでした。最初の注文を送ったという返事に追加の注文があったので捜して送って、その翌日に大売り出しの広告をかけたらまた新規がはいって。

 そうしたら、先日連絡があって、1回目と3回目の郵便が届いたが、2回目がまだだというのです。

 この理由はすぐにわかりました。郵便事故でなければの前提で、その確認はまだしていないのですが。

 通常、発送には店舗のすぐ近くにある特定郵便局を使っています。しかし、最後の注文だけは殺到したので、土曜日の夜に本局に持ち込みました。

 おそらく、最後の郵便は配送過程で最初の郵便と合流し、二番目の郵便を追い越してしまったものと想像されます。

 それにしても、特定から発送するのと本局からでは、国際郵便にざっと一週間の差がでるというのはある意味驚愕しました。

2005/02/28へ

2005/02/23 (Wednesday)
BackupExec の すごい バージョンダウン

 最新版の10.0の試食版を入手したので先週の水曜日に立てたテストサーバにインストールして試していました。

 水曜日の晩の100GBフルバックアップ、木曜日の晩の差分バックアップは無事成功しましたが、土曜日・月曜日・火曜日・今日と4回続けてフルバックアップに失敗しました。

 原因はよく分かりません。エラーメッセージはシステムリソース不足みたいなこと。また、システムの電源再投入時に、サービスがテープ装置を認識できないというエラーも出ています。

 なんとなく、このテープ装置を認識できないためにサービスを開始せず、そこからトラブルがエスカレートしているような印象がありますがよくわかりません。

 何より1回だけは成功しているのが解せません。

 しかし、こんなことをしていていは時間の無駄なので、時期尚早と判断、さっさと9.1にもどすことにしました。

 とはいえ、問題なく再インストールするんだったら OS からだねということになり、サーバの建て直しをしました。

 2個の 120 GB ハードディスクを SPAN 処理して 230 GB のハードディスクにしていたのですが、これをそのままにしていきなり上書きインストールしたものだからさあ大変。

 一個目のハードディスクを区画を切って、最初の 4 GB をシステムと BackupExec に、残りの 116 GB を、二個目のハードディスクと SPAN させていたのですが。

 同じ容量切ってはみたものの、いったん区画を削除したときに、おそらくダイナミックボリュームからシンプルボリュームにもどってしまったためと思われますが、起動ディスクは F: になるわ、ディスク管理を開いてみればその同じ領域が二重指定されていてドライブ番号を与えのに失敗しているわ、SPAN ディスクは使用不能になっているわともう散々。

 あらためて起動ディスクをシンプルボリュームからダイナミックボリュームに変更して、SPAN 切り直し、初期化を試みますが失敗しました。

 こういうときは再起動だよねとシステムを再起動してもう一度試すと、今度は 230 GB ワンドライブになりましたが初期化してないという。
 では初期化せい、とやらせてみたら、前回同様約4時間かかって今度は「シパーイしますた」

 アホか、ともう一度クイックフォーマットしてみたらあっさり通って((汗))
 あらかじめインストールしておいた BackupExec からジョブを作成して明日朝の結果待ちという状況です。

 どうもこの BackupExec というプログラムは相性がよくないみたいです。

2005/02/25へ

2005/02/21 (Monday)
久しぶりの すごい プログラミング

 一週間更新をさぼっていましたが、土曜日にあった年2回の大仕事に備えてのシフトで、まあ心にゆとりがなかったのが主な原因でした。

 通信販売の大売り出しで、水曜日から土曜日までの4日間に注文が殺到し、土曜日は10時まで作業してこれを全部処理するみたいな内容です。

 それで、金曜日の夜、翌日の作業に備えて自宅でプログラムを書きました。

 注文はフォームから入力されてメールで届きます。
Keyward : Valeur
みたいな行が40行くらいから構成されたメールです。

 このプログラムを書いた当初は、受信メールをまずファイルに保存し、整形プログラムで印刷して、内容を見ながら受注プログラムに手入力していました。

 注文が増えてきたので、受注プログラムに画面を追加し、受信メールを直接読み込んで表示し、印刷したり、それまで使用していた受注画面に流し込めるようにしました。

 それでずっと使ってきましたが、最近の大売り出しで不都合が出るようになりました。つまり、在庫に対して注文が殺到して足りなくなるようになってきたのです。
 追加で仕入れることができる場合もあり、できない場合もあり、そういうときは数量を調節して売らないといけないということになりました。

 注文きたら即出荷すればいいだけのことですが、同日に注文がはいる場合もあります。それに、件数が多すぎて週末まで待たないと処理できません。

 何度かは、EXCELの別表で管理しましたが、手入力が追いつかなくなってとりあえず ACCESS データベースを作りました。
 これも最初は手入力でしたがすぐにメールをファイルに保存してから取り込む方法に変えました。
 同じ ACCESS データベースなので、在庫との突き合わせが格段に楽になりました。
 この方法を2回使って重宝しましたが、このテーブルからから受注画面への入力が手入力でした。

 要するに、受注画面でこのデータを取り込むための i/o デザインが思いつかずにずっと悩んでいたのです。
 金曜日になってとうとう後がなくなり、決め打ちしてボタンとテキストボックスを幾つか追加してコーディングしてみました。そうしたらさあ大変。

 そのテーブルに対して SQL を2回発行するのですが、1回目のレコード件数取得は成功するものの、2回目のキーを指定したデータ取得では、レコードを返さないのです。
 さあ困った、と2回目の SQL の内容を取得して ACCESS データベースを起動し(プログラムは VB の統合環境)、Query 画面から SQL をはりつけるとちゃんと1レコード返します。

 一体何なんだ、Recordset オブジェクトを Close してるのがいけないのか、別の Recordset オブジェクトを宣言してもやはりだめ。
 SQL に WHERE 句があるからだめなのかと、全件取得して1レコードずつ検査して、キーの値が一致したら処理とかやってみてもだめ。
 まあこの段階で1レコードずつ読んでいるデータの内容を debug すればよかったのですが、もう寝ないと翌日の長丁場にたえ切れないと判断し、きっと現場のコンピュータでは動くよ、と根拠なしに決めつけて寝てしまいました。結果的にはそれ、正しかったのですが。

 それで、土曜日になりまして、まず予約していた鍼に行って、ってずいぶんと余裕です。それで、打ってもらいながらつらつらと前日のうまくいかなかった原因を考えていたら、そういうゆとりのあるときにひらめくものなのですね。

 もう仕様なんて忘れてはてていましたが、ini ファイルにデータベースファイルのパスを記述してあって、作業していた領域ではない、もっと古い日付のデータベースを参照していたということでした。

 だから、現場にプログラムを持って行って、作業域に複写して実行したら、一発で通りました。
 おかげさまで手入力がなくなって、商品番号の打ち間違いはなくなり、処理は高速化されといいことづくめ。

 こういう楽をするためには苦労をいとわないのがいい SE の資質だとか申します。

2005/02/23へ

2005/02/15 (Tuesday)
続・仕事先の すごい 鯖立て

 同じタイトルを1月21日にも使いましたのでいきなり「続」と出てきますがご了承ください。

 なんでこんなにひんぱんに同じことをくり返さなくてはいけないのかとなんか涙が出て来ますが、今回は、収容するデータが大きくなりすぎたのが原因です。
 筐体は限られていてもうハード・ディスクを増設する余裕がないので、システムディスクを大容量のものと換装し、システムも再インストールの運びになりました。

 もう完全にマンネリになっていますので悩むことなど何もなく作業が進むかといえば決してそんなことはなく、今回もNICのドライバがない、と。

 こういう時はいつもの help desk だね、とさっさとメイカーに電話してブツの置いてある url を教えてもらいます。
 今回のツッコミはその時の会話。

お客様、弊社のレストアCDをご利用で再インストールですか
ちがいます
作用ですか、それでご使用のOSは何でしょうか、Windows95ですか
2000です

 今 時 9 5 か よ

2005/02/21へ

2005/02/12 (Saturday)
続・NT4 の すごい ミ田アップデート

 昨日のうちに本社の担当者がエントリーを削除してくれていましたので、前回と同じ手続きで強制フラッシュ、強制同期をかけて、エントリーを再作成して無事ドメインに参加できました。

 これで気を許すとまた参加できなくなるので、今日はこの NT4 端末は電源投入状態を保持したままで放置することにします。

 この後、アプリケーションをいっこインストールし、ODBC をセットアップして完成です。

 ODBC セットアップは、ACCESS VBA でプログラムを組んであるのですがあいにくとこの端末には Office をインストールしてありません。
 それだけのために Office をインストールするのもアホらしいので、久しぶりにマニュアルで ODBC を定義するつもりです。

2005/02/15へ

2005/02/10 (Thursday)
NT4 の すごい ミ田アップデート

 みごとに起動しなくなりました。

 HP に問い合わせて分かったのですがこれは半分は M$KK の仕業ではなく、HP が独自につけ足している、サスペンド状態から復帰させるユーティリティとのバッティングが原因で、HP はすでにこのプログラムの再新バージョンをアップして問題解決しているそうです。
 不勉強ですみません。

 Compaq DESKPRO で一台、NT4 マシンを作っていた同僚が教えてくれたので、めったに行かない M$KK のサイトに行ってみたのです。この2月にアップされた、ミ田アップデートの最新版がありました。それで、手持ちの NT4 ワークステーションにこれを適用してみました。

 その結果表題のような結果になりまして。まあ、読者の方に HP Vectra をお使いの方がもしいらっしゃいましたら、このミ田アップデートを適用する前に、HpLock というアプリケーションのバージョンを最新版にするか、削除しておかれることをおすすめします。
 このプログラムは上にも書きましたように、サスペンド状態から復帰するための支援プログラムなので、普通に使用するぶんには必要ないのではないかというのが HP のヘルプデスクな方のご意見でした。
 コントロールパネルの、プログラムの追加と削除から削除できるそうです。
 また、最新版は HP のサイトにアップロードしてあるとのこと。 url は確認しませんでしたがその理由は以下に :

 とりあえず起動できなくなった環境は、再インストールするしかないということですので、汎用のミ田NT4.0 から再インストールしました。これで、HPLock がそもそもインストールされません。

 もうアプリケーションをひとつ動かすだけのために残してある端末なので、OSの他にはそのアプリケーションしか入れないことにしました。
 OS は午前中にインストールし終わりましたが、例によってミ田ドメインに参加できません。
 どういうことだよこのマシン名は昨日まで有効だっただろうにと毒づいても参加できないものは参加できないので、しかたないこれから本社の技術担当にお願いしてドメインコントローラからマシン名のエントリーを削除してもらい、それを確認した上で、こちら側のドメインコントローラの情報を強制リフレッシュ、新たにエントリーを再作成という手続きを取ることにします。

 もうネットワークの構成がミ田XP に合わせてチューニングされているので、古い NT4 などもうネットワーク管理者の眼中にないものと思われます。

2005/02/12へ

2005/02/09 (Wednesday)
MD5000i の すごい 復活

 昨日帰宅しましたら、修理上がりで配達されていました。わーい。

 原因はサブキャリッジ部の摩耗にともなうカール矯正メカニズムエラーということだそうです。避けて通れない道なんですね。

 玄関で開封して、プリンタだけ取り出して作業場に搬入し、元の場所にセットアップしました。
 まあ、修繕してくれただけでなく清掃までしてもらって新品同様の輝きです、なんかうれしい。
 布でカバーを作ってかけておいたほうがいいかもとか思いました。

 報告書には、購入以来の印刷枚数まで記述してありなんとカウンタがはいっているのだそうです。摩耗度合の測定に使用するのでしょう、きっと。
 枚数が疑問で電話してみました。
 購入以来約150枚印刷されていると記述されていたのです。でも、実際にはもう3回は年賀状を印刷しているので、どうみても300枚以上になるはずと思って。
 そうしたら、A4換算の枚数ですと明快に回答をいただきました。なぁるほど。

 まともかくこれですっかりなおったので、これからも使っていこうと思っています。

2005/02/10へ

2005/02/06 (Sunday)
Morgan le Fay の すごい 復活

 というわけでどうやら再生に成功しました。

 まだ全部のアプリをインストールしていませんしチューニングとかいろいろ残っていますがともかくもインターネットアクセス環境とメールを読む環境は確保したということで。

 メモリと干渉したCDR、DVD-Rは結局ねじ穴の関係で5センチばかり筐体から突き出しています。まあみっともないったら。
 あと、どういうわけかディスケットドライブにエラーをみつけて、起動時に F1 で進めるか BIOS にはいることを勧告してシーケンスが停止するので、BIOS で殺してしまいました。原因追求は将来の課題です。
 音も出ません。サウンド関係のデバイスドライバはすべて正常にインストールされているということですが、内蔵のスピーカからも接続したオーディオからも出ません。これも将来の課題。
 起動時シーケンスで、CPU ファンの回転数が0と赤字で表示されます。しかし、CPU 温度は特に加熱していませんし、だいたいファンが回っていなかったら Athlon は一瞬でヤキトリになりますから、これは多分冷却ファンの電源を、CPU ファンのためのものではない所から取ったためと思われます。筐体の中がせますぎて、裏からママンをはずさない限り確認できません。したがって放置です。

 後はこの構成で一日でも長く運転が続いてくれることを祈るばかりです。

2005/02/09へ

2005/02/04 (Friday)
続・Morgan le Fay の すごい ママン

 筐体が小さいうえにママンがフルサイズということで、メモリがCDRとガチに干渉してます。

 このままでは1本もさせませんので、奥行きの短いDVD-Rを1センチ程度、奥行きのあるCDRを5センチくらい筐体から前面に突きだす感じで運用するしかないという結論。

 筐体自体は Natharie のが空いているのですが余り使いたくないというか要するに分かったのは自分 Natharie の筐体が実は好きでなかったということ。
 ごめんね、交換した友人な人。

 というわけで今夜はそんな奇怪な形態になる Morgan le Fay の組み立てと、せめて OS くらいはインストールしたい計画です。

2005/02/06へ

2005/02/03 (Thursday)
Morgan le Fay の すごい ママン

 というわけでメモリ共々討ち死にしやがりました。

 ママンの起動シーケンスを見ると 52h でフリーズ、これはメモリチェックの段階です。

 ちょうど Natharie を使っていないので、メモリを引き抜いて交換しますが症状は変わりません。
 ママンが逝ったか、というとそれだけではありませんでした。
 引き抜いたメモリを Natharie に装着して起動すると、そちらでも 52h でフリーズします。
 もちろん、もともと Natharie に装着していたメモリで Natharie を起動すると ok です。

 もう情けないやらくやしいやら、とにかく Natharie のママンをはがして換装することにしましたが、時間が取れるのが日曜日になるので、それまでの間更新ができないと思われます。

 この1年でママン3枚殺すとは、天中殺か厄年かと思わず木枯らしの吹きすさぶ懐をたたいてしまいました。

2005/02/04へ

2005/02/01 (Tuesday)
メールサーバの すごい route

 1/13 の報告でこわしてしまった Linux メールサーバですが、今日になってやっと復活させることができました。

 読み返してみたらフロントパネルの交換よりもっと深刻なことになっていたのに報告してませんでしたね((汗))

 実は事故の直後から、唯一機能していた sendmail がきちんとメールを発信しなくなっていたのです。
 いつまでたっても配信されないので調べてみるとキューに溜まっていて、アドミニストレータ宛のメールを開くと「送信できませんでした」というメッセー市があります。

 プロバイダのメーリングリストに投げて何かわからないかと問い合わせたり、どこまでつながっているんだろうと ping 打ったりしました。

 名前解決ができず、IP 直接指定しても ping は中も外も一切通りません。
 外からこのサーバを見られるのは、losts に固定 IP を記述してある1台の端末だけなのですが、この端末からの ping は通ります。

 メーリングリストのアドバイスに従って、各種構成ファイルの調査を始めました。
 /var/log/mail*.* では前述のように「送れませんでした」というメッセージを確認しました。問題は sendmail の外側で起きている模様。
 /etc/resolv.conf を調べました。DNS サーバの値はよさそうです。
 ping は前述のように名前でも IP 指定でも一切通りません。

 route を調べてみたところ、見たこともない IP を指定した行が見つかりました。ゲートウェイも覚えのない値になっています。
 これかな、と route をいじりはじめたのが多分 17 日のころ。コマンドライン引数など忘れ果てていて、インストール当時に作成したメモなど見ながら悪戦苦闘しました。

 この時点ですでに値を誤っていたのですが、デフォルトゲートウェイの指定をするために、まず 192.168.3.0 というダミーのエントリーを追加して、それから現在(というか当時の)デフォルトゲートウェイのエントリーを削除、あらためて、192.168.3.10 をデフォルトゲートウェイに設定しました。

 実はこれは値が間違っていたのですが当時それに気づいていませんでした。

 route で、192.168.3.0 と、値の変なエントリー2行、それから 127.0.0.0 のローカルループの計3行をささっ、と表示してから待つことしばし、ようやっとデフォルトゲートウェイの 192.168.3.10 を表示します。
 あいかわらずメールは送信せず、ping も通りません。通るのはただひとつ、192.168.3.10 の IP 指定のみ。

 値の変なエントリー2行も、どうやってもネットマスクの値があり得ないから削除できないというエラーメッセージを返すばかり。

 それから約半月、ほったらかしにしてあったのです。そして、今日。

 同僚と話をしていてひょんなことからサーバの IP の話しになりまして、なにげなく、そういえば、インターネットに出るルータの IP は、3.10 だよね、と聞いたのです。
いや、3.5 だよ
 何ということでしょう。

 すぐに route を使って 192.168.3.10 を削除、192.168.3.5 を追加しました。
 わくわくしながらアドレス指定して ping を打ちます。
 すぐに名前解決しました、やった!
 でも、応答がありません。

 これは単に気が短すぎただけでした。別の名前で ping 打ったらすぐに応答がありました。whois でも情報を表示しました。

 さらに、route で、変な IP の2行の削除を試みました。これもまったく問題なくさっくりと削除されました。それからダミーで作成した 192.168.3.0 も削除、実にすっきりしました。

 メールを送信、無事配信を確認しました。

 なぜ route テーブルが破損したのかは不明ですが、ともかく二度と蹴飛ばすまいと心にちかいました。

2005/02/03へ

最初に戻る
戻る