OSのハナシ＜元SE独白記＞

＜元SE独白記＞  2016/06/16

今日はOSの話をしたいと思います。しかし僕が携わってきた大型汎用機のOSは専門的過ぎてしまうので、ブログの読み物としては重いと思います。そこで、僕が大型汎用機の事務処理計算の仕事に入る前のゲームのプログラミングをやっていた時代までタイムスリップしてみます。パソコンのOS上で開発をしていたのですが、そのころのパソコンのOSは、Windows OSがまだありませんでした。昔の人なら誰でも知っている「MS-DOS」です。もっとも昔はOSといえば「MS-DOS」しかなかったのですが。これは「 Micro Soft Disk Operating System 」のことで、マイクロソフト社開発による、パーソナルコンピュータ向けの16ビットOSです。いまのWindowsのようにきれいなアイコン等はなくて、真っ黒な画面があるだけです。コマンドラインにすべてコマンドを入力してプログラムを動かすのです。

じつは今のWindows OSからエミュレートできるのです。エミュレートというか、Windows OSはそもそもMS-DOSの上に建てられた家のようなものなので、これはWindowsが内部のMS-DOSの機能を使って表示しているということでしょうね。下の画面を見てください。これは僕がいま使っている、どこにでもある「Windows7」で立ち上げたMS-DOSの画面です。

 

最初はこういう画面が出てきます。ここにディレクトリーを表示するコマンド「 dir 」と入力してリターンキィを押します。すると、

 

これは僕の現在のパソコンの中のCディレクトリーの中味を表示しているのです。

このMS-DOSの機能は低いものでした。簡単にファイル管理とメモリー管理を見てみましょう。

ファイル管理：FAT（File Allocation Table 俗称ファット）でファイルを管理。

メモリー管理：一時的にアクセス可能なメモリー空間は、最大640KB～768KB程度だったというのですから、いかに低機能だったかですね。そのためバンク切り替え（バーチャルメモリーのようなもの）などで解決していたのですね。

現代のパソコンOSのメモリーはギガ単位です。隔世の感がありますね。

KOSEI

プログラム開発工程（続きの続き）＜元SE独白記＞

＜元SE独白記＞プログラム開発工程（続きの続き）  2016/06/14

ところで昨日のブログでは端末が並んでいる部屋があると言いましたが、端末の数は２０～３０でしょうか・・・。大規模システム開発になるとそれぐらいの規模になります。端末ですが一見するといまどこの家庭でも使っている「デスクトップ型パソコン」に似ていますが、実はまったく違います。これはコンピュータではなく端末に過ぎないのです。大型汎用機にたくさんの端末が繋がれているところをイメージしてもらうと一番わかりやすいです。単なる端末なのでこの中には「CPU」はありません。「ダム端」とかいう言い方をします。操作するだけであって、計算しているのはメインフレーム本体なのです。

ところでそんなに何十台の「ダム端」がぶらさがって仕事をしていて、処理スピードは落ちないのだろうか？と誰しも不思議に思うでしょう。でもそこにはメインフレームにはマルチタスク可能な機械で、「タイムシェリングシステム」という仕組みが働いています。下の手書きの絵を見てください。

 

メインフレームに左上の図のようにいまA、B、C、Dの４台の端末が繋がっているとします。するとメインフレームのCPUは、まずA端末が要求している仕事をします。次にB端末の仕事・・・、というようにすべての端末（ここではA、B、C、Dの４台）をし終わったら（D端末まで終わったら再びA端末に戻り同じことを繰り返します。A→B→C→D・・・・・という具合に。「でもA端末の仕事をしている間、B、C、Dは待ってなければいけないのでは？」と考えますね？上の図では例として時間が経過しているということを表すためにA端末の処理が6:30から始まって、その後１分ずつ増やしていますが、汎用機のCPUの処理速度は、僕が使っていたメインフレームマシンは第４世代のマシンだったので１秒間に１億回の演算ができたマシンです（100 MIPSいまは更に性能が向上しているはず）から、一つの端末の簡単な演算に必要な時間はナノセカンド秒単位でしょう。それこそ目にも留まらぬスピードなので、人間はまるで自分がメインフレームを独占して使っているような錯覚を起こしているのです。これを実現させているのが「タイムシェアリング・システム」です。現代のパーソナル・コンピュータという言葉は「パーソナル＝個人の自分だけの」コンピュータです本当に個人が占有しているのですが、汎用機の時代は単なる端末にすぎなかくて、このような仕組みでパーソナルのふりをしていただけなのです。

