●こないだの投稿
ＲＰＧサイクルに苦戦でお話ししたように
IBM AS/400のプログラミング技法のひとつにＲＰＧサイクルって言うのがあります
前職では、聞いた事があるだけで使う事も覚えることもありませんでした
●名前だけ知ってる
ところが、現職ではお客様のシステムも改修する必要があり
その中にＲＰＧサイクルを使用したプログラムも存在していました
●ゲッ
もう、ほんと、なんでこんなの使ってんだろ？って
心の中でブツブツ文句を言いながら、まずはプログラムコードの解析
でも、読めば読むほどわからない（笑）
●相談
木曜日、同僚の一人に聞いたら、大体わかるけど１からプログラミング出来ない
金曜日、もう一人に聞いたら、ネットで調べてくれて自分の知識と合わせてこんな感じって
そして、二人の同僚とわいわい話してましたが大体の流れが分ったぐらいで（笑）
●１日勉強
でも、概要が分ったら、その後は経験を頼りにＩＢＭのマニュアルを解説したサイトで（笑）
（マニュアルに解説が必要になるって…なんて難解なんだろう？）
確かに金曜日の同僚も『これは難しいパターンのＲＰＧサイクル』って
解析中のソースを見て言ってました(笑)
私は、ＲＰＧサイクルは初心者なのにーーーーって思いました
まぁ、金曜日は１日勉強して、何となく理解できたので
改修を開始
理解したら早いもので、改修は１０分で完了（笑）
●便利だ
ＲＰＧサイクルって確かに良く考えられてる
理解すればこれは随分と便利な技法だと思います
印刷アプリなら、大抵はこれを使えば済むのでは？
しかも、簡単な設定並みのコーディングで
ただ、簡単なのは量で、そのコードを読むのは大変
しっかりとした仕様書が無いと、暗号を読んでいるみたいで
なので、開発する時には便利だけど、保守とかデバッグは困難を極めるって感じ
●私は、全手順派
全手順とは、コンパイラにプログラム制御を任せるのではなくて
全て（データベースや画面への入出力）を一つ一つコードで記述す方法
ＲＰＧの簡略化されたプログラムコードに対して、全手順って言われます
この方法が、最初はめんどくさいけど、後のメンテナンスは簡単
デバッグも簡単
これは、超重要です
しかも、全手順でもそれほどコードが増えるとは思えません（笑）
まぁ、それゆえに前職では避けてたんですけどね
●でも、今は・・・
新規で簡単な印刷アプリを開発する場合
私なら、全手順方式を使用します
だって、車だってオートマよりマニュアルの方が好きだもん（笑）
人気ブログランキング
" allowfullscreen>【このカテゴリーの最新記事】
-
no image
-
no image
-
no image
-
no image
-
no image
やはり、全手順派でしたか（笑）
ＤＢが内部記述って・・・・それは私には太刀打ちできません・・・きっと
RPGのF〜I仕様書の例を載せてくださっていますが、私には暗号の様でさっぱりわかりません（笑）
RPGサイクルは標識も多用していますよね。
3月5日に発覚したんですが、お客様のプログラムコードでRPGサイクルを多用していて、昨年から今年１月にかけてベンダーに変更してもらったらしいんです。 このコードを今私がメンテナンスかける事態になっています😨
ただ、そのベンダーさん、RPGサイクルで作成されたアプリを改変するのはいいんですが、標識の使い方がチャランポランで、良く分かっていないような感じでアプリの変更をしてしまっています。 なので、たまに訳の分からない伝票・・・ヘッダーが出力されておらず明細行だけの伝票がごくたまに印刷されます。
なので、頻度の低い条件が成立した時に、標識の使い方のヘボっているところで、本来出力すべきヘッダーが出力されていない・・・そんな気がします。
私もあーでもないこーでもないと数日勉強してみました。
確かに、ＲＰＧサイクルは作りやすいように考えられていますが・・・保守は困難ですね。加えて他人の開発したプログラムでは暗号の塊のように思えて、改修しなければならない時は、全手順で１から開発した方が今後のためには良いような気がします（笑）
ちなみに、このお客様のプログラムコードに抱えるバグは、瑕疵担保責任の契約により、そのベンダーが責任をもって回収しなければならないわけで、私が手を出すことはできません。残念ですが（笑）
それから、最後のREADEを知らないって件・・・新大阪から東京に行くときに、新幹線特急券をもっているのに、在来線の各駅停車を乗り継いで目的地を目指している・・・そんな条件が思い浮かびました(笑)
いずこも大変ですね。
RPGサイクルの先生ではなくて・・・サイクルを書くのがいやなので自動作成を作っただけで（それも30年くらい前）その後、ほぼ作ってなかったんですが。。。
昨年転職した会社のシステムで多用されていて、しかもＤＢが内部記述と来てます。
↓ある得意先の請求書を出力するRPGのＦ〜Ｉ仕様書
FFILE IP F 128 DISK
IRECNAME NS 12 1 CR 2 CN 27 CS
OR 13 1 CR 2 CN 27 CC
OR 14 1 CR 2 CN 27 CF
OR 15 1 CR 2 CN 27 CZ
このあと長〜い DSの記述（I仕様書）
標識も多用されてもう何がなんだか・・・って感じです（笑）
データの構造上、あまり累積されたＰＦが無いんですよね。
だから全件を読んで 一括に項目をクリアするなんて時には
UPの指定とMOVE*BLANKとUPDATで出来上がり。
（条件がある時は、ＩＦ文で囲うだけ）
全手順でも SETLLした後、READE せず READして
キーが変わったら手動でEOF標識ＯＮしてます。READE知らんの？て聞いてみたいけど
退職済みなので聞けない（泣）