84 ビジネスコミュニケーション　2014 Vol.51 No.7

アーカイブアーカイブ

　

TSS（Time Sharing System）は、計算機システムを通信の手段により、複数の端末装置から同時に使用するような利用方式のことである。TSSと似たようなものにリモート・バッチ・システム、オンライン・リアルタイム・システムなどがあるが、これらとは明確に区別されるべきものであろう。

TSSが具備しなければならない機能としては、①各端末にたいして時分割によって平等なサービスをおこなうこと②プログラムを入力して実行させられること③強力なファイル・システムを備えていること④会話モードで処理ができることなどがあげられる。

TSSの初期における目的は、ターン・アラウンド・タイムの短縮、距離的な制約を克服することであった。しかし計算機の利用が進むにつれて、より高度な TSS

の応用として、情報の一括管理に基づくその蓄積と共用という新しい面があらわれてきた。また、大形計算機の出現により、経済性の面からも TSSの重要性が増してきた。本稿ではアメリカを中心として、TSSの現状と問題点を述べてみたい。

TSSが初めて提唱されてから約 15年近くになる。その思想は画期的なものとして、いたるところで多くの

実験的あるいは実用的なシステムが開発されてきた。とくにアメリカにおいては、数えきれないほどの大小さまざまなシステムが出現した。初期の頃は、TSSの設計と開発に経験を積むため、

多くの時間がさかれた。まがりなりにも一応使用できるシステムが完成する時期になると、利用面での研究がさかんにおこなわれ、研究用や教育用あるいは商業用としてのサービスが提供できるようになった。とくに、TSSのサービスを提供することを目的とした会社がアメリカでは続続と設立され、一時は TSS全盛期がきたかのようにみえた。しかし、乱立による過当競争と利用の仕方が十分に確立されていなかったこともあって、1960年代の後半には倒産する会社が続出した。この時期における経済状勢の悪化や計算機業界の再編

成なども、この動きに拍車をかけた。しかし多くの経験を積むことにより、大学や研究所における TSSの有用性は実証され、また商用TSSの位置づけも明確になっていった。そして 70年代に入ると、大規模な TSSがつぎつぎと開発され、本格的な実用化の時代へと移っていった。最初の TSSは、1960年にアメリカのマサチューセッ

ツ工科大学（MIT）で開発された CTSS（Compatible

TSS）である。このシステムは、現在の TSSに比べると大変単純なものであったが、その後 2～ 3年の間に改良がおこなわれ、CTSS 1.5や 2が開発され、IBM 7094を用いて約 30台の端末にたいしてサービスすることができた。CTSSは、現在でもMITの計算センタで既存のユーザにたいしてサービスをおこなっている。CTSSの意義は、その後の TSSに大きな影響を与えたことである。1965年からは CTSSを母体として、同じくMITで

TSS の動向と今後のあるべき姿

【1973年 6月号掲載】

宮崎 正俊東北大学 大型計算機センター講師

はじめに

「特集 タイムシェアリング・サービスをいかに利用するか」より

１. TSS の発展経緯

アーカイブ

85ビジネスコミュニケーション　2014 Vol.51 No.7

TSSの動向と今後のあるべき姿アーカイブ

Multics（Multiplexed lnformation and Computing

Service）の開発がはじまった。Multicsの影響を受けて、IBM 360/67による TSSや GE635の GCO Sなどが開発された。一方 IBMでは、CTSSをもとにして IBMのCMS（Cambridge Monitor System）や IBM370のための TSO（Time Sharing Option）が開発された。さらにCMSからは、IBM 370/168による仮想記憶（Virtual

StorageまたはMemory）をもつ TSSが最近完成された。MITのMulticsは、GE 635を仮想記憶が可能なように改造した GE645で動くシステムであるが、73年の 4月からは HIS社（Haneywell Information Systems）の6000シリーズに置き換えられた。これに先立ち HIS社は、73年 1月にMulticsを一般市場に売り出すことを発表した。ここに、2つの本格的 TSSが出現したのである。

CTSSの流れをくむ TSSの他に、60年以後独自に開発された多くのシステムがある。たとえば 62年から65年頃にかけて開発されたダートマス大学の DTSS、バークレイのカリフォルニア大学にある SDS940、ランド社の JOSSシステム、60年代後半から 70年にかけて開発された CDC6600、UNIVAC1108、B6700などの TSSがある。DTSSで使われた BASIC（Beginner’s All Purpose Symbo1ic lnstruction Code）という会話用言語は、TSSの普及に大いに役立った。日本においても、60年代の中頃からアメリカの影響を受けて TSS開発の機運が高まり、後半にかけていくつかの実験的 TSSが現われた。大阪大学の阪大MAC

（NEAC2200/500）、電子技術総合研究所の ETSS

（HITAC8400）、日立中央研究所の 5020 TSS（HITAC

5020）、電電公社の DIPS－ 0（HITAC 8400）、東北大学の東北大 TSS（NEAC2200/500）などがその例である。70年代に入ってからは電電公社の DEMOSのサービスが開始され、最近は東京大学に仮想記憶をもったTSS（HITAC8800、8700）が導入された。　

