|
ここでは、サブファイルを利用した適用業務画面の設計を考えてみましょう。当たり前のことですが、ここですべてのパターンを説明することは出来ませんし、この他に、様々な方法があることを予めご了解ください。
まず、最初に確認しておきたいことがあります。それは、以下のことです。
あくまで、最終目的は、ユーザーフレンドリーな画面を作ることです。なにも、サブファイルによらずとも、それ以外に効果的な方法があれば、それに従うべきです。当然なのですが、最初にそのことを確認しておきます。ここでは、サブファイルのメリットを生かして、どのような応用例があるのか、を考えてみたいと思います。
サブファイルのメリット
-
複数レコードを容易に画面に出せます。
-
表示しないフィールドも、配列を使わなくても、Hiddenフィールドで、レコード単位にメモリに保持できます。
-
READCとSFLNXTCHGを有効利用することで、変更レコードを、効果的に、簡単に取り出せます。
サブファイルのデメリット
-
複数レコードを1画面で処理するため、他のジョブとの整合性が問題になる場合があります。つまり、すでに表示されているものが、ほかのジョブで変更されている可能性がある、ということです。複数レコードすべてに、更新ロックをかけることは、できません。排他の更新ロックは、1つのファイルに1レコードまでです。
-
プログラム内のサブファイルの処理ロジックによっては、レスポンスがひどく悪い場合があります。いきなり、5000件をロードしてから、表示することがあれば、初期の表示までに時間がかかります。見た目が同じでも、内部のロジックで、早くも、遅くもなります。
-
サブファイルは便利な機能ですが、「便利」＝「システムの負荷」であることに注意しなくてはいけません、ひとつのプログラムが、同時に10個のサブファイルを活動させていたら、いいプログラムだと思いますか？
こんなところでしょうか。上に出ている意味はお分かりですよね。まあ、大抵は、複数レコードを画面に出す場合に、まずは使うものでしょう。
サブファイルの3つの基本ロジック
ここで、サブファイルのレコードのロジックを、もう一度、確認しておきましょう。
なお、ここでは、NEWS 3X/400の1993年5月のSubfile Blueprints
(Subfile Encore) by Mr. Wayne Madden
で使われている用語を引用させていただきます。この記事は、非常にサブファイルをきれいにまとめてある、素晴らしいものでした。この記事に、敬意を表して用語を引用しようと考えました。
※ネットーワーク上（news400.com）を探しましたが、古すぎて、この記事を見つけられませんでした。残念です。
|
ロジックのまとめ
この詳細なロジックは、すでに説明をしています。しかし、これらを、そのような局面で使うのが最も効率的か、に関しては、まだ、お話していませんでした。結構多くのサブファイルのプログラムを作ってきたので、その経験を元に、3つのロジックの有効利用を考えてみたいと思います。
なお、老婆心ながら、１つのサブファイルの最大レコード数は、9999件です。
One-Time-Load Subfileの場合
一度に、すべてのレコード、を読み込む方式です。
| 長所 |
短所 |
| もっとも単純なロジック。 |
OSの表示機能をフルに使っているので、資源を食う。
実際のレコードが、変更されても、ロードされたレコードは、変更前のままです。
|
あまりに多くの件数をこの方式で、ロードしようとすると、表示するまでユーザーは長く待つことになります。また、通常、初期ロードで、そんなに大量のレコード件数を蓄える必要が、ユーザー側にも無いはずです。したがって、最初の表示の段階で、すでに、かなり無駄な資源を使うことになります。と、考えていくと、この方式を使えるケースは、かなり、限られてくると思います。件数が、1000件までなら、迷わず、これでしょう。開発効率はいいし、その分、修正も楽です。まあ、1001件はだめかと言うと、そうでもないのですが、大体の目安です(人によっては、100件まで、と言う人もいますが、最近のハードの性能からすると、1000件くらいではないかなぁ)。 また、そのプログラムが、どのくらい多くのユーザーに、同時に使われるのかで、システムに与える負荷も大きくなりますので、そのあたりも見据えて、考えたほうがいいでしょう。注意として、たとえ1000件以内でも、その1件を表示するために、商品マスターから単価履歴をみて、何かしらのステータス判定のために多くのファイルを参照しなくてはいけないとすると、たった一件のために、異常な負荷をCPUにかけることも在ります。こんなときに、紋切り型に1000件と決めるのも、本当は、いけないことなんですけど、目安として、考えてください。
また、ファイル全体を一括処理したい場合（一括更新してから、全レコードの最終合計を処理したい場合など）も、この方式が便利です。なぜなら、すべてのレコードがAS/400のメモリ上に展開されているから、プログラムを作り易いのです。しかし、当然、この場合でも、最大レコード数は、1000件以内を目安に、考えたほうがいいでしょう。
例
「ひとつの」オーダーに含まれる、明細を表示したい場合
あくまで、１つのオーダーです。オーダー（のヘッダー）の件数は、1000件を超えるでしょうが、ひとつのオーダーに含まれる明細が1000件以上ということが（多分）ほとんど無いはずなので、明細を表示するだけならば、この処理方法で十分です。それに、オーダーの明細件数が、将来のシステム変更で、いきなり、10倍以上になることは無いでしょう。大抵、行番号って、3桁くらいではないですか（つまり001から999件）？もし、これが、4桁だと、サブファイルの限界ですね。また、オーダー行の金額などをプログラム内部で、集計して、画面に出す場合を考えても、この方法がベストです。これ以外の方法だと、その合計金額のために、結局全レコード読み込むことになります※。
※ただし、まあ、大抵は、ヘッダー（いわゆる鏡）とデテールに、ファイルが分かれていて、ヘッダー内部に合計金額があるはずなので、いちいち全件読む必要は、無いはずですが...このサイトも、「初心者です」と、正直に断ってメールを下さる方もいるので、はっきり言いますが、上記のように、表示プログラムで集計しなくてはいけない状況（実はそういうプログラムを修正したことがあります。いるんですよ、そういう設計をする人が！）は、はっきり言えば「DB設計のミス」です。プログラムのロジックに精通しないと、「無理やり」達成するプログラムが現れて、まあ、「失敗作」と言う感じのシステムができてしまいます。システムデザイナーやデータベースデザイナーを目指す方は、まず、確実にプログラム経験が豊富でなければ、ろくな物を作りません。きつい言い方ですが、事実です。「下積み」が長いほうが、先見の明を養えるのです。頑張りましょうね。
コラム
なお、最初は、500件くらいのレコードの表示のつもりでいたら、システムの変更で、そのプログラムが表示する件数が、一気に、5000件以上になり、表示が遅いために、修正を余儀なくされた実例があります。たとえば、１セクションだけで見るマスター照会があったのですが、ある時のシステム変更を境に、そのプログラムが参照するマスターの内容が、全セクション対象になったため、一気にレコード件数が10倍上に膨れ上がってしまった、何てこともあるわけです。 |
Extending Subfileの場合
自動的に拡張される機能を利用した、サブファイルです。
| 長所 |
短所 |
| 初期ロードに時間がかからないので、表示が速い。 |
One-Time-Load Subfileに比べると、やや、作成が難しい。
ロールアップを多くして、多数のページをロードしてしまうと、その分、資源を食う。
実際のレコードが、変更されても、ロードされたレコードは、変更前のままです。
|
呼び出されたプログラムは、まず、初期ロードすべきレコードを、ユーザーが最初に見る、1ページ分だけに、限って行う、。最初にページが出た時点では、2ページ以降は、まだ書き出されていません。ユーザーが、さらに「見たい」と考えて、「次ページ」を押すと、初めて、次のページ分のレコードをロードして、表示します。つまり、ロードにかかる時間は、1ページ分をロードする時間と、ほぼ同じになります。たとえば、1ページ10件のレコードを表示する場合なら、たとえ全体で、5000件のレコードが在っても、表示そのものは、10レコード単位のものになりますので、きわめて、ロードが早くなります。この方法は、非常に効果的です
私の場合、この方式の利用は、とても多くて、多分7割から8割は、このやり方でしょう。レコード件数が、500件以上で、ロールアップを400回以上（笑）押さない（最大9999件なので）しないだろう、という場合、この方式を使っています。採用の理由としては、初期ロードに時間がかからず、また、9999件まで、表示するユーザーは、確率的に、ほぼ0です。（これは、私個人の意見ではなく、News
Groupでも、同じ意見が見られました。）
ここで注意したいのは、このサブファイルには、全件のレコードが入っているとは、限らないと言うことです。サブファイルのレコードのみ集計して、合計を出したりして、いきなり、本来の合計と、プログラムが算出した合計が合わない、なんてこともあるわけです。たとえば、5000件のレコードがある場合、サブファイルにロードされたのが100件くらいで、本来5000件の合計なのに、プログラムが出した合計が、100件分でした、なんて、ことがあります（恥ずかしながら、自分もやったことあります）。デバッグで気が付くでしょうが、まれに、テストのレコード件数が少ないと、このバグに気が付かないこともあります（テストデータが20件くらいでは、いつでも、全レコードがメモリ展開されているので...）。
例
大量オーダーの選択画面につかう。
たとえば、出荷オーダーの一覧を表示して、その中から選んだ、オーダーの明細を表示する場合、
ユーザーは、当然、気が付かないでしょうが、複数レコードを処理する局面を、各々分けて考えています。これが最も合理的だと思います。モジュールを完全に分けて考えているので、この場合、2つのプログラムに分けています※。この方が、デバッグもし易いし、機能拡張（オプションの追加など）も簡単です。
※プログラムを分けるとは、たとえば、イメージとしては、PDM
(WRKPDMMBR)
を思い浮かべてください。そのソースメンバーの一覧を出す部分は、初期表示が速いようにExtending
Subfileにして、そこからのオプションで呼び出される機能は、すべて別個のプログラムにすると言うことです。つまり、その一覧表示のプログラムは、サブファイルの処理をしてからは、オプション分のCALL命令を持っていることになります。使われるか分からないオプションのプログラムを組み込んでしまうと、その一覧表示プログラムを呼び出すだけで、無駄な資源を使ってしまいます。（資源、資源って、けち臭いようですが、やっぱ、考えたほうがいいと思います。）
下図は、初期ロードにかかる時間を比較したものです。Extending
Subfileの形式では、On-time-loadに比べて、1ページあたりのロード時間が、やや、長くなっています。体感的にはほぼ同じですが、少しだけ、違うのも事実です。
One-Page-at-a-Time Subfile (パターン3)
1ページ単位にサブファイルを作成して、表示する方式です。データが書かれた長い紙テープの上を、大きさが固定された枠が、するすると、その紙に沿って動いているイメージです。
| 長所 |
短所 |
| 最も、実行効率がよく、すばやい動きとなる。 |
最も作成が難しい。
たった1ページ分、実際のレコードが、変更されても、ロードされたレコードは、変更前のままです。
マルチページレコード選択の場合、処理を考える必要がある。
|
これは、サブファイルの最大のレコードサイズを、1ページ分のレコードと限定して、画面には、とにかく1ページ分のレコードだけを表示します。最も効率がいい方式です。その代わり、「手軽な」サブファイルのイメージとは、かけ離れて、プログラム作成は難しくなります。さらに、ページをまたがって、レコードを選択（オプション入力など）をする場合、選択したレコードのキー情報などを、すべてを配列などに保管して、実行キー押下とともにそこから情報を取り出していくか、さもなければ、マルチページレコード選択は放棄してしまうか、のどちらかになります※。私は、後者を選んでいます。マルチページレコード選択は、極端に言えば、あるページのたった一つのレコードをオプション指定して、そのまま次のページの別のレコード選択をすることができる、ことです。この、全ページのレコード選択を保存して、次ページのレコード選択へ、進む、と言うのは、このOne-Page-at-a-Time
Subfileでは面倒な物になります。ですので、一回の作業に、1ページ以内の複数レコード選択で可能な場合のみ、このOne-Page-at-a-Time
Subfile方式を採用しています。
 追記 2000-9-10
