見出し画像

この製品覚えてますか?

ウイングアーク1st 20周年

「いつも昔話ばかり書いていて良いのだろうか」「何か他の技術者の役に立つようなことを書くべきか」と、毎回何を書くか悩んでいますが、今回は20周年ということで、堂々と昔話を書くことにします。
あまりにも昔のことなので、記憶違いや勘違いがあったらごめんなさい。

まずは、ウイングアーク1stになる以前からある製品から。

Virtual-DOS

これはWebで検索してもなかなかヒットしませんね。「翼システム Virtual-DOS」で検索すると数件出てきますが。
MS-DOS をマルチタスク化するという、かなり興味深いものです。
この製品があったから、いま私はこの会社にいるんです。

たぶん1995年だと思いますが、私は「人売り」のような会社にいて、何もすることがないのに長時間拘束されるのが嫌になっていました。
まあ、残業代はちゃんと出たので、ボーナスよりも残業手当の方がずっと多くて、そういう意味ではよかったんですけど。
そんな時に偶然、雑誌の広告?でこの製品を見つけたんです。
「こんな面白そうなものを作る会社が日本にあるんだ」と思ったのが転職のきっかけになりました。
ただ、結局入社してから一度も現物は見ていないんですけどね。

Visual Formade for Report

Visual Formade for Report は、SVFの元になったもの、というかSVFに含まれているものです。SVFは「Super Visual Formade」Visual Formade for Report に Super の部分(Report Writer 機能)を追加したものです。
現在、ウイングアーク1stのサイト見ても Visual Formade という文字列はあまり出てきませんね。もう、SVFという名前の製品になったということですね。

そういえば、この Super 部分には「クラスタリング機能がある」と作者から聞いたことがあります。
この機能を有効化すると、LAN内にあるSVFを見つけて自動的にクラスタリングを行い、負荷分散だったり冗長化が行えると言っていたと思います。
私はこの辺りのソースを見た記憶がないので、どのように動くのかは分かりませんし、本当にこんな機能があったのかは定かではありませんが。

Visual Formade for Screen

で、なぜ for Report と付いているのか?それは for Screen という別製品があったからです。印刷を制御するものと画面を制御するものがあったのです。
私は、この製品が動いているのを見たことがありません。営業からの問い合わせがあったことは覚えているので、ちゃんと存在したはずですが。
この製品は、とある事情によりソースファイルが失われたため、途中で販売停止になったような気がします。

サポートシステム

これは製品ではありませんが、「営業からの問い合わせ」で思い出しました。当時は営業から開発への問い合わせは FAX で行われていました。
当時の FAX は感熱紙だったので、そのまま保存しておくと消えてしまうし、ロール紙が無くなると受信できないし、結構大変でしたね。
過去の履歴はわからないし、進捗状況もわからないし。
というのをなんとかしようと社内向けのサポートシステムを構築しました。

このサポートシステムに入っていた過去データは、現在使われているシステムにもインポートされて残っています。
製品名とかが手入力だったので、名前のブレが大きくて後から検索するときに大変でした。新しい製品の追加とか、名前の変更なんかがよくあったので、名前を選択式にすることができなかったんですよね。
当然、製品マスターDBなんてありませんでしたし。

私はWEB屋さんでは無いですし、Macromedia Dreamweaver(Adobe Dreamweaver)のようなWebオーサリングツールも無かったので、エディタで地道に書いてましたね。
セキュリティ上 Java Script 禁止という時代だったので、ほぼ HTML だけでしたが。

余談ですが…

Windows 95が出る前、日本国内で PC を使う個人はまだ少なくて、高性能PCは並行輸入とかで入手していました。
で、1995年に「日本ゲートウェイ株式会社」ができる直前くらいだと思いますが、アメリカのGATEWEY2000から購入したPCを使ってましたね。
当時を知る人には「牛柄の箱」でお馴染みのやつです。

USロボティクス製のモデムなんかも輸入して使ってました。
夜な夜な新潟事務所と繋いで、DOOMとかQuakeとかのゲームをやるためだったというのはここだけの話。
夜11時を過ぎると通話料金が固定になる「テレホーダイ」があったから。
すいません。モデムとかテレホーダイとか、常時接続が当たり前の若者にはまったくわからない話でした。

PCを輸入したのは、確か1ドル80円くらいの時でした。決済された時は86円くらいになっていて悔しかったことを覚えています。それが最近は150円。
もうPCを輸入しようなんて人はいないでしょうね。

FormDistributor

これは流石に誰も知らないと思います。
昔なので「共有ファイルサーバー」なんてものは無かったのです。
SVF設計部を使用して様式ファイルを作成する人/PCと、それを使用して印刷を行う帳票サーバーとの間でなんとかして様式ファイルを同期させる必要があるのですが、手作業でコピーしてるとミスが発生します。
双方のPCにこのアプリを常駐させておくと毎日1回ファイルを同期してくれるというだけのアプリでした。
今だったら Windows の標準機能だけでできそうです。

SVF Unix版

SVFのUnix版なら今でもあるじゃないか。そうですね。今あるのはJava言語で書かれたもので、Java VMがあるOSなら大体どのOSでも動くはずです。

初期のSVFはC言語で書かれていて、Windowsで動作するように作られていました。初期は Windows NT の16ビットモード(Win16)用のドライバーもあったはずで、デバッグしているのを見た記憶があります。
で、このSVF(C版)をUnix系OSで使いたいという人がいて、Solaris版を作りました。あ、最初の頃はまだ Sun OS だったな。
開発用のUnix機を自前で用意できる状況では無かったので、要望があるたびに客先へ出向いて、現地でビルド&デバッグしていました。
一番レアなのは、たぶんNEWS(SONYのワークステーション)版ではないかと思います。1社しか使っていないはず。

