TSS/360

1964年春天，当IBM宣布System/360系列计算机时，整个计算世界为之震动。这是第一次，一家公司敢于用一套统一的架构覆盖从科学计算到商业数据处理的全方位需求，用一条产品线取代此前各自为政的IBM 1401、7090、1620等数十种不兼容机型。System/360的诞生本身就是一场豪赌，IBM为此投入了50亿美元——相当于今天的400多亿美元，比曼哈顿计划还要昂贵。而在这一庞大计划的阴影下，一个更加激进、更加冒险的项目悄然启动，它被称为TSS/360，全称Time Sharing System/360。

要理解TSS/360的诞生，必须回到那个时代。1960年代初，计算机的使用方式正在经历一场静默的革命。此前，计算机是神圣的圣殿，程序员将穿孔卡片交给操作员，等待数小时甚至隔夜才能拿到结果。这种批处理模式效率低下，浪费了程序员最宝贵的资源：思考的时间。麻省理工学院的费尔南多·科巴托（Fernando Corbató）领导团队在1961年开发了CTSS（兼容分时系统），首次让多个用户通过电传打字机终端同时使用一台计算机。CTSS展示了分时的魔力：每个用户感觉自己独占机器，而计算机在用户思考的间隙迅速切换任务。这种体验让IBM的工程师们坐不住了。

IBM内部对分时技术的兴趣由来已久。早在1959年，IBM的约翰·麦卡锡（John McCarthy，后来发明了Lisp语言）就曾建议在IBM 7090上实现分时系统，但未被采纳。当System/360计划启动时，IBM的高级副总裁鲍勃·埃文斯（Bob O. Evans）和弗雷德·布鲁克斯（Fred Brooks，后来写了《人月神话》）意识到，如果System/360不能支持分时，它将被新兴的竞争对手——尤其是通用电气的GE-645和麻省理工的Multics项目——甩在后面。于是，在1964年4月System/360正式发布的同一个月，IBM秘密启动了TSS/360项目。

TSS/360的野心令人瞠目。它不仅要实现分时，还要提供虚拟内存、动态链接、文件系统保护、多处理器支持等当时闻所未闻的功能。虚拟内存意味着程序可以访问比物理内存更大的地址空间，操作系统自动在内存和磁盘间交换数据。动态链接允许程序在运行时才加载共享库，而不是在编译时静态绑定。这些概念在今天看来稀松平常，但在1964年，它们几乎是科幻小说。

负责TSS/360的团队位于IBM的波基普西实验室（Poughkeepsie Laboratory），由工程师埃德·萨瑟兰（Ed Sussenguth）领导。队成员包括后来在计算机科学史上留下名字的人物：肯·汤普森Ken Thompson）、丹尼斯·里奇（Dennis Ritchie）虽然当时尚未加入，但汤普森确实参与了TSS/360的早期工作；还有查尔斯·巴赫曼（Charles Bachman，后来因数据库技术获得图灵奖）。这个团队面临着一个几乎不可能完成的任务：同时开发全新的硬件（System/360）和全新的操作系统（TSS/360），而且两者都在不断变化。

开发过程的混乱程度超乎想象。System/360的硬件设计在1964年到1966年间经历了多次重大修改，TSS/360的软件必须随之调整。更糟糕的是，IBM内部同时存在多个操作系统项目：OS/360（面向批处理）、DOS/360（面向小规模用户）、CP-67/CMS（面向虚拟机），以及TSS/360。每个项目都在争夺资源和工程师。弗雷德·布鲁克斯后来在《人月神话》中描述了这种“焦油坑”般的困境：大型软件项目的复杂性远远超出任何人的预估。

TSS/360的第一个版本原定于1966年交付，但直到1967年才勉强发布了一个“测试版”。这个版本的问题多如牛毛：虚拟内存交换效率极低，响应时间长达数秒甚至数分钟；动态链接经常导致系统崩溃；文件系统保护机制存在安全漏洞。IBM的客户，包括美国国防部、麻省理工学院和贝尔实验室，在试用后纷纷失望。麻省理工学院原本计划用TSS/360作为Multics项目的基础，但很快转向了GE-645。贝尔实验室则因为TSS/360的性能问题，决定放弃分时系统，转而开发自己的操作系统——这后来导致了Unix的诞生。

1968年，IBM发布了TSS/360的正式版本，但问题依旧。用户报告说，在20个用户同时登录时，系统响应时间就变得不可接受；而IBM宣传的目标是支持200个用户。虚拟内存的实现方式——分段式分页（segmented paging）——过于复杂，导致页面错误处理效率极低。动态链接虽然技术上先进，但缺乏有效的版本管理，常常出现“链接地狱”。IBM投入了超过1000名工程师和数亿美元，但TSS/360始终未能达到设计目标。

1969年，IBM做出了一个艰难的决定：停止TSS/360的进一步开发，只提供有限的技术支持。这个项目实际上被放弃了，虽然IBM直到1971年才正式宣布终止。TSS/360的商业失败是惨重的：它从未获得超过50个客户，大部分是IBM内部和少数研究机构。相比之下，OS/360获得了数万客户，CP-67/CMS也在学术圈取得了成功。

