初めてのコンピュータはバッチ処理

1974年、京都産業大学に入学した当時のコンピュータは、東芝の電子計算機 TOSBAC-3400 Model-41という大型コンピュータでした。計算機センターの１階中央に２階まで吹き抜けの大きな空調制御されたコンピュータ室がありコンピュータが設置されています。２階の見学コースからコンピュータ室内を見ることができます。磁気テープ装置がずらりと並び、磁気ディスク装置、コンソールパネルなどが見えます。

１回生のときに、FORTRANで初めてプログラミング言語を勉強し、２回生のときにCOBOLを勉強しました。

この時代のコンピュータはバッチ処理方式でした。利用者は、プログラムを打ち込んだパンチカードをコンピュータセンターの窓口に提出してコンピュータ処理を依頼しました。翌日に処理結果のラインプリンター用紙を受け取り、内容を吟味してプログラムが正しく動作しているか判断します。普通は１回で完了することはなく、最初はコンパイルエラーが発生して数回実行するうちに実行結果が出力されるようになります。しかし、バグがあるために正しい結果が得られず、修正して再度依頼することを繰り返します。

今の時代から考えると利用者にとってはとても効率の悪い方式です。しかし、高価なコンピュータを効率的に利用するためにバッチ処理は最適だったのかもしれません。

プログラムの作成手順

•  プログラム設計

フローチャートという流れ図を書いて処理手順を明確にします。きれいに記述するためにテンプレート定規を使用していました。また、誤ったところのみを消しゴムで消すために字消し板を使いました。

その当時は、オブジェクト指向や構造化設計など知らなかったので、流れ図でプログラム構造を設計していました。

下記は、私が長年使用していたテンプレート定規です。もう割れて使えなくなってしまいました。字消し板はアルミ製なのでまだ使えますが、いま時は使用する機会がありません。

 

•  コーディング

罫線の入った80桁欄の原稿用紙のようなコーディングシートにプログラムソースコードを記述します。FORTRAN用、COBOL用、DATA用など使用目的により罫線の引き方が異なりました。
例えば、FORTRAN言語なら、１桁目から５桁目が文番号、６桁目が継続行、７桁目から７２桁目が本文でしたので、その境界は太い罫線が引かれてコーディングしやすくなっていました。

 

•  プログラム・パンチ

プログラムをコンピュータに入力するために、パンチ室でコーディングシートを見ながらカードパンチ機でタイプしてカードに穴を開けてパンチカードを作成します。プログラム１行ごとに１枚のカードを使用します。パンチカードの上部にはパンチした文字が印刷されていますので、ここを読んでパンチミスがないか確認します。
パンチミスがあれば、ミスした部分のカードを再度パンチしてカードを差し替えます。

このパンチカードを持って計算機センターの窓口に提出するわけです。COBOL言語などは、500ステップから1000ステップ規模になりますので、パンチカードを段ボールなどの箱に入れて肩の上に担いで運びました。パンチカードを落としてバラバラになって途方に暮れた先輩がおられたことを聞いたことがあります。大きめのプログラムの場合は、パンチカードの上部に太いペンで斜めの線を入れるようにしていました。もし、落としてバラバラになった場合は、この斜めの線を手がかりに正しい順番に並べるわけです。

•  コンピュータでの実行

パンチカードをコンピュータセンターの窓口に提出しコンピュータ処理を依頼します。翌日に、実行結果のラインプリンター用紙とパンチカードを受け取り、結果を確認します。
プログラムが完成するまで、毎日パンチ室とコンピュータセンターへ通いました。

コンピュータの操作

最初はコンピュータ室などに入室できませんでしたが、「計算機科学会」というサークルに加入して、ある時間帯にコンピュータを借りる機会がありました。

当然、コンピュータの操作は自分たちで行います。先輩に教えていただいて初めてコンピュータを操作しました。今から40年以上も前のことなので、 あやふやな記憶ですがこんな手順だったと思います。
まず、磁気テープを磁気テープ装置に装着して磁気テープの先を受け側のリールに巻き込み、左右のリールを右側は右回転、左側は左回転で一気に手で回転するとバキュームに吸い込まれて装着が完了します。
次に、ディスクパックをパック型磁気ディスク装置に装着します。
最後にコンソールパネルで、パネルに並んだトグルスイッチをON/OFFして指定されたアドレスを設定して、アドレス設定ボタンを押した後に、RUN/STOPスイッチをRUNに入れます。
そうすると、IPL(Initial Program Loader)が磁気ディスパックからプログラムをロードしてコンピュータが動き出します。コンソールパネルのアドレスランプは点滅を開始して、プログラムが実行されていることがわかります。

自分のパンチカードをカードリーダーに入れると、「バァバァバァ･･･」というような音を立ててコンピュータに読み込まれます。
いくつもの磁気テープが回転し、そのうちにラインプリンターが「ダァダァダァ･･･」と音を立てて実行結果がプリントアウトされました。

ラインプリンタ用紙を持って、コンピュータ室の外へ出て、結果をみるとコンパイルエラーが数個印刷されてます。エラーメッセージを見ながら、ソースコードの文法誤りを探し、正しい文法にするためのソースコードをノートに書き込みます。パンチ室で修正する行のカードをパンチをしてカードを差し替えます。そして再び、コンピュータ室に入り、順番を待ってカードリーダーに自分のパンチカードを入れて再度実行です。

バッチ処理でも、コンピュータを自由に使用できる環境であれば、ターンアラウンド時間は短くなり、プログラムの開発効率が上がることを実体験しました。

オペレーティングシステムが新しくなった

ある日、オペレーティングシステムが新しくなったと先輩から聞きました。これまでは、バッチ処理でジョブ単位でカード入力、コンピュータ実行、ラインプリンター出力が順次処理されてました。カード入力やラインプリンター出力などの入出力装置は、コンピュータ内部処理に比べて遅いのでコンピュータ内で待ち時間が発生してしまいます。
新しいオペレーティングシステムでは、スプールを導入して複数ジョブのカード入力を行い、入力・処理・出力を見かけ上同時に動作できるようになっていました。カード入力は、途中で止まりながら読み込まれます。入力が止まっている間は別のジョブが走っていることになります。

オペレーティングシステムが新しくなったで、以前よりターンアラウンド時間が短くなったような気がします。

パソコン時代の今思うこと

この時代のパンチカードによるプログラム作成は、ターンアラウンドタイムがとても長いわけです。少しでもコンピュータセンターへの依頼回数を減らしたいので、最初のフローチャートもじっくり考えて論理ミスが少なくなるよう努力します。また、バグ発生時は何が原因なのか論理的な説明がつくまで考えます。それから、ソースコードの修正をします。

この時代に比べてパソコン時代の今は、ソースコードはスクリーンエディターでタイプして、即コンパイル・実行ができるわけです。ターンアラウンドタイムは、とても短くなりました。スケルトンを先に作成して動作確認してから、詳細な部分を作成する手法も可能となりました。

最近のソフトウェア技術者をみて気になることは、バグ発生時にしっかり原因を突き止めず怪しそうなところを修正してすぐ実行し、試行錯誤でバグを修正する技術者が見受けられることです。
修正した内容で説明がつかないけれどバグが発生しなくなったから良しとする人や、プログラムを数日間寝かせたら熟成してバグが発生しなくなったと、とぼけたことを言う技術者がいたことにはビックリしました。

論理的にバグの原因を考え、既存部分への影響も含めて修正方法を検討する力をつけることが、ソフトウェア技術者の育成には大事なことだと考えます。