会員の皆様へ(2006年4月のご挨拶)

コンピュータ事始め(NEC PC9801)

目次

 困難を分割せよ
 複数個のプログラムに分割
 構造化プログラミング
 パソピアから9801へ
 OA-BASICとN88-BASICとの相違に悩む
 OA-BASICのREAD命令相当のサブルーチンをN88-BASICで作る
 論理レコード番号と物理レコード番号との関係など
 OA-BASICのWRITE命令に相当するサブルーチンをN88-BASICで作る
 パソコン間の異機種間通信を行う
 N88-BAISCからBASIC98へ
 ハードディスクの導入
 BASICシステムの問題点
 メニュープログラムとログ機能
 終わりにあたって

困難を分割せよ

フランスの数学者・哲学者であるデカルトは、「困難を分割せよ。しかる後に総合せよ」と語ったと伝えられています。
 「座標」は、まさに「点」というとらえどころのなかったものを空間であれば、3つの、平面であれば、2つの座標値という数値の組としてとらえることを教えてくれました。
 彼の創始した「座標幾何学」は、ギリシャ以来の幾何学に新しい生命を与えたのでした。
 座標を使えば、ややもすると直感に頼るところの多い「補助線」を使わずに、機械的な計算だけで幾何学上の定理を証明することが可能でした。
 もちろん、座標の利点は、定理の証明だけではなく、今日では、物理学や工学など、座標を使わないですますことが考えられないほど便利で当たり前のものとなっています。
 座標は、まさに「点」の「困難」を分割したのです。
目次に戻る

複数個のプログラムに分割

システムを設計、製作することは、まさに「困難」なことです。
 その困難さを分割することは、まず、プログラムを複数個に分割することにより「統治」され得ます。
たとえば、「データの入力」と「印刷」は、別のプログラムにより行うことにより、困難さが軽減されることは、容易に想像できます。
 プログラムの困難さは、ロジックの複雑さにも当然、依存しますが、単純に割り切れば、プログラムの長さ(ステップ)で換算・評価されると考えてよいでしょう。
 複数個のプログラムに分割することにより1個のプログラムの長さは、短くなり、作成は、容易になり、デバッグも簡単になります。
 短いプログラムを複数個、使用してシステムを形成することは、ディスク上に保存される「ファイル」という概念があって初めて実用になります。
 メモリー上のデータだけでは、複数のプログラムを連携してシステムを作ることは、難しいです。

 私が前回の「コンピュータ事始め(東芝パソピア)」で記載したように形式管理システムを複数個のプログラムに分割することをどうやって会得したのか、ということですが、おそらくは、前職の不動産会社の電算室時代に経理などのシステムが複数個のCOBOL語のプログラムによって作られ、それらが作業ファイルを介して連携していたのを見聞きしていたことがその原因でしょう。
 その前の時代の測量会社のシステムでは、JCL(ジョブ制御言語)で順次、プログラムを呼び出していたように覚えていますが、それらは、プログラムの数も少なく単純なものでした。
 今、あらためて考えてみると、形式管理システムでのプログラム分割の参考となったのは、やはり不動産会社時代の経験でした。
 当時、公私ともにお世話になった(そして、多大なご迷惑もおかけした)「Iさん」には、感謝しています。
目次に戻る

構造化プログラミング

1個のプログラム自体も、やはり、困難の固まりです。
 この困難さは、「構造化」という手法で解決する、というのが「構造化プログラミング」の考え方です。
 この概念を正確に知ったのは、1981/9に「ストラクチャード・プログラミング入門」(國友義久 著:オーム社:1981/5 初版)
