今度は、JDEの技術基盤のトレーニングに参加してみました。このコースは、システムを管理する人は、必ず出た方が良さそうです。メニューの設定や、各種パラメータの設定、ファイルの構成やライブラリー構成など、技術面に的を絞って、説明してくれます。いままでの利用者の立場からの説明よりかは、自分に近い説明が続きます（4日）。その中で、感じたことを、以下に述べていこうと思います。
柔軟性
パラメータが多いシステムとは、プログラムの中で、「ハードコード」が少ないシステムです。つまり、変更したい場合は、プログラムの外部に存在する、引数を変更する事で変わるシステムです。早い話、プログラムの修正なしに、動きを変更したり、見てくれを変更できるわけです。これは、設計思想の中でも、結構、根元的で、誰しもが考えることですよね。特に、マルチリンガルなシステムになると、コード別に1次言語の記述と、2次言語の記述をつけたりして、言語環境で、コードの意味を英語とか日本語に切り替えたり考えませんか？つまり、日本人以外の人間が画面を見たりすることを、最初から考慮して有るんです。従って、画面の表示項目も、英語とに日本語を切り替えたり、も出来るようにしたり。これが、JDEに取り入れられています。残念ながら、その2次言語の指定は、かなりやりづらいのですが、細かな部分まで、徹底していることは事実です。
「JDEに長けた人」とは、つまりは、「どれだけJDEのパラメータに長けた人」か、と言うのと同じ事のようです。いままで求められていた、プログラマーは、不要となります。そのかわり、どれだけパラメータを知っているか、が企業の業務上の問題を解決する上で、重要になってくるようです。プログラムの専門知識は不要で、パラメータの組み合わせ次第で、様々なビジネスに対応するシステムを構築していこう、としているようです。JDEが、多くの国の、多くの会社で採用されているのは、この柔軟性のおかげだと思います。
しかしながら、何でも出来る、と考えるのは早計です。パラメータの中には、動きを制御する部分が有ることは事実ですが、それはあくまで、プログラムが最初から、いくつかの動きを想定して作られており、その限られた動きの中から、一つを選択することが中心です。何も作り込みがないのに、パラメータを指定したら、急に新しい動きをした、と言うことはあり得ません。もしそのように感じたとしたら、隠されたパラメータの値にふれた、だけでしょう。
ある人が、「パラメータは、開発者の自己満足だ。」と言っていました。この言葉で、グサッ、と胸を突かれた開発者もいることでしょう。一面、この指摘は正しいものです。また、一面、これは、永遠の課題（解決できない課題）で有ることも、示唆する言葉でしょう。（つまり、いくらやっても、完璧にならない。出来たと思ったら、それは自己満足にすぎない、ということです）。これを考え出すと、本当にきりがないのです。
HELP機能
システムの中には、ひつこいくらい、操作援助テキストが入っています。画面フィールド、プログラムには、HELPがあって、キーを押せば、操作援助が出てきます。また、この操作援助をサーチする事も出来るようです。JDEに批判的だった、自分は、このHELP機能で、少し、見直しました。まだ、英語だけで、日本語になっていない部分もあるようですが、このしぶといくらいの操作援助は、見習うべきだと思いました。勿論、最初からテキストが入っているのですが（無かったら、意味がない）、この内容も、変更できるようです。また、サーチは、純粋なテキストサーチではなくて、サーチ専用のキーワードを設定して、サーチはその部分に行われます。とても残念な事に、サーチキーワードは、あくまでその言葉に一致するかだけで、OR,ANDの指定や、絞り込みの指定など、は無いようです。また、1次言語、2次言語には分かれていないようでした。
メニュー
メニューは、特に目新しさは感じませんでした。パッケージのメニューでは、標準的機能だと思います。数字を指定すると、登録されていた内容を実行する、メニューの識別子を指定してジャンプ（メニュートラベルと読んでた。）する、コマンドを実行できる、ユーザーによって表示項目を増減する、など。また、変わりどころとしては、%MENUと呼ばれるもの。これは、あたかもバッチファイルのように、登録されたメニューの一個一個を、メニュー単位に、一括して実行できるものです。ただし、途中でエラーが起きた場合は、無視して先に進むそうなので、エラーのハンドリングがなくても問題がない場合に限ります。
参照ファイル
今回のトレーニングで、驚いたのは、この参照ファイルです。偶然ですが、自分がSYSTEM38で仕事しているころに考えて、一部のシステムで行ってきたことと、全く同じなのです。結局、システムの構築とは、膨大な数のフィールドの集合体を作ることなのです。無駄なフィールドはなく、必要なものは取り漏らさず、ファイルによって、その属性がまちまちにならない方法、それは、最終的にフィールド参照ファイルの作成に落ち着きました。ここでは、自分が実践したと時の問題点と、JDEで如何に行っているかを、述べてみたいと思います。
基本的発想は、フィールドの源になるデータの作成を、データ辞書という感じで、DDSを作ります。ここには、フィールド名と、属性と、COLHDGやTEXTを記述します。CRTPFをすれば、そのフィールドの属性が、そのファイルの中に出来ます。目的は、このフィールドにデータを登録することには、ありません。そのフィールドの記述が欲しいのです。このセンターとなる、フィールド記述の参照されるファイルを、「フィールド参照ファイル」と呼びます。システムで使われるファイルは、全てこの参照ファイルを参照します。したがって、同じデータを示すのに、ファイルによって記述が違ったり、属性が違ったりしなくなります。
フィールド名は、自分の場合、xxDTAyという、6バイトで構成しているのですが、DTAはデータの意味を表すニーモニックです（JDEではデータ項目と呼ぶようです。）。xxは、ファイル別のIDで、システムの中でユニークな2バイトです。最後のyは、DTAの続きでもいいし、連番でもいい、というようにしていました。DTAの部分は、場合によって、2バイトになったりもしました。また、xxがどうして2バイトかというと、1バイトでは足りず、3バイトでは多すぎるからです。そして、フィールド参照ファイルには、DTAの部分を登録します。そして、ファイルを作成する場合、xxDTAを参照ファイルのDTAフィールドを参照するように作成するわけです。問題は、この最後のステップで、xxを如何に、楽に決定するかです。フィールド参照ファイルのフィールドを画面に表示して、作成したいファイル名を入れた後、必要なフィールドを画面から選択して、「未使用のファイルID」を探し出して、そのファイルIDxxを指定すると、DDSソースを作るようなものを作りました。これは便利でしたが、大きな問題がありました。このころはAPIがまだ無いころだったので、DSPFFDがひどく時間がかかるのです。そうです。フィールド参照ファイルが巨大に膨れていった為でした。（注意：データは不要なので、CRTPFではMBR(*NONE)を指定します。）
JDEでは、この部分をやはり、ツール化していて、フィールドの命名基準も全く同じです。xxを接頭辞と呼んでいた様です（うろ覚え）。さて、JDEでは、登録されるデータを、アルファベットの範囲指定をして、たとえばAで始まるDTAは、Afile、Bで始まるDTAはBfilへ（実際のJDEとは異なりますよ）作成して、ファイルの巨大化を分散することで、避けていたようです。また、登録されるデータはデータ辞書（DD）と呼ばれ、マスター登録されていくようです。つまり、「参照ファイルを作成するため」のマスターファイルが存在していました。ここで、接頭辞の重複を避けているようです。（ちなみに、xxが重複してしまうと、全く同じ名前のフィールドが、全く違うファイルに各々に存在する事になり、とても、危険です。これを避けるために、xxをつけているのは明白です。）
ディスク上の日付の形式
６桁の数字フィールドを以下のように使用しているそうです。たとえば、１９９９年１月１５日の場合、
| 0 |
9 |
9 |
0 |
1 |
5 |
| 0=1900、 1=2000 |
年下2桁 |
ジュリアンデート |
ドリームライターやワールドライターは、この日付をサポートして、日付範囲の指定ができるようです。印刷でも、きちんと通常の日付に変換して、印刷しています。しかし、このままでは、QRYでは利用できません。指定した日付を、上記の形式にするのは、CVTDATと世紀判定部分をつけることで可能なのですが、（JDE独自の世紀変換をしているので、CVTDATの世紀は使えません。DDの#CYRを参照してください。また、外サブX0028がこの日付のハンドリングをするようです。）、印刷出力として、ジュリアン日を年月日の形式にQRY内部で行うのは難しいです。せいぜい、二次ファイルとして、カレンダーファイルの通算日を使って、該当する日付を取り出すくらいならできるでしょう。でも、日付がいくつもあったら、いくつもカレンダーファイルを定義しなくてはならず、かなり面倒でしょうね。これでいいの？＞JDE
残高移行のバッチ変換方法がJDEから示されない
また、驚くのは、これだけ売れている（らしい）システムなのに、現行システムからの残高や、T/Rの移行の準備がなされていないことです。RPGで、いきなりJDEに書き込むのは危険だという、エンドユーザーの意見が多く（つまり、移行プログラムに、更新や追加を見落としたファイルが有ると不安だ、と言うことらしい。）、それが出来ないのが現状です。その場合、手作業でデータのセットをするのが、唯一の手段の様です。商品マスタ、取引先マスタ、売り掛け、在庫、総勘定元帳、仕訳帳、...これらは、移行する手段が、JDEからは提供されていません。手作業で入力するようです。通常の導入では、決算直後の時期に導入して、残高のみ移行して、期中のログはほとんど無い状態で、カットオーバーしてきたそうです。しかし、今回当社は、10月頃カットオーバーです。決算は12月です。カットオーバーして、12月に、棚卸しやら、決算を迎えるのに、残高のみで、明細データはJDEに入れないそうです。旧システムが明細を提供する、という事らしいです。「馬鹿な」と思うのですが、そうなのだそうです。
どうして、残高移行用のインターフェイスが無いのだろう。だれも疑問に思わないのでしょうか？＞JDE
今のところ
どうも、理念らしきものは見えてきました。なかなか、捨てがたい、いいものも有りそうです。しかしながら、ヘルプの充実や、隠しコマンド、縮小コマンドなど、変に、玄人受けする部分があるだけに（どれだけたくさんの縮小コマンドや隠しコマンドやシステムIDを覚えたか、なんて辺りを、くすぐられるのが好きそうなユーザーがいますよね。たかが、パッケージなのに...）、洗脳されやすい統合パッケージです。もし、口のうまい人が、2時間も説明したら、まっすぐ傾倒するユーザーが出そうな代物です。結果のみを見る人ならば、つまり、プロセスやユーザーインタフェイスなんて無縁の、そう、管理者レベルだと、大喜びしそうなパッケージです。地道にシステムを作っているのが、ばかばかしいくらい、不細工なパッケージです。
残念なのは、最初は、いまより、ずっと良かったような、痕跡が有ることです。多分、最初のフェーズでは、かなり良いものだったのでしょう（勘です）。それが、時間がたち、様々な要求や、開発マシンの変更（多分、System38からAS/400）での、仕様の変更を徹底できなかったり、無理矢理、追加したように見える機能が見受けられることです。前にも書きましたが、ウインドウの下の部分に、「Bottom」とか、「More..」と表示するのですが（OSのまねでしょうが、日本語環境なのに、「続く...」「終わり」ではなく、英語で出ている。）、この「More...」というメッセージの出る部分が、次ページキーを押す度に、最も下の行を、左右に移動します。つまり、サブファイルのSFLEND(*MORE)を使っていません。多分、WINDOWキーワードは使わず、S38の時代から有るウインドウ手法（KEEP,ASSUME,PUTOVR,OVERLAYを利用したもの）を使って、後から無理矢理、下の行に出しているのでしょう。技術者から見れば、すぐに化けの皮ははがれます。JDEの担当者の人で、7年AS/400をやっている人がいました（ということは、AS/400のバージョン1かぁ。最近は、もうSystem38を知らない人の方が多いのかな？）が、よく何とも思わず、平然としていられるなぁ、という気持ちがしました。自分だったら、恥ずかしいです。しかも、変な画面を見たり、オプションを4で選択したり、F12が使えなかったりしたら、悪態をついて、唾棄しそうです。ああ、このとんでもない、パッケージを使っていくのか。暗たんたる未来が、見えてきた。
用語
以下は、JDEの中で出てくる用語です。
DD=Data Dictionary
UDC=User Define Code（汎用のコード定義）
VO=Vocaburary Overide（規定のテキストを一次変更）
FP=Fast Path
DW=Dream Writer
VL=Version List
SVR=Software Version Repository
HS=Hidden Selection
1999/1/31 | 
