AI雑感
色々な業種のシステム開発を経験して参りました。良い機会なので記録として残しておこうと思います。
サンルートホテルグループが有ります。
現在も「サンルートホテル」で検索すると関連するホテルの情報が出てきますので、健在と思われます。
全国規模で展開しており確か大分では中津市にも有ったと記憶しています。
当時、HBM（日立ビジネスマシン）に出向という立場で社内のホテルチームの一員として参加しておりました。
ネットで検索するとまだヒットする「サンルート徳山」の新規オープンに備えての開発でした。
日立のオフコン（オフィスコンピュータ）でL-320モデルを使用します。
この頃OSはなんとFD（フロッピーディスク：一枚で1MB）の数枚に格納されており、
電源をオンにする時必ずアドレス1にOSのFDをセットしてローディングするのです。
このFDはメモリの常駐する為、正常に起動すれば取り外します。
筐体に左側下は、FDドライブが最大4台配置されています。予算の少ないユーザーは2台と言う事も有りました。
椅子に座ると、手の位置にキーボードが有り、その後ろにCRT（カソードレイチューブ：ブラウン管）のモニタが有ります。
その頃のモニタは、英文字の大文字、小文字、数字、記号を横80文字X縦24行=1920文字表示します。
1文字は小さなドット（点）で構成されておりその具体的な構成数は失念しましたが例えば12*8とか縦長でした。
お客様が操作するときの画面はこのサイズを意識して設計する必要が有りました。
専用の画面設計用紙があり、それに鉛筆で書き、客先での打合せ時はコピーして持って行くのです。
L-320のプログラム開発言語は「RFD」ReocordFormatDiscripterでした。
これは、複数のバッファーと言う連続するメモリ空間を開始位置とその長さと属性で区切っていきそれを如何に上手に使うか？
イメージ出来ない人は何を言ってるのか全くわからないとは思いますが。
所謂「高級言語」COBOLやPL/Iは、メモリ空間の場所に、予め名前をつけて長さと属性を定義します。
プログラム内での操作はその名前でハンドリングします。コンパイラと言う高級言語の付属のプログラムが
その名前とメモリ空間への割り当てを保証してくれて、プログラマはメモリのどこにその項目があるのかを知る必要無いのです。
RFDでは、複数あるバッファのどれか？その位置と属性を常に意識してプログラミングを行います。
実際のコーディングではバッファを間違えたり位置や属性の扱いを誤るとバグになり処理は停まります。
じつに緻密な作業です。この所作は実は、コンピュータの内部処理と密接な動きと連携しています。
私は汎用機のアセンブラ言語を理解しておりましたので、RFDを使いこなすのはそう難しい事では無かったのです。
アセンブラは、日立のコンピュータ学校で給料を頂きながら10か月勉強させて頂き卒論では
アセンブラで書かれたOSのロジック解析を発表しました。
アセンブラは、もっとも原始的な言語でメモリと命令語の動きを意識した「低級言語」（高級言語の逆」であります。
RFDは、インタプリタで実行されていました。
これは、実行命令を書かれたソース行を実行時に逐一解釈しながら動的に生成された実行命令を連続していく仕掛けです。
開発時のデバッグ作業では非常に使い勝手の良い動きです。命令文に書き方の誤りがあれば
即時、ここで異常が発生しました！とアナウンスしてくれるからです。
しかし難点は、常にソース行の解釈を実施しているので、その頃はCPUの性能が十分では無く動作自体が遅くなってしまうのです。
インタプリタのこの弱点を補うのがコンパイラ言語です。
ソース文全体を捉えて、文法的な矛盾点は警告やエラーを表示して書き方の改善を促してくれます。
コンパイラは検出可能な限りのエラーが解決された事が判ると、CPUが直接解釈可能なマシン語を生成し
メモリ上に配置可能な状態を作成します。
現在でもProgram.exe とかの名前の付いたファイルは、コンパイラのお陰で作成されたものです。
インタプリタに比べると格段に速く動作する事になります。
しかし、アルゴリズムの誤りで発生する実行時エラーでは、どこで発生したのかが判らない場合が殆どです。
VB.NET等では、異常終了時にイベントのトレースが行われて報告してくれるケースも有りますが。
ホテルのフロントシステムの開発では、この実行速度で問題が発生しました。
チェックアウトの時間は10：00までにとかの制限が有ります。
その時間になるとお客様が集中する訳です。
この問題の解決には実は日立本社も絡んでプロジェクトが作られました。
1) RFDのソースを解析し、アセンブラのマクロを生成する。
アセンブラ言語にはマクロ機能が有りまして、私もその機能も充分理解済でした。
この部分はHBMの先輩でアセンブラのプロで非常に優秀だった人が担当しました。（中原さんと記憶してます）
2)アセンブラをコンパイルして実行プログラムを生成する。
3)ユーティリティ同様のポジションでホテルフロントシステムを動作させる。
日立のオフコン（オフィスコンピュータ）は、愛知県の有った日立製作所のアサヒ工場で制作されていました。
そこを巻き込んでの想像以上に大規模なプロジェクトになり、その活動は私にとって大変貴重な経験になりました。
私の役割は、実行ステップ数を如何に減らして、必要な機能を実現するか。
ステップが多ければメモリの占有領域が大きくなるからです。
実はこのプロジェクトは確か、新製品の発表が待たれる状況下であり
CPUの高速化と実装メモリの拡大が行われたので、その発表を待つと言う事になり頓挫したと記憶してます。
実際にお客様の現場で、動く陽の目は見なかった幻のプロジェクトでした。
L-320の帳票系はRPG（ReportProgramgenerator）でした。
これはIBMと言う世界的なメーカーが開発した言語です。80文字を一行としてカラム位置を固定化し
確か8文字目にその行の命令語の種類が決められておち、決められたカラムにメモリを操作する命令を書いていきます。
印刷系に向いた言語でした。
のちにUターンしてOECさん（当時：大分電子計算センター）に一時的に雇用して頂いてた頃、I
BMの汎用機でRPGを使う機会があり経験値が大変役にたちました。
長くなりますので、一先ず区切りましょう。