なので、それぞれの端末で実行をかけたりすると、その数が増えれば増えただけ一台の端末での動きが遅くなります。開発が佳境に入ってくると皆テストを始めたりで、処理速度はグッと遅くなり、ひどいときは停まってしまいます。決してハングアップしているわけではなく、CPUが他の端末からの要求（デマンド）を処理するのに忙しいのです。そういう時は夜間に仕事をするしかありません。まったく身体に悪いワーストテンに入る仕事です。また夜間は「バッチ処理」というのを定期的に流すのでそれがもの凄く時間がかかりその間はまったく一般の処理はできませんでした。端末が使える時間をいかに確保するか？が成功の鍵でしたね（笑）。

「バッチ処理」というのは、対話型で動くプログラムではなくて、順次に一定の処理を繰りかえりていく一括処理プログラムのようなものです。いまのパソコンでも電源を入れて立ち上がった後に走るのは「バッチ処理プログラム」です。バッチ処理で何をするかというのが「ブートストラップ」エリアにあらかじめ格納されていて、電源が入るとこのプログラムをキックする（最初から始める）のです。そこにはキレイなWindowsの初期画面を出力し、仕事の準備をして待ち体勢になるのです。バッチ処理に関しては次のサイト（Wikipedia）をご覧ください。

https://ja.wikipedia.org/wiki/%E3%83%90%E3%83%83%E3%83%81%E5%87%A6%E7%90%86

KOSEI

プログラム開発工程（続き）＜元SE独白記＞

＜元SE独白記＞プログラム開発工程（続き）  2016/06/14

プログラム開発工程の続きです。昨日は自分がコーディングしたソース・コード（人間がプログラミング言語で記述した大元のコード-プログラム本文-）に論理的な間違いが無いかどうかを念入りに机上でチェックします。もっとも念入りにといっても、特に大規模なプログラムになるとチェックし切れませんからその後の「コンピュータによるチェック」でやればいい、というようになってきますが、仕方の無いことでしょう。眼や神経が最初から余り疲れてしまっても後の作業に影響します。チェック箇所は２つのポイントです。まずは文法チェック、次に論理チェック。このうち文法チェックも確かに大切ですが、論理チェックに重点を置いたほうがいいと思います。論理的にまちがったコードを書くと実行時に動きが止まってしまいキーボードの入力ができなくなってしまったり（大体が無限ループが原因です）、abort（アボート＝流産とか、流れが止まるとか言う意味）したりします。アドートとは、俗に「落ちた」というやつです。

コンパイル作業：これはプログラマーがコーディングしたソース・コードを機械語に落とし込むための中間ファイルを作る作業です。ここでの主目的は「文法エラー」を取り去ることです。最初は１００行ぐらいの文法エラーは出るものです。しかしエラー箇所を修正すればどんどん減っていきます。大体はニァミス、ポカミスの類です。スペル間違い、入れ子が対応していない（入れ子またはネスティング）、ピリオドがついていない・・・・・等々。エラーコードを見ながら修正していきますが、慣れてくればエラーコードの番号を見ただけで原因がつかめます。問題は見たこともないエラーコードが出てきた場合です。原因を追究していったら深刻なエラーだったという場合もありますが、ある程度考えてみてそれでもわからない場合もあります。そのような時は無視します。なぜかというと、「コンパイラー」も4またプログラムであり、これを造ったのも人間ですから、なかには造った人が間違っていることも充分あり得るのです。ちなみにプログラム上の動作上の間違いを「バグ（虫）」と呼んでいます。バグをなくして正常に動くようにすることを「バグフィックスする」とかいいます。