然而，TSS/360的遗产远比它的商业表现更加深远。首先，它证明了虚拟内存在大型机上的可行性。尽管实现有缺陷，但TSS/360的虚拟内存概念直接影响了后来IBM的MVS操作系统和英特尔的x86架构。其次，动态链接技术虽然在TSS/360上表现不佳，但后来被Unix和Windows采纳，成为现代操作系统的标准功能。第三，TSS/360的多处理器支持为后来的并行计算奠定了基础。

最引人注目的遗产来自一位参与TSS/360的年轻工程师：肯·汤普森。1966年，刚从加州大学伯克利分校毕业的汤普森加入了IBM波基普西实验室，参与TSS/360的测试工作。他很快对TSS/360的复杂性和低效感到沮丧。据说，汤普森曾抱怨说，编写一个简单的“Hello World”程序在TSS/360上需要加载整个操作系统，花费数分钟时间。这种体验让他对“小而美”的软件哲学产生了信仰。

1968年，汤普森离开了IBM，加入了贝尔实验室。在那里，他遇到了丹尼斯·里奇，两人开始开发一个“简化版的分时系统”。汤普森在IBM的经历告诉他，分时系统的核心是简洁和效率，而不是堆砌功能。他借鉴了TSS/360的虚拟内存概念，但去掉了复杂的分段机制，采用更简单的分页。他借鉴了动态链接的思想，但将其简化为共享库。他借鉴了文件系统保护，但设计了一套更清晰的权限模型。这个系统最初被称为Unics（Uniplexed Information and Computing Service），后来演变为Unix。

Unix的诞生故事有很多版本，但一个广为流传的轶事是：汤普森和里奇在贝尔实验室的走廊里用一台废弃的PDP-7计算机开发Unix，因为TSS/360的失败让他们意识到，分时系统不需要大型机，小型机也能做到。1970年，Unix在PDP-11上运行，证明了这一点。Unix的设计哲学——简单、模块化、可移植——与TSS/360的复杂、臃肿形成了鲜明对比。

TSS/360还间接影响了Multics。Multics是麻省理工学院、通用电气和贝尔实验室联合开发的分时系统，原本计划使用TSS/360作为基础，但因TSS/360的失败而转向GE-645。Multics虽然商业上也不成功，但它引入了许多创新概念，如层次化文件系统、动态链接（再次）、安全分级等。这些概念后来被Unix吸收，并通过Unix传播到整个计算世界。

在计算机历史博物馆的展柜中，TSS/360的磁带和手册静静躺着，旁边是System/360的模型和Unix的早期版本。参观者可能会问：为什么一个失败的项目值得纪念？答案在于，失败往往比成功更能揭示技术的本质。TSS/360的教训是深刻的：软件工程不能靠蛮力，复杂性需要被管理，用户需求必须被倾听。IBM在TSS/360上的失败，催生了《人月神话》中关于“没有银弹”的著名论断，也催生了Unix这个改变世界的操作系统。

TSS/360还留下了另一个有趣的细节：它的文档系统。为了管理庞大的代码库，TSS/360团队开发了一套早期的版本控制系统，称为“Source Code Management System”（SCMS）。这套系统允许开发人员追踪代码变更，回退错误，协调多人协作。SCMS后来被IBM内部的其他项目采用，最终影响了RCS（Revision Control System）和CVS（Concurrent Versions System）的设计。今天，Git的祖先可以追溯到这些早期的尝试。

1970年代初，当TSS/360被正式废弃时，IBM内部有一些工程师试图挽救它。他们提出了TSS/370计划，试图将TSS/360移植到新的System/370架构上。但IBM高层已经失去了耐心，决定将资源集中在MVS（Multiple Virtual Storage）上。MVS继承了TSS/360的虚拟内存和动态链接概念，但采用了更务实的设计。MVS后来成为IBM大型机的主流操作系统，一直使用到21世纪。

TSS/360的故事告诉我们，技术史上最伟大的进步往往来自失败。如果TSS/360成功，Unix可能永远不会诞生，或者会以完全不同的形式出现。如果TSS/360成功，分时系统的演进路径可能会更早成熟，但也可能更早陷入僵化。TSS/360的失败不是终点，而是起点。它像一块垫脚石，让后来的工程师们看到了些路走不通，哪些路值得探索。

在撰写这篇文章时，我查阅了计算机历史博物馆的档案，看到了TSS/360的原始设计文档。那些泛黄的纸张上，工程师们用铅笔绘制了复杂的流程图，标注了数百个模块的接口。他们显然付出了巨大的努力，但努力的方向有时比努力本身更重要。TSS/360的设计者试图用一次工程奇迹解决所有问题，结果却被问题淹没。而Unix的设计者选择了另一条路：先解决核心问题，再逐步扩展。这两种哲学的对立，至今仍在软件开发中反复上演。

最后，让我们记住TSS/360带来的两个重要数字：它投入了超过1000名工程师和5亿美元（按当时币值），最终只服务了不到50个客户。如果按每个用户成本计算，TSS/360可能是历史上最昂贵的软件之一。但它的价值不能用金钱衡量。它教会了整整一代工程师如何思考操作系统、如何管理复杂性、如何从失败中学习。这些教训，比任何成功的软件都更加宝贵。