Technical FAQ - Net Express (開発環境)

質問一覧:

1.1 旧バージョンCOBOLのインストール環境上での動作について
1.2 環境変数COBDIR、COBCPYの使用方法
1.3 アプリケーション開発の際のファイルについて
1.4 ACCEPT/DISPLAY文使用について
1.5 プロジェクトを複数者での共有はできるか
1.6 プロジェクト上のソース管理
1.7 GNTの生成方法
1.8 ライブラリールーチンPC_PRINTER_SET_DEFAULT がWindows95上で動作しない
1.9 UNIX Option のパブリッシャーが異なるネットワーク間のNAT変換アドレス上で動作しない


1.1 旧バージョンCOBOLのインストール環境上での動作について

質問:

旧COBOL製品がインストールされているマシン上でNetExpressでコンパイルするとエラーがでる。旧COBOL製品がインストールされているマシンにNetExpressをインストールし、旧製品では、コンパイルエラーのでなかった、プログラムをNetExpressでコンパイルしたところエラーが返りました。何故でしょう?

回答・回避策:

この場合、環境変数に、旧バージョンのCOBOL製品がインストールされているディレクトリ(フォルダ)名が設定されているのが影響していると思われます。コンピュータに COBOL V3.1J、V4.0 J またはCOBOL V5.0J などの 32 ビット製品がインストールされている場合、NetExpress を使用するには、NetExpress の使用前に次の環境変数から旧製品への参照を削除する必要があります。

COBDIR、COBLANG、COBCPY、INCLUDE、LIB、OODIR および PATH環境変数を設定すればNetExpressは、Micro Focus の旧製品がインストールされているコンピュータで 使用できるため、ハードディスクから旧製品を削除する必要はありません。また、旧製品を使用するときは、上記の環境変数の設定を復帰してください。

1.2 環境変数COBDIR、COBCPYの使用方法

質問:

環境変数COBDIRとCOBCPYの使用方法は?

回答・回避策:

統合開発環境(IDE)はこれらの環境変数をプロジェクトフォルダに入っていないコピーファイルや呼ばれるサブプログラムを見つけるために使います。NetExpressの「プロジェクト」メニューから、「プロパティ」を選び「環境-IDE...」ボタンをクリックし、「IDE環境設定」ウィンドウで、設定できます。NetExpressの外からの設定は、例えば、Windows95/98の AUTOEXEC.BAT中に設定しておくのも一つの方法です。

「なお、COBDIRにユーザー作製サブプログラムのパスを追加する場合には、必ず Net Express の bin ディレクトリを追加することを忘れないでください。

例) set COBDIR=C:\NetExpress\Base\Bin;C:\Myprgs

1.3 アプリケーション開発の際のファイルについて

質問:

アプリケーション開発にはどのようなファイルが必要なのでしょうか。

回答・回避策:

それぞれのアプリケーションには、次の拡張子を持っている生成されたファイルが必要です。

.app        プロジェクトファイル 
.cbl         CGI ソースプログラム 
.cpy         フォームデータ 
.cpf         ブラウザデータ 
.cpv         妥当性ルーチン コピーファイル 
.mff         妥当性情報とCOBOL属性 
.htm         HTMLページ定義ファイル

1.4 ACCEPT/DISPLAY文使用について

質問:

ACCEPT/DISPLAY を使っているアプリケーションを正しく表示できません。ACCEPT/DISPLAY を使っている .EXE アプリケーションを実行・アニメートした時、DISPLAYで何も表示されません。

回答・回避策:

.exe あるいは .dll ファイルを作成するとき、それがキャラクタベースアプリケーションなのか、グラフィカルアプリケーションであるのかどうか示さなくてはいけません。 もしアプリケーションが ANSI ACCEPT と DISPLAY ステートメントを使い、そして、グラフィカル アプリケーションとしてそれをリンクしていると、実行 
しても何も表示されなくなります。デフォルトはグラフィックになっています。 ここを変更するには、NetExpress の 「プロジェクト」 メニューから 「ビルド設定」 を選び、ビルドタイプが、一般リリースビルドかどうかを 確認して、「リンク」 タブ中の 「インターフェースタイプ」 の 「キャラクタ」 を選び、プロパティウィンドウをクローズし、リビルドして下さい。または、DISPLAY文の前に”DISPLAY SAPCE UOPN CRT”の一文を追加してください。