このコンパイルエラーのうち「定義エラー」は無視します。たとえば外部のファイルを参照したり、外部のプログラム（このプログラムをサブルーチンともいいます。今コールしているプログラム本体はメイン・ルーチンです）をコールしたりしていても、記述はしてあっても実態はまだ繋げていないからコンパイルエラーが出ても当たり前なのです。

ついでに説明しておきますと、外部プログラム（サブルーチン）で外部に出さなくても、内部ですべて終結させることも、もちろんできます。サブルーチンでやっていることを全部メインルーチンに記述すればいいだけの話です。しかしプログラムを設計するときはサイズの問題、メンテナンス性の問題、といった部分を考慮しなければいけないので、特に他のプログラムでもよく使う処理であれば、外部に出してサブルーチン化すべきでしょう。その方が生産性も上がります。

リンケージ作業：上記のようなコンパイル時に定義エラーになった、まだメインプログラムに繋がっていないファイルをすべてこのリンカーが繋げてくれます。この段階でエラーがゼロならあとは実行あるのみです。

実行：僕が使っていた開発環境ではプログラムの実行はすべてコマンドラインからコマンドを打ち込みました。このときの注意点ですが、最初の一回の実行で一回目から正しい動きをすることは１００％ありませんから、本番とまったく同じテスト用の環境を作っておき、その環境下でテストを何回も繰り返します。こういう段階を踏まずにもしも間違えて本番環境で実行してしまい、本番環境に深刻なダメージを与えてしまったら、それこそ損害賠償問題です。僕のやっていたのは金融システムや航空システムだったので、、コンピュータが停まってしまうということは、社会に混乱を引き起こし、かつ企業にとっては大損害なのです。

じつはこの「実行」の段階が最終段階だと思ったら大間違いです。いちばん時間がかかる段階なのです。ロジックどおりに動いているのに何故画面上の正しい位置に表示されない？とか、表示はされるが数字が増えている、文字が化けている、こんなことはザラです。何回見直しても原因がわからない、こんなことはしょっちゅうです。自分が趣味でパソコンでプログラムの勉強をしているのなら、判らないのはそのままにしておいても誰も何も言いませんが、プロフェッショナルとして仕事をしている場合はそうも行きません。プログラマーがいちばん胃を悪くするときでしょう。

このような時は「トレーサー」というプログラムを使います。問題の半分近くは解決します。トレーサーとは、順を追って流れを追いかけてくれる（トレースしてくれる）プログラムです。プログラマーが書いたメインプログラムの動きに合わせて、必要な記憶領域の内容等を１命令（演算）ごとに表示してくれるプログラムです。例えばどこかの記憶領域に何かしらのデータを格納したとします。するとここでその記憶領域の内容をみれば間違っているかどうかは一目瞭然です。たとえば本来格納する数字が「１」だったとします。ところがトレーサーの内容を見たらまったく違う値が入っていた！ここが原因だったということになりますね。

ですが、面倒な場合は記憶領域にデータの出し入れが発生するところで自分でディスプレイ命令を挿入しコンパイル、リンク作業を再びおこない、ディスプレイの結果を見て判断します。また「ウォークスルー」という手法がありますが、これには僕もずいぶん助けられました。情報システム用語辞典によると、

★

ソフトウェア開発において、ソフトウェア成果物の品質向上を目的に、その作成者が主体となって開催するレビューのこと。インスペクションに準じる公式なソフトウェアレビューに位置付けられることが多い。ウォークスルーは、レビューを希望する作成者が数人のレビューアを招集、成果物の内容を順に説明する形式をとる。それに対してレビューアは、説明を通じて対象を追跡・検証し、その誤りや矛盾、抜け漏れなどを指摘するというのが大まかな流れである。カジュアルなグループディスカッションから公式レビューまで、幅広いバリエーションが存在する。いずれにしても、一つの製品を完成させるには色んな方の苦労の結晶だということですね。

