摘要

  • NETRJS 让远端主机模拟批处理终端，向 UCLA-CCN 的 IBM 360/91 提交作业并取回结果。
  • 操作台、卡片输入与打印输出使用不同通道；RFC 还记录了真实的字符映射与结果交付问题。

用户离线后，结果仍会返回

批处理作业完成时，提交它的人可能早已断开连接。NETRJS 允许远端用户把作业送到 UCLA 校园计算网络，退出会话，稍后再登录取回结果。ARPANET 把输入送到主机，也把主机的输出送回用户。关键单位不是一次网络连接，而是作业走完的整个往返。

虚拟终端让批处理作业接入网络

1977 年的 RFC 740 将 NETRJS 称为 UCLA-CCN 为 IBM 360 Model 91 批处理提交而实现的“专用协议”。同一套 Remote Job Service 也通过专线服务真实的远端卡片批处理终端。因此，这是一项既可由 ARPANET 访问、也可经其他通信线路访问的具体计算服务；它并不能证明所有 ARPANET 作业都在 UCLA 上运行。

结果送达之前，作业还未完成

远端被建模为 Virtual Remote Batch Terminal（虚拟远程批处理终端）：卡片读入器接收作业，打印机与穿孔机返回输出，操作员控制台用于登录、下达命令和接收状态或错误。输入是一串卡片映像，每张最多 80 个字符，并可携带作业控制语言。服务器按优先级将作业排入批处理系统，然后把打印或穿孔结果送回提交它的虚拟终端。用户可以等待，也可以稍后回来。

控制与数据分开传送。操作员控制台使用全双工 Telnet 连接；卡片读入、打印与穿孔各有独立的单向通道。协议允许客户端与服务器之间最多建立五条连接。数据通道只需在使用时打开，读入、打印和穿孔也可以并行。远端主机由此操作的是一组批处理虚拟外设，而不是一台交互式终端。

NETRJS 的历史早于 1977 年规范。RFC 88 在 1971 年描述了它，RFC 599 于 1973 年更新；RFC 740 后来取代 RFC 189 与 RFC 599。1973 年的更新留下罕见的运行快照：当年 10 月，UCLA-CCN 经 NETRJS 提交 1,373 个作业，其中 1,105 个打印、没有作业穿孔。记录还列出读取 49,400 张卡、打印 822,900 行、18,907 页，以及 393.6 个连接小时。这些数字只描述当月的 UCLA 服务，不是整个 ARPANET 的统计。RFC 599 将平均 360 行（“卡片”）输入、745 行输出、共 17.1 页的作业称为相当典型。

这些总数并不意味着结果一定安全到达。RFC 599 解释了名为“squish”的问题：NCP 缓冲延迟可能让批处理主机在第一条消息抵达远端前，就先删掉短打印文件。远端主机崩溃或用户取消传输时，唯一输出可能因此丢失。UCLA 的修复办法是：NETRJS 等待网络对数据结束标记给出 RFNM 确认，再通知 RJS 删除输出。于是，作业完成要跨过两道边界：计算结束和交付完成。

字符集是另一道边界。UCLA 的 IBM 360 用 EBCDIC，而部分远端用户进程使用 ASCII。1972 年，RAND、犹他与伊利诺伊的用户指出初始转换表存在缺陷；UCLA 随后修改映射并增加另一种方案。1977 年的规范允许虚拟终端选择 EBCDIC、ASCII-68 或 ASCII-63，必要时由服务器转换卡片输入和打印输出。

NETRJS 展示了互联网如何承载排定的计算工作，而不只是实时对话。用户提交结构化作业，服务决定何时执行，再通过分离的通道返回结果。RFC 留下的不是抽象的“远程访问”，而是一套具体交付契约：谁能登录、卡片如何进入、结果如何取回、字符怎样兼容，以及何时可以安全删除。网络使批处理主机可达，服务才让整段工作流程真正可用。

一手资料