1.5 プロジェクトを複数者での共有はできるか

質問:

NetExpressのプロジェクトは複数の開発者で共有できますか?

回答・回避策:

残念ながらできません。プロジェクトをマルチユーザーで共有できないのは、現在の NetExpress の重大な制限事項であり、開発部門でも優先的な課題として機能拡張に取り組んでおります。
いずれにしても、ひとつのプロジェクトに対して同時に複数のユーザーが更新をかけに行くのは安全なことではありませんので、誰かがオープンしていたら終わるまで待つような運用にする必要があります。したがって、プロジェクトをネットワーク上の共有ドライブに置いて、誰でも参照できるようにしておくやり方も間違ってはいません。
しかし、管理者が責任を持ってソースの更新リビルドを行い、個別の作業は、管理者からソースを借り出して作業者がそれぞれのローカルなプロジェクトで作業する方法をお勧めします。

1.6 プロジェクト上のソース管理

質問:

NetExpressのプロジェクトはすべてのソースを同じディレクトリに置かなければならないのですか?

回答・回避策:

プロジェクトを実行単位毎に個別に作成する場合、共通の COPY ファイルなどはどのように管理したら良いのかと言う問題が出てきます。COPY ファイルに関しては、環境変数 COBCPY に共通COPYメンバーの置き場所を設定しておくことによって、プロジェクトに含まれていなくてもコンパイラがそこを参照しに行ってくれます。IDE のメインメニューから [プロジェクト] > [プロパティ] で [IDE] ボタンをクリックし、ここで 変数:COBCPY、値:<共通COPYのパス名> を設定して下さい。それ以外のソースメンバーは、プロジェクトディレクトリの直下に置くことが推奨されています。このようにしておくことによって、あとでプロジェクトを丸ごと別のマシンの異なるディレクトリにコピーして移動させることができます。
共通サブルーチンは、それだけを別のプロジェクトに持っておき、そこで保守するという方法があります。この場合、一般リリースビルドで GNT ファイルを作成しておき、そこにある共通サブルーチンを CALL しているプロジェクトでは、環境変数 COBDIR に共通サブルーチンの GNT が置かれているパスを追加指定しておきます。このようにしておくと、共通サブルーチンに対するCALL をステップ実行するとその中にステップインせずに、サブルーチンの内部処理だけを実行して CALL文の次行からアニメートを再開できます。即ち、共通サブルーチンの保守に責任のある人だけがそのソースを持ってデバッグすることができるようになります。

1.7 GNTの生成方法

質問:

「一般リリースビルド」では、EXEができてしまいますが、GNTを作るにはどのようにすればよいのですか?

回答・回避策:

最初に IDEのメインメニューから、[プロジェクト] > [プロパティ] で「EXE/DLLベースプロジェクト」をチェックオフしておきます。次に、一旦右側のソースプールウィンドウ中でマウスを右クリックして「ソースプールへファイルを追加」を選んで、ファイルを追加し、左側のプロジェクトツリービューへドラッグすると、「コンパイルされたファイルタイプを選択」ウィンドウが表示されます。この中の「コンパイル後のファイル名」の項目のところを、マウスの右クリックして「生成コード」を選択してください。 GNTコードがビルドされるようになります。

1.8 ライブラリールーチンPC_PRINTER_SET_DEFAULT がWindows95上で動作しない

質問:

PC_PRINTER_SET_DEFAULT を使用してプリンター出力をしようと思うのですが、出力できません。

回答・回避策:

Windows95にPC_PRINTER_SET_DEFAULTを実行させるための関数が実装されていません。Windows95ではPC_PRINTER_SET_DEFAULTは使用できません。

1.9 UNIX Option のパブリッシャーが異なるネットワーク間のNAT変換アドレス上で動作しない

質問:

異なるネットワーク間をNAT(Network Address Translation) によるIPアドレスの変換を行っている環境下において、UNIX Option のパブリッシャーが起動しないのですが。

回答・回避策:

UNIX Optionが内部で使用している UNIXの Remote Shellプロトコルの制限です。Remote Shellプロトコルは Telnet と異なりユーザー認証が自動的に行われるため、サーバー側からクライアント側のネットワークバックルートが行われます。このため IPアドレス変換されたネットワーク接続には対応できません。

戻る

-----