スライド 1

Download Report

Transcript スライド 1 

コボル文化の人と共存共栄
汎用機系開発者とオープン系開発者が
円満に開発できるために
なぜ、現場では、衝突するのだろう?
Ognac
第02回わんくま１３９勉強会
• 自己紹介: Ognac
• 高校の時に取得したアマチュア無線の
コールサインがJE3OGNでした。
• じいさん・おじんと揶揄されました。
郵政省は人を見ているのでしょうか。
• Automatic Computer をつけて名乗ってます。
• 過去形なのは、うっかり失効で無効にされてしまいました..orz。
• 阪神間でフリーランスの.NET系システム開発やってます。
• VBシンパでしたが、最近はC#が多いです。
• お仕事、頂けたら有難いです。頂戴ね。
• 今日の資料は以下でダウンロードできます。
• http://ognac.wankuma.com/Download/SRC/PPT_DownLoad1.htm
• 拙いBlogを書いています。
• http://blogs.wankuma.com/ognac/
第02回わんくま１３９勉強会
• 略歴
• プライベート
•
NEC_TK80以来のインテル系ユーザー
•
初期は68系が好きだったのですが....
•
Z80の対の裏レジも好きだった。
• パブリック
•
S/370VM/MVSでCobol
•
S/36でRPGⅡ/RPGⅢ(AS400の前身)
•
その後、IBM_AT系を経てMS系の開発
• おあにいさん、おあねぇさんにご厄介かけがちな若造です。
以後見苦しき面体お見知りおかれまして、恐惶万端
引き立って､宜しゅうお頼み申します
第02回わんくま１３９勉強会
•
•
•
•
•
•
•
•
•
•
•
今日のお話
「コボル文化の人と共存共栄」～開発スタイルの差
という大仰なタイトルを付けちゃって恐縮です。
コボル系がメインの方はどれ位いらっしゃるでしょうか
コボル系(汎用機)は知らないという人は?
コボル文化という、曖昧な表現をしていますが、汎用機文化
と言ってもいいでしょう。
オープン系人と汎用機系人の間に溝を感じて早、256年....
この温度差を、オープン系開発者の視線で考えることで、小
さくできたらなぁ...
と思った次第です。
「コボル系vs オープン系」としてますが、
「FrameWork1.xに縛られている人」も同様です。
第02回わんくま１３９勉強会
• システム開発の分野とは
• 業務アプリ、ゲームアプリ、制御アプリ、画像解析、組み込み系ア
プリ、 その他、多数、あらゆる分野がありますが、今回は比較的、
多い、事務データ処理分野で考えます。
• オープン系の事務データ処理分野は、広がる一方で、POS端末や
券売機、ATMも範疇に入ってます。もはや、制御系と業務系の区
別は無意味です。券売機も一台のWindowsマシンですものね。
• 守備範囲が拡大中なので、文化(開発スタイル)を形成する以前の
状態でしょう。
• 反対に、コボルの守備分野は、ほぼ固定化されています。それ故
に、文化(開発スタイル)が形成されているとも言えそうです。
• 守備範囲が異なるので、比較することに無理があるのですが、互
いに、理解し合うことは大事なことです。
• 最近、ワークステーションのことを聞きませんが、どうなっています
かね。
第02回わんくま１３９勉強会
•
•
•
•
•
•
•
•
•
オープン系開発者が感じる温度差
オープン系の開発プロジェクトでも、管理者／PM層 が
オープン系の人とは限りません。
世代問題、年功序列、関連会社.出向..その他色々な事情で、コボ
ル系の人が、管理者層やPMなることが、往々にしてあります。
その結果、オープン系開発にそぐわない、ルールやお作法で開発
標準が確立されたりします。
互いに理解し合えば、よいのですが、地位を使って、上意下達に
なるケースも多いようです。
現場に溜まるガスのガス抜きは難しいとも聞きます。
その結果、品質となって表面化すると、お客様も開発者も不孝
温度差を無くして、幸せな開発生活を
第02回わんくま１３９勉強会
• 異なる文化はなぜ衝突する
• 「自分と異なる文化でも、文化の存在を歓迎して、受け入れると衝
突するはずはない」…理想であり願望です。
• 宗教戦争や内乱が無くならないように、人の思考力は堅い。
• 閉じた文化の中では、各々が正論です。二つが同席したとき、
• 「正論」+「正論」= 「正論」とはならず、
• 一方を「邪道」だとみてしまう悲しい傾向があります。
• こうなる原因は荒っぽくいえば、相互理解力不足と言えそうです。
第02回わんくま１３９勉強会
•
•
•
•
•
•
•
•
•
•
自分と違う文化や思考に出会った時
・「相手を理解しよう」とする人
・「相手は間違っている」と非難、排除する人
・「相手は間違っている」だから、正しい道に矯正してあげようとす
る人
に分かれるようです。
管理者側の人が前出の『「相手を理解しよう」とする人』だとハッピ
ーです。
『「相手は間違っている」と非難、排除する人 』の場合は、管理者と
しては疑問ですね。でも、管理者を指名できない辛さが…..orz;
『「相手は間違っている」から、正しい道に矯正してあげようとする
人』
このケースは、困ります。現場にガスがたまります。
カトリック宣教師を経て殖民地…..脱線しそうなので補正。
第02回わんくま１３９勉強会
• 逆に、オープン系の人が、汎用機系の人を教育しようとしないのは
、年齢層の差か、地位の差か、あきらめか....どうでしよう。
• 管理者側の発言力が強いのは、組織上の宿命なので、厳しいの
かもしれませんが。
• あと、10年もすれば、解消するでしょうが、消極的解消な気分。
第02回わんくま１３９勉強会
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
なぜ、相手を誤解してしまうのか
「常識」という概念に惑わされている
普遍的な「常識」は存在しない。
単にその人の経験則であり、知識に過ぎません。
同様に、「業界の常識」も存在しません
「業界符丁は共通語である」錯覚する。
そして、「常識・符丁」が通じない相手を格下に見てしまう人も
います。差別意識の根底問題に通じると思っています。
盗人や放火以外の道徳的善悪や犯罪は、固定ではありません。
時代や環境によっては善悪が逆転したり、合法になります。
人は保守的である。
慣れ親しんだ方法が最善で最良と思う。
全体的なメリットと、自分にとってメリットの区別がアヤフヤ。
自分の基準を押しつけることで生じるメリットデメリットが読めない
目前の、作業の妥当性に疑問を感じない
第02回わんくま１３９勉強会
• ウォーターフォール型開発と管理手法の誤解
• ウォーターフォール型を過去のものとして否定する人がいますが、
そうでしょうか。
• ウォーターフォール型のメリットは多くあります。オープン系の開発
でも有効な手法です。
• ただ、表皮的に運用されて、誤解されているのは残念です。
• goto文==悪人説に共通点を感じます。適切に用いれば、
• 有効ですよね。
• 前工程と後工程を明確に分離し、責任範囲を明確化する機能は
是非取り入れたい手法です。
• (*)上流工程の手抜きで、下流工程が火を噴く現場が多いのは、減
りませんね。….下流工程の責任にされた日にはねぇ。
• 下流で発覚した、上流工程バグは、差し戻せるのが理想です。
第02回わんくま１３９勉強会
• スパイラル開発も誤解運用されているようです。、
• 業務ルールの確定が製造段階まで持ち越されている現場があっ
たりします。
• スパイラルの名を騙った「行き当たりばったり」の感がありますね。
第02回わんくま１３９勉強会
• 私が感じた「?」なルール等
• (汎用機文化から派生していると思われるもの)
• (*)ルールは幸せな製品開発に寄与するものです。
•
足枷になってはいけません。
• コードレベルのプログラム設計書を書かせて、その後にコーディングさせ
る。昔は、机上コーディングして、パンチャーがパンチしました。その名残
かと思われます。
• 「少しコーディングして、ブロックテストする」のを悪とするルール
• 「バグはテストで見付けるべきだ」とされます。
• 「設計書を書く手間でコーディングできる」「ケアレスミスは、その場で見付
けたい」という、現場の思いは強くなります。
• ステップ数で管理する。
•
「1000行あたりn個のバグが発生する」これを「経験則ながら実体に近
い」と信じている。
•
その個数に達するまで承認しないというのもありますね。
•
そのため、ワザとバグを作り込む人が出ることに。
第02回わんくま１３９勉強会
• バグ票で品質を評価する。など
• 基底クラスにバグがあると、 派生クラス各々に表皮的なバグが
でます。派生数が多いとバグ票が増える事になります。しかし、そ
のことで、「オープン系はバグ率が高い」と評価されたりします。
• テスターは、仕様でテストするので、継承元クラスのバグとは判断
しません。「テスターは実装を見ない方がよい」が裏目にでます。
• でも、実装者側がテスト項目を作ると甘くなりがちだし…..
• 意味の薄いコーディングルール
•
「実行文にはコメントを書いて、読みやすいコーディングをしましょう」
•
良いことなんですが、表面的なレビューチェックしかしない現実が
あったりします。
• (例) A = (B+C)/2; // BにCを加えて 2で割り、Aに代入する.....
•
// 無意味なコメントですが、レビューはOKのようですね。
• 本質レビュワーが少ない現実。レビュワーは実装力が要りそう。
第02回わんくま１３９勉強会
• 項目名称
• RDB全盛の今日では、存在を知らない人も多いモノに「スペーシ
ングチャート」があります。これは、カラム開始位置から終了位置
まで縦棒を引いて、項目を図式化したものです。
• 0000000001111111111222222222233333333334444444444
1234567890123456789012345678901234567890123456789
コード ZIP
県名
市名
価格
• xxxxxxXXX-XXXXロロロロ▼▼▼▼▼▼▼▼▼▼▼▼0010
• のように、記述していきます。EBCDICコードの時は, SI/SOが付く
ので少し複雑になります。いまでも、これを要求する所も。
• 項目名は、「コード」「県名」や「CODE/Kenmei」とつけずに、
第02回わんくま１３９勉強会
•
•
•
•
•
•
•
•
•
•
•
•
F001006 PIC X(6),
F007008 PIC X(8).
F015008 PIC X(8).
F023024 PIC X(12).
F047004 PIC 9(4).
とするルールがあったりします。解るでしょうか？
カラムの開始位置と長さが項目名になっています。
1byte目から6byteの項目だから F001006
項目長が変わると、眼も当てられません。
１レコード長が1000byte以上になっても破綻します。
知り合いの現場では、最近まで現役でした。
特に、不満を聞かなかったので、馴らされていたのでしょうか。
第02回わんくま１３９勉強会
•
•
•
•
•
•
•
FreeWare/ShareWareに対する見解
Freeは無料で、ShareWareは有料と理解されています。
これらは、開発者が個人の場合が多いですね。
でも、品質は、有料製品版より優れている事も多いです。
「製品責任が問えないし、動作保証がない」として採用しないの
は、コボル系(汎用機系)の人に多いように感じてます。
粗雑性や無責任性は有料製品でもあります。優秀な製品なら、拘
ることは無いと思うのですが、ブランド保障を求める文化のようで
す。
• 企業の保守性なのかも知れません。
第02回わんくま１３９勉強会
•
•
•
•
•
•
•
•
•
バグ取り文化
家内制手工業で手作りなのは、コボル、オープン系共に同じです。
(前述と重複する内容ですが)
バグの発見は、テスターが行い、バグの特定は、ソースを追うので
はなく、再現性を追求し、この操作でこのバクがでる..とバグ起票し
ます。
バグ票単位に行われるので、原因が継承元でのバグであっても、
表皮的な現象が違うので、再現性の追求も複数回行われます。
ソースを理解しているものからみると、冗長性を感じます。
これは、構造的な宿命かもしれません。
継承元をTest対象とすべきですが、継承概念が無ければ
話が通じません….今後の課題です。
第02回わんくま１３９勉強会
•
•
•
•
•
•
•
•
•
•
•
•
業務分析でプログラム本数が判るか?
要件分析=>外部設計=>内部設計=>コーディング=>テスト
の流れは、汎用機／オープンに関わらず、工程として存在します。
工程の分類であって、相互依存関係は粗くあるべきです。
複数のクラスの関係は、粗なほうが良く、保守性が高まります。そ
れに通じるものがあります。
汎用機文化では、そのような認識ではなく、次のように考えている
現場もあります。
・要件を砕いたモノが外部設計
・外部設計を砕いたモノが内部設計 とされる。
内部設計書の本数とコーディング本数が対になるとされます。
外部設計書に、内部設計書の本数が反映されているので、外部
設計書が見積もりの根拠になったりもします。
オープン系の実装ではクラスの継承関係で対にならないですね。
基底クラスの設計書は、外部設計書に登場しないのが多いし。
第02回わんくま１３９勉強会
• プロジェクトの進行は何所を基準にするか
• 開発要員を複数箇所から調達するプロジェクトでは、開発者のス
キルを均一にするのは難しいものです。
• 円滑にプログラム開発を進めるには、基準を何所に設定するかは
重要な要素です。
• スキルの差は、計るのは難しいので、単純に速度差で見ることに
します。
• プログラマの開発速度の差は、コボル系では三倍とされていまし
た。(私の過去の職場値)
• オープン系の差はもっと大きいとされます。一説には10倍以上とも
聞きます。
第02回わんくま１３９勉強会
• 遅い人のレベルを引き上げても、開発はもたもたします。
• 遅い人に合わせるほうが開発が確実に進むと考えられています。
•
進捗結果だけでみるとそうかも知れません。
• ソースのスマートさは、業務仕様とは無縁の部分とされ、スキル引
き上げは消極的になるようです。
• クラスの継承とか、ジェネリック、リフレクション云々は御法度にな
っている現場があったりします。
• 継承クラスを使いこなせない開発者がいるから、継承禁止とか、
• 再帰コールは、理解できない開発者がいるから、再帰禁止とか、
• 下に合わせる傾向があったりします。
• 確実に一歩ずつでも前進するプロジェクトを良しとするようです。
• 品質に対する温度差を感じてます。
第02回わんくま１３９勉強会
• 内部仕様から、テストケースを洗い出す、WhiteTestは少なく、
• 業務仕様からテストパターンを洗い出す、BlackTestが多いようで
す。テストをクリアすれば、完成度100%と見なされます。
• 業務要件上の品質面では、そうなりますね。
• ソース品質は不問でいいのでしょうか。ソース品質が高いと、
• バグる率も低くなり、トータル的に開発期間の抑制につながると思
うのですが。
• ソース品質レビューがお座なりになっているようです。
第02回わんくま１３９勉強会
•
•
•
•
•
•
•
•
•
Coble開発では能力差が小さいのか
コボル系の開発速度差が三倍らしいと言いました。
オープン系の差ほど大きくならないのはなぜでしょう。
開発者の向き不向き等の人的要因は、どちらも同様ですよね。
オープン系のコーディング要素は大量にあり、知識の保有量・活
用力が開発力を左右します。
コーディングパターンを試行錯誤する部分も多々あります。
コボルの開発パターンは、ほぼ確立されており、新規開発でも、過
去資産をテンプレートとして、使用します。
コボル開発では、設計書に、「xxxのパターンで作成する」と記され
ていて、そのパターンには、「xxxxとxxxを実装時に変更」と記され
ていたりします。
テンプレート文化とも言えます。ここまで、親切だと、開発速度に
差が出るほうが、不思議です。
第02回わんくま１３９勉強会
• 生産工程が工場化されていて、工業製品として、完成の域に近づ
いていると言えます。
• 近い将来、オープン系もその道を歩むかもしれません。今は拡大
期なので、当分安泰ですが。
• 環境が成熟すると、開発者として、面白みが減るのは産業の宿命
なのかも知れません。
第02回わんくま１３９勉強会
• OSと言語の関連性
• オープン系の開発では、OSサービスやOSの機能を知らずにアプ
リケーションは作れるでしょうか、Win32APIを使う機会は減ってい
ますが、.Net.FrameWorkの機能を使わずして、アプリは作れませ
ん。 言語と、ミドルウェアーの区別する意味は薄いです。
• 汎用機は、OSサービスを利用する開発者をシステムプログラマ
• と称して、アプリ・プログラマとは別の人種とされます。
• コボルの知識だけで完結しているアプリ開発者もいます。開発仕
事もそれで成立します。
• 一般的に汎用機のEXEは単独では動きません。
• JCL/CLという Job Control Language を介して動作します。
• これは、Exeの実行に必要な環境の定義や、Exeの処理分岐をす
るものです。
• 平たく言えば、バッチFileやCMD_Fileの親分みたいなものです。
第02回わんくま１３９勉強会
• コボルExeは1プロセス1スレッドが基本
• 汎用機OSにもOSサービスがあり、APIを介してサービスを享受で
きるのですが、利用している開発者は少数です。
• JCLにも EVAL機能があります。言語でなく、JCLで値を判断させ
て、処理分岐したことがあります。しかし、
• 「そんな処理パターンは前例がない。他の人が理解できない作り
は、不可だ」と説教されたことがあります。
• 一つのEXEに複数機能を持たせるのも原則禁止されたりします。
• ExeからExeを引数経由で呼び出すことは副プログラムコールとい
う形態で可能ですが、一体化しないので、スマートさに欠けます。
• (注) 外部プロセスリンクではなく、Shell.Callに近いです。
• 「自分はコボルプログラマだから、OS周りは知らない。OS周りは
システムプログラマの範疇だ」とする風潮を感じます。
第02回わんくま１３９勉強会
• 1機能1Exe
• 汎用機で画面を扱うのはOnline機能が実装されてからです。
Onlineは、乱暴に言えば、Webアプリの1画面 = 1HTML/1ASP と
同様です。画面単位のプロセスです。
• 各画面が独立してて、UIは端末依存で、submit後が汎用機の範
疇なので、Webアプリと同じとも言えます。
• このように1機能1Exeが原則です。
• DOS/Windowsアプリの初期には、1画面1exeという、開発標準が
あったりしました。さすがに最近は、聞きませんが。
• 一つのシステムを１Projectにするか、複数Projectにするかは
•
結合度で分ければよく、適度な判定が要ります。
• (例)
• 要件:郵便番号簿から大阪市だけを抜き出し、一覧表にする。
• 何本のプログラムが必要でしょうか。
• 一本のプログラムというより、数行のSQL文でできますよね。
第02回わんくま１３９勉強会
• SQLの結果をCSVにして、EXCELに喰わせれば、プログラムも不
要ですね。
• ある、コボル開発者は、
• 1: 郵便番号FILEから大阪市に該当するデータを抜き出すプログ
ラムを作成する。
•
[郵便番号FILE] => 【抽出プログラム。(&ソート)】
•
=> [WorkFile]作成
• 2: 一覧表作成プログラムを作成し、一覧表を作る
•
[WorkFile] => 【一覧表作成プログラム】 => [一覧表]
• の二本作ると見積もってきました。
• １機能１本というスタイルは徹底しているようでした。
第02回わんくま１３９勉強会
• 上位互換性と過去の資産
• オープン系は、「ソース互換性が無い。だから駄目だ。」とよく指摘
されます。
• 確かに、言語仕様もOS仕様も、操作性も、互換性を捨てて、バー
ジョンアップしてきました。
• ソースレベルの互換性もありません。API仕様や引数が変わること
すら有ります。
• これは、思想というより、宿命と思います。
• 不具合になった仕様は捨てるし、相反する要求が生じた時でも、
有効なら取り入れます。
• それだから、ここまで発展してきたと言えます。
第02回わんくま１３９勉強会
•
•
•
•
•
•
•
•
•
•
汎用機系は逆に、ソースの完全互換を重視します。
「過去の開発資産を腐らせない」というのが、大前提です。
同じ系列のOSだと、Exeモジュールがそのまま走ったりします。
Windows系は一応バイナリ互換性は意識していて、
DDE_APIが現役だったりします。(現版は?)
動かないのもあるので???感がするのですが。
少し、脱線。
過去資産の面で見れば、 ソース互換が重要だと言えるのですが。
JAVAはWriteOnceを目指しましたが、現実は、.....ですね。
技術とは....環境が成長期である間は、固定化できない...と言えま
す。
• 1985年に始まったΣ計画....触れる事はタブーとされてますが...
• これは、コンピュータはこれ以上発達しないと仮定し、機能を固定
化し、汎用化・理想化しようとしたので失敗した..と言われてます。
第02回わんくま１３９勉強会
• バイナリ互換は裏目にでることもあります。
• ソースがなくなっても、Exeだけが使い続けられていたりします。
• 保守したくても出来ない状態になります。
• 一度作ったモノは、永久に使えるというメリットがあります。
• こういう背景があるためか、一度作ったソースをとっても大切にし、
再利用する風潮が生まれたのかも知れません。
• スクラップビルドも汎用機の人は極端に嫌がります。
• オープン系人は、スクラップビルド(過去ソースの思想だけ踏襲)す
ることに抵抗は少ないようです。
• これも文化の違いでしょうか。
第02回わんくま１３９勉強会
•
•
•
•
•
•
なぜコボルは第一線言語でいられるのか
コボルは1959年に開発された共通事務処理用言語です。
日常語風の言葉で記述できる言語です。
(英語でです。日本語ではありません。)
Fortranはもっと古く、規定されました。
共に50年の歴史があり、現役言語です。
• 「優れているから現役である」でしょうか。
• 優れて無くても、広く普及するとデファクトスタンダードになります。
• VHSやMS-DOSやWindowsやWord....ウルトラマンや仮面ライダ
ーや...
• その後PL/Iや4GLなど、もっと優れた言語は多数、登場しましが、
• コボル/フォートランの地位は不動でした。
第02回わんくま１３９勉強会
• コボルやフォートランが世界的に普及してしまった後では、少し良
いくらいでは、ひっくり返らなかったのでしょうね。
•
今も、毎年のように、新言語、画期的言語と称されるものが登場
しますが、普及するのは希です。C#が普及したのは、OOP化の流
れと、.netの普及という、組みあわせの時期が良かったのかも知
れません。(.net用に作られたので、変な言い回しですが。)
• Rubyが受け入れられたのは、登場前の環境に不便を感じていた
人が多くいたので、受け入れられたとも言えそうです。
• これから多く登場する、動的言語、F#等には大いに頑張って欲し
いところです。
第02回わんくま１３９勉強会
• OpenOfficeが普及しないのもExcelが普及しきったからとも言えま
す。
• でも、ひっくり返るとなると、一瞬かもしれません。 Lotus 1,2,3.....
マルチプラン...?
• コボルは 1980年以降84 88, 93 と拡張されていますが、新しい
機能は普及してないようです。
• 開発者のコーディング水準は Cobol-80/84だったりします。
• 是非の問題ではなく、業務アプリの要件をそれで満たせば、製品
としてはOKとされるからです。
• 新しいOS機能や言語機能は、業務アプリにとっては、十分条件に
過ぎない...と考えているようです。
• 便利機能を使いたがる開発者もいますが、「新しい物好き」と見な
され、歓迎されない風潮も感じます。
• 開発者が抱える、矛盾であり葛藤でもあります。
第02回わんくま１３９勉強会
• この現象は、.net系でも言えます。 VS2008が普及しても、Linqが
知られていなかったり、ジェネリックを知らない、開発者が少なから
ず、います。正規表現が知られていないのはガックリします。
• 知らない技術者に対して、安易に、
• 「開発者のスキル向上意識,,,自己研鑽..学習..」などと、批判しが
ちで、酒の肴にするのですが、開発会社の仕事の短期的安定化と
いう面でみると、責めるのは酷だと思います。
• 是非の問題ではなさそうです。仕事のありかたが問題なのかも知
れません。
• でも「次世代に残れるか否かは、本人次第」ということは確かなよ
うですが。
第02回わんくま１３９勉強会
• ASP.NET1.xは結構普及したようで、喜ばしいことです。
• しかし、普及しすぎて、ASP2.0に切り替えられない会社を散見しま
す。ASPのお仕事で、現場に入ると, FrameWork1.xだったりしま
す。ジェネリック等が使えない環境は、「使えねぇ」と感じる瞬間で
す。
•
もうすぐしたら、Linq to XMLが使えない環境は「使えねぇ」と叫
んでいそうです。
•
XMLをDOM操作やPath操作することに比べて、便利・便利
第02回わんくま１３９勉強会
• 旧VBは普及しきってますね。これが足枷になっているのは皮肉な
ことです。
• VB6.0の新規開発案件が未だにあるくらいです。
• VBAがこれからも存命なので、旧VBは不滅なのかも知れません。
• 旧VBと今の .NET.VBは名前か「BASIC」でも別物文化てすしね。
• 共に「BASIC」にしたのは失敗だと思っています。
• 「同じBASICなんだから、ソース互換あるんでしょ」と見られます。
• 「別物」と叫んでも、コボル系の人には通じないようです、オープン
系の内部事情と映るようです。
• 正規表現、ラムダ式、匿名Delegateなど手放せない機能も、使用
者が増えなかったりします。
• 必要を感じなければ、普及しないという、宿命があるのかも知れま
せん。
• .netにあるSqlStringやSqlInt型という型も知られていません。
• 便利なのに埋もれている機能は沢山あります。
第02回わんくま１３９勉強会
• SQLの開発者でも、SQL92の機能を、知らない人がいるのは残念
なことです。
• OuterJoin を (+)= と記述するのを標準としている現場もありま
す。
• スキーマ情報の取得も規定されてますが、各DB依存のＳＱＬ文で
処理しているのも見かけます。
•
PL/SQL T-SQLも新機能が普及しない事もあります。
• コボル文化が硬直化したのと、同じ道をオープン系も歩んでいる
...気がします。
• 普及しきった言語は、何時までも第一線言語 なのかも知れませ
ん。 旧VBが今も現役で、 .NET.FW1.1.が今も現役……
• 逆かも。普及している言語の事を第一線言語というのかも。
• FrameWork 3.5/ 4.0が普及するのは何時の日か?
第02回わんくま１３９勉強会
• 初めてのコボルの仕事で説教
• 256年前、コボルがある程度作れるようになったとき、コボルの初
仕事を頂きました。
• (仕様)
• ・会社には A,B,C,D,Eの5つの課がある。
•
そのうち、外販している課は B,D,Eである。
•
・売上データは 売上ファイルに存在する。
•
・外販の売上を集計せよ。
• いまなら、数行のSQL文で作れるものですが、当時はRDB自体、
存在しませんでした。
第02回わんくま１３９勉強会
• (私のコード) : <コボルに読み替えてね。>
•
String[] 対象課 = new String[]{“B”,”D”,”E”}
•
Decimal sum =0;
•
売上ファイル.Open();
•
while(true)
•
{
•
if(EOF) break;
•
一件Read;
•
if(!対象課.Constain.Key(読んだ行の課)) continue;
•
sum += 読んだ行の売上;
•
}
•
売上ファイル.Close();
•
write(sum)
第02回わんくま１３９勉強会
• 該当データを全件読み込んで、メモリ上の変数 SUMに足し込むだ
けの単純ループ処理。
• ・レビューを受けたら、教官から、
• 「これでは駄目だ。このような処理パターンは、我が社にはない。」
と説教1時間コース。
第02回わんくま１３９勉強会
• (正解とされるコード): 2本のExeで作るそうです。
• ①本目
• 1:該当課のデータを保持するFILEを作る。該当課ファイルとし、
ソート結果を格納する。
•
「該当課ファイル」
•
1件目 : [B]
•
2件目 : [D]
•
3件目 : [E]
第02回わんくま１３９勉強会
• ②本目
• 2:売上ファイルを課別にソートし、入力ファイルとする
• 3:売上額の蓄積用に、 変数SUMを確保する
• 4:入力ファイルをOpen
• 5:該当課ファイルをOpen、課別
• 6: マッチングルーチン
•
入力ファイルの課と該当課ファイルの課を比べて、
•
一致しなければ、超過するまで片方を読み飛ばす。
•
一致すれば、sumに足し込む
• 7:共にEOFになれば終了する
• 8:CLOSE
• 典型的な、二つのファイルのマッチング・マージパターンです。
第02回わんくま１３９勉強会
• 「業務要件を、極力、既存のパターンに当てはめて、コーディング
する」
• 指針の一つではあります。
•
「一本のプログラムで作れて、ファイルIOも少なくて済むのに何
故NGだ」と思っていました。リソースの効率面ではそうですね。
• でも、品質保証の面からみると、既存にないパターンで作成した場
合、テストも1から行う事になり、テストケースの洗い出しから工数
が発生するので、テスト完了までのコストは、大きくなります。
• 既存パターンに則って作成した場合は、テスト箇所は限定的にな
るので、総合的な生産コストは少なく済むというのが、理由でした。
• 開発会社としたら、危険率は低い方がよいので、既存のパターン
に固執するのですね。
• このあたりの価値判断は難しいものがあります。
• 不満を感じる開発者もいるようです。
第02回わんくま１３９勉強会
•
•
•
•
•
•
コボルはCopy文化?
コボルには Copy命令があります。
既存のソースFileをインクルードする機能です。
単独で存在する共通ルーチンを利用するとき、
ルーチンだけをインクルードすることができます。
LibraryLinkもできるのですが、Module Callは手続きが手間なの
で、多用はされないようです。
• Copy文が好まれるようです。
第02回わんくま１３９勉強会
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
(例)
COPY INPUT-FILE.
FD OUT-F.
01 OUT-R
PIC X(15).
/////////////////////////////////////////
000010******************************************************************
000020* (COPY句) INPUT-FILE(入力データ）
000030******************************************************************
000040* 入力データ
000230 01 IN-R.
000240
03 NAME
PIC N(10).
000250
03 KANA
PIC X(10).
000260
03 ZIPB
PIC N(8).
000270
03 TEL
PIC X(15).
000310*
第02回わんくま１３９勉強会
• HTML/Javascriptにもあるので、違和感は無いと思います。
• Cにもincludeがありますしね。
• C#やVBにあってもいいと思うのですが。
• 脱線しますが、 C#やVBになぜ、プリコンパイルのMacro機能が
無いのでしょうね。
• 有って欲しいと思うのは私だけ？
第02回わんくま１３９勉強会
• コボルの基本書式
• オープン系の言語の多くはフリーカラム言語です。
• オープン系開発者は固定カラムを嫌がります。
• C系の人は 文末は ";" であり、改行であるVBに難色を示す人が
いる位です。
• フラグ桁の決まっているRPGⅡ/Ⅲ/400をみると違和感一杯かも。
• 厳密にはコボルは領域規定言語で、カラム固定ではありません。
• 80桁の紙カードが原型です。
第02回わんくま１３９勉強会
• 行番号領域 :
• 1～6カラム目:6桁の行番号 : 実際は無意味です。
•
紙カードの時代に、落としても復元できるためにありました。
•
現実は空欄のまま、が多いようです。
•
カードを束にして、上から斜めに線を引いて代用してました。
• 行指令
• 7カラム目 : ‘*’ :その行はコメント行
•
: ‘-‘ : 継続行
• A領域
: 8～11カラム目 : 段落名記述
• B領域
: 12～72カラム目 : 処理記述欄
• 欄外
: 73～
: 何を書いても無視される............
•
実質上のコメント欄だがそうは言わないのは、
•
72桁カード時代の名残か?
• 段落: コボルの処理は、段落名から ‘.’ までが一段落。
第02回わんくま１３９勉強会
• M-PROC.
•
COMPUTE M-P = M-A / M-B
•
COMPUTE M-Q = M-A - M-P * M-B.
•
c#に訳せば
•
M_PROC:
•
{
•
M_P = M_A / M_B;
•
M_Q = M_A - M_P * M_B;
•
}
• となりましょうか。
• “M-A” のように ‘-’ が入っても、有効な変数名なので、
•
読みにくい?
第02回わんくま１３９勉強会
• 駆け出しのころ、 M-B. の’.’の位置が、たまたま、73カラム目にな
り、次の命令まで実行されて、 バクりました。
• ソースを見ても原因がわからす、一晩苦しんだことがあります。
• この手の’.’にまつわるバグ話は、結構多くあります。
• とある公共システムが半日止まったのもこの類だったとか.....(伝
聞ですが)
•
COMPUTE M-P = M-A / M-B などと
• と書きましたが、本来
•
COMPUTE A = A + B. は
•
ADD A to B.
• と書きます。しかし、数式が複雑になると、表現しきれないので
• COMPUTE 命令が加わったという話もあります。(真偽は不明)
第02回わんくま１３９勉強会
•
•
•
•
•
構造化記述、整構造記述
今や、懐かしい響きのする「構造化で記述しましょう」
でも、コボル(汎用機)系では、現役のスローガンだったりします。
コボルの世界でも goto文は悪役で、歓迎されません。
しかも、「goto文をなくすことが、構造化することだ」と錯覚している
人がいるのは、どちらの世界も同じです。
• 上から下へ流れて、処理が手戻りしないスタイルを「整構造」と言
ったりしますが、
• 表皮的なものでなく、記述思考がそうあるべきというのも同じです。
第02回わんくま１３９勉強会
• 例)
• 主処理.
•
Perform 処理A
•
Stop RUN.
• 処理A.
•
なんたら
•
かんたら.
• と書いたりします。 処理Aの「なんたら」から「かんたら」までが段落
です。
• 疑似関数といっても良いでしょう。
• Perform 処理Aは、古のBasicの gosub です。処理後、戻って来
ます。
• 分岐し、戻ってくるので goto文と同意です。
第02回わんくま１３９勉強会
•
•
•
•
•
•
•
•
•
•
•
End-Performという、括り句が登場し、
主処理.
Perform
なんたら
かんたら
End-Perform
Stop RUN.
と記述できるようになりました。
処理は、上から下に流れます。
このようなソースの作りを「整構造化」と称する事もあります。
第02回わんくま１３９勉強会
• Perform句は、ある程度のサイズの塊で段落化する文化があり、
数行(1行の時も)でメソッド化する、我々のソースは、
• あちこち分岐するので、「読みにくい」らしい。
•
Perormはgoto文同等と認識されているようで、メソッドCallも、
• goto文と映るようです。
• これも、見えない溝ですね。
第02回わんくま１３９勉強会
•
•
•
•
•
•
•
•
•
•
•
•
•
コボルの４つの部
コボルは４つの部で構成されます。
IDENTIFICATION DIVISION.（見出し部）
プログラム名、
作者情報やバージョン情報を記します。
フログラム的には無意味です。
ENVIRONMENT DIVISION.（環境部）
TapeDeviceやFileのIO情報を記します。
物理仕様は、このプログラムに対応するJCL/CLで規定します。
DATA DIVISION.（データ部）
変数定義
印刷レコード定義
Fileの項目定義などを記します。
第02回わんくま１３９勉強会
• PROCEDURE DIVISION.（手続き部）
•
ロジックを記します。
• これだけでも、面倒だと感じる人がいますが、RPGもっと煩雑で
• I仕様書,O仕様書、T-仕様書、D仕様書...など部ごとに、コーディ
ングシートが分かれていて、エディターでソースをみても、ロジック
か読めない、不思議な世界です。
• 専用の三角立体定規がありまたねぇ….遠い目…..
第02回わんくま１３９勉強会
• 数字の扱い
• オープン系言語では、整数と浮動小数点の概念は基礎中の基礎
とされます。
• コボル文化では浮動小数点の概念がなかったりします。
• 有効数字の概念もなかったりします。
•
中学で習うと思うのですが、浸透していないものですね。
• 固定小数点の世界になります。 格納形式は二進化十進(BCD)で
ゾーン形式とパック形式の二種類がありますが、アプリ面では同
等です。(浮動小数点はCobol2002で追加されたようてすね….)
• どちらも、桁数だけの保持です。
• File上は、小数点位置が保持されません。
• 読むときに小数点位置を指定します。ソースに依存します。
• 小数点位置を変更して読み取るといったトリッキーなソースも有り
ます。
第02回わんくま１３９勉強会
• 「1兆円単位の計算でも1円の誤差も許せない」という発想のペー
スにもなってます。
• BBS会議室などで、 「0.1 + 0.1...(10回) =1.0 が成立しない」は、
• 定期的に話題になりますが、浮動小数点を知らなければ、疑問は
解決しないでしょう。FAQ.扱いですね。
• 質問者が初期にマスタした言語の影響もあるのかなぁ..と思いま
す。
• 現実世界では 0.1 * 10 は 1 なのが当然で、1.0 != 1 とするのが
異常とも言えます。
• 処理系の限界かも知れません。
• 開発者としては、「知っとけよ」と思う時もあり、矛盾してますね。
第02回わんくま１３９勉強会
• 「0.1」をどのように感じるか、オープン系の人は、「半端な数字だ」
と感じますよね。
• コボル系の人は、「半端感」はないようです。
• 2^-n である 0.5 , 0.25, 0.125はスッキリした数字である。
• と感じることが、浮動小数点を扱う基本なんですが、一般人と乖離
しています。
• 「開発者の見解は非常識」と言われる一面です。 コボル系の方
が、自然なのかも知れません。
• 業務分析は、業務面から行うもので、「実装制約から行うものでは
ない」と言われる根拠の一つかも知れません。
第02回わんくま１３９勉強会
• コボルの基本パターン
• Procedure Division.
•
Perform 前処理
•
Perform 主処理 Until 終了条件.
•
Perform 後処理.
•
Stop Run.
• という形が基本だと、叩き込まれる現場があります。
•
前処理を実行して、
•
Fileを終了するまでLoopして、一件ずつ処理する。
•
後処理をする。
• という流れになります。
第02回わんくま１３９勉強会
• このパターンは、徹底されるようで、至上主義に陥る人がいるよう
です。
• このLoopパターンは SQL文化と対立することになります。それは
後ほど。
• Performはgosubであって、関数ではありません。
• 呼び出し名は、Procedure Division.直下でユニークになります。
• 変数名もそうですが、広域的にユニーク名称になります。
• このような構造なので、 Classにメンバーにメソッドがあり、
• 変数がインスタンス毎に割り振られる...
• という、名前空間やインスタンス毎に、メモリー空間が取られるとい
った概念は、理解し難いようです。
第02回わんくま１３９勉強会
•
•
•
•
•
•
•
•
•
変数名、プログラム名
IDENTIFICATION DIVISION.
PROGRAM-ID. SAMPLE-xx.
「SAMPLE-xx」 がプログラム名です。
8文字以下です。 RPGでもそうですが、カラム固定の制約から、名
称は8文字以内という制限があります。
8文字に無理に短縮すると、可読性を損ねて、追跡しづらく、感じ
ますが、当事者はそうでもなさそうです。慣れは恐ろしいものです。
01 OUT-REC.
05 OUT-CODE
PIC 9(5).
OUT-REC, OUT-CODE : 変数名のほうは長さ制限が緩いです。
第02回わんくま１３９勉強会
•
•
•
•
•
•
•
•
•
•
•
•
•
•
広域変数しかない影響
例)
FD IN-FILE.
01 IN-REC.
05 IN-CODE
05 IN-NAME
05 IN-TANKA
05 IN-SURYO
FD OUT-FILE.
01 OUT-REC.
05 OUT-CODE
05 OUT-NAME
05 OUT-TANKA
05 OUT-SURYO
PIC 9(5).
PIC X(20).
PIC 9(6).
PIC 9(3).
PIC 9(5).
PIC X(20).
PIC 9(6).
PIC 9(3).
第02回わんくま１３９勉強会
• FDは File Defineで入力File/出力Fileを規定します。
• 01と05は階層の意味で 01 IN-RECのなかに4つの変数が存在す
るという意味です。
• 変数名は DATA DIVISION内では、レベルに無関係にユニーク
です。
• 同一性質なので共に CODE PIC 9(5) にするほうが、可読性が
高まるのですが、できません。
• コボル系は、変数が異なれば名前が異なると考えます。
• 平たく言えば、ローカル変数の概念が存在しません。
• これは、プログラムの設計に大きな影響があります。
第02回わんくま１３９勉強会
• 関数がないので引数がない。強いて、引数の説明をするときは、
違うEXEを引数付きで呼び出す副プログラムを例に揚げて説明す
ることになります。
• 「必要な変数は、プログラムの最初に規定する」といった規約の背
景になったりします。
• 「必要な変数は命令の直前で規定する」....は理解されないようで
す。
• 組み込み関数は存在しますが、ユーザー記述関数ではないです。
Cobol84から。
• 再帰コールは概念自体ありません。
• .NET系でも再帰コールを禁止している現場がありますが、
• 「再帰が理解できない開発者がいるからだ」と言ってましたが、??
です。もっとも、業務アプリに「再帰」が登場する局面は少ないのか
も知れませんが、
• 明細や製品構成がネストしていれば、再帰でないと嫌ですが…..。
第02回わんくま１３９勉強会
• 脱線
• うーん。ということは、構文解析のツリー展開など、
• 再帰が必要な処理はコボルでは書けないということかな?
• コボルではコンパイラを記述するのは不可能? 教えて、エライ人
• スタックもないから、厳しいか。
•
•
•
•
•
•
処理ロジックの構築は平面レベルの展開で考えることになります。
Classの中にClassがあったり、自分のインスタンスのなかに、
自分のPointerがあるようなリスト構造とは縁がないです。
構造を持つデータの組みあわせも理解に苦しむらしいです。
オープン系の人が汎用機の人に説明するときは、
説明の開始点に注意が要ります。
第02回わんくま１３９勉強会
• 変数やPerormの管理に 管理台帳を作成して、一カ所で管理する
風潮もあります。
• 管理責任者は大変な労力のようです。
• オープン系では、リフレクション機能が充実しているので、
• クラス自体が、自分は何者か知っていますし、自分が持っているメ
ンバーの情報も把握出来ます。自分や他人のメソッドを動的にコ
ールすることも可能です。これを多用しているモジュールも多々あ
ります。
•
カスタム属性も有効に使えば、コメントも有効なコンパイラが認識
できるソースとして扱うことも可能です。。
• RDBのテーブル情報もスキーマに問い合わせれば、判明すること
を台帳で管理しています。
• 二重管理で、冗長性を感じてしまうのは、私だけでしょうか。
第02回わんくま１３９勉強会
•
•
•
•
•
•
•
•
•
•
コボルでもSQLが使えます
参照)http://www.t3.rim.or.jp/~buchi/proco.html
▼▼▼▼引用開始
000010 WORKING-STORAGE SECTION.
000020*
|
000030
EXEC SQL BEGIN DECLARE SECTION END-EXEC.
000040 01 USERNAMES PIC X(32) VARYING.
000050
EXEC SQL END DECLARE SECTION END-EXEC.
000060
EXEC SQL INCLUDE SQLCA END-EXEC.
000070*
第02回わんくま１３９勉強会
•
•
•
•
•
•
•
•
•
•
•
•
000080 PROCEDURE
DIVISION.
000090*
|
000100
EXEC SQL WHENEVER SQLERROR GOTO SQL-ERR ENDEXEC.
000110
MOVE "SCOTT/TIGER@WGS_SRV_ORCL" TO
USERNAMES-ARR.
000120
MOVE 24 TO USERNAMES-LEN.
000130
EXEC SQL CONNECT :USERNAMES END-EXEC.
000140*
|
000150
STOP
RUN.
000160*
000170 SQL-ERR.
000180*
|
000190
STOP
RUN.
第02回わんくま１３９勉強会
•
•
////////////////////////////////////////////////////////////
000010 PROCEDURE
DIVISION.
000020*
|
000030
EXEC SQL SELECT tokui_name
000040
INTO :TK-NAME
000050
FROM m_tokui
000060
WHERE tokui_code = :TK-CODE
ENDEXEC.
000070*
|
000080
EXEC SQL UPDATE m_tokui
000090
SET tokui_name = :TK-NAME
000100
WHERE tokui_code = :TK-CODE
ENDEXEC.
000110
IF SQLERRD(3) NOT = 1
000120
DISPLAY "SYSTEM ERROR (UPDATE m_tokui)"
000130
STOP RUN
000140
END-IF.
000150
EXEC SQL COMMIT
END-EXEC.
000160*
|
▲▲▲▲引用終了
第02回わんくま１３９勉強会
• 外部 Exeとしてコールします。
• コボルからみると、別プロセスなので、結果のやりとりが、煩雑に
なるのは不可避です。
• 煩雑になるだけなら、大した問題にはならないのですが。
• データ取得後の処理が、既存のソースでは対応できないことに
• なります。
第02回わんくま１３９勉強会
• データの配列処理～縦持ちと横持ち
• 課別の年間売上予定実績表を考えて見ましょう
• (簡略化して、年度始めを1月とします)
• 課コード 課名
1月
2月
•
予定額 実績
予定額 実績
01
ワンクマ飲課 20 14
17 15
• 02
まっちゃ食課 55 62
5 5
•
:
:
:
:
: :
:
3月 ......12月
予定額 実績
35
95
15
99
• この表をデータベース上に保持するとき、どのように定義するでし
ょうか。
• 正規化のレベルで異なりますが、縦持ちしますよね (年は省いてま
す)
第02回わんくま１３９勉強会
•
•
•
•
課テーブル
課code 名称
01
ワンクマ飲課
02
まっちゃ食課
•
•
•
•
値区分
ID
Value
Y
予定額
J
実績額
第02回わんくま１３９勉強会
•
表
•
•
•
•
•
•
•
•
•
課Code 月
01
01
01
01
01
02
01
02
:
: :
02
01
02
01
:
: :
値区分
Y
J
Y
J
:
Y
J
:
値
20
14
20
14
55
62
• とでもなりましょうか
第02回わんくま１３９勉強会
• コボルでもこの形式のテーブルは扱えますが、前出したように、
SQLの結果のMoveに手数かかります。Move命令が従来のパタ
ーンと異なることになり、ソース資産が使えなくなります。
• コボル系の人が設計するとそのまま、横持ちする人が多いようで
す。(主観ですが)
• RDB思想よりも、ソース資産を基準にするのかもしれません。
• 課コード 課名
１月予定額 １月実績
2月予定額 2月実績
...... 12月予定額 12月予定額
• 01
ワンクマ飲課 20
14
17
15
• 02
まっちゃ食課 55
62
5
5
• これはこれで、理に叶う面もあります。
第02回わんくま１３９勉強会
• コボルソースを見てみましょう
• 01 予定実績行.
• 02 課コード.
• 02 課名.
• 02 予定実績 occurs 12.
•
05 予定額 9(5).
•
05 実績額 9(4).
• と定義できます。
• 意味は 01 予定実績行.が一つのデータ行に相当します。
• 間を飛ばして,05が二つあり、直ぐ上にOccurs 12.とあります。配
列らしいな..と類推できますよね。
• 予定額と実績額の組みが12個あると解釈します。
• つまり、これで、1月から12月の各項目を定義したことになります。
第02回わんくま１３９勉強会
•
•
•
•
•
•
•
•
•
•
使用例を見ましょう。
仕様【今月の予定額と実績額を表示せよ】
今月値の取得は次のようにします。
01 DATE-REC.
02 YY PIC 99.
02 MM PIC 99.
02 DD PIC 99.
ACCEPT DATE-REC FROM DATE.
これで、今月の値が MMに入ります。 雰囲気でわかりますよね、
DateTime.Now()に相当するのが DATEで yymmddの6桁の数
字になります。
• それを二桁ずつ3つの組みとして受け取り、MMを切り出します。
• 変数領域の階層構造の指定は便利です、Unionに近いかな。
第02回わんくま１３９勉強会
• 表示時は
• Display 課コード , 予定額[MM] ,実績額[MM]
• このように、予定額[MM] で扱えます。配列と同じ操作ですね。
• ・奇数月の実績を集計せよ
•
PERFORM VARYING MM FROM 1 BY 2 UNTIL I > 12
•
COMPUTE SUM = SUM + 実績額[MM]
•
END-PERFORM
• となります。
•
for I as integer =0 to 12 step 2 ….Next I
•
for(int i=0; i<13; i+=2){}
• と同じ感じですね。
第02回わんくま１３９勉強会
• SQLで作成すると、SQLを呼び出し、結果を読み込みゴニョゴニョ
することになり、文が大きくなります。
• SQL結果を配列に代入する文を書くか、このイメージで取得する
• SQL文を書くことになり、記述量が増えます。
• フログラムロジックを変えるのは、ソース資産の変更になるので、
嫌がられるようです。
• 汎用機文化の人が設計したRDBの正規化が浅いのが多いという
のは、このあたりも背景にあると思います。
• 個人的には、このような配列操作は、SQLレベルでサポートして欲
しいなぁ.....ADO.NET(DataTable)でラッパーすれば済みますが。
• サポートすると横持ちを肯定することになるので無理か?
第02回わんくま１３９勉強会
• RDBを旧来のDBとして使ってしまう
• 横持ちの話をしましたが、縦持ちのTableがあるとします。
• Cobolでゴニョゴニョ書くことになるのですが、前述したように、以
下のパターンが、擦り込まれているので
•
Procedure Division.
•
Perform 前処理
•
Perform 主処理 Until 終了条件.
•
Perform 後処理
•
Stop Run.
• 折角ＲＤＢを使っていながら、条件抽出や SUM()を使わずに自前
のLoopで処理する人がでてきます。ソースレビューでも不問にな
り、放置されている現場もあります。
• RDBが普及して、16年(?)位になりますが、お寒い事情があったり
します。
第02回わんくま１３９勉強会
•
•
•
•
•
•
•
•
•
•
•
SQLで結果を取得するパターンを標準化して、
新パターンとして徹底すれば、改善されると思うのですが、
パターンを作る層が薄いのが実情だそうです。
改善して欲しい項目です。
ソート・マージ・マッチングもSQLのJOIN処理を使えば単純化され
ることも多いです。
SQLで1テーブル毎にSelect文で取得して、自力でマッチングして
いるソースをみると、開発資産って何だろうと思ってしまいます。
役割の終わったサンプルや資産を破棄できないのは、何所の文
化も同じなのかもしれませんね。
逆に、オープン系の人で、マッチング等の基礎アルゴリズムを
知らない人がいます。
日々の技術は、日頃使う手法の範囲で間に合うのかも..
寂しい感じがしますが。
第02回わんくま１３９勉強会
•
•
•
•
•
•
•
•
•
領域再定義:Redefine:
CのUnionとは、違います。ソースを見て貰いましょう。
WORKING-STORAGE SECTION.
01 販売品目.
02
PIC X(20) VALUE "チャーハン".
02
PIC X(20) VALUE "焼きめし".
02
PIC X(20) VALUE "ピラフ".
02
PIC X(20) VALUE "カレーチャーハン".
02
PIC X(20) VALUE "ワンタン麺".
•
•
01 販売品目-TBL REDEFINES 販売品目 .
02 名称 PIC X(20) OCCURS 5.
•
•
01 I PIC 9.
*
第02回わんくま１３９勉強会
•
•
•
•
•
•
PROCEDURE DIVISION.
MAIN.
PERFORM VARYING I FROM 1 BY 1 UNTIL I > 5
DISPLAY 販売品目-TBL(I)
END-PERFORM
*
•
•
•
•
•
直感的に読めると思います。
5つの文字列の定義の領域を 要素５つの配列で再定義しているので、
プログラムで配列として使用できます。
この構造規定はシンプルになるので、C#やVB, SQLにも欲しいと願うのですが。
第02回わんくま１３９勉強会
• 時間の許す限りDEMO
•
•
•
•
•
コボルが走る環境を探すと、幾つかありますね。
UnixやSysgwin環境にもあります。
Windows環境で走る手軽なものに、
YcobolというCOBOL インタープリタがありました。
カラム定義が異なりますが、基本動作します。
第02回わんくま１３９勉強会
•
•
•
•
•
•
•
•
•
•
•
最後
好き勝手なことを言ってきましたが、
文化の差は伝わりましたでしょうか。
互いの文化を理解しようと勤めれば、溝は埋まります。
が、拒否反応を示す人がいるのも事実です。
新人でも染まってしまうと、拒否反応を示す人がいます。
環境は、どんどん変わっていきます。VS2010や動的言語がどん
どん登場します。
何が残るかは、誰にも判りません。
OS/2が残ると信じていた私….orz。
優れたモノでもポシャるかも知れません。
しかし、基礎知識と言われているモノを押さえておけばなんとかな
ります。
第02回わんくま１３９勉強会
• その面で、コボル文化の人も、オープン系の基礎知識をマスターし
て欲しいです。
• オープン系の人も、現行バージョンの機能は押さえて欲しいです。
• コボル文化も押さえて欲しいです。
• もっと相互交流して楽しい開発を!!
第02回わんくま１３９勉強会