|
ここまでの予備校では、割合と机上での話ばかりでした。これからは、端末を前に（したつもり）で、受講してください。また、「いつ勉強するのか」といった、問い合わせがありましたが、習得したければ、それなりの努力が必要です。中・上級プログラマーを目指すならば、できる限りのチャンスを生かしましょう。自分の場合、1本5日かかるプログラムを、4日で仕上げ、残った1日を有効利用します。また、サブファイルのプログラムなら、デバッグで納得できるまで、調べ尽くします。また、昼は簡単に済ませ（確か、後半は昼を抜いていた）、残業もサービスにして、機械の前に座って（とにかく端末を長く触ることが、重要だと思います）、勉強していました。（ただし、知らないコマンドは実行しないこと。危険です））今にして思えば、やっぱり、好きだったのですね。嫌々やる仕事では、こんなことできません。
プログラムを作る前に
プログラムを作るためには、サインオンして、ソースファイルに、プログラムのソースメンバーを登録していかなくてはいけません。そこで、プログラミングの前に、しなくてはならないことを、簡単にまとめておきましょう。
端末
大抵は、パソコンで、5250のプログラムを動かすことで、端末として、使えるようになります。5250とは、AS/400の端末用のデータ通信のプロトコル（事前の取り決め条項）のことで、何はともあれ、この5250のプロトコルを守っていれば、AS/400のサインオン画面を出すプログラムを作れます（大抵はIBMが作って、販売しています）。
海外では、IBM以外のメーカからも多数販売されていて、知っているだけでも十数の5250エミュレーション（5250のマネッコと言う意味）のプログラムがありますが、日本では、数は少ないです。代表的には、Windows
+ PC5250（パーソナルコミュニケーションズ5250）でしょう。
DOSでは、5250PC(多分、コンソール以外は、もう無いだろう）、や5250WSくらいです。以上はIBM製品ですが、サードベンダーからも、いくつか、5250エミュレーションが出ています。
ユーザープロファイル
AS/400に貴方が誰なのかを、知らせなくてはいけません。そのため、予め設定しなくてはなりません。そのために、ユーザープロファイルというオブジェクト（タイプは*USRPRF)を、CRTUSRPRF(もしくはWRKUSRPRF)で、予め作成します。これは、いわば、貴方の「戸籍」を区役所に作成するようなものです。ただし、管理上、一つのユーザープロファイルを、複数の人が共有する場合があります。ユーザー名＋パスワードを不特定多数の人々が知っているわけで、機密保護の観点からすれば、あまり好ましくはありません。しかし、ここでは、その功罪を話題にする場ではないので、まあ、管理者の方の指示に従ってください。
ライブラリー
以下の目的のライブラリーが、予め必要です。無ければ、CRTLIBで作成します。大きく分けて、本番環境用ライブラリーと開発途中（開発中のソースファイルやテストのためのオブジェクトを含む）ライブラリーに分かれます。 本番用ソースファイルライブラリー
ここには、本番ソースファイルを作成します。普段のDailyのバックアップ対象ライブラリーです。ただし、変更したソースメンバーのみ保管でもいいと思います。 本番用オブジェクトライブラリー
本番用の、プログラム、画面装置ファイル、印刷装置ファイル、その他、関連するデータベース以外のオブジェクトの収まった、ライブラリーです。普段のDailyのバックアップ対象ライブラリーです。（リカバリーが急を要する場合、コンパイルを待っていられないので、ソースのほかにオブジェクトの保管も必要なのです。）
本番用データベースライブラリー
本番用のデータベース（物理ファイル、論理ファイル）やそのデータと整合性を取るべきオブジェクト（たとえば、データエリアなど）が収まった、ライブラリーです。業務別に分けて作成される場合が多いようです。普段のDailyのバックアップ対象ライブラリーです。
どうして、整合性を取るべきデータをこのライブラリーに入れるか分かりますか？たいした理由ではないのですが、バックアップデータを復元する場合、ライブラリー単位に行うのが楽だからです。考えてもみてください。トラブルの回復のために、保管したものを復元するなんて、普通の精神状態ではないですよ。業務開始をストップさせておいて、オブジェクト1個1個確認しながら、復元するなんて、ゆとりは無いでしょう？そして、もし、データに関連するデータエリアだけ、別ライブラリーにあって、それを復元するのを忘れると、復元しても、業務は完全に戻りません。
例）会計システムで、会計年月をデータエリアに持たせている場合。（データエリアの、CLPで簡単にアクセスできるメリットは大きい。）復元データが、たとえば2000年2月の処置をしているとき（データエリアが、2000年2月になっている）に、訳あって、2000年1月を復元したい場合。データをもどして、データエリアを戻し忘れた場合、2000年1月分の処理をしたいのに、2000年2月を曽y利しようとしてしまう。（大抵、未来の仕分けはOKだが、過去の仕分けはエラーにするはず。この基準をデータエリアに持つとこういうことになる）。
ただし、「わざと」ライブラリーを別にして、データエリアがある場合は、むしろ、復元をしてはならないことがあります。複数のライブラリーで共有されるデータで、1個のライブラリーの復元のために、共有のデータエリアまで復元してしまうと、その他のライブラリーでおかしくなってしまうからです。
このあたりは、プログラムの問題ではなく、「システムのデザイン」の問題です。
|
開発用ソースファイルライブラリー
ここには、開発ソースファイルを作成します。ソースファイルの種類は、あとで説明します。普段のDailyのバックアップ対象ライブラリーです。 テスト用オブジェクトライブラリー
ライブラリーをTYPE(*TEST）で作成すること。これは、後に出てくる、STRDBG（デバッグ機能の開始）に関連しています。省略値が*PROD
(Product；テストではない、生産物用、本番（live）のこと）ですので、*TESTに書き換えて、CRTLIBをすることになります。ここには、作成するプログラム、画面装置ファイル、印刷装置ファイル、さらに、テストデータを含む、すべての物理ファイルと論理ファイルを含みます。もし、ディスクにゆとりがある場合、プログラマー別にこのテスト用ライブラリーがあることが望ましいです。Dailyのバックアップ対象にするかどうかは、記録媒体やバックアップの時間などを考慮して決めます。できるなら、とっておいたほうがいいかもしれません。
ソースファイル
一般的に、ソースメンバーのタイプによって分けているところが多いようです。
| ソースタイプ |
ソースファイル名 |
作成時の長さ |
|
PF/LF |
QDDSSRC |
92 (80+12) |
|
DSPF |
QDSPSRC |
|
PRTF |
QPRTSRC |
|
RPG |
QRPGSRC |
|
RPG IV |
QRPGLESRC |
112 (100+12) |
|
CLP |
QCLSRC |
92 (80+12) |
この他、/COPY用や、大型機のJCLなど、プログラムで参照されるソースや、スクリプト系の言語も別にソースを作るようです。また、この他にも、通信ファイルや、その他の言語（COBOL、PLIなど）もあるでしょう。
私見ですが、上記の、PF/LF以外は、すべて112のレコード長（100＋12）で、一つにまとめた方が開発がしやすいと思います。まあ、このあたりは、オブジェクトの命名基準の設定となり、この予備校としての立場では、突っ込んだ話はしません（というより、できない）。各開発プロジェクト、チーム内での開発ルールに従ってください。
注意：ルールは従ってこそ、ルールとしてまっとうできる物です。従わなければ、ただの、戯言です。
スペックの確認
スペックとは、プログラムの仕様書（RPGの仕様書ではありません。どのファイルの、どのデータを、どうするのか、をまとめた、指示書のようなものです。）のことです。たいていは、システムのデザイナー（SE）が作ってくれているはずです。昔は、字の下手な人も、結構いましたが、最近はワープロか、その類でまとめているようです。重要なことは、理解することです。何をしたいのか、何をすればいいのか、です。SEの人は、ユーザーの「要求」を聞き出して、その対策として、システムを考えます。そのシステムの構成単位のほとんどが、プログラムであり、あなた方が将来作るプログラムです。したがって、そのプログラムの一つ一つには、必ず、存在意義というか、目的というか、を必ず持っているのです。1000個のプログラムの総意がまとまって、ひとつのシステムが有機的に動き始める姿を、なんとなくでいいですから、イメージしてください。その一個のプログラムの目的を知るためには、事前に全体をある程度知らなければならないと、私は思います。何も、その1000個一個一個の説明をしなくてはならない、ということではなくて、システムの概要と、自分のプログラムの所属するサブシステムの動き、あたりは知ってて当然だと思います。
以下の図式を頭に入れておいてください。 ユーザー業務
→ ユーザー不満(業務改善要求) → 現状分析、業務分析 →
業務改善案提案 → ユーザーセッション →
業務改善 改定案 → 承認 → システム概要設計 →
システム詳細設計 → コーディング → テスト → 納品 →
オペレーション、運用指導 大雑把ですが、これが、ひとつのシステム開発サイクルです。ただ、途中の「改定案」は、最初の改善案のままでのこともあります。ソフトハウスにいたころ、セミナーでそのように教わったのですが、まあ、「一般論」なので、ケースバイケースで変わります。 ※ 14.17.System Development Life
Cycleを参考にしてください。 あなたがやるのは、そのうちの、コーディングとテストですね。これらの準備が完了したら、いよいよ、プログラムの作成です。
次回は、実際にサインオンして、プログラム作成に必要なジョブ属性などを勉強して、画面を見ながら勉強しましょう。
起立、礼、着席
続く...
2000-2-6 | 
