← 2026-02-08 の一覧へ戻るホーム
IBM 3270 情報表示システムに新たな視点を――

2026/02/04 1:40

IBM 3270 情報表示システムに新たな視点を――

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

（欠落しているポイントを含む）**

要約

IBM 3270情報表示システムは、1台のメインフレームが数千人のユーザーにサービスを提供できるよう設計されました。階層的な構成―Central Processor Complex (CPC) とI/O・通信・暗号化用の多種多様な専用プロセッサ―によってこれを実現しました。端末は「ブロックモード」で大量データを転送し、EnterキーやPFキーなどが押されたときにのみ更新を送信します。

物理リンクは93 Ωのコーキルケーブルで、最大3 kmまで2.3587 Mb/sで動作可能でした。これはRS‑232（15 m、9 600 bps）を大幅に上回ります。主要ハードウェアにはIBM 3179 CRT（14″、7色、115 VACトランスフォーマー）とIBM 3174 Establishment Controller が含まれます。このコントローラは最大8台のディスプレイを駆動し、同期／非同期、Ethernet、Token Ring、「Bus & Tag」インタフェースをサポートし、SNA、TCP/IP、およびASCIIホスト間のゲートウェイとして機能します。

現在、このプロトコルはTelnet 3270（tn3270）として存続しており、現代のLinuxやWindows端末がtelnet経由でそれをエミュレートできます。Open Establishment Controller (oec) プロジェクトは、レガシーなコーキルとモダンなシリアル／Ethernetリンクを接続するオープンハードウェアのPython/FPGAブリッジを提供します。その第1世代はDP8340/DP8341 IC と Arduino Mega 2560 を使用していましたが、新しい interface2 デザインではそれらを Lattice iCE40 FPGA と STM32 マイクロコントローラに置き換えています。

著者は希少なEthernet版 IBM 3174 コントローラを取得し、oec ハードウェアで使用できるよう変換する計画です。再構成後、Hercules を実行している Raspberry Pi がヴィンテージメインフレーム OS をエミュレートでき、現代のデバイスとレガシー 3270端末との本格的な相互作用が可能になります。これにより、新しい IBM 装置を高価に購入することなく既存のインフラストラクチャを保存・拡張できることが示され、ホビイスト、教育者、および古いメインフレームインタフェースを維持または研究する必要がある企業に利益をもたらします。

本文

昔ながらのメインフレーム表示システムは、時代を先取りした点が多く、当時としては画期的でした。

IBM のメインフレームコンピュータは約 60 年にわたり進化し続けてきました。これは「ミッドレンジ」やパーソナル・コンピュータの登場、TCP/IP の爆発的な普及といった業界全体のトレンドへの対応でもありますが、同時に小型システムには後からしか現れない機能や性能を提供し続けてきた点も特徴です。さらにその信頼性は今なお揺るぎません。

本稿では、単一のメインフレームコンピュータで数千人のユーザーにサービスを拡張できる IBM 3270 情報表示システムについて解説します。主に過去形で語られますが、メインフレーム自体は存続しており、3270 も現在では TCP/IP 上で動作するプロトコルとして生き続けています。

大規模システム

IBM 3090 プロセッサの研修ビデオ。

日常的に遭遇するコンピュータシステムは、サーバー・デスクトップ・モバイル機器といった共通したアーキテクチャを持ちます。主な違いは CPU コア数や RAM／ディスク容量です。中央処理装置（CPU）がそれ以外の作業を担います（GPU やストレージコントローラがある場合を除く）。

大規模システムでは、メインフレームが中心に配置され、より階層的な設計が採用されます。1 つまたは複数の「メイン」CPU に加えて、I/O、通信、暗号化など専用プロセッサが多数存在し、中央処理装置コンプレックス（CPC）が本来のコアタスクに集中できるようになっています。

これで IBM 3270 へとつながります。3270 は大量データブロックをメインフレームに転送する端末ファミリで、I/O 割込みを減らす設計です。現代の Web フォームが入力フィールドにデータを記入し、送信前に検証されるように、3270 端末は Enter・SysReq・Clear・PF といった特定キーが押されたときだけデータを送ります。ミッドレンジシステムではすべてのキーストロークに応答しなければならない点も大きな違いです。

メインフレームは高稼働率、ホットスワップ可能な CPU、運用中のファームウェア更新、そして近年では Linux ワークロードを古典的メインフレームタスクと共存させるハイブリッド戦略により、サイズとコストを削減しています。

本稿の目的はアーキテクチャの詳細比較ではなく、3270 に焦点を当てることです。

データストリームとインターフェース