※マルチページ対応をOne-Page-at-a-Time Subfileでする場合、選択した内容の退避保管は、配列またはオカレンスなど、と使えますが、気をつけなくてはいけないことは、対象となるファイルのレコード数が、表示中に、増えたり、減ったりする場合です。このときに、ロールアップしてからロールダウンで戻った場合、サブファイル上のレコードと、配列の要素との結びつきが切れてしまうため、不具合となります。変動レコードを使う場合は、ファイルのユニークなキー項目を使える場合に限られるでしょう。どちらにしても、面倒ですね。
自分なりに考えているのは、データ件数に関わらず、「データ変動が頻繁」で、マルチページレコード選択が重要でない場合、このOne-Page-at-a-Time
Subfileを使っています。データ変動が頻繁の場合に困るのは、サブファイルで表示してしまったデータが、古くなっていると言うことです。複数のレコードを一気に画面に表示するサブファイルの場合、必ず、表示した直後から、データは古くなっているんだ！という危機感をもっていたほうがいいと思います。このOne-Page-at-a-Time
Subfileだと、一度に1ページだけですので、古くなったページのリフレッシュが、頻繁に行われるので、古いページをユーザーが見る確率が、きわめて低くなります（確率がゼロではありませんが...）。
また、この方式の魅力は、最大サブファイルレコードサイズが、1ページ分だけなので、表示対象のレコードが事実上無限に等しいと言うことです。9999件を超えるデータはAS/400では決して珍しくはありません。またユーザーによっては、必死にデータを追いかけるために、サブファイル最大レコード件数9999件まで、ロールアップをしないと言い切れない場合、このOne-Page-at-a-Time
Subfileを使っています。
例
実際変動が多いもので、マスター保守や、残高参照などがあるでしょう。
ただし、メンテナンスする人が一人だけとか、残高が変動するのが、夜間に一回などと言うと、One-Page-at-a-Time
Subfileがプログラム的に難しい部分（あのページのソースをコピーしてしまえば、簡単ですが）もあるので、ExtendingSubfilのほうが有利でしょう。 プログラム作成の前に、どのサブファイルの方式でやるのか、という比較考量は、とても、とても、大事なことです。
また、データの書き出しも、1ページのレコード分ごとで、問題ない場合、はこの方式が楽です。但し、1行のエラー検査を、サブファイル内で済ませたい場合、メモリにロードされたレコード内容を参照できるほうが、いいかもしれません。また、1ページ単位に、たとえば10件、10件、10件とデータが増えていくよりも、いきなり30件書き出しの方がいい場合もありえます。そこを考えると、一概に言うことはできません。ケースバイケースで考えるしかないようです。
簡単なDecision Path
このページも大きくなってきてので、続いての、サブファイルの画面構成や、実例は、第2部にまわします。
続く...
2000-9-5
| 