アメリカにおける TSSは、前にも述べたように、本格的な実用化の段階に入っている。利用の範囲は大別する

と、大学や研究所と企業に分けられる。大学のばあいは、研究の道具として使う他に教育にも効果をあげている。企業のばあいは、自社内だけで利用するばあいと、

TSSを他の多くの企業にサービスすることを目的としているばあいがある。企業のばあい、多量の入出力データを扱う事務計算には問題があるが、技術計算や意志決定の道具としては有効である。たとえば、ニューヨークにある TSSのサービス会社では、株式に関する情報提供のサービスをおこなっている。投資家が端末から必要なパラメータを入力すると、特定の株価のグラフなどが出力される。大学の TSSは 2つのケースがある。1つはメーカが

作った TSSをそのまま使用するばあいであり、他はなんらかの形で大学が改造あるいは開発に参加するばあいである。アメリカにおいては、とくに後者の例が多いようである。前述のMulticsは、MITとメーカが共同で開発したものである。計画の当初は研究的な色彩が強かったが、開発をはじめてから 4年後には稼動を開始し、その後は料金をとって実際のサービスをおこなっている。しかし、なお研究の対象として多くの改造や実験がなされつつある。アメリカの大学では、研究と教育のために大きな計

算機システムをもっていることが多いが、MITのように TSSサービスに力を入れているところと、プリンストン大学のようにバッチ処理だけをおこなっているところがある。バッチ処理が中心のところでもリモート・ジョブのサービスはおこなっており、相当数のリモート・ステーションをもっている。リモート・ジョブの入力の際、プログラムやデータの修正だけは TSSのように会話モードでできるようになっているところもある。大学の研究室単位でも、小形の計算機をもっていることも多いが、これらを TSSで使用していることがよくある。端末は数台程度と少ないが、タイプライタの他にキャラクタ・ディスプレイやグラフィック装置などをつけて、特殊な問題向きとして使用している。小さな計算機でも、占有して使用するよりは TSSのほうが効率が良いのであろう。

TSSの発祥の地であるMITの TSSについて少し述べ

２. アメリカの TSS

86 ビジネスコミュニケーション　2014 Vol.51 No.7

アーカイブアーカイブ

てみる。計算センタのMulticsはこの春にシステムのレベル・アップがおこなわれ、能力は約 3倍となって150端末が同時に会話できるようになった。さらにIBM370/168が 165に代わって設置され、バッチ処理の他に 30端末の TSSサービスができるようになった。MITの構内には約 300台の端末があり、どの端末からも電話のダイアルを回すだけでどちらのシステムのサービスも受けることができる。回線の速度は 110、134.5、1,200、3,300ビット／秒などであり、いろいろな種類の端末が接続できる。この他に、特定の研究所や研究室専用の TSSもいくつかある。たとえば、Project MACの PDP-10などである。

Multicsの開発は、MITと HIS社（以前は GE社とベル研究所）の共同でおこなわれている。現在は、HIS社の技術者が約 10名研究室に派遣されてきている。研究室に約 25台の端末があって、システム・プログラムの作成とデバッグに連日活用されている。TSSは最初、プログラムの作成とデバッグのために提唱されたともいわれるが、Multicsの例ではその効果はいちじるしいものがある。アメリカの TSSの動向で注目しなければならないのは、コンピュータ・ネットワークとの関係である。現在、強力に研究と開発が進められているネットワークにARPA（Advanced Research Project Agency）ネットワークがある。これはアメリカ国防省が中心になって進めているもので、大学、研究所、企業などその参加は広範囲にわたっている。ネットワークは、50Kビット／秒のリース回線を用いて全米にはりめぐらされており、約 25のユーザの40台程度の計算機（これを HOST計算機と呼んでいる）が結ばれている。これら HOST計算機は、ほとんどTSSである。Multicsもこのうちの 1つである。あるHOST計算機を使用するばあいは、自分のところのHOST計算機を介すときと、端末から直接使用するときとがある。筆者はこの 1月の末にロスアンゼルスのカリフォルニア大学（UCLA）から ARPAネットワークを通してボストンのMulticsを使用してみたが、ネットワーク・コントロール・プログラムによって端末が

Multicsに接続されたあとは、MITにいるときと同じ感じで使用することができ、ほぼ実用化の域に達していることがわかった。

ARPAネットワークの予算は各ユーザに配分され、ユーザのところでは各種の HOST計算機やネットワークの理論的な研究がおこなわれている。たとえばハワイ大学では、点在する多くの島々に TSSのサービスを提供するために、無線通信方式による TSSの開発をおこなっている。これを ALOHAシステムと呼んでいる。計算機は IBM360/65を使用している。筆者が 2月上旬に訪問したときは、6台の端末しか完成されていなかったが、安定に動作していた。別のグループではBCC500という TSSを開発している。これら 2つのシステムは、人工衛星のインテルサットで ARPAネットワークにつながれている。UCLAでは ANTS（ARPA

