汎用機時代のデータ通信 ~温故知新シリーズ2~

汎用機時代

ココネコネクトでサーバエンジニアをしているYです。「温故知新シリーズ」第2弾として、改めて過去の技術を書いていきたいと思います。今回は今もまだ使用されている、汎用機でのデータの扱いをまとめてみました。

クラサバと言われてました。
広義では今のwebサービスもブラウザとwebサーバーとでクライアント・サーバ関係が成り立っています。
ここでは専用のPCをクライアントと呼び、このPCを使用することでホストとの通信を行える様になっています。

例えば自分が扱っていた損害保険のシステムだと以下の流れでデータが取り込まれます。

フロッピーディスク1による手作業でのコピーを行っていました。
クライアント200台とかキツかった。

バグとかで1日４回とかインストール作業があったことも。

(フロッピーディスク 3.5インチのものを主に使用。1.44MBの大容量を格納でき、今でも保存のアイコンに用いられていることもちらほら。ドクター中松が発明したという噂も。)

別名「電文」と呼ばれてました。

余計なデータを送信しないように、以下のような厳密に定義された形でのデータ送信を行なっていました。

今でこそJSONやxml等が当たり前ですが、現在とは異なり、通信環境も悪く、保存するためのストレージも小さかったので、限りあるリソースを有効に使用するための当時の主流となっていました。

上記の画像をもとに、実際に送信していたデータとしては以下のような形になります。

100-10-001 やまだたろう　　　　　　　　　 20220530163045

全角の文字の前と後には特殊な制御コードが入っており、これをシフトコードと呼んでいました。

大概使用する文字列よりも長く確保し、末尾にバッファとして数十〜数百バイトの予備枠を設けていました。これをFILLERと呼んでましたね。

文字コードも異なっており、ASCIIではなく、EBCDIC（エビシディック）が主流でした。

前述の全角文字を表示するためのシフトコードは、EBCDICから文字コードが切り替わりますよ。という符号と考えてもらえるとわかりやすいかもしれません。

シフトコードの前側、上記の「やまだたろう」の前1バイトはシフトアウトと言います。
この文字を境に、EBCDICコードから切り替わるサインです。逆に終わりはシフトインと言い、EBCDICコードに戻るサインです。

上述の固定長データで恐ろしいのがデータの増加です。

新規項目の追加
上記のFILLERを利用して、末尾に新しい項目を追加します。余裕です。
項目の分割
以下の様に一つの項目の続きを後ろに追加するケースが結構多くありました。後から後から追加されるので、1、2、3とかになることもありました。
固定長データのレングス変更
最悪のパターンです。
予期しない問題が発生するケースが多かった記憶があります。
当然テストは十分にしている（つもりな）んですけどね。