これは結構いろんなところで使われるようになって、対応OSも増えてきたので、どうやったら簡単にビルドできるか考えました。
まだ configure スクリプトを生成する AutoConf が普及していなかったか、私が知らなかっただけかはわかりませんが、configure を使用せずに、make の機能だけでやってました。
make を実行すると、OSの環境変数とかを見てビルド時に必要な引数とかを自動的に変えていました。
CPUのエンディアンを区別していたりするのがC言語っぽいですかね。

コネクト系いろいろ

昔は、社内システム本体はUnixがメインで、印刷もUnix上の専用アプリから行うことが多かったと思います。

SVFはWindowsで動作するソフトウエアなので、印刷データをなんらかの方法でWindowsに持ってくる必要があります。
前述したUnix版を使うというのもありですが、Windows版の方が安いですし、複数台必要なら価格差もさらに大きく。
そこで、UnixとWindowsの間を橋渡しするソフトウェアをいろいろ用意しました。

VFD(正式名称はなんだろう?UnixConnect?)の場合は、帳票サーバーはUnixです。Unix上のユーザープログラムからSVFっぽいAPIを呼ぶと、SVFの内部形式で書かれたテキストファイルが生成されます。
APIでジョブの終了を指示すると、Unixで動作しているVFDにスプールされて、順に指定されたWindows側に送信されます。
Windows側にはこれを受信するサーバーがあり、受信データをSVFに渡して印刷を行います。
Unix側にはCUIでできた制御画面があるという変わった製品でした。
とても単純な構造とスプール形式だったので、後日ユーザー側でGUI画面を作って使っていましたね。

最初はHP-UX版しかなかったのですが、AIX、Linux と対応OSが増え、最後にはWindows版まで作ることになってしまい、UnixConnect(Windows版)という謎製品ができることに。

send/kick/svf_ora(svf_oraは今でもfor OracleEBSとしてあるのか?)は、「出力用のcsvファイルは自前で用意できるので、印刷だけWindowsのSVFでやって欲しい」という要望に応えたもの。
sendはファイルを送信して印刷も行うもの。
kickはファイルはすでに送ってあるので印刷指示だけを行うもの。
svf_oraは、Oracle EBSの印刷処理をSVFで行うために、クエリー条件などをSVFに引き渡して印刷を行うものです。

RD connect(RDI Connectじゃないよ)
Report Director(C版)のUnix版というのは存在しないので、Unix機からRD(C版)を通してスプール/印刷したい場合は困るわけです。そこで、SVF Unix版のソースに通信機能とRD(C版)のAPIを追加して、Unixから呼び出せるようにしました。
これを作ったというのは覚えているのだけど、納品されたかどうかは分かりません。

コネクト系は他にもあったと思いますが思い出せません。

SVF用perlライブラリ

perl言語からSVF(C版)を呼ぶためのライブラリです。
当時は、Webサーバーで何かプログラムを実行したい場合は、cgiという仕組みが使用されていて、手軽に書けてそこそこ複雑なことも行えるので、perl言語が使用されることが多かったと思います。
社内で、WebページからPDFを出力するのにSVFを使っていたのですが、C言語で書くといちいちコンパイルしないといけないので、cgi本体はperlで書いて、perlからSVF(C版)を呼ぶためのライブラリを通して呼んでいました。
社内ツール(というか私が使いたかっただけ)としてのライブラリだったのですが、それを誰かが聞きつけて売ってしまったような記憶があります。

ソース管理の話

と、ここまで書いて「他に何があったかなあ?」と思い「ソースでも見るか」と思ったのですが、今となってはソースが見つからないものもあります。
昔のことなのでソース管理がちゃんとしていなかったんです。
もしかするとソースはあるのかもしれないけれど、リポジトリから見つけることができないということも。

まさか売られるとは思っていないので、最初はzipしてバックアップ。
あ、嘘です。昔なので、zip ではなく、lha で圧縮してました。

その後、ローカルでソース管理を行うようになり、RCS を使用。
私が関わった古いソースには RCS のキーワード置換用文字列が埋まっていて、コンパイル後の実行ファイルしかない状態でもバージョンなどがわかるようにしていました。

複数人で作業するようになってくると RCS では難しいので、CVS に移行、最近まで CVSWeb というWebブラウザーからリポジトリを見るツールが残されていましたが、CVSWebのメンテナンスも止まってしまい、最近のOSで動かなくなったということで、サーバのリプレイスと共にすべて git に変換されたようです。

そういえば VSS も使ってたような。VSS にあったやつは CVS に取り込んだんだっけかな?

こうやって振り返るときにも役に立ちますので、些細なツールもリポジトリにあげておきましょう。選定したバージョン管理システム自体が廃れちゃうとちょっと大変ですが。
CVS の後に一瞬だけ SVN を使っていましたが、すぐに git になったような気がします。
というわけで、バージョン管理システムの選定には注意しましょうという話でした。

おわりに

もう忘れられてそうな製品をいくつか挙げましたが、覚えているもの、気になったものはありましたか?
ネットワークが普及して一般的になるまで、つなぎ的に使用されていた製品はこのほかにもいろいろあったと思います。
また、PCの高性能化とOSの進化で、高価なUnix機を買わなくても、Windows/Linuxでできるようになり、不要になった製品もあると思います。
ただ、製品としては廃盤になってしまったものでも、その一部がそのまま後継製品の一部となって受け継がれていたり、他の言語にコンバートされて残っていたりします。
古い製品を思い出してみると、新しい製品を思いつくきっかけになるかもしれません。

次回はクラウドのことを書けるといいなあ。また昔話かなあ。



この記事が気に入ったらサポートをしてみませんか?