Network Terminal System）という TSSを開発しているが、このシステムの目的は主として ARPAネットワークの稼動デー夕を自動的に収集して解析することである。バークレイのカリフォルニア大学では、前述のSDS940を使って PRIMEという TSSを開発している。ハワイ大学の BCC500と PRIMEは CPUが 2つ以上（6と 5）ある多 CPUシステムである。

TSSの目的は、プログラムの作成やデバッグを容易にすることから、その後の研究と使用経験によって多目的利用へと拡大されていった。Multics開発のリーダであるMITのコルバト教授の構想は、コンピュータ・ユーティリティを実現しようというものである。つまり、電話や電力のように計算機のサービスを提供しようということである。そして、TSSがARPAのようなネットワークと結ばれることにより、広域コンピュータ・ユーティリティが実現することになる。コンピュータ・ユーティリティの実現のためには、

解決しなければならない多くの問題がある。Multicsの開発過程においても、これらの問題が重要な研究テーマになっている。主なものをあげてみると、

３. TSS の理想

アーカイブ

87ビジネスコミュニケーション　2014 Vol.51 No.7

アーカイブTSSの動向と今後のあるべき姿

①情報の蓄積と保護、およびその共用②システムの信頼性③システムの変更にたいする柔軟性④端末の独立性⑤使用可能なリソースの量⑥豊富なアプリケーションとライブラリーなどである。

TSSの有用性が認められはじめた背景には、情報を蓄積して一括管理したいという要求があるからである。TSSでは、情報（データやプログラム）をファイルという形で蓄積する。したがって、ファイルを障害による破壊や機密漏洩から保護することは、TSSにおけるもっとも重要なテーマである。一方では蓄積された情報の利用効果を高めるため、あるいはコンピュータ・ユーティリティの性格上その共用が必要になってくる。機密を保つことと共用とは技術的には相反する要求であり、ファイル・システムの設計の難しさがここにある。システムの障害によりファイルの内容が乱れたばあいは、可能な限り直前の状態に復元する必要があるが、これにはファイルの 2重化などによる経済上の問題と運用面におけるバック・アップの問題が含まれている。ユーザにとって、ファイルの信頼性は重要な問題である。システムの信頼性が要求されるのは一般のシステムと同様であるが、とくに TSSはリアルタイムでユーザと結びついているので、障害発生時の影響は大きい。障害をゼロにすることは事実上困難であり、その発生時の影響を最小限に止めるよう配慮すべきである。システムを 2重化するのも 1つの方法であるが、経済性の問題が出てくる。障害がハードウェアのばあいは、その箇所を切り離して自動的にシステムの再編成ができることも必要である。障害がソフトウェァによるものであれば、システム・プログラムの修正が必要となるが、これらが簡単におこなえるようになっていることが望まれる。一方、システムの変更はユーザからの要求などによりたびたびおこなわれることが多い。これらのことから、システムの変更にたいする柔軟性がきわめて重要である。

TSSでは、各端末のユーザ間に不要な干渉があって

はならないのは当然であるが、ユーザが自分の好みに合わせて独自の機能を追加できるようになっていることが望ましい。極端な表現をすれば、各端末を別々のオペレーティング・システムをもった計算機であるかのように見せようというわけである。このことは、TSS

の融通性をいちじるしく大きくするものである。TSSが単なる計算処理の道具から、ファイルを中心

とした情報処理システムに移っていくにつれて、要求されるシステム・リソースの量が問題になってくる。もっとも重要なのは、主記憶とファイルの容量である。これは、主としてコスト面での制約と関連があるが、妥協点を見つけるのは容易なことではなく、技術的あるいは運用面で解決する方法がいくつか考案されている。TSSの用途を広くし、使いやすいものにするには、多くのアプリケーションやライブラリーが用意されている必要がある。しかし、全部のユーザの要求を満たすだけのものを供給することは困難である。ユーザが開発したものを共用という形で利用していく必要がある。ユーザにとってもそのほうが便利なばあいがある。これらのプログラムは、ユーザが端末から容易にシステムヘ組み込むことができる必要がある。最近の大形機による TSSは、以上述べたような要求

を満たすように基本的な設計がなされている。もう 1度Multicsの例をとって、それらがどのように実現されているかをみてみる。ファイルの機密保持は、4段階のロックがなされてい

る。第 1段階はパスワード、第 2段階はそのファイルにアクセスしてよいユーザの名前、第 3段階はファイルのモード（読出し可、書き込み可、実行可など）、第4段階はリング機構である。リング機構はMultics独特の方式であり、これはファイルの全領域を仮想的な同心円状に分割し、中心に近い領域におかれているファイルほどアクセスの制限がきつくなっている。外側の領域から内側ヘアクセスすることは、あらかじめ決められたエントリー・ポイントを除いて禁止されている。逆方向のアクセスは自由である。一方ファイルの共用については、第 2段階から第 4段階までの機能を制御することにより実現している。