今までずっと封印してきた私がリードしてきた大型プロジェクトの一つの話を終活としてするべき時が熟したと思う。このプロジェクトは、時代の変化の中で、バッチ型処理の全盛期の終期に行ったもので高コストの大型計算機の使用効率を上げ、多数のユーザへのサービスを安定的に供給する目的で行われた。話の本筋の上にかぶされた姿、それぞれ大きな意味はあるが、をひとつづつ取り払っていくことからはじめたい。それにはまず６０年代あるいは７０年代前半に時を戻そう。そして大型情報処理体系の場をイメージしてほしい。
まず、IBM/360誕生前の事で、36bitワードマシン全盛だった。整数型変数というのは、ワードをそのまま扱うということを意味していた。高級言語としては、FortranとCOBOL全盛で、むしろFortranは、「高級アセンブリ言語」として機械語命令までの写像がとても見やすく、各社とも最適化機能に注力していた。たとえば、 I =I*4 と書かれていたら、2ビット左シフト命令を生成する。といった、個別の最適化にはじまりさまざまなことが供えられ始めていた。そのうち、日本の国家予算規模の金額が36bitではたりなくなるのが見えてきて、72ビット倍長演算が割り込むようになってきた。そして、多くの場合には32bitですみ、そして長くても64bit演算で対応できる、そして何よりも、6bitBCD文字を６字詰める文字処理では破滅が見えた応用が見えたテキスト処理応用の爆発的な増加があった。
次に、タイムシェアリングあるいは、端末からの対話的利用はハードおよびソフトともに時期尚早で、バッチ処理がほとんど唯一の処理方法だった。ともあれ、その頃はメインフレームといえばバッチ処理を指していた。部門ごとにマシンタイムを予約し、「２４時間！」隙間なくマシンをまわすようにしていた。これに、リアルタイムシステムでのトランザクションモニタ、たとえばオンラインシステム、がそろそろ広がる頃の話。だから、磁気テープベースで、ディスクもない時代に、多人数のプログラミング教育を行うには、連続的に学生が作ったプログラムとそれに与えるデータをパンチカード等の形で一度に100人分とかをまとめて、一日数回流して結果を学生に返す、という使用形態が中心だった。その頃、IBMには、ウォータールー大学で開発されたWatforという常駐型Fortranがあり、多数回のCompile & Goをきわめて高速に繰り返すシステムがIBM7040上で動作していた。また、Pascal, C,その他の言語はまだ登場していなかった。Lispは動き始めていた。
この時代の大学等教育機関での各社の受注合戦の焦点はIBMがWatforの次のWatfiv をIBM/360上で配布仲介をすることが明らかになっていたので、この対応機能をどうするかが焦眉の急だった。実はFortanベースの教育は、８０年代に入り、急速に、その価値を下げていった。しかし、メインフレームの新規契約のサイクルは速くても５年とかであり、おおむね１０年サイクルとも言えた。もちろん、各社の首脳部には、この変化をウォッチしかつそれに対応しようとする部署があった。そこで７０年代中期の受注では、コストを下げて、常駐型機能を供給し、時代の変化に対応しようとする考え方がでてくる。
１９７８年、今年2026年からちょうど48年前、ACOS6用の常駐型Fortanを作ってくれないか、という話があった。おもしろそうなので、やってみようかと下調べを始めた。1979年、４人ほどの学生チームを編成して、初版を作成した、1980年に、更新していき、先方に渡した。
マシンエラーになりそうなコードがあっても絶対に落とさないで次の処理へ向かうexception handling、今入ってきたプログラムコードを入る先からプログラム構造に応じた形式に変換しながら、文法チェックをしていく、ＯＫであれば、実行フェイズにそれを渡す、変数名、プログラムコードの行番号などソース情報は確実に覚えていて、それを使ってデバッグ情報を学生に返し修行しなおしせよ、とする。かなりのプログラムは実行までいかず打ち切りになるが、丁寧な教育的メッセージでどこがわるいは指摘をつける。実行まで行ったとき、およその記憶で一番多いのは、undefined variable、変数の値をセットしていないのに、それを参照した。配列の添え字が範囲外を指した。…絶対的に自分を落とさないためにソフトウェア構成法には大きな工夫が必要だった。そして、コンパイル時と実行時のありとあらゆるエラーに対応し、できるだけそのエラーの根源を見つけられるメッセージを出すことがソフトウェア品質評価につながった。このタイプの処理なら、self-reflectionを機能させることも、今だったら考えられよう。そうするとAgentic AIのほんの入り口に立てることになろう。
Quick Translation: Memories of Developing a Resident Fortan Batch System (1)
I believe the time is ripe for me to finally share a story about one of the large-scale projects I led. A story I’ve kept under wraps until now. This project was undertaken during the end of the heyday of batch processing, amidst changing times, with the aim of improving the efficiency of high-cost mainframe computers and providing stable service to a large number of users. I want to begin by stripping away the layers that superimposed the main story, each of which has significant meaning. To do this, let’s first go back in time to the 1960s or early 1970s. And I want you to imagine the world of large-scale information processing systems.
First, before the birth of the IBM/360, 36-bit word machines were in their heyday. Integer variables meant handling words directly. As for high-level languages, Fortran and COBOL were dominant. In fact, Fortran, as a “high-level assembly language,” had a very clear mapping to machine code instructions, and supplying companies were focusing on optimization features. For example, if it was written as I = I*4, it would generate a 2-bit left shift instruction. Various features were beginning to be implemented, starting with individual optimizations. Eventually, it became clear that 36 bits were insufficient for amounts the size of Japan’s national budget, and 72-bit double-length arithmetic began to emerge. Furthermore, there was an explosive increase in text processing applications, where 32 bits sufficed in most cases, and 64 bits at most could handle longer operations, and, most importantly, where character processing using 6-bit BCD characters per character proved disastrous.
Next, time-sharing or interactive use from terminals was premature in both hardware and software, and batch processing was almost the only processing method. In any case, at that time, “mainframe” referred to batch processing. Machine time was reserved for each department, and machines were run “24 hours a day!” without any gaps. This was around the time when real-time transaction monitoring, such as online systems, was beginning to spread. Therefore, in the era of magnetic tape and no disks, the primary method of teaching programming to large groups of students involved continuously processing programs created by students and the data to be assigned to them, using punch cards or similar methods to collect the programs for 100 students at a time, and then sending the results back to the students several times a day. Around that time, IBM had a resident Fortran system called Watfor, developed at the University of Waterloo, which ran on the IBM 7040 and performed numerous Compile & Go cycles at extremely high speed. Pascal, C, and other languages had not yet emerged. Lisp was just beginning to take shape.
The focus of the bidding war among companies for universities and other educational institutions during this period was on how to handle the distribution of functions like Watfiv, the successor to Watfor, on the IBM/360, as it had become clear that IBM would be the distributor. In fact, Fortran-based education rapidly lost value in the 1980s. However, the cycle for new mainframe contracts was at most five years, and generally a ten-year cycle. Of course, each company’s leadership had a department to monitor and respond to these technological advancements. Therefore, in orders received in the mid-1970s, the idea emerged to reduce costs, supply resident functionality, and adapt to the changing times.
In 1978, exactly 48 years ago from 2026, there was a request to create a resident Fortan for ACOS6. It sounded interesting, so I started researching it. In 1979, I formed a team of about four students and created the first version. In 1980, I updated it and delivered it to the client, a mainframe manufacturer.
It included exception handling to ensure that even if there was code that might cause a machine error, it would never be dropped and would proceed to the next process; it would convert incoming program code into a format appropriate to the program structure from the source, perform syntax checks, and if OK, pass it to the execution phase; it was required to remember source information such as variable names and program code line numbers, and use that information to return debugging information to the students for further practice. Processing of many programs terminated before execution due to compilation errors, but they need to be given clear, educational messages pointing out what went wrong. When execution does occur, the most common errors, in my memory, are undefined variables (referencing a variable whose value hasn’t been set) and array indices pointing out of range. …To absolutely avoid failure of continuous processing, significant ingenuity was required in the software’s structure. And responding to every possible error at both compile and go phases, and providing messages that help identify the root cause of those errors, was crucial for software quality evaluation. With this type of processing, it might even be conceivable to implement self-reflection now. Doing so would bring us just a glimpse into the world of Agentic AI.