技術情報 - Revolve - ホストからソースコードをダウンロードする
ホスト上のリソースを転送してＰＣ上メンテナンスを行う場合、様々な考慮すべきポイントがあります。そのためすべて場合に一律に当てはまる方式はなく、既存ツールの組み合わせで対応するユーザーもあれば、新規に転送支援システムを構築するケースもあります。この章ではこうした検討に役立つ技術的な判断基準と実際の手順を以下の構成で提供します。
A. 判断基準
B. 手順
A.判断基準
1. 目的
Revolve の利用目的が明確であれば、そこから要件が決まります。大きく次の２つの場合が考えられます。
- 既存システムのメンテナンスをＰＣ上で実行したい（分析、修正から単体テストまでをＰＣで）
- 既存システムを別環境に移植、あるいは既存システムを再利用して別環境で新システムを構築
メンテナンスの場合
- ダウンロードだけでなくアップロードも発生する。
- メンテナンスのマスターをサーバーに持つのかホスト上に保管するのかでボリューム（転送量）と頻度に影響する。前者なら最初に一回にまとめて大量に転送することになるが、後者ではその都度必要箇所を選んで転送する。
- ソースだけでなくテストデータもダウンロードすることも考えられる。１回当たりのボリュームは、それほど多くない
- １回のソースのアップロードのボリュームは比較的少ないが多頻度ですばやい更新が要求される
移植、再利用の場合
- ダウンロードのみでアップロードは発生しない
- 移植の場合データのダウンロードが重要な課題になる（ボリューム、品質）。
- ソースのダウンロードは一回にまとめて大量に転送することになる。
2. 転送対象
ダウンロードする対象は、開発環境として Revolveだけを導入するのか、あるいはクロス開発用途に Net Express も合わせて導入するかに関係します。又、メンテナンスのためホストで発生した不具合を再現したいという場合や移植、再利用の場合には、テストデータもダウンロードする場合があります。
＜ソース＞常に必要なものは
- COBOLプログラム
- COPY文
- DB2 DCLGEN COPYメンバー
Assemblerソースも適用する場合
- アセンブラ・ソース
- マクロ
IMS 環境にも適用する場合
- DBD
- PSB
- MFS
CICS 環境にも適用する場合
- BMS
テスト準備として
- リンク用パラメータのリスト
- JCL（参照情報として）
- PROCLIB（参照情報として）
- コントロールカード
- テストデータ
3. 転送の方向
- 一方向（ホストからのダウンロードのみ）
- 双方向（ホストからのダウンロードとホストへのアップロード）
双方向の転送の場合は、ホスト側のファイルとの同期に注意する必要があります。例えばプログラムＡのファイルをダウンロードし、修正してホストにアップロードしようとした時、ホスト上のＡがダウンロード後に更新されていたという場合、上書きによってダウンロードからアップロードの間の修正は無効になってしまいます。
4. ボリュームと更新頻度
実用的な転送手段を決定するための要素にボリュームと更新頻度もあります。小ボリューム（１０本以内）のソースを不定期に手軽にダウンロードするにはエミュレータの転送ツールによる対話型のオンライン転送が手軽です。しかし数十本〜のソースの一括転送を何度も実行し、履歴を管理したい場合にはそれなりの転送支援ツールが必要かもしれません。ホストのテープを媒体変換するサービスの提供会社もあり、最初に大量のソースをまとめてＰＣに取り込む方法として、検討の価値があります。
5. 転送データの取り扱い
ホストとＰＣではコード体系の違いによりソースやデータのダウンロード時に注意すべき点があります。
双方向の転送を実行する場合には、ダウンロードでの変換方法を決定する時に、ホストにアップロードする時の書き戻しを考慮しておく必要があります。
拡張子
ＰＣ上ではファイル名と３文字の拡張子でソースを識別します。ソースのタイプごとに拡張子が決められています。
- COBOL･･････.CBL, .COB
- COPY･･･････.CPY, .COP 等
前処理
PANVALET, LIBRARIAN等バージョン管理ソフトウェアでソースを管理している場合、最新のバージョンを取り出し、区分データセットに落としてからダウンロードします。
又、IDENTIFICATION DIVISIONでのPROGRAM-IDとライブラリのメンバー名が一致しない場合があれば、メンバー名に拡張子を付けたものをPCでのソースファイル名として下さい。
シフトコード
ホストとＰＣでは文字コード体系が違うため、エミュレータの転送ユーティリティなどを用いて自動変換を行います。漢字（ＤＢＣＳ）を含む場合にはJISCII（シフトJIS＋ASCII）での転送になります。文字コードの変換で重要になるのは漢字（ＤＢＣＳ）の前後のシフトコードの取り扱いです。転送時に取り除くか非表示文字にするかを選択できますが、取り除いてしまうと７３バイト目以降の連番がずれて構文チェック時にエラーとなる場合がありますので、非表示文字への変換をお勧めします。エミュレータを経由しない転送や媒体変換の場合は、どの段階で何の機能でコード変換をするかを決めておく必要があります。
外字
ホスト上で外字を作成していてプログラム中で使用している場合、コード変換が必要になります。
その他事前変換
ＡＮＳＩ規格あるいはＩＢＭのＣＯＢＯＬに準拠しない記法はコンパイル時にエラーとなる、あるいは警告となって新しい環境では予期した動作をしない可能性があります。又、文法的にはサポートしているVALUE X'nnnnnn'という１６進で書かれた文字列についてはコードが異なり、通常のコード変換では対応できません。変換プログラムを自作する必要があります。
B.手順
1. 前提条件の明確化
前記の技術的な検討も含め、現行の運用状況との関連や投入可能な予算、期日など条件を多角的に検討し、ニーズをどのように満たすかを決定します。
2. ツールの選定、導入
必要に応じ、ハードウェア、ソフトウェアの選定、導入を行います。ダウンロード、アップロードの履歴を管理するために、システムを構築する場合もあります。
3. 運用設計
導入したソフトウェアでパイロット作業を実行し、詳細な利用手順を作成します。
4. 棚卸し、対象選択
対象資源を選択します。ホスト上で選択することもできますが、MicroFocus Revolve も導入されていれば、まとめてダウンロードし、PC上で効率良く棚卸しを支援することも可能です。
5. ダウンロード
選定した手段でPCにダウンロードします。
6. 事前変換
ダウンロードしたソースに事前変換をかけます。
7. 開発環境構築
ダウンロードしたソースを適切なライブラリ配置にして管理します。LAN環境である程度の規模の修正を行う場合は、次のような管理を行う場合もあります。
8. アップロード
修正したソースの事前変換を書き戻し、ホストにアップロードします。