表示システムの特徴的な点はデータストリームにあります。リアルタイムでキー入力を送信する通常端末とは異なり、3270 端末やプリンタには erase・write・read・copy 等のコマンドで管理されるバッファがあります。各画面位置にはアドレスが割り当てられ、メインフレームはそれを操作し、特定キーが押されたときのみ割り込みを発生させます。プログラムが画面を更新すると通信は終了し、ユーザーはフィールド間を移動できるようになります。

物理インターフェース

  • 通常端末は RS‑232（最大 15 m ケーブル、約 9,600 bps）を使用
  • 3270 端末は 93 Ω の同軸ケーブルで、コントローラから最大 3 km 距離、2.3587 Mb/s で接続
  • マルチプレクサにより複数の端末が1本のケーブルを共有；後期モデルは複数セッションとファイル転送もサポート

現在は Ethernet と TCP/IP が標準的なネットワーク技術ですが、IBM の 3270 と Systems Network Architecture（SNA）は DECnet 等の競合する標準が存在した時代にリーダーでした。

現代への関連性

3270 は Telnet 3270（tn3270）のおかげで生き続けています。これは Linux や Windows で端末エミュレーションを行い、Telnet 経由で 3270 データストリームの送受信が可能です。多くのメインフレームアプリケーションは現代的なフロントエンドへ移行しましたが、システムとアプリケーションプログラミングは tn3270 セッションを介して継続されています。

表示装置

3270 の表示装置には多くのバリエーションがあり、それぞれに固有のモデル番号があります。モノクロからカラーへ、フロッピードライブやファイル転送機能の追加まで進化しました。

主な区別

  • Control Unit Terminal（CUT）：データストリームは表示コントローラで終端
  • Distributed Function Terminal（DFT）：表示装置がデータストリームをほぼ全て処理。ファイル転送や複数セッションに対応

PC の登場により、ISA・MCA・PCI 拡張ボードやラップトップ用 PCMCIA カードで 3270 エミュレーションが可能になりました。

IBM 3179

完全な 3279 表示装置を入手するのは難しいですが、米国では比較的入手しやすいです。ロジックボード付きベースユニットは見つかることがありますが、IBM 独自のモニタとキーボードは希少です。

  • モニタ：年齢に伴う故障が多く、数は減少
  • キーボード：構造品質と打鍵感で高評価

3179（1984 年発表）は 14 インチ CRT、7 色表示を備え、ディスプレイ／プリンタアダプタ経由または IBM 3274 コントローラ経由で直接接続可能です。コントローラはトークンリング、Ethernet、あるいは「テレプロセッシング」アダプタを同期シリアルライン上で使用します。英国向けには 115 VAC トランスフォーマー（Block 200VA）が必要で、メインソケットは C13 IEC コネクタに置き換えられ、230 VAC の警告ステッカーが貼付されます。

設定コントローラ

表示装置にはコントローラが不可欠です。英国では IBM 3174 設定コントローラを数台見つけました。それぞれ最大 8 台のディスプレイに接続し、同期・非同期・Ethernet・トークンリングインターフェースでリモートメインフレームへ接続可能です。ローカル版は「Bus & Tag」というパラレルインターフェースを備え、専門プロセッサ経由で直接メインフレームに接続できます。

3174 は柔軟性が高く、デフォルトサービスへのディスプレイ接続やオプション提示、TCP/IP と SNA の両方をサポートし、ASCII ホスト（例：UNIX サーバ）とのゲートウェイとして機能します。また応答時間を監視して QoS を確保します。Ethernet モデルは希少で、使用する場合はシリアルまたはトークンリングから変換が必要です。

動機

IBM 4381 プロセッサマルチチップモジュールの上に Raspberry Pi 1 を置く例は、今日でも 3270 表示装置を実用的にしたい理由を示しています。2012 年 5 月には、Raspberry Pi が Hercules を動かしてメインフレームエミュレーションと本格的なビンテージ OS の実行を可能にする方法を発表しました。本物のメインフレーム端末があれば体験はさらに完成します。

オープン設定コントローラ

この欲求には共感者もいます。GitHub ユーザー lowobservable は oec（Open Establishment Controller）を作成し、Python 実装と 3270 用オープンハードウェア同軸インターフェースを提供しています。第 1 世代のハードウェアは廃止された National Semiconductor DP8340/DP8341 IBM 3270 プロトコル送受信 IC と Arduino Mega 2560 を使用します。後続設計ではこれらの IC を Lattice iCE40 FPGA および STM32 マイクロコントローラに置き換えています。

私はまず National Semiconductor IC 版を構築し、次に FPGA + STM32 バージョンへ取り組む予定です。

— Andrew Back

同じ日のほかのニュース

一覧に戻る →

2026/02/08 6:45

