ふと今気が付いたんですが、この日記、もう一年になろうとしています。「朝の連続・・・・」のボードを何とか書き込みで埋めたくて始めたわけですが、もう一年になりました。ただ、最近は（以前からも）ほとんど書き込みしていませんので、本来３６５日あるべき日記が数十しかありませんからえらそうな事は言えませんが。

　さて、本日は何の話をしたくてキーを取った（？）かということなんですが、Ｙｍｏｄｅｍについての話です。実はここ半月ばかり、以前からやりかけになっていたＡＴＬＡＳのホストプログラム（現在ＱＢで作成してある）のＣ言語版への変更作業をやっています。プログラムもほぼ完成、デバッグを行っているところです。近々発売される「ワープロパソコン通信ＢＢＳ電話帳（９０年秋号）」にはＹｍｏｄｅｍサポートと掲載される予定ですので、何としてもプログラムの入れ替えを行う必要があるのです。

　さて、新しくサポートするＹｍｏｄｅｍに関し、仕様を正しく反映したものができたかどうか確認するために、Ｙｍｏｄｅｍをサポートしている幾種類かの既成の通信ソフトと対向テストをしてみました。その結果、どれも皆、動きが少しずつ違うので困ってしまいます。そのテストした結果ですが、

1. 　ファイル情報ブロックに taime stamp を乗せるのは仕様の上ではオプションになっているからでしょうか、使用しないものがほとんどです。
   　なお、使用しない場合には本来 time stamp を乗せるべきフィールドには NULL を埋めることになっているのですが、ゴミを送信してくるソフトがありました。（たぶんバグ？）
   
   
2. 　受信ファイル生成は、ファイル情報ブロックで受け取った file length に従ってファイルを生成すべきところ、送られてきたブロック全体のサイズを持つファイルを生成してしまうものがあります。
   　受信ファイルは、オリジナルのファイルサイズを超える 128byte の倍数のサイズになってしまっているのがほとんどでした。
   
   
3. 　プロトコルの選択メニューに YMODEM とあった場合に、single transfer でなく batch transfer になっているものがあるかと思えば、YMODEM , YOMODEM_batch と明確に２つのプロトコルに分けているものもありました。さらに、batch が送信時には使えなく、受信時のみというものもありました。
   
   
4. 　1024ブロックと128ブロックは混在できるのが本来の仕様ですが、送信の時は、常に1024ブロックを採用しているものがありました。受信側が file length どおりに受信ファイルを生成する時はいいのですが、そうでない時には、数バイトのファイルが受信側では1024バイトのファイルになってしまいます。
   

　ちなみに、フリウェアーの ZM.EXE ですが、これは一つのソフトで XMODEM から YMODEM, ZMODEM までこなすすぐれものですが、次のようになっていました。YMODEM, YMODEM_g はbatchプロトコルになっている。time stamp は使用する。file length に関係なく受信ブロック全体のファイルを生成する。

　私個人の意見としては、time stamp については無視してもいいと思いますが file length についてはそれに従ったファイルを生成して欲しいと思っています。これをやらなくてはｙｍｏｄｅｍの価値がないように感じます。ｘｍｏｄｅｍ 1k crc と比べた場合、これをやらなくては意味があまりないような気がします。

　なお、ＡＴＬＡＳの新しいプログラムですが、これは今月末頃に切り替え る予定です。

　気になるＹＭＯＤＥＭサポートについてもしっかり載ってしまってたのは勿論です。