KOSEI

プログラム開発工程＜元SE独白記＞

＜元SE独白記＞プログラム開発工程  2016/06/13

僕が現役SEだったころはパソコンやワークステーション上での開発という現場はありませんでした。すべて「大型汎用機」と呼ばれるものでした（ 「メインフレーム」とも ）。メインフレームとパソコンの違いをみてみましょう。

コンピュータにはCPUというものがあります。これはCentral Processing Unit 中央演算処理装置ですが、現在パソコンのCPUはマイクロチップ化されていますが、メインフレームのCPUは、どデカイ箱であってその箱が中心だったわけで、なので「メインの」「フレーム（枠・箱）」と呼ばれていたわけですね。メインフレームのCPUは「TTL」「ECL」と呼ばれるものですが、マイクロプロセッサのCPUは「MOS」と呼ばれるものです。マイクロといわれるだけあって「集積度」はすごいのですが、いっぽうメインフレームのCPUは集積度が上げられないため、複数のチップから構成されていたのです。しかし処理速度はメインフレームのCPUのほうが速いです。

僕は若い頃から趣味でマイクロコンピュータをいじっていたため、メインフレームの部屋に入って「これがCPUだよ」といわれたときは「？？？」でした。ピンと来なかったですね。（初期のころのメインフレームは特にですが）人間考えすぎると頭が熱くなってきますが、CPUも同じで発熱が大きかったのです。コンピュータルームに入ると、２４時間体制でクーラーがガンガンきいていて、理由をあとで聞いて納得しました。最初は「オペレータ（操作員）は皆暑がりなのかな？」と真面目に考えていました。

　IBM_704_mainframe

しかし1990年代に各社ともCMOSマイクロプロセッサに移行したそうですが、発熱量も同時に下がったとのこと。じゃあ処理スピードも下がったの？と思いきや、マルチプロセッサ化で性能をキープしたそうです。僕が現場にいたころはちょうどそのハザマのころだったようです。「現在は独自仕様のマイクロプロセッサを複数（最大64個など）搭載するものが多い」とWikipediaにはありました。

メインフレームの定義を見ると、「企業の基幹業務である組織内部の処理と、大量または機密性の高い処理に利用する大型コンピュータを指す。」とありました。構造化や分散処理の波がメインフレームを「滅び行く恐竜」扱いしていますが、じつはいまだにまだ製造し販売しているのです。もちろん全盛期よりははるかに台数は少ないですが。理由は組織内の機密処理をオフラインで行えば機密性は上がるためでしょうね。

ところで、僕がメインフレームの世界に入って仕事を始めたころの開発環境は、いま考えても或る部分は笑えるものがあります。その当時の僕のプログラム開発の流れを再現してみましょう。

昨日のブログでも書きましたが、プログラム仕様書が手元に渡ってきたらまずプログラム・フローチャートを作成します。

１）コーディング・シートと呼ばれる紙に手書きでコーディングします。間違えたら消しゴムで消して書き直します。

２）コーディング・シート上にすべてのコーディングが完成したら、これをあるところに届けます。これは届ける係りの人がいるので申請をして待ちます。

３）自分でコーディングしたプログラム文を、いったいどこに届けるのかというと、「キーパンチャー」という人のところに届けるのです。早くて数時間、遅くても数日のうちにはキーパンチャーがパンチしたカードがプログラマーである僕のデスクに届けられます。このキーパンチャーという職業は若い女性がやります。一度見ていたことがありましたが、イヤ、その速いこと速いこと！指なのかキーボードなのか見分けがつかないほど・・・・。僕がキーパンチャーに「きみはサイボーグ？」と聞いても誰も同意すると思います。