を読んでのことでした。



 ただ、測量会社時代のプログラムでもCOBOL語のPERFORM命令(サブルーチン呼び出し)を使っていたのである程度の知識は、あったものと思われます。
 構造化プログラミングは、近年の「オブジェクト指向」などの登場により、やや古びてしまいましたが、その意図するところは、同じだと思います。
 構造化の御利益は、2つ挙げられます。

 まずは、「難しい個所は、分割(階層化)し、より容易にプログラムを作成できる」ことが挙げられるでしょう。
 これは、会社などの組織と同様です。小さな会社であれば、社長一人でもできるでしょうが、大きな会社であれば、部所を分けて仕事を整理・分担します。
 そして、一つの部署内も分割して部長→課長→係長→主任→担当というように一人の担当者ができる分量と困難さに調整(=分割)することにより、個々の仕事が実施でき、その成果が逆順に戻っていくことにより全社の業務が遂行(=総合)されるわけです。
 オブジェクト指向風に言えば、難しい個所を上の階層から「隠蔽」してもいるのです。
 大きな会社の社長さんが個別の担当者の仕事内容をすべて把握することは不可能ですし、無駄でもあります。
 まあ、厳密に言えば、「分割」と「隠蔽」は、異なった考え方ではあるでしょうが・・
 ただ、分割しないと「隠蔽」はできないですから、「分割」の方が大切な考え方と言えると思います。

 2つめの御利益は、「1つのサブルーチンを同じプログラム内や別のプログラム内で共用できる」ということでしょう。
 この2つめの御利益は、1つめほど簡単ではありません。すべてのサブルーチンが共用できるわけでもありません。
 ただ、当初の構造化手法は、どちらかというとこちらのプログラムの部品化という点に焦点があったかと思われます。
こちらは、サブルーチンを製品を組み立てる部品のようにとらえているわけです。
工場の製品であれば、複数の製品間で特定の部品を共用できないかと、考えるでしょう。それと同じです。
目次に戻る

パソピアから9801へ

昭和58年(1983年)になり、職場でもパソコンを購入していただけることになりました。
 そのとき、検討の対象となったものは、東芝パソピアの16ビット版である「パソピア16」とNECの「PC9801」でした。
パソピア16は、パソピアのプログラムとデータを比較的、スムーズに移行できると期待できましたが、パソピア発売当時と異なり、パソコン界でのNECの優位性が徐々に浸透してきた時代でしたので、結局、職場では、PC9801を購入することになりました。

 初代のPC9801は、それまでのPC8001やPC8801の後継機種であり、初めての16ビットパソコンとして、1982年に発売されました。
 購入した機種には、8インチFD装置(2ドライブ)が外付けドライブとして接続できました。
 8インチFDは、1枚で1MBの容量があり、パソピアの5.25インチ(2D)ドライブと比較して、4倍の記録容量がありました。
 ただし、価格も本体、カラーディスプレイ、FD装置、プリンタで約100万円程度となりました。
 私個人としては、なお、しばらくの間、パソピアを利用していました。
 OSとしてCP/Mを導入してみたり、CP/M上で動作するソフトとしてTurbo Pascal言語を利用したりしていました。

※共立出版の「Pascalプログラミング講義」(1985/8/10購入)

 しかし、職場での個人パソコンの利用という変則的な状態は、解消されることになり、そのためにパソピアからPC9801へのデータ及びプログラムの移行作業を行うことになったのです。
目次に戻る

OA-BASICとN88-BASICとの相違に悩む

まずは、プログラムを書き換える必要があります。
 PC9801で使用されていたのは、N88-BASIC(正確にはN88 DISK-BASIC)という、マイクロソフトのBASICをNECが日本語化したもので、基本的には、マイクロソフトのBASICとほぼ同様でした。
 ところが、私がパソピアで使用しているOA-BASICは、東芝が独自に開発したもので、COBOLの考え方も取り込んでいて事務用には、最適のものとなっていましたがマイクロソフトBASICとの互換性はありません。
 たとえば、ファイル編成も直接編成ファイルと索引順編成ファイルに対応していたり、計算も十進計算でしたので、小数点の入った数字を含んだ計算でも桁落ちなどの誤差が出なかったのでした。

 しかし、N88-BASICの方は、索引順編成ファイルのサポートもなく、また、2進計算でしたので小数点の入った数字の計算には注意が必要でした。
 中でも一番、困った点は、直接編成ファイルの利用法でした。N88-BASICでもランダム呼び出しが可能でしたが、それは、物理レコード単位なのです。1つの物理レコードは、256バイトの固定長であり、GET文、PUT文でそれぞれ呼び出しと書き込みができるという単純なものでした。
 一方、OA-BASICでは、論理レコード単位でREAD、WRITEができ、物理レコードを意識せずに、また、1物理レコードを複数の論理レコードの集まりとして、いわゆるブロック化して使用することができました。
 形式管理システムでは、この論理レコードを対象として処理を書いていたのです。
