復活！ＣＰ／Ｍ ワンボードマイコンでＣＰ／Ｍを！
ＣＰ／ＭがＴＫ－８０互換のワンボードマイコンの上で復活します
ＮＤ８０ＺⅢとＭＹＣＰＵ８０の上でＣＰ／Ｍが走ります！
［第４２０回］
●／ＢＡＴで遠隔デバッグ！（２）
前回からの続きです。
Ｎ様にお送りして実行していただいたバッチプログラムには、ＺＣＣＰプログラムのファイルＯＰＥＮのところにブレークポイントを設定してありました。
またシステムのＦＣＢエリアのメモリダンプも設定してありました。
ＺＣＣＰプログラムのユーザープログラムを実行するプログラム部分では、キーボードから入力したプログラム名をシステムＦＣＢエリアにセットしたうえで、ディスクディレクトリからそのファイル名を探してそのファイルをＯＰＥＮします。
Ｎ様から／ＢＡＴを実行した結果を記録したログファイルを送っていただいて、その内容を見ましたところ、ファイルＯＰＥＮでこけていることがわかりました。
でもなぜ？
これには説明が必要です。
プログラムを修正するまでは、ずっとまともにＯＰＥＮできていたのです。
新たに修正をおこなったプログラムをお送りしたら、ファイルがＯＰＥＮできなくなってしまいました。
プログラムを修正したことが原因であることは明らかです。
どこを修正したのかといいますと。
Ｎ様と同じように、大分県のＨ様からもいろいろなアプリケーションの実行結果のレポートを送っていただいています。
ところがＨ様からいただいたバグ報告をもとにプログラムを修正しましたところ、複数のエクステントにまたがる大きなプログラムをコピーさせると、そのエクステントの数だけ繰り返しコピーが行なわれてしまう、という新たなバグの報告をいただきました。
うう。
なんともややこしい説明です。
実際このところ実にややこしくてため息がでてしまうバグ修正をしてきましたのです。
こちらを直すとあちらがだめになり、あちらを直すと今度は別のところがだめになってしまうということの繰り返しです。
ＣＰ／Ｍファイルのエクステントにつきましては［第１４８回］で説明をしています。
ディスクディレクトリのＦＣＢエリア（ファイル名とデータブロック№などがかかれているエリア）は３２バイトで構成されています。
その３２バイトは前半１６バイトと後半１６バイトに分かれています。
後半１６バイトには２バイトずつ８個のデータブロック№が書き込まれます。
１ブロックは１６レコード２ＫＢですから、そこに記録できるのは１６ＫＢ分のデータブロック№までです。
それでは１６ＫＢ以上の大きなファイルはどうやって管理するのかといいますと、そこでエクステント№が使われるのです。
１６ＫＢを越えるファイルの場合には同じファイル名のＦＣＢが複数登録されます。
１６ＫＢまでのファイルの場合にはＦＣＢは１個だけで、そのときはエクステントの№は００です。
エクステント№はＦＣＢの先頭から１３バイト目に置かれています。
そのことは勿論わかっていましたから、ファイル名をサーチするときにもエクステント№を確認して、それが最初の（つまりエクステント№が００の）ＦＣＢなのかそうでないのかということもチェックするようにプログラムは組んでありました。
なので、実際にファイル名をサーチするところでは、ファイル名部分のみ（８バイト＋３バイト）だけを比較するようにしてありました。
ところがＨ様、Ｎ様からのバグ報告を受けてその原因を追究していきましたところ、どうもファイル名サーチはファイル名部分の８＋３バイトだけではなくて、その次のエクステント№も含めて比較しなければならないらしいということがわかってきました。
そこでそのようにプログラムを修正したのですが。
それはＺＢＤＯＳのファンクションコールの部分だけで、ＺＣＣＰのプログラムは外からコールされるものではありませんから、もとのままの８＋３バイトだけの比較をしていました。
つまりファイルＯＰＥＮするためにシステムＦＣＢにセットされるのはファイル名の８＋３バイトだけだったのです。
それはＺＣＣＰ側のプログラムでの設定です。
しかしＺＣＣＰがコールするファイルＯＰＥＮルーチンはエクステントも含めて比較するように修正してしまいました。
そこで今回の問題が発生しました。
下は前回お見せしました、Ｎ様から送っていただいたログファイルの一部です。
>DM E93C,E95F E93C 00 50 49 20 20 20 20 20-20 43 4F 4D 01 00 00 0D .PI COM.... E94C 61 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 a............... E95C 0D 00 00 00 00 00 00 E8-02 00 00 E1 02 00 00 E1 ................ |