Google
オフコン練習帳内を検索
インターネット全体を検索

NECオフコン関連
オフコン一般
情報

Re: RDBに項目追加をしたいのですが、DDFの修正方法がわかりません

投稿者: ターラヤン 投稿日時: 2012-5-2 20:12:11

こんにちは。


>・ユーザーDDFに項目追加後、併合は、普通に日中、基幹業務稼働中に実行しても、
>問題ないでしょうか。
>SYS@DDFは、RDBQとかskylinkくらいしか影響はないような気がしますが・・。

業務稼働中はやらない方がよいのではないでしょうか。
WindowsやUNIXでも、日中基幹業務がガンガン動いている最中にOracleの
テーブル作成とかはしないと思います。
併合によって業務に使っているデータが壊れることは無いと思います。
SYS@DDFに併合するということは、SQL文のcreate table xxxに相当するので
単にテーブルの定義を行うだけです。
でも普通はシステムに変更を加えるようなときはバックアップは取っておきますよね。

プログラム開発の順番は自由ですが、普通は以下のような感じで行います。
1.表定義保守(#DDM)の表定義で、ユーザDDFに表&テーブル定義。
2.表定義保守(#DDM)のライブラリ出力で、COBOLのレコード記述項用の
  ソースを出力。
3.COBOLでプログラム作成。このとき2で作ったソースをレコード記述項用と
  してCOPY文記述。
4.表定義保守(#DDM)の併合で、ユーザDDFからSYS@DDFに表定義を併合。
  このとき一緒に実ファイルの領域確保も行う。


1は、これからプログラムを作るので、まだ実業務環境には表定義も実ファイルも作らずに、
準備だけしておく。
2は、1で定義した情報を元にレコード記述項の情報を作る訳で、システム上の情報とCOBOL
プログラム上のレコード記述項の情報を常に一致させるためには必須。レコード定義のCOPYを
手で直したり、直接COBOLソース上に記述したりしていると、プログラムを改修したりした時に、
システムとプログラムのテーブル情報が一致しなくなる原因になります。(とはいえ、レコード
記述項を手で直したりはよくやっていますが。)
実際に実業務環境に組み込んでもOKとなったら、4でユーザDDFの情報をSYS@DDF
に併合することになります。(テスト環境があれば、ユーザDDFからテスト環境のサーバの
SYS@DDFに併合してテスト実施、テスト終了後に実業務環境のSYS@DDFに併合して
運用開始という形になるのかもしれません。)
基本的にこのとき#DDMで実ファイルの領域確保も同時に行います。(#ABCとかで作る
訳ではない)



名前※
題名
メッセージ url email imgsrc image code quote
サンプル
bold italic underline linethrough  



 [もっと...]
パスワード※
オプション ※印の項目をクッキーに保存