--- tcs-1.orig/ex00.src
+++ tcs-1/ex00.src
@@ -0,0 +1,192 @@
+From dmr Thu Jan 30 17:00:03 EST 1992
+誠に申し訳ありませんが、MH front end はあと１週間だけ待って下さい。
+新しい xterm のために vtwin の変更が必要となって、それにちょっと
+手間取ってしまいました。まだもう１つ直したい bug があるのですが
+もう今日は時間がありません。
+拝啓　新緑の候、ますますご清祥のこととお喜び申し上げます。
+さて、斎藤信男先生は４月１日をもちまして、慶応義塾大学理工学部教
+授に御昇任なられました。そこで、日頃斎藤先生にお世話になっている
+私達が斎藤先生に お祝いを申し上げるためのささやかな 祝宴を企画致
+しました。当日は  斎藤研究室 OB/OG の方々、斎藤研究室現役の学生、
+また、斎藤先生ゆかりの方々が集まり、斎藤先生を囲んで楽しいひとと
+きを過ごしたいと考えております。ご家族、御友人おさそいあわせのう
+え御列席下さるようお願い申し上げます。
+おそれいりますが、ご出席の確認を下記連絡先に電話または電子メール
+にてご連絡下さるようお願い申し上げます。
+                            				敬具
+                    「斎藤信男教授を囲む会」
+日時： 昭和６２年４月２４日（金） 18:00 より
+場所： 新橋第一ホテル「レストランクラレット」
+       電話；　 03-501-4411
+会費： １万５千円 （当日記念品代１口５千円を別に御用意下さい。）
+	ただし、学生料金は別途設定してありますので御安心！
+連絡先:中村　修  osamu@keio.junet
+       電話 044-63-9137 （斎藤研究室直通）
+       電話 03-704-4715 （中村自宅）
+		         幹事代表	村井　純、　中村 修
+拝啓　新緑の候、ますますご清祥のこととお喜び申し上げます。
+さて、斎藤信男先生は４月１日をもちまして、慶応義塾大学理工学部教
+授に御昇任なられました。そこで、日頃斎藤先生にお世話になっている
+私達が斎藤先生に お祝いを申し上げるためのささやかな 祝宴を企画致
+しました。当日は  斎藤研究室 OB/OG の方々、斎藤研究室現役の学生、
+また、斎藤先生ゆかりの方々が集まり、斎藤先生を囲んで楽しいひとと
+きを過ごしたいと考えております。ご家族、御友人おさそいあわせのう
+え御列席下さるようお願い申し上げます。
+おそれいりますが、ご出席の確認を下記連絡先に電話または電子メール
+にてご連絡下さるようお願い申し上げます。
+                            				敬具
+                    「斎藤信男教授を囲む会」
+日時： 昭和６２年４月２４日（金） 18:00 より
+場所： 新橋第一ホテル「レストランクラレット」
+       電話；　 03-501-4411
+会費： １万５千円 （当日記念品代１口５千円を別に御用意下さい。）
+	ただし、学生料金は別途設定してありますので御安心！
+連絡先:中村　修  osamu@keio.junet
+       電話 044-63-9137 （斎藤研究室直通）
+       電話 03-704-4715 （中村自宅）
+		         幹事代表	村井　純、　中村 修
+ＪＵＳ幹事の皆様：
+４月１０日の幹事会でお話した、次のような講演についての件ですが、
+	発内容：Ｍａｃｉｎｔｏｓｈ　ＩＩへのＵＮＩＸの移植
+	発  者：米国ＵｎｉＳｏｆｔのエンジニア
+	発時間：１時間（幹事会において決まった時間です）
+	発当人からＡＢＳＴＲＡＣＴが届きました。このような内容での話でよけれ
+ば、来日するがどうだろう？との問い合わせがあったのですが、皆様いかがでしょうか？
+皆様の御意見を伺ったうえで、本当に来てもらうかどうか当人に連絡したいと思います。
+（交通費、宿泊費などはＪＵＳから出す必要はありません）
+御返答、よろしくお願いいたします。
+						ＤＣＬ　坂本　文
+ＪＵＳ幹事の皆様：
+４月１０日の幹事会でお話した、次のような講演についての件ですが、
+	発内容：Ｍａｃｉｎｔｏｓｈ　ＩＩへのＵＮＩＸの移植
+	発  者：米国ＵｎｉＳｏｆｔのエンジニア
+	発時間：１時間（幹事会において決まった時間です）
+	発当人からＡＢＳＴＲＡＣＴが届きました。このような内容での話でよけれ
+ば、来日するがどうだろう？との問い合わせがあったのですが、皆様いかがでしょうか？
+皆様の御意見を伺ったうえで、本当に来てもらうかどうか当人に連絡したいと思います。
+（交通費、宿泊費などはＪＵＳから出す必要はありません）
+御返答、よろしくお願いいたします。
+						ＤＣＬ　坂本　文
+	次回のｊｕｓ幹事会は下記の場所で行います。
+日時	５／８（金）午後６時
+場所	（株）アスキ?、ＦＦＦビル、７Ｆ役員会議室
+地図
+	至赤坂
+国道２４６号（青山通り）
+	| |*（地下鉄表参道Ｂ３出口）
+	| |					（ラ?メン屋）
+紀ノ国屋| |出光GS				天下一
+	| |		住	      大	Ｆ*
+	| |		友	      仁	Ｆ
+	| |		南	      堂	Ｆ
+	至渋谷		青	      ビ	ビ
+			山	      ル	ル
+			ビ
+			ル
+（１）地下鉄表参道駅下車、Ｂ３の出口を出る。
+（２）青山通りを渋谷方面へ歩く
+（３）初めての信号（角が出光ＧＳ）を右へ曲る
+（４）約５００Ｍ歩き（信号４つ目）、Ｔ字路の交差点の右側
+（５）ＦＦＦビルの７Ｆ
+ＰＳ．当日１４：４０着の便で成田に帰って来ますので、少し遅れるかもしれません
+      が先に始めて下さい。
+	この間の集りでマーク・シートの読み取りのsoftの話題があったと思うので
+すが，「インタフェース５月号」の新製品紹介の欄で，ANK character の読み取りの
+softの紹介があったように思います。
+	ただ，その雑誌がいま，手元にないので詳しくはわかりませんが，調べてみ
+ます。
+一部の人は知っていると思いますが，現在 rmap のＰＤ化を進めています．
+余分な機能をそぎ落し，一通り動くようになりました．あと，２，３
+新たな機能を追加する予定ですが，問題はその前提となる rwhod にあります．
+御存知のように rwhod はつながるマシンの数が増えると，急激に network 及び
+CPU を食いはじめます．また，routing の機能がないため複数のネットワークが
+接続されているような環境ではやはり問題です．東工大ではいままで，gateway
+となるマシンの rwhod に手をいれて routing をするようにしていましたが，
+その場しのぎのいい加減なやり方だったので，４月にネットワークの接続形態が
+変って以来，２重に packet を流していたことが判明しました．昨日急いで
+直しましたが，それまでネットワークは collision の嵐だった訳です．
+たかだか３０台のネットワークでこの有様ですから，何百，何千という
+本格的ネットワークを考えると単純に routing を行う今の方法は非現実的です．
+そこで，いくつかのアイディアを加藤君と考えました．
+1.  broadcast packet は止めて，ＮＦＳを利用し /usr/spool/rwho をできる限り
+　共有する．どうしても必要なところは point-to-point で routing を行う．
+2.  routing する場合に独自のプロトコルにより複数のホストの情報を
+  1 packet で送る．
+3.  on demand で必要な時だけ他のマシンに対し情報を要求する．
+  トリガーは，例えば誰かが rmap でそのマシンを含むページを表示しようと
+　した時とする．
+4.  どうせ，そういう情報が必要なのは phone をかけたい時ぐらいだから，
+　むしろ，phone を改造して phoned が broadcasting や routing をしながら，
+　特定のユーザがどこにいるか探し回るようにする．
+さて，そこで皆さんの意見を聞きたいと思います．どうするのが一番良いでしょうか．
+今考えているのは，1, 2 の機能を持った public domain rwhod を作るといった
+ところですが，果してそんなことをするのは意味があるのか．４を実現すれば事実上
+rmap はいらなくなるんじゃないのか．有益な議論をお待ちしています．
+私は前の mail で次ぎのようなことを書きました．
+> 御存知のように rwhod はつながるマシンの数が増えると，急激に network 及び
+> CPU を食いはじめます．また，routing の機能がないため複数のネットワークが
+> 接続されているような環境ではやはり問題です．東工大ではいままで，gateway
+> となるマシンの rwhod に手をいれて routing をするようにしていましたが，
+> ....，何百，何千という
+> 本格的ネットワークを考えると単純に routing を行う今の方法は非現実的です．
+> そこで，いくつかのアイディアを加藤君と考えました．
+> 1.  broadcast packet は止めて，ＮＦＳを利用し /usr/spool/rwho をできる限り
+> 　共有する．どうしても必要なところは point-to-point で routing を行う．
+> 2.  routing する場合に独自のプロトコルにより複数のホストの情報を
+>   1 packet で送る．
+> 今考えているのは，1, 2 の機能を持った public domain rwhod を作るといった
+> ところですが，果してそんなことをするのは意味があるのか．...
+今考えていることを，もう少し具体的に説明すると，
+既存の rwhod は自分のマシンの network configuration を見て
+自分の属するサブネットワークにはすべて broadcasting で，
+point-to-point のリンクにはその相手先に対し，自分のマシンの情報のみを
+流しまています．
+私が手を入れた rwhod はそれらに加えて，他のマシンから来た
+情報を自分の spool に書き込むと同時に，リストとして貯め込んでおき，
+自分の情報を流す時に同時に，個々のマシンの属するネットワーク以外の
+すべてのリンクにその情報をリレーするというものです．
+しかし，この方法だといくら broadcast packet を使ったところで，
+論理的にはネットワーク全体が完全グラフをなすように packet を
+流すことになりますし，しかも普段はそういう情報を必要としない
+場合が多い訳ですから，明らかに供給過剰です．で，これを少しでも
+軽減することができれば，と考えている訳です．
+新しい rwhod は，様々なネットワーク上の制約を盛り込めるように，
+例えば /etc/rwhod.rc のようなファイルからリレーのための configuration
+を読み込むようにするといいでしょう．そのファイルの中に書かれるべき
+項目としては，次ぎのようなものが考えられます．
+1.  自分のマシンの情報をどのマシン，またはどのネットワークに対して
+　　送信するか．また，それをローカルファイルに格納するか否か．
+2.  他のマシンの情報をどのマシン，またはどのネットワークに対して
+　　リレーするか．それは packet として受信されるべきものなのか，
+　　ＮＦＳによってそのマシンの rwhod が書き込んだファイルを
+　　読みにいくのか．前者の場合には，さらにその情報をローカル
+　　ファイルに格納するか否か．
+3.  1, 2 は何秒間隔で行うのか．
+これらに加え，さらに通常は packet を流さずに必要な時だけ，
+rwhod が他のマシンに対し情報を要求するという機能を付け加えるのも
+いいかもしれません．このためには，/etc/rwhod.rc の中に
+4.  あるマシンの情報に対する要求があった時にどのマシンに
+　　対して問い合わせを行うか．
+という項目を付け加えるべきでしょう．1,2,4 は実際には統一した
+フォーマットで記述するのがいいかもしれません．
+もし，こういう on demand 型のサービスを取り入れると当然 rwho, ruptime, rmap
+といった client 側にも変更が必要になります．恐らくあるマシンの情報を得るには，
+といったようなライブラリ関数を用意することになるでしょう．
+この関数は自分のマシンの rwhod に対してそういう request を
+行い response を受け取るという単純なものにするのがいいと
+思います．一方その request を受け取った rwhod はスプールを
+見てそれが充分新しいものであれば，そこから読み取り，そうでなければ
+rwhod.rc に書かれたマシンに対し問い合わせることになるでしょう．
+いや，もうそこまでするのだったら，いっそスプールは全廃して
+rwhod が on core で情報を管理した方がいいかもしれません．
+というようなところが今まで考えたところですが，そこでこの前にも書いた
+疑問に戻ります．果してこんなことをする意味があるのだろうか？
+phone を hack すれば，それで問題は解決するのではないか？
+何か意見を言ってください．お願いします．
+私はこれを今度の meeting で議論してもらいたいとは思っていません．
+あくまで mail で意見を聞かせて下さい．そうすることで，
+議論がたまたま meeting に出席した人の中だけでの閉じたもので
+終るということがなくなると思いますから．
+ところでこの mailing list はいつまで東工大で管理されているのですか．
+u-tokyo に移した方がいいのではないのですか？
+