４）次はその穴の空いたカードを持ってコンピュータルームへ行きます。ここでは入室の時に自分のID、所属部署、氏名、処理内容を記入して入室。オペレーターがカード読み取り機にパンチ済みカードをかけて、フロッピーディスクに読み込みます。それをもらって自分のデスクに返ります。コーヒーでも飲んで一服してから、端末が並んでいる部屋があるのですが、そこへ行っていまもらってきたフロッピーの中身を端末に表示して内容をチェックします。間違いがあれば修正します。

言っておきますが、メインフレームがあるビルは自分のデスクがある部屋や端末が並んでいる部屋があるビルとはかなり離れたところに在るので、いったんビルを出て他のビルまで徒歩でトボトボと移動するのですから、面倒なことこの上ないです。書いているだけで疲れてきましたので続きは明日にします。

KOSEI

プログラミング設計＜元SE独白記＞

プログラム・フローチャート  2016/06/12

フローチャートというのは、別にプログラムを設計するときでなくても、頭の中でやる作業ですし、人生は選択の連続です。例えば朝ランニングに行くときのことを考えて見ましょう。朝起床してランニングに行くかどうかを決定するまでのフローチャートはこうなります↓↓（手書きなので見苦しいです）

 

＊このフローチャートによるとランニングした朝は朝食抜きですネ。

プログラムをつくる時もいきなりコーディングから始めることはまずありません。頭の中をまとめる意味でもまず「フローチャート」を作成します。その後にそれぞれの判断文や決定した処理をプログラミング処理言語に置き換えていくのです。

その際に覚えておかなければならない約束事があります。それは次のサイトをご覧ください。

http://www9.plala.or.jp/sgwr-t/c_sub/jis_fl.html

このサイトには「流れ図」とありますが、「フローチャートflowchart」の直訳です。資料によっては「流れ図」といっているものもあります。

最初のころよく使うフローチャート記号は、次の６個ぐらいなものでしょう。

「処理」を表わす長方形

「判断」を表わすひし形

「直接アクセス記憶」を表わす円筒形

「書類」を表わす紙の下端が切れたような図、

端子（流れ図の入口と出口）を表わす横長の円

流れ図が複数にわたる時に「結合子」としてつかう小さな円

まあ短いプログラムであれば、フローチャートを書かずにコーディングを始めてもいいと思うのですが、ある程度以上の長さのプログラムになる場合はフローチャートは必須です。でも論理的な思考を身につけるという意味でもフローチャートを書くことをクセづけたほうがいいでしょう。

KOSEI

論理演算＜元SE独白記＞

＜元SE独白記＞  2016/06/11

今日は「論理演算」について書きます。といっても何をどう書いていいのやら。「使ったことがある」というのと「説明できる」というのは話が違いますからね。そこでインターネット検索の力を借りましょう。「論理演算」で検索すると、以下のような説明がでてきます。

論理演算とは、2つ以上の１または０入力値に対して、１つの演算結果（１または０）を出力する演算のことである。 論理演算は、初級シスアドの試験では重要でSQL文における抽出条件の作成などにおいて必要不可欠な考え方だからだ。 論理演算の演算の種類として、論理積（AND）、論理和（OR）と否定（NOT）の3種類がある。

またまた意味不明な言葉が出てきたと思います。「シスアド」とは、システム・アドミニストレーター、つまりシステム管理者とでもいう役割を受け持つ人です。初級とあるのでシスアドになるためには基礎的で重要な知識ということですね。SQLとはデータベースを使いこなすときに必要な言語です。さて、この論理演算ですが、別名「ブール代数」ともいいます。上の説明にもあるように「０」と「１」だけの演算です。２進数演算といってもいいですね。具体的に説明します。演算をする二つの要素を「A」と「B」とします。

論理積（AND条件）　AもBも、すべて「１」の時に「１」を出力する（答は「１」になる）、それ以外の場合の答えは「０」。つまり次のようになります。

０ｘ０＝０、０ｘ１＝０、１ｘ０＝０、１ｘ１＝１

