☆ アカウント(顧客)担当SE
・ 1966年11月より某製造会社様を先輩SEと二人で担当することになった。
・ 1967年1月よりA電算センターとB銀行一人で担当することが加わった。
・ 1967年7月より上記3顧客の担当から外され、Y銀行の担当SEとしてアサインされた。三年先輩のSEと二人であった。この時期から”地銀協同テレ為替システム”構築プロジェクトが始まった。全国の地方銀行をオンラインで結び、為替の決済を行う、当時としては画期的なシステムであった。日本で初めてオンラインシステムなるものが稼働したのは1964年10月の東京オリンピックの時の記録収集システムである。民間の企業では三井銀行(現在の三井住友銀行)の普通預金システムが1965年5月稼働開始が業務処理システムの草分けであり、続いて国鉄(現JR)のみどりの窓口が稼働していたくらいである。
・ 1967年7月から1968年6月のプロジェクト期間であったが、初めの3~4か月間は地銀協の方での要件定義のフェイズで担当する顧客では自行の内部のシステム要件の取りまとめの打ち合わせであった。当時Y銀行では自行の大型店補間ではテレタイプによるメッセージ交換システムが稼働していたが、いったん本店内の事務センターで中継され相手店へ手動で再びテレタイプで送信されていた。これは本支店勘定をセンターで起票するためでもあったと考えられる。センターに於ける手動による操作と本支店勘定の記帳をコンピュータで自動的に行うようにするシステムの開発であった。地銀他行との為替についてはY銀行では地銀協同センターとの間は中継端末を設置する方法を採用した。従来の本支店間の方式とあまり変わらない。センターに設置された自行の端末から出力される紙テープをその中継端末にかけなおして送信する方式であった。当時の端末には記憶装置(メモリー)など持っていない。せいぜいスタックされるのは一文字分癖来のメモリーであった。季節のテレタイプの通信速度は50ボー(50ビット/秒)である。即ち1秒間に7文字(紙テープの当時の主流は7ビットのJISCII)だけである。現今の送信スピードとは隔世の感あり。センターに設置された中継用の端末はそれよりは4倍速い200ボーの送信能力を持つものであった。ただし8ビット/文字のEBCDICコードが採用されており、実質的には25文字/秒の送受信能力の機械であった。現在のネット通信に使われている200MBの送信能力は、理論的には10万倍の送受信が可能であることになる。
・ このプロジェクトにおいてmoriが任されたのは、ファイル・コントロール・プログラム(FCP:File Control Program)とセンターの自行端末の入出力を制御するライン・コントロール・プログラム(LCP:Line Control Program)であった。
・ FCPで取り扱うファイルは、メッセージ・データのロギング・ファイルおよび入出力を一時的にスタックするファイル(Input Queue,Output Queue:それぞれINQ、OUTQと呼んだ)であった。当時のSEはお客様と一緒に、設計からプログラム開発、統合テスト、システムテストをやっていた。moriも設計をし、プログラムを書いた。先輩SEが本支店間のテレタイプの入出力を管理するプログラムを担当した。お客様が適用業務(アプリケーション)を担当した。お客様要員4名と我々SEが2名、計6名での開発プロジェクトであった。
・ 当時のコンピュータの主記憶装置のメモリー・サイズは128Kバイト(文字にして約12万８千語を記憶できる)であった。これに当時のオペレーティング・システム(OS)も乗っかる。当時のOSのサイズが約64Kバイト。つまりユーザーが使える領域は残りの６４Kバイトだけ。当時扱っていたデータは文字と数字だけであり、現今のような音声や画像イメージは取り扱えなかった。何せ当時のメモリー(ｺｱ･ﾒﾓﾘｰ)は高価であった。64Kバイトの月々の使用料(レンタル料)が約６４万円。買取価格にするとその50倍の3,200万円。設計者はいかにこの少量のメモリーを有効活用するかが腕の見せ所であった。直接アクセスできる外部記憶装置も当時から使い始められていたが、こちらディスクはコア・メモリーに比べるとはるかに安価であった。当時のディスク一台当たりの記憶容量はせいぜい768Kバイト程度だった。平均アクセスタイムは２５~３０ミリセカンドかかった。それよりも高速アクセスができるドラムというDASD(Direct Access Storage Device)があったがとても高価なものであった。Y銀行では４台のDISCが設置されていた。１台がOSのため占有使用、１台がデータ・ソートなどンために使われるWORK ディスク、残りの２台が今回の為替システムで使用することができた。1台をLoging DATA用に、もう１台を入出力キュー(INQ,OUTQ)に半分ずつ使用することにした。為替の一電文の平均長は200文字程度であった。そこでレコード長を２５６バイトとする１ブロック、１レコードのログ夕のファイルを定義した。約３，０００レコード収納が可能だった。その当時の一日当たりの取引件数は多くても2,500件ていどであったから充分であったが、予備用としてQueue ファイル用のディスクの半分を充当することにした。再送要求にも応えられるように、(店番+出力通番)をキーに持つレコード形式にした。LOG,Queueファイルすべて当時のBDAM(Basic Direct Access Method)を使って工夫しながらmori一人で構築した。
・ 当時のコンピュータの演算命令の平均長は4バイトである。２５６ステップで１Kバイト必要となる。命令だけだとその６４倍のプログラムがかけるわけである。つまり16,000ステップの命令がかける。といっても、OSが事前に用意してある入出力用のプログラムを合わせてである。ユーザーが使えるものはさらに狭まる。プログラムは命令だけの集合ではない。いろいろな制御のためのテーブル、入出力用のデータエリアなども必要である。お互いが節約しながらのプログラム開発であった。
・ moriが担当したもう一つのプログラムは地銀協為替センターとの中継紙テープの入出力端末の制御をおこなうもので、これにはOSが用意しているBTAM(Basic Telecomunication Access Method)を使った。moriはその時までBTAMの研修は受けておらず、マニュアルを片手に必死の勉強でやっとのこと紙テープの読み込み、書き出しが出来たとき、本当に感激した。
・ 10カ月足らずのプロジェクトであったが、当時Y銀行にはコンピュータは一台しかなく昼間は本番業務に使われており、開発チームが機械を使用できるのは午後１０時過ぎから朝の８時前までの間だけであった。機会を使い始めてからの半年間は夜の出勤、朝帰りの毎日である。独身だったmoriは夕方６時ごろ家を出て、電Y銀行まで行き近くの食堂で夕食を取り、朝食は銀行の食堂で食べて帰り、家に着くとバタンキュー。この間ほとんど陽の目を拝めずの生活。日曜日は本番業務が稼働しないので昼頃に出勤月曜日の朝までテスト。人間太陽に当たらない生活を続けると、しまいには膝がガクガクして階段の上り下りが危なくなることを知った。
・ 1968年６月１７日Y銀行の為替オンラインシステムのカット・オーバーを迎えた。前日の日曜日すべての用意をして夜の１０時ごろ帰宅、翌日早朝から出勤、スタンバイ。「当行のオンラインシステムを開始する。」頭取の宣言と同時にスタート・ボタンが押された。セレモニーに出席した一同がかたずをのんで見守った。だがシステムはうんともすんとも動かない。前日、いや当日の早朝まで入念に準備していたのに。頭取のスタートボタンが押されると中継端末のプリンターに”トウコウノ オンライン・システムノ カドウ オ シユクス”の文字が打ち出される予定であった。だが出ない。とっさに銀行の開発要員の方が、頭取にもう一度スタート・ボタンを押していただいた。やっとくだんの文字が印刷されて、セレモニーが無事終了した。この印刷の端末制御を担当したmoriはなぜかその場で何が原因か閃いた。”そうか、ECBのクリアーのタイミングがおそすぎた!” 。正解は端末へのREAD命令を出す前にクリアーしておかなければならなかったのにREADの後でクリアーしていたのだ。つまり一回目のスタートボタンがすでに読み込まれた後その完了を知らせるシグナルを消してしまい。その後に完了の知らせを待つていたのだ。待てど暮らせど反応しないわけである。ならばなぜ、事前テストではうまくいったのか。システム全体では多くの回線からの完了通知を知らせるECB(Event Control Block)をリストの形で取りまとめて一か所で管理しておりそれぞれの完了通知に従って行う処理プログラムが呼び出される仕組みであった。テスト時は多くのイベントが発生しており当時の性能程度のコンピュータでは手が回らず、クリアーのタイミングが少々遅れても間に合っていたのが、この朝のスタートボタンが押されるまでは他のイベントは何も発生していない。つまりシステムにとって最初のイベントであり、イベントの完了をスキャンするだけの仕事をしていた状態だから、READでイベントが完了した後にクリアーしてしまったので無反応になった。したがって二回目のイベント完了に反応した。つまり１サイクル・ディレイが発生したのだった。その日は何とかシステムは終了までダウンせずに稼働してくれた。