目次に戻る

OA-BASICのREAD命令相当のサブルーチンをN88-BASICで作る

次のように各マスターファイル専用のREAD文に相当するサブルーチンをN88-BASICで作成しました。
 マスターファイルを利用するプログラムの冒頭で次のように物理レコードを読み書きするバッファを定義します。
 たとえば、コードテーブルのフィールド文では、
' COFILD : TA : 89,1 : CODTBL.CD FILD
' MAIN BF04$(16)
FIELD# 1,8 AS BF04$(1),24 AS BF04$(9),8 AS BF04$(2),24 AS BF04$(10),8 AS BF04$(3),24 AS BF04$(11),8 AS BF04$(4),24 AS BF04$(12),8 AS BF04$(5),24 AS BF04$(13),8 AS BF04$(6),24 AS BF04$(14),8 AS BF04$(7),24 AS BF04$(15),8 AS BF04$(8),24 AS BF04$(16)
 と書きました。(実際は、行頭に行番号が記載されています)
 ここで、FIELD#1というのは、ファイル番号です。また、BF04$(n)というのは、論理レコードの各項目の集まりを入れる場所です。
 コードテーブルでは、1論理レコードは、次のような構造を持っています。
 8バイト=2バイトの整数項目×4個: K04(1)~K04(4)
 24バイト=24バイトの文字項目×1個: C04$
 計 32バイト
 これを1物理レコード内に8つ、すなわち、ブロッキング係数=8として格納しています。
プログラム内では、論理レコード内の変数(K04(1)~K04(4)とC04$)を使用しますが、OA-BASICのREADを使用している場所では、次のようなサブルーチンを呼び出します。