これだけだと、一体何のことやら・・？ですよね。でもちゃんと使い道があるのであります。それどころか論理演算はかなり重要なものなのです。では引き続き

論理和（OR条件）　AかBのいずれかが「１」の時に「１」を出力する。それ以外のときは「０」を出力する。

０ｘ０＝０、０ｘ１＝１、１ｘ０＝１、１ｘ１＝１

否定（NOT条件）　A、Bどちらかの値が「１」なら「０」に、「０」なら「１」に反転する。

以上３つを基本にして幾つか組み合わせパターンがあります。

否定的論理和（NAND条件） すべての値が「０」のときに「１」を出力

ここら辺は説明が煩雑ですので、「こういうのがあるな」ぐらいに考えて置いてください。

排他的論理和（EOR、XOR条件）　入力値が違うとき1を出力する。それ以外（入力値が同じとき）は、0を出力する。

これらは高校の数学で習った「集合」を想い出すといいと思います。以上の記事はインターネット上のサイトを参考にさせていただきました。

http://www.pursue.ne.jp/jouhousyo/sysad/sysad011.htm

もうちょっと詳しく知りたい人は上記サイトで勉強してください。他にもたくさんあります。

では「実際にどう使うの？」という話ですが、たとえば「あるビットにフラグが立っていたら（「１」だったら）処理するようにしたい」というときには二つのコーディングの仕方があります。ABCと名前をつけた８ビットの記憶エリアの一番右端の（０ビットめ）が「１」だったら、ある処理をしたい、としましょう。

方法１：if ABC = 1 then ある処理　　これは最もベタなコーディングです。

方法２：ABCDという記憶エリアにあらかじめ「00000001」を格納しておきます。そのうえで、

「ABC XOR ABCD = 真 ならば ある処理」とします。

論理演算の一番簡単なつかい方はこのようなビット検査の時に使いますが、そのほかにも論理演算子を使うことで「a と bが等しい」かつ「c は dよりも大きい」といった条件式を組み合わせたより複雑な条件式を記述することができるのです。

上の例で０ビットめのチェックの場合、もちろん方法１でも方法２でも、どちらでも結果は同じで同じ動作をします。しかしプログラムが走っている（動作している）環境はしょっちゅう変わるものです。「０ビットめじゃなくて３ビットめのみが「１」だったら「ある処理」を実行しよう、というように変わったとします。すると方法１でコーディングしていた場合は、変更が発生します。コードの修正です。「if ABC = 1」のコードを「if ABC = 4」に修正する必要が発生します。使用している箇所が多いとそれだけ修正時のミスも増えます。ところが、論理演算をつかうことによって、大元の「ABCD]の内容のみを修正すればいいので、ラクですし間違いも少ないのです。

KOSEI

プログラミング言語の種類その3＜元SE独白記＞

＜元SE独白記＞  2016/06/10

・C言語

・日本語プログラミング言語

・LISP

プログラミング言語の種類ということでお話してきましたが、昨日のブログでは「フォートラン言語」までお話しました。次に挙げているのが「C言語」というプログラミング言語です。いまはすっかり定着していますが、この「C言語」が登場したとき、「妙な名前のプログラミング言語だなあ～」と思ったのを覚えています。仕事仲間と「C言語」の話題になった時に「Cという命名があるからにはのはBもあって、Bの次に出たんじゃないの？」と冗談半分で盛り上がったものです。僕も半信半疑で「どうでもいいか」ということで無視していましたが、Wikipediaに次のようにありました。

B言語（ビーげんご）は、AT&Tベル研究所のケン・トンプソン (Ken Thompson) によって開発されたプログラミング言語である。ケン・トンプソンがデニス・リッチー（Dennis Ritchie）監修の元で設計し、1969年頃に登場した。

やはり本当にあったのですね。でも「C言語」のほうが使い勝手がいいので主流になってしまったのでしょう。なぜかというと、Wikiの同じ頁に「特徴」として以下の様に書かれています。