小型 C コンパイラ

## Japanese Translation: Tiny C Compiler（TCC）は、非常に小さな（約100 KBのx86実行ファイル）Cコンパイラであり、1回のステップでコンパイル・アセンブル・リンクを行い、バイトコード層なしでネイティブx86マシンコードを生成します。2.4 GHz Pentium IV上では、Links BrowserテストをGCC（20.0 秒）より約10倍速く実行できます（2.27 秒）。これは別のコンパイルステージが不要であるためです。 TCCはISO C99を完全にサポートし、自身をコンパイルでき、任意のC動的ライブラリを直接リンクすることも可能です。完全なプリプロセッサ、GNUスタイルのアセンブラー構文、オプションのメモリと境界チェック機能、さらにはシェバンベースの「Cスクリプト」まで含まれ、コマンドラインから実行できます。libtccライブラリにより、他のプログラムがTCCをランタイムコード生成のバックエンドとして使用できるようになります。 性能テストはPentium IV上で行われました。新しい測定値（参照1–4）では、モダンハードウェアでも速度向上が継続しています。ドキュメント、メールリストサポート、およびSavannah/GitHubリポジトリは最新情報を提供します。 TCCはGNU Lesser General Public License（LGPL）の下で配布されており、商用利用も許可されています。

2026/02/08 8:23

**良質なコードの静かな終焉**

## Japanese Translation: 著者は中学時代から「Good Code™」―読みやすく、保守しやすく、特定の目的を持って存在するコード――を書き続けることに情熱を注いできました。機能提供に重点を置くソフトウェアエンジニアとして、彼は今日の高速開発環境で良いコードがますます希少になっていると感じています。 同僚の経験はこの状況をよく示しています。外部Linuxカーネル統合システムをCからRustへ書き換えた後、最初のバージョンは機能していたものの読みづらく保守が困難でした。原始的なCロジックを学習した上で再度書き直すと、コードはクリーンになり、自明であり、元のCよりも優れていると言えるようになりました。この経験が著者に品質コードへの熱意を再燃させました。 現在、彼はほとんどの場合初期バージョンを書かず、代わりに「Good Code™」ではなく許容できるものを生成するコーディングエージェントに頼っています。このようなツールへの継続的な依存が個々の行レベルでの品質への注意を薄め、業界実務におけるGood Codeの静かな消滅を招くと彼は恐れています。コード品質が低下すると保守コストや技術的負債が増大し、開発者の生産性、製品の信頼性、そして最終的には企業から提供されるソフトウェアへのユーザーの信頼まで損なわれます。

2026/02/08 2:39

**セクターC：512バイトで実装されたCコンパイラ**

## Japanese Translation: SectorCは、x86‑16アセンブリで完全に書かれたCコンパイラで、単一の512バイトのブートセクタに収まります。Ultra‑compactなトークン化スキーム「Barely C」を使用しており、各スペース区切り語を「メガトークン」とみなし、`atoi()`で識別子をハッシュし64Kテーブルに格納します。変数はこのハッシュを通じてセグメント0x3000に保存されます。最初のBarely C実装は468バイトで、シンボルテーブルなしの再帰下降パーサーでした。バイトスレッド化されたForth風の変種も試みられましたが、サイズをさらに削減することはできませんでした。 最終的なコンパイラはわずか **303 バイト** です。サイズは、フォールスルーロジック、テイルコール、コールフュージョン、`lodsw/stosw`の広範な使用、およびすべてのジャンプオフセットを1バイト内に収めるなどの手法で削減されました。残り約200バイトでBarely Cは完全なCサポートへと拡張されました：ネストされたif/whileブロック、包括的な演算子集合（+, −, *, &, |, ^, <<, >>, ==, !=, <, >, <=, >=）、ハッシュテーブルを介した関数定義と再帰、インライン`asm`ステートメント、および単一行(`//`)と複数行(`/* */`)コメントの両方が実装されました。 コンパイラのランタイムは `rt/` ディレクトリ内の2つのCファイルに分かれています：ライブラリルーチン（多くの場合インラインasmを含む）を持つ `lib.c` とエントリポイントとして機能する `_start.c` です。これらはプログラムソースと結合してからコンパイルされます。記事には、全ブートセクタのBase64文字列、VGAモード0x13hで動くサイン波を描画するデモ、および追加例（`hello.c` はビデオメモリ0xB8000に書き込み、`twinkle.c` はPCスピーカーで「Twinkle Twinkle Little Star」を再生）が含まれています。この作業は、512バイトという一見不可能な目標—完全機能のCコンパイラを実現すること—が、創造的なトークン化、ハッシュ化、および積極的なコードサイズ最適化によって達成できることを示しています。