(下記は、後述のBASIC98で書かれたものですが、基本的にはN88のものと同様です)
5000 ' COMOLD : TA : 89,1 : CODTBL.LD キソ゛ンレコート゛ ケンサク
5010 * COMOLD
5020 ' KB04,KY04,KY041 ハ MAIN PROGRAM
5030 ' COERR%=0,1,3 ハ ミツカル ,ミツカラナイ,ソノタ
5040 IF (I11%<1) OR (I11%>10) THEN COERR%=3:GOTO 5250
5050 IF I12%>999 THEN COERR%=3:GOTO 5250
5060 IF I13%>999 THEN COERR%=3:GOTO 5250
5070 COERR%=0:W10#=I11%*100+I12%*10+I13%
5080 NL04=(W10#-INT(W10#/KY04)*KY04)*KY041+1
5090 NP04=INT(NL04/KB04)+1:NB04=NL04-(NP04-1)*KB04
5100 IF NB04=0 THEN NP04=NP04-1:NB04=KB04
5110 I14%=0
5120 GET#1,NP04
5130 FOR I15%=NB04 TO KB04
5140 I14%=I14%+1:IF I14%>KY041 THEN COERR%=1:GOTO 5250
5150 IF CVI(MID$(BF04$(I15%),1,2))<>I11% THEN 5190
5160 IF CVI(MID$(BF04$(I15%),3,2))<>I12% THEN 5190
5170 IF CVI(MID$(BF04$(I15%),5,2))<>I13% THEN 5190
5180 GOTO 5210
5190 NEXT I15%
5200 NB04=1:NP04=NP04+1:GOTO 5120
5210 NB04=I15%
5220 FOR I15%=1 TO 4:K04(I15%)=CVI(MID$(BF04$(NB04),(2*I15%-1),2))
5230 NEXT I15%
5240 C04$=BF04$(NB04+8)
5250 RETURN
 ここで、NP04というのは、物理レコード番号で、NL04というのは、論理レコード番号となります。
 W10#=I11%*100+I12%*10+I13% は、キーとなるI11%とI12%、I13%という値(これは、K04()からサブルーチンを呼び出す際に与えています。)から論理レコード番号を計算するための基になる数字を計算しています。
 NL04=(W10#-INT(W10#/KY04)*KY04)*KY041+1
 上記で、KY04とKY041は、このマスターファイルに固有の数値で、W10#からホームレコード番号を計算します。
基本的にこのホームレコード番号は、ファイル内である程度、ランダムな値(ハッシュ値)になるように考慮しています。
サブルーチンが複雑になっている理由は、すでにNL04に別のレコードがある場合に一つずつ次のレコードを検索しているからです。
 また、KB04というのは、ここでは、8というブロッキング係数を表しています。
 これらのKY04、KY041、KB04は、メインプログラムでセットしています。

 なお、当時は、いわゆるグローバル変数だけで書く方法が普通でした。
 というか、N88-BASICでは、ローカル変数が使用できなかったと思います。
 そのためサブルーチン内の変数は、特別な命名規則に従ってメインルーチン内の変数と重ならないようにと考えていました。
 5120行目のGET文で呼び出された物理レコード内のデータは、FOR~NEXT文でブロッキング係数分(ここでは8回)、ループ状に項目の値が呼び出したいレコードかどうかをチェックしています。
 そして、一致した場合は、そのレコードのNP04(物理レコード番号)とNB04(その物理レコード内の何番目の論理レコードかという値=1~8)がセットされ、K04(1)~K04(4)とC04$にも各項目の値がセットされます。
 このようにこのサブルーチンでREAD文の代用ができることになりました。
 なお、見つからなかった場合などは、COERR%にエラーコードをセットしました。
 この値がゼロの場合のみ、見つかったことになります。
 これらのサブルーチンは、数十本のプログラム内にコピーされて、再利用できました。
 ただ、残念だった点は、個々のプログラム内にコピーしなければならず、1個所のサブルーチンを共用する(実行時にIncludeするような)ことができなかったことです。
 このため、サブルーチンは、入念にテストしてエラーがなくなってから、メインのプログラム内にコピーされました。
 ただ、サブルーチンの書き方を標準化していたおかげでマスターテーブルが異なっても、いくつかの変数名以外は、まったく、同一でよかったことでした。
目次に戻る

論理レコード番号と物理レコード番号との関係など

論理レコード番号NL04と物理レコード番号NP04とは、
 NL04=NB04+(NP04-1)*KB04、ここで、NB04=1~KB04。
 ランダムな(大きな)数値W10#と論理レコート番号NL04とは、下記で結びついています。
 NL04=(W10#-INT(W10#/KY04)*KY04)*KY041+1
 コードテーブルでは、KY04=13、KY041=32。KY04*KY041=416件は、ファイルの最大論理レコード
件数であり、416/8=52件は、物理レコードの最大件数です。
 実際のファイル領域確保では、52+1=53件の物理レコードを確保しました。
目次に戻る

OA-BASICのWRITE命令に相当するサブルーチンをN88-BASICで作る

OA-BASICのWRITE文に対応するN88-BASICでのサブルーチンも同様の方法で作成しました。
 WRITE命令に相当するサブルーチンについては、新規レコードなのか、書き換え(更新)なのかにより2つのサブルーチンを作成しましたが、ここでは、それらの詳細は、省略しましょう。
 書き込む場合は、物理レコードをPUT文により書き込むことになります。
 この際、バッファにデータを書き込んでおく必要があるのですが、下記は、メインプログラム内でそのために呼び出すサブルーチンです。
5000 ' COBUFR : TA : 89,1 : COレコート゛ ==> ハ゛ッファ
5010 * COBUFR
5020 ' NB04 MAIN PROGRAM
5030 B20$="":B21$=""
5040 FOR I20%=1 TO 4
5050 B20$=B20$+MKI$(K04(I20%))
5060 NEXT I20%
5070 RSET BF04$(NB04)=B20$
5080 LSET BF04$(NB04+8)=C04$
5090 RETURN
 逆にバッファから変数にセットするサブルーチンも作成しました。
5000 ' BUFRCO : TA : 89,1 : ハ゛ッファ ==> COレコート゛
5010 * BUFRCO
5020 ' NB04 MAIN PROGRAM
5030 FOR I20%=1 TO 4
5040 K04(I20%)=CVI(MID$(BF04$(NB04),(I20%*2-1),2))
5050 NEXT I20%
5060 C04$=BF04$(NB04+8)
5070 RETURN
 なお、書き込む位置は、計算した論理レコード番号の場所になりますが、すでにその場所にデータがある場合は、一つずつ数を増やして空いている位置を探して、空いている位置があれば、そこに書き込むことになります。
 その位置が最終的な論理レコード番号となります。

 万一、空いている場所がなければ、書き込む場所がない(オーバーフロー)エラーとなります。
 そのような場合は、前述の場合は、COERR%にエラーコードが戻りますので、メインプログラム側でメッセージを表示するなどの措置をとります。
 ただし、オーバーフローとなる場合は、ファイルの容量を大きくするような手段がいずれにしても必要となります。
※上述のようにレコードの位置を探したりする方法でのランダム呼び出しを行うファイルを(ハッシュを使う)直接編成ファイルと呼んでいます。
 私は、測量会社の時代にNECのACOS(オフコン)の講習会に参加した際のテキストを参考にこのようなサブルーチンを作りました。
目次に戻る

パソコン間の異機種間通信を行う

さて、このようにOA-BASICのプログラムをN88-BASICの命令に変更する準備を整えていきました。
 次に問題となったのは、プログラム及びデータをどのようにPC9801に接続した8インチFDにコピーするか、という点でした。
 現在では、OSが同一であれば、媒体が異なってもデータのコピーは、保証されていますが、当時、OSというものがなかったので(強いて言えば、BASICがOSだった)、単純にコピーしようにも方法がなかったのでした。
 まして、パソピアのFDは、は5インチ、9801のものは、8インチという物理的な寸法も異なります。

 そこで、パソコン間通信を行いました。
 この時代は、パソコン通信の黎明期にあたっていて、私も「日本マイコンクラブ」のマイコンサーキュラという雑誌を読んでいました。
 これらには、パソコン通信や異機種間通信のプログラムが掲載されていました。
 これらを参考に、いわゆるハンドシェイク手順のデータ通信のプログラムを作成しました。
 プログラムは、双方で作成する必要がありました。

 最後の課題は、2台のパソコン間の接続ケーブルでした。この記事のトップに掲載している写真は、そのケーブルの一方の端子を示しています。
 いわゆるRS-232Cケーブルでリバースケーブルが必要になったのでしたが、そのようなものが販売されていなくて、仕方がないので、テスターで確認しながら、一部の線を接続し直して作成したものでした。
 実際のテストとデータ転送は、土・日の2日間をかけて行いました。
 2台のパソコンを会議室に並べて通信を行いました。
 1秒に1件程度のゆっくりとした速度で、しかし、確実に、アスキー形式のプログラムやデータなどが9801のFDにコピーされていきました。
目次に戻る

N88-BAISCからBASIC98へ

こうして、PC9801でのシステムの運用が開始されました。
 1981年、16ビットパソコン用のOSとして、アメリカでMS-DOSが開発されました。
 日本でもバージョン2となってから発売されるようになり、バージョン3にいたって広く利用されるようになりました。
 ワープロソフト「一太郎」にMS-DOSが付いてくるという、今では、考えられないような時代でした。
 MS-DOSが日本で普及したのは、一太郎のおかげもあったように思います。

 MS-DOSに日本語入力などを組み込むためには、MS-DOSのCONFIG.SYSとAUTOEXEC.BATの書き方がポイントとなり、その後、拡張メモリが販売されるようになるにつれ、これらの記法は、複雑なものとなりました。
 その後、メルコやアイオーデータなどから自動的にこれらを書き換えるツールが発売されるまでは、記法に関する解説本まで出版されました。


CONFIG.SYSの記法解説本など。右はWINDOWS3.1の時代になっている。PC98の文字も見える。

 このようになってくるとMS-DOS上で動作するBASICが必要になってきたのです。

 
BASIC98 FASTのテキスト類。

 ここで、私が導入したのは、1990年頃に、神津システム設計事務所(後に電脳組に引き継がれました)が発売したBASIC98でした。
 このBASIC98は、BASIC98 FASTやBASIC PROと、順次、バージョンアップされ、MS-DOS時代における日本のBASICのデファクトスタンダードになったのでした。

BASIC98 Proのテキスト。「プロ仕様 EMS対応」の副題が時代を物語っている。

 このようにして、プログラムは、何度か書き直されることになりました。
 ただ、BASIC98の言語は、可能な限り、N88-BASICと互換性がありましたので、パソピアから移行するときほどは、困難な作業ではありませんでしたが。
 MS-DOSの時代では、AドライブのFDには、MS-DOSと日本語システム(当時は、ジャストシステムのATOKでした)を入れておき、BドライブのFDにデータを入れることになったのでした。
 しかし、容量が足りないので、システムディスクで起動して、MS-DOSを読み込ませて、FDを入れ替えて、処理するというような涙ぐましい操作が必要なときもありました。
目次に戻る

ハードディスクの導入

私個人は、パソピアから9801のVMに移行したように記憶しています。このあたり、少し記憶(と記録)が曖昧です。
 ところで、この頃、緑電子という会社が20MBのハードディスクを販売することになりました。
 このHDは、もちろん、9801専用でした。当時は、「98にあらずば、パソコンにあらず」という時代でしたので、緑電子のHDが9801専用だったのは、当然のことでした。
 いや、速い、速い。オフコンの洗濯機ほどあったハードディスクの何倍も容量があるHDが手のひらにのる大きさで、しかも手頃な価格で売り出されたので、これは、買うしかないと直ちに購入しました。(確かLittle Bというような名前でした。)
 価格は、LAOXで本体が72600円、接続用SCSIボードが23500円でした。購入日:1988/3/12)

 勤務先でも緑電子の40MBのHDを接続しました。
 当時のHDは、SASI(SCSIの98用の規格)に沿ったもので9801のCバスに専用のボードで接続するものでした。

 今、考えると9801のバスは、便利なもので、現在のPCIバスのようにパソコンの筐体を開けずに、各種ボードを接続できるという極めてメンテナンス性に優れたものでした。
 現在のパソコンの難点は、タワー型のPCでもPCIボードやHD、メモリの増設や交換時にいちいち、内部の配線をかき分けて、作業するという、信じられないくらい、ばかばかしい作業を強いられることです。
 サーバ専用のものやノートパソコンで一部、比較的簡単に作業ができるものもありますが、内部は、配線のスパゲッティです。もう少し、部品をカチッカチッと組み合わせるだけでメンテナンスできるように部品の規格を作れないものかと思ってしまいます。
 ~閑話休題~

 緑電子のハードディスクの威力は、驚きで、たとえば、9801になってから作成した、あるシステムで見ると、FDの時代、一日半かかっていた作業が3時間で終了するような力がありました。
 また、緑電子のHDには、MS-DOSのシェルに相当するメニュープログラム(SOSと呼ばれていた)が搭載されるようになり、これを利用すると、初期のMS-DOSの利用時に行っていたコマンドラインからCOPY命令を打ち込むなどという必要は、なくなっていきました。

 今から振り返ると、この年は、大容量のHDがパソコンに内蔵される時代の幕開けとなったのでした。
 少し、付け加えると、この頃は、CD-ROMというものは、ありませんでした。
 CD-ROMがパソコンに内蔵されるようになったのは、もう少し後、WINDOWS95が発売された1995年頃になります。
 わたしは、WINDOWS95の前身のWINDOWS3.1を3.5インチフロッピーで約15枚組で購入したことがあります。
 WINDOWS3.1のインストール時は、1枚ずつパソコンにFDを挿入していくのですが、FDの読み取りエラーを起こすとまた、最初からやり直すことになったりして、一枚、二枚と、とんだ「番町皿屋敷」になったりしたものです。
 やや時代が下った、WINDOWS95の時は、CD-ROMで販売されたものを購入しましたので、だいたい、1995年頃には、CD-ROMがパソコンに一般的に搭載されるようになったことが分かります。
目次に戻る

BASICシステムの問題点

このようにしてBASIC98により、その後もいくつかのシステムを開発していきました。
 ところがシステムの作成時には、各種データの最大件数を想定していたのですが、件数がそれを越えるようになってきたのでした。
 前述のような直接編成ファイルは、あらかじめファイルの容量(最大データ件数)を決めて確保(アロケート)しておく必要があります。
 すなわち、ファイルの大きさが固定なのです。
 このため、システムの作成時にマスターファイルの作成を行う特別のプログラムを作成しました。
 このプログラムによりファイルの領域がブランク又はゼロによりクリアされます。
 KY04、KY041などは、最大件数と連携していましたので、こちらも変更しなくてはならなくなりました。
 今から考えるとこれらのパラメータは、メインプログラムではなくてサブルーチン側に持っていた方がよかったのかも知れません。
 それは、ファイルの最大件数を増やすだけで、ファイルに関係するプログラムすべての変更が必要になったからです。
 ただ、BASIC98には、スクリーンエディタが付属していたため、置換機能などもあり、パラメータだけの変更は、比較的、簡単でした。
 しかしながら、データを再度、新しくしたマスタファイルに旧ファイルからコンバートしなくてはならず、これらの作業のために別途、コンバートプログラムを作成する必要がありました。

 このようにBASICシステムでは、DBASEやアクセスのようなデータベース管理機能が組み込まれている訳ではないため何をするにもプログラムを書くという非効率的なことになってしまっていたのです。
 このため、項目を増やすなどとファイルフォーマットの変更になるとおおごとになったしまいました。
 ただ、一応、予備の項目を確保していたため、ある程度は対応できたのでしたが、何回か、プログラムを変更する作業を行うことになりました。
 これらの問題の解決は、WindowsXPとアクセス2002の組み合わせによる新システムの完成まで十数年、待つことになったのです。

 余談になりますが、Windowsで動作するBASICとして電脳組からBASIC98のWINDOWS版も発売になっています。
 
Windows版Basic98のテキスト類。

 また、富士通からもF-BASICというWINDOWSで動くBASICが発売されたこともあります。
 どちらも購入してテストしてみました。
 これらに乗り換えることは、私が退職したことなどもあり、結局は、できなかったのですが、このようなソフトが発売されていることで、日本全体でPC9801によるBASICシステムが多くの会社で作成され、最近まで稼働している(いた)ことがおわかりいただけると思います。
目次に戻る

メニュープログラムとログ機能

前述のようにBASICシステムの問題点も徐々に顕在化しつつありましたが、わたしの作成したこれらシステムの小さな自慢は、メニュープログラムとプログラムの実行時間を記録していくログ機能でした。


※メニュー画面の一例

 メニュープログラムは、システム毎にいくつかありましたが、いずれも一つのプログラムを選択するとそのプログラムが終了時にこのメニュープログラムを自動的に呼び出すことにより一連の処理を実行するというものでした。
 BASIC98には、COMMON文というプログラム間でデータの受け渡しを行う命令がありましたので、これを利用したのです。
 すなわち、プログラムのEND文の前でCOMMON文で宣言した変数に自分のプログラム名、実行開始日時と終了日時を書き込み、メニュープログラムを呼び出します。
 メニュープログラムは、プログラムから渡された、これらデータをログファイルに書き込んでいくというものでした。
 さらに、メニュープログラムは、自分を呼び出したプログラム名を元に次に使うべきプログラムを呼び出すか、それとも終了すべきかを判断して、メニュープログラムに書き込まれた順序にプログラムを実行していくことができました。
 このことにより作業者が最初のプログラムを選択すれば、後は、自動的に一連の処理が行われるようになりました。
 たとえば、「交付書」や「検査依頼」などを選択すれば、マスターファイルから必要なデータをセレクトして、並び替え、さらには、当該帳票の印刷後にマスターファイルの更新日やフラグのセットまでを複数のプログラムを連携して自動的に行うことができたのです。

 これは、当時としては、画期的なことだったと密かに思っています。
 後年、私が作成したマイクロソフト「アクセス2002」を利用した新システムでも複数のプログラムの実行は、プロシージャの順序制御として当然、アクセスに備わっているからよいのですが、アクセスには、プロシージャの実行履歴を自動的に記録する機能は、ありませんので、各プロシージャにそのような機能を実装しないとログの記録ができません。
 システム作成の時間的な関係で現在、ログ機能を実現できていないことが残念です。
目次に戻る

終わりにあたって

今回の続きは、「コンピュータ事始め(PC98全盛期)」として掲載しましたので、是非ご覧ください。
 では、今月は、ここまで。今後も時間ができましたらば、随時、更新していきたいと思います。
 皆様、お元気でお過ごし下さい。
目次に戻る

前回のご挨拶に戻る今月のご挨拶に戻る次回のご挨拶に進む