B言語で記述されたプログラムは、コンパイラによって中間コードに変換され、実行にはインタプリタを必要とした。実行時にインタプリタによって逐次処理されるため、実行速度は極めて遅かった。ただしPDP-7版は機械語を出力できるように改良された。

これからプログラミングを勉強しようとしている人に向けてこのブログを書いているため、そのような方は上記「コンパイラ」といわれてもチンプンカンプンでしょうが、「高級言語で記述されたコードをコンピュータが理解できる言葉に直す処理の一つの段階」と思っていてください。

インタプリタというのは僕のブログでもベーシック言語の紹介のところで書きましたが、実行時にワンステップ単位で翻訳していく方式です。当然速度は遅いのです。ふつうはコンパイルをした後は、リンカーというものによって「リンケージ」の作業、つまり関連ファイルをくっつけて（リンケージして）、オブジェクトファイル（exe-イグゼファイル-とか実行ファイルとも）をつくりあげます。これが最終の実際に動くプログラムですが、exeファイルは機械語になっていますからスピードは速いのです。しかしコンパイラのあとにインタープリタって・・・、やっぱり非現実的で「変わり種プログラミング言語一覧」にでも掲載するような部類ですね。でもこの「B言語」のコード例をみてみましたが、C言語の前身というだけあって、似ている部分は結構あります。

しかしこのB言語のほかにも驚くべきことに、「O言語」以外はA～Zすべてあるのです！物好きで暇な方が調べた結果がこちらsappari wiki

http://memo.sappari.org/a2z-languages

僕が現場を離れて事務所での管理職に昇格したあたりに、概念としては「構造化プログラミング」とか、ハードウエアの枠組みとしては「ワークステーション(WS)」というものが出始めてきて、C言語も普及し始めたのです。だから僕は「C言語」は実務ではほとんど使っていません、数本組んだだけですが、やはりとてもわかりやすく機能が高いプログラミング言語だと思っています。

C言語はネットワークにも強い言語です。今はPCでネットワーク接続をして独立して仕事ができますから、ある業務に慣れていて、またひとつのOSを使いこなせるならば、自宅でも仕事ができるわけです。僕の現役時代からは信じられないことです。

ある物流会社のNECの中型コンピュータで支社とラボを通信回線で繋ぐという仕事を経験したことがありますが、その当時はインターネットが無かった時代です（信じられないでしょう？！）。なので電話回線を使って繋いだのですが、詳細は覚えていませんが、「通信プロトコル（通信上の双方の決め事）」が現在のインターネット通信を前提としたものとはまったく違っていて、プログラムで直接に、あるビットのフラグを立てて、相手に送る。すると受信側はそのフラグが立っているのを確認してそれなりの処理をするという段取りなのですが、人生を同じで、話どおりに進まないのがプログラミングの世界で・・イヤ苦労の連続でした。失敗の繰り返しで3日間缶詰状態とか1週間前後でようやく繋がりました。

日本語プログラミング：これは経験した技術者は少ないと思います。富士通の「BAGLES」という名前のプログラミング言語なのですが、COBOLの英文をそのまま日本語に置き換えてコーディングするのですが、結局は内部的にCOBOLに変換されますから、内容のチェックをするときはCOBOLが解っていないと読めません。某金融会社（生保だったかな）の仕事でしたが、この「BAGLES」で組みました。しかし日本語プログラミングは、あまり意味が無かったように思います。いまはだいぶ進化しているみたいです。↓

http://www.fujitsu.com/jp/group/fmcs/solutions/purpose/developptlang/bagles-open/

他のメーカーでも色々と販売していたようですね。

最後のLISPですが、これは人工知能言語です。これは解説すると長くなりますので、やめておきます。それに僕は実務での経験はまったくないです。会社内で「LISP研究会」をやろうという話が持ち上がったので、僕も賛同し勉強会を開いて研究していた程度です。

＊＊さすが「C言語」ですね。ブログ記事がいつのまにか長くなってしまって。次のブログでは、「論理演算」についてお話したいと思います。

KOSEI