NASAはジェット推進研究所(JPL)が太陽系外を航行中の探査機「ボイジャー1号(Voyager 1)」の復旧に成功したと発表した。
Voyager 1から送られてくるデータが昨年十一月から読み取り不能な状態になっていて、NASAは原因が46年前に製造された搭載コンピュータのメモリチップの一部が破損したことと公表していた。
今回の復旧作業は破損したチップ上にあったソフトウェア(プログラムやデータ)を他のチップに移動し、さらに破損したチップにはアクセスする必要が無いようにしたソフトウェアに置き換えたということだ。
この作業内容だけでも判る人が聞いたら「うへぇー、面倒」と思ってしまうだろうなぁ(汗)。
今のソフトウェア開発はメモリのアドレスなんか意識すること無いからなぁ・・・
昔は物理アドレスを意識してメモリマッピングをしたりするのが当たり前だったし、プログラムだってマシン語でジャンプ先やリード/ライトのアドレスを絶対アドレスで指定することもあった(通常はリロケータブルにするので相対アドレス指定)。
デバッグだってメモリダンプを取って16進数のデータを読むのが当たり前だった。
でも今の時代にそんなことはしたくないなぁ(汗)。
今回はそれに加えて「Voyager 1」との通信に片道約22.5時間もかかることがネックになっている。
つまり、新ソフトウェアに置き換える命令群を送信しても、結果を知ることが出来るのは最低でも45時間後になる。
いやぁ、NASA(JPL)の技術陣は凄いなぁ。
More from: プログラム
数年越しで発覚したプログラムのバグ(汗)
ユーザーからシステムの動作がおかしいと連絡が来た。
症状を聞くと過去に聞いたことが無い不具合が起きているようだ。
ソフトの開発者と連絡を取り合いながら対処したところ、どうも特定の手順で処理をさせた場合のみ発生するらしいということが判った。
#私もその部分の開発に携わっていて処理の中身は理解できるので助言が出来た。
ということは少し違う手順で処理をさせれば回避できるということで、開発者が実際にやってみると不具合は発生しなかった。
ほぼ同時にユーザーからも同じような内容の連絡が来たので、一応は回避できることが確定。
その後さらに調べると不具合が発生した際はプログラム内で使っているグローバル変数の値がリセットされていないことが判明。
通常時はかならず特定の範囲の値がセットされ、それ以外の場合は初期値がセットするようにしているので不定値がセットされることが無く、プログラムが”落ち無い”ので見逃していたようだ。
今回は別のルーチンでセットされた値がそのまま使われてしまったために不具合が表面に出てしまった。
対策として処理毎に必要な値をセットするようなステップを処理の前段に追加したので今後は発生しない筈。
とはいえ、複数のプログラムで同じ修正が必要になるので、見落としがあれば再発するなぁ(汗)。
今時VB6と格闘とわ・・・
仕事とは関係なくVB6のプログラムと格闘中orz
WindowsXP向けに特注で作られたソフトをWindows10で動作するかどうかの検証なんだけど、最初はMSCOMCT2.OCXが無くて動作しなかった。
これはVB6のSP6をダウンロードしてから解凍し、出て来たファイルを
C:\Windows\SysWOW64
にコピーし、コマンドプロンプトを管理者権限で起ち上げて
cd C:\Windows\SysWOW64
regsvr32 MSCOMCT2.OCX
を実行してレジストリに登録すればなんとかなった。
本来なら一緒に出てくる.infファイルを使ってインストールするんだけど、Windows10Pro64bit版ではインストール出来なかった。
問題はそこから先なんだけど、内部を解析しないとならないことになりそうなので気が重い・・・
モジュール数が多いので目的の処理がどこで行われているを探すだけで一苦労・・・
なんとかなるかなぁ?
あれ?まだ直ってないのね。
先ほどNIFTY-Serveのサービスから三日ぶりにログアウトしたら、利用時間の表示がおかしいままだった。
証拠のスクリーンショット
引用開始———————————————————————————————-
ログアウト
LOG IN - – – 2012/06/14 21:49:47
LOG OUT - – – 2012/06/17 23:16:59
ご利用時間は、73時間4334分12秒でした。
ご利用誠にありがとうございました。
Clear PAD
Host requested clearing the call
HOST NAME?
*OFF
NO CARRIER
>
引用終了———————————————————————————————-
本当は3日と1時間27分12秒なので、73時間27分12秒となる筈なのだが・・・・・・
この表示を見ると時間の差と秒の差の表示は合っている。
で、分差の計算が間違っていて、どういう計算をしたらこの数字が出てくるのかを考えてみた。
単に73時間27分をそのまま分で表示しているのなら4407分となる筈。
で、その分の数字と実際に表示された数字の差が73なので、本来は4407/60(=73.45)の小数点部に60を掛けたのが分(この場合は27)の表示になるべきなのだが、何故か4407(分)-73(時間)を引いた数字を分の数字として表示しているようだ。
うーん、結構単純なバグだなぁこれは(笑)。
実際には秒差を求めてから時分秒の表示に直しているんだと思う(自分ならそうする)けど、そこで計算式を間違ったと思われる。
#整数計算なら
時間差=秒差/3600
分差=(秒差-時間差*3600)/60
秒差=秒差-時間差*3600-分差*60
で求められる。(筈、この式で合ってるよね?)
サービスを開始してから半月以上も経っているからとっくに気付いて直してあるかと思ったけど、もしかしたら気付いてさえいないのかな?
それとも昔のNIFTY-Serveの時も同じで、そのまま再現しているとか?
昔は時間で課金されていたから、今回のような長時間のログインはしていなかったけど、数時間程度なら入ったままのことはあった。
その時にはこんなことは無かった様に記憶しているけど、ちょっと不確かだなぁ。
さて、このバグはいつまでこのままなのだろうか?
#教えてやれって?そうかもしれない(笑)
インターフェース
よそのSNSに日記を投稿していてふと思い出したが、昔はシリアルやパラレルを使っていたなぁ。
シリアルはモデム、パラレルはプリンタを主につないでいたっけ。
LANとブロードバンドの普及でモデムがほぼ不要となり、USBの台頭でプリンタもUSBを使うようになった。
結果シリアルもパラレルも最近のPCには見られなくなってきた。そもそもIntelがレガシーデバイスを排除しようとしてるしなぁ。
PS/2すら付いてないPCも多いしなぁ。
でも未だにシリアルインタフェースを必要とする外部機器もあるから、そういうものを使う時はPCを選ばなくてはならない。
先日も大型ディスプレイ用のタッチパネルを探していて、提案されたのがシリアル接続のもの。液晶で有名な某メーカーの製品だったが、耳を疑ってしまった。他メーカにはUSB接続のものもあるのにねぇ(笑)。
昔GPSユニットをつないだときもシリアルだったなぁ。通信速度が4800bpsと決められていたが、シリアルポートのドライバが9600以上にしか対応してない(というか9600以上にしか設定できない)ので、直接16550のレジスタをいじって4800以下に設定できるようにするサブルーチン書いたなぁ。
パラレルも外部端子を接続して使うのに、レジスタ読み込み用のドライバ書いたなぁ、、、

