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

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

ＮＥＣのオフコン情報掲示板（ノウハウ系）

ＮＥＣのオフコンを活用するためのノウハウを話し合うための掲示板です。

1: ＃ＮＦＣＮＶの制限？(2)   2: LLNIPの印刷(3)   3: ＃ＢＫＵＰでｕｓｂに直接出力できますか？(3)   4: A−VXのプリンタ設定方法が分かりません(2)   5: ＯＳのＣＤについて(4)   6: 初期プログラムに関する質問(4)   7: ボリュームMAPにあるが、#ABCだとファイルがみつからない(2)   8: SYS@DDFの復旧(2)   9: スプールデータの取り出し方法についての質問(10)   10: SG処理にて、PAGW実行中にエラーが発生しました(9)   11: ソースライブラリの一括検索(9)   12: 帳表をＰＤＦ印刷する方法（PRINTVEWを使わず）はありますか(2)   13: SKYLINKでテーブルを検索するとエラーとなる(1)   14: オフコン(3)   15: 管理人さんへの質問です(3)   16: #LTEDITでフォームのソースを指定するとメンバーが見つからないと表示される(4)   17: UPS無しの構成へのシステム移行(12)   18: #NFCNV でパソコンへ転送すると、データの先頭に空白がついてしまう(3)   19: CBL85資産をＯＰＥＮｃｏｂｏｌに移行する(3)   20: COBOLソースから仕様書の鏡作成ツール(3)   21: PrintBridgeの使い方(8)   22: WSエミュレータをWindows7Pro32bitSP1PCにインストール出来なくなった(1)   23: 漢字とANKの縮小印字について(3)   24: #NFCNVで先頭のカラムが０になるのは？(2)   25: N7884-14Bと互換性があるプリンタについて(2)   26: 表示（印刷）を任意の順番にしたいのですが・・・(6)   27: JSまたはPMのコールが間違っています(3)   28: ページプリンターのＳＧ方法(2)   29: SMARTの画面明細項目が終われない(8)   30: ＡＶＸでの外字(槇）について(6)  

 新規投稿 | スレッド表示 | ツリー表示 | 投稿順表示 | i-mode | トップ 
« 1 ... 31 32 33 (34) 35 36 37 ... 108 »

COBOL74とCOBOL85の違い
６４０Ｘｉ 2010-3-26 10:18:00  [返信] [編集]

こんにちは。


先日、温泉好きのうさぎさんから、COBOL74とCOBOL85の
違いを、次のように教えていただきました。

「COBOL85になってからは、64KBを越えたらコンパイラが自動的に
　区分化してしまうので、明示的にSECTIONで分ける必要は無い」

私は、「SKIP」キーと「ENTER」キーの使い分けが可能になっただけと
誤解して、これまで運用してきました。

今更ながら、これ以外にも魅力的な違いがあるのかが知りたいので、
ご存知の方は教えてください。

Re:データ部１単位領域の大きさ
６４０Ｘｉ 2010-3-26 10:03:00  [返信] [編集]

温泉好きのうさぎさん、おはようございます。



本プログラムは、COBOL74で作成されております。

本来であれば、COBOL85へ組み替えしなければいけませんが、

私の怠慢でできておりません。



実は、温泉好きのうさぎさんのご回答の下記仕様を知りませんでした。

とても魅力的ですので、本プログラムと、他にCOBOL74で構築している

プログラムをCOBOL85へ組み替えていきます。



>「COBOL85になってからは、64KBを越えたらコンパイラが自動的に区

> 分化してしまうので、明示的にSECTIONで分ける必要は無い」



有益な情報をありがとうございました。



Re:データ部１単位領域の大きさ
６４０Ｘｉ 2010-3-26 9:58:00  [返信] [編集]

桃太郎さん、おはようございます。

区分化を再度見直し、細分化しましたところ、
エラーがなくなりました。

ありがとうございました。

Re:データ部１単位領域の大きさ
温泉好きのうさぎ 2010-3-26 0:53:00  [返信] [編集]

COBOLの時代なら手続き部での区分化は必要でしたが、COBOL85になってからは、64KBを越えたらコンパイラが自動的に区分化してしまうので、明示的にSECTIONで分ける必要は無いはずです。



従って、#LINKでオーバレイなど特殊なリンク方法をとらないのであれば、手続き部のSECTIONは全て取り払って、区分化をコンパイラにまかせてしまったほうが良いと思います。
Re:データ部１単位領域の大きさ
６４０Ｘｉ 2010-3-25 21:31:00  [返信] [編集]

桃太郎さん、ご回答ありがとうございます。



ご指摘の通り、入力系で、ステップ数が多いものです。

区分化機能は設定していたのですが、もっと細かく区分してみます。



後程、結果を報告します。ありがとうございました。

Re:データ部１単位領域の大きさ
桃太郎 2010-3-25 11:59:00  [返信] [編集]

こんにちは、桃太郎と申します。



もしかしたら、そのプログラムは入力系とかでPROCEDUREのステップ数の

多いものではないですか？



そうだとしたら、PROCEDUREの中で64Kバイトを超えている可能性が考えられます

もしそうだとしたら区分化機能で回避することが出来ます。



PROCEDUREの中をSECTION文で区切るだけです、

詳しくはCOBOL85プログラミング手引書の区分化機能の項をご覧下さい。



参考になれば良いのですけど？

Re:ＣＯＢＯＬ８５のＳＥＬＥＣＴ命令について（再度質問）
温泉好きのうさぎ 2010-3-25 0:45:00  [返信] [編集]

回答できる保証はありませんが、差し支えなければ、もう少し詳しく具体的な内容を教えていただけませんか。

・表定義情報・RDBQでの検索条件
・COBOL(CBL85)のコーディング
・返ってきたエラーコードの値
・その他．．．

同じ環境を構築して試してみます。
Re:データ部１単位領域の大きさ
６４０Ｘｉ 2010-3-24 20:05:00  [返信] [編集]

富山さん、早速のレスありがとうございます。



私も、富山さんと同様に、01レベル１ヶのバイト数が

64Kを超えた場合は、作業領域を分割しています。

（コンパイルエラーが出てから対応していますが。。）



その際のエラーメッセージは、

「F F0041 単位領域の大きさが 64K バイトを超えている」

です。

このエラーメッセージの場合は、どの作業領域がサイズオーバー

かを、コンパイラが行潤・ﾅ教えてくれます。



しかし、今回のエラーメッセージ、

「F N0004 データ部の１単位領域の大きさが 64K バイトを超えた」

は様子が違い、どの作業領域がサイズオーバーなのか教えてくれません。



もしかしたら、確認漏れで01レベル１ヶのバイト数が64Kを超えている

のかも、と、見直してみましたが、制限を超えてはいませんでした。



DATA部全体で 64K を超えるとＮＧなのか？とも思いましたが、

それでは、他のプログラムも余裕で制限を超えてしまいます。



同じようなエラーメッセージですが、２種類あるところから、

意味合いが違うような気もします。



勉強不足ですみませんがヒントでも構いませんので

お気づきの点を教えていただければと思います。

Re:データ部１単位領域の大きさ
富山清風 2010-3-24 19:21:00  [返信] [編集]

苦労していますね。

小生は下記の方法により対応していますが、
６４０Ｘｉさんの場合の当てはまるかどうかは、わかりませんが・・・

内容：
もともと、｢TBL-AREA｣だったのですが「TBL-AREA-1」､「TBL-AREA-2｣、・・・「TBL-AREA-6｣と分けて対応しています。
01レベル１ヶのバイト数が64Kを超えないように分割しています
参考になれば幸いですが・・・

以上



000490 01  TBL-AREA-1.
000500     03  T-O-1           OCCURS 1008.
000510       05  T-GYO         PIC  9(04).
000520       05  T-NO          PIC  9(06).
000530       05  T-SRKB        PIC  X(03).
000540       05  T-TYUNO       PIC  X(07).
000550       05  T-JYUDT       PIC  9(08).
000560       05  T-KTCD        PIC  X(13).
000570       05  T-KTCD-EDIT   PIC  X(18).
000580 01  TBL-AREA-2.
000590     03  T-O-2           OCCURS 1008.
000600       05  T-KTNM        PIC  X(30).
000610       05  T-BHCD        PIC  X(30).
データ部１単位領域の大きさ
６４０Ｘｉ 2010-3-24 18:14:00  [返信] [編集]

いつもありがとうございます。

１点教えて下さい。
COBOLプログラムをコンパイルすると、
「F N0004 データ部の１単位領域の大きさが
64K バイトを超えた」というFATALエラーが発生しました。

本メッセージの通り、データ部は非常に大きいのですが、
どの項目も外すに外せない項目なので苦慮しています。

何とかコンパイルを通したいのですが、裏技などありましたら
教えて下さい。

ＣＯＢＯＬ８５のＳＥＬＥＣＴ命令について（再度質問）
ＥＸＣＨＡＮＧＥ 2010-3-18 20:01:00  [返信] [編集]

＊　どなたかご存じないでしょうか、以前にも質問させて頂いたのですが、再度質問させて頂きます。

＊　以前は出来ませんでしたが現在のＡＶＸＲＤＢにおいては、結合表のセカンダリテーブル上の項目での検索条件指定はＲＤＢＱ２等では可能です。動作を見ているとワークエリアへ一旦出力するするなどの中間処理を経て検索可能です。

＊　またＡＶＸＲＤＢのマニュアルなどにもセカンダリテーブルの項目を検索条件にしたＳＥＬＥＣＴ命令について言及されています。

＊　しかし実際にはＣＯＢＯＬにてＳＥＬＥＣＴ命令の条件指定にてセカンダリテーブルの項目を含めるとデータ数がごく少数の時以外、実行結果が正しくなく、またＦＩＬＥ　ＳＴＡＴＵＳを定義しておくとエラーコードが返されてきます。

＊　ＲＤＢＱ，ＲＤＢＱ２で出来るのに。。という思いがどうしても残ります。

＊　どなたかこの件についてご存じの方はおられないでしょうか？
　　ＮＥＣ側にてバグ有りのまま放置されているのか、それとも何か可能になるような記述指定の仕方があるのか？

＊　ＣＯＢＯＬ上でこれが可能になればデータベースの正規化がぐっとやりやすくなります。

:（ＦＤの変換について）
ＥＸＣＨＡＮＧＥ 2010-3-18 19:43:00  [返信] [編集]

＊　ほいほいさんのＦＤ受渡の前提環境は存じませんが

ＩＢＭフォーマットＦＤ、ＤＯＳフォーマットＦＤ間の媒体での変換は、ＮＥＣが提供するユーティリティ、ＩＯデータ社のＵＳＢ版３モードＦＤ装置などを組み合わせてＰＣ上で可能だと聞いています。

＊　他にもシステムポート社の「仮想ＦＤファイル変換」というシェアウエアがあります。使ったことがないので仕様内容は分かりませんが、なんでもＩＢＭＦＤの内容を圧縮してメールなどで添付送信できるなどと聞いております。なにか使えるかも。。

＊　６００シリーズ＜−−＞６００シリーズ間でしたら最近リリースされた＃ＢＫＵＰディスクバージョンを双方で使って受渡が可能でしょうね。　やったことありませんので実際の事はよくわかりませんが。。



Re:＃ＮＦＬＮＫについて
ほいほい 2010-3-18 9:50:00  [返信] [編集]

皆様ありがとうございました。

結論から言うと、システム構築のときにカンパニなし／セキュリティコードなしで設定がされているようです。

カンパニなし／セキュリティコードありであれば

＃ＯＣＦＭから設定ができ＃ＮＦＬＮＫも使用できると

いう結論に自分の中で到りました。



現在は＃ＯＣＦＭにて登録するときにセキュリティコードがまず

飛ばされます。ＢＫＳＰでカーソル戻して英字１桁＋数字１桁を

入力しても入力エラーとなります。



今回ハードをリプレイスするに当たりＩＢＭフォーマットのＦＤが使えなくなるため、ＰＧでダイレクトにＦＤ読み書きしている

場合、今回＃ＮＦＬＮＫで対応しようと思いましたが

仕方がないのでＰＧでディスクに出力し＃ＮＦＣＮＶで対応する方向で考えます。



Re:RDBQ2について
富山清風 2010-3-18 1:06:00  [返信] [編集]

ご苦労様です。



投稿番号３４６「RDBQでのデータデータディクショナリの分け方」

http://otd10.jbbs.livedoor.jp/286441/bbs_reply?reply=346

回答番号３５２「Re:RDBQでのデータデータディクショナリの分け方」

http://otd10.jbbs.livedoor.jp/286441/bbs_reply?reply=352 が参考になるものと思いますが・・・



概要は以下のとおりです

/ASSIGN EFN=EIGYOU@DDF,OEFN=SYS@DDF;

/RUN RDBQ,DEV=MSD;

/> ;



RDBQ2について
ぅな 2010-3-17 14:24:00  [返信] [編集]

ＲＤＢＱ２でＤＤＦの定義が1000を超えている場合に数字で表の指定が出来なくなりました。

表名(漢字)で指定しても選択されません。

＃ＤＤＭでは表の番号が「０００」と表示されております。

表定義を１０００未満になるように定義を削除すれば良いのですが、平行でプロジェクトが動いているため容易に削除ができません。

お助けくださいれば幸いです。

Re:＃ＮＦＬＮＫについて
温泉好きのうさぎ 2010-3-16 0:16:00  [返信] [編集]

セキュリティコードが未設定ということですから、ローカルのオペレータコードからであっても #OCFM により新しくグローバルのオペレータコードを作成することができます。

グローバルのオペレータコードが未設定あるいは不明なのでしたら、新規にグローバルのオペレータコードを作成し、それで #NFLNK の設定をされてはいかがでしょうか。

#NFLNK 設定後、不要であればそのグローバルのオペレータコードを削除しておけばよいでしょう。

Re:＃ＮＦＬＮＫについて
ほいほい 2010-3-15 11:45:00  [返信] [編集]

グローバルオペレータについて詳細な説明
ありがとうございました。

当社ではカンパニＩＤは設定していません。
＃ＯＣＦＭでオペレータを見たところ４つオペレータＩＤが
存在していますがすべてセキュリティコードは未設定でした。
当然Ｚ９に設定することは出来ませんでした。
最後にもう１つ質問ですがグローバルオペレータは
＃ＯＣＦＭでは見ることが出来ないものであり、
絶対に存在するものなのでしょうか？
単に当社の場合グローバルオペレータが未設定（ありえるのか
どうか分りませんが・・・）ということも考えられます。

最終的にはＳＥに聞く方向しか解決策はなさそうなのは
分りました。


Re:＃ＮＦＬＮＫについて
ＥＸＣＨＡＮＧＥ 2010-3-13 15:56:00  [返信] [編集]

＊　グローバルという用語について私のほうで少し認識違いしていたようですので訂正しておきたいと思います。
説明は単純化していますので、細かい点は省かれています。

＊　まずカンパニＩＤですが、これはファイルやライブラリのグルーピングに使うものなので
　　カンパニＩＤなし（＝カンパニＩＤがスペース２桁、ＣＩＤ＝＾＾）が、カンパニありの上位にあるわけではありません。
Ａ−ＶＸの論理ボリューム（ＭＳＤＸＸＸ）の直下には
例えば、カンパニコードＡＡのファイル群と、カンパニコードＢＢを持つファイル群と、それからカンパニコードなしのファイル群がある、といった具合です。

＊　それから、ファイル、ライブラリ、ライブラリのメンバはそれぞれ（英字１桁＋数字１桁）からなる権限（セキュリティコード）を定義できます。（例：Ａ３）

＊　Ａ−ＶＸにおけるオペレータとはＷｉｎｄｏｗｓで言うところの「ユーザ」、ＡＳ／４００のユーザプロフィールです。
オペレータにはそれぞれ、カンパニＩＤ、セキュリティコード、を付与できます。

＊　例えば、Ｕ０１というオペレータがカンパニＩＤ＝ＣＣ、セキュリティコード＝Ｓ３である場合を考えると、　
Ｕ０１は、　
カンパニーコードＣＣのグループに属するファイルと
カンパニーコードなしのグループに属するファイルが見えている状態になります（つまり、この範囲のファイルを探索できる）

また、Ｕ０１が探索して見つけたファイル、メンバ（実行プログラムも含む）を使用できるかどうかはＳ３というセキュリティコードと照合して判定されることになります。ここでは照合の規則についてはこれ以上立ち入りません。

＊　Ｕ０１は libpath=msd , libpath=msdcc の状態です。
　　ＭＳＤはＭＳＤ０００を含むすべての論理ボリュームです

＊　もし、Ｕ０１に付与されたカンパニＩＤがなし（空白）の場は、カンパニＩＤなしのファイルのみが探索の対象となります。

＊　以上の説明の中で出てきたカンパニＩＤなしのファイルというのがＡ−ＶＸで言うところのグローバルファイル（こちらはファイル！！）と呼んでいる物かと思います。

＊　グローバルオペレータというのは、また別の概念で、
カンパニＩＤがなし（＝空白）で、かつセキュリティコードがＺ９（管理権限）をもつオペレータのことです。
このオペレータはユーティリティなどを使った場合、カンパニＩＤを指定することによって（その都度、絶対パスを指定することによって）あらゆるファイルにアクセス出来ます。

しかしグローバルオペレータにカンパニー配下のディレクトリにたいしてライブラリパスが追加されているわけではありませんので、
　（１）ユーティリティに於いては常にカンパニＩＤの入力が求められる（絶対パスの指定が必要）
　（２）ＲＵＮ＝＾＾＾＾（コマンドプロンプト？）においてはカンパニＩＤなしの領域のメンバしか起動できない。（注１）
　（３）カンパニＩＤありの領域の実行形式メンバ（＝プログラム）をカンパニなしの領域へ移動してきても、プログラムの内部で使われているデータファイルの定義が相対パスなのでデータもカンパニなし領域へ移動し、プログラムでのファイル定義、またはデータベースでの表定義を変更（主にカンパニＩＤというパスを変更）しなければ「ファイルが見つからない」というエラーになるでしょう。


＊　以上まとめですが、
グローバルファイル（カンパニＩＤなし）のファイルは、カンパニをまたいでのファイルの受渡などに使うケースが多いようです。
これは別々のカンパニＩＤをもつオペレータが起動したプログラムから共通でアクセスできる領域だからです。
個々のカンパニコードを持ってＡ−ＶＸにログインしているユーザからは空白以外の別のカンパニ配下にある領域のファイルは見えませんし、絶対パスを指定してアクセスすることも出来ません。

＊　それからだいぶほいほいさんの質問から遠ざかってしまいましたが、＃ＮＦＬＮＫは前述グローバルオペレータ（オペレータのほうです）でないと起動できないみたいなので、カンパニＩＤが空白でかつ、Ｚ９（管理権限）をもつユーザを捜す（もしくはシステムを構築したベンダに問い合わせる）ことが必要でしょうね。

（追記）　（注１）の部分は例外というか指定方法があって起動が可能かもしれません。自信がありません。だれか確実な方がおられましたらお教え下さい。

（さらに追記）　カンパニと言う用語はちょっと不適切な用語かな、と思います。リコーのＲＩＣＯＭのＯＳ「ＣＯＭＰＯＳＳ」で使っていたＧＩＤ（グループＩＤ）のほうが適切な用語でしょうね。（最もこの考え方はＮＥＣからのパクリですけどね）

リコーの場合は、オペレータという考え方がなく、セキュリティの考え方はありませんでした。単にＰＡＳＳの設定です。メニューの定義の中にＧＩＤが記述できて、操作員がジョブメニューから、起動したいプログラムまたは子メニューを番号で選んだ時点で呼び出し側のメニューに定義されたＧＩＤ（グループＩＤ）が付与される、つまりファイルの探索範囲が付与される＝ＰＡＳＳが設定される、というやり方でした。　従って子メニュー、孫メニューと伝っていく毎にＧＩＤを変更することも出来ました。
その点ＮＥＣのは堅い（融通がきかない）なあ。。と思います。

なお、カンパニという用語はＮＥＣも後日不適切と思ったのでしょうね。いつの間にかログイン画面では「部門コード」という名称に変わっています。

Re:＃ＮＦＬＮＫについて
ターラヤン 2010-3-12 0:17:00  [返信] [編集]

ほいほいさん、こんにちは。

グローバルオペレータは、Ａ−ＶＸの管理者権限を持つユーザのことです。
ＷｉｎｄｏｗｓやＵＮＩＸやＯｒａｃｌｅデータベースでも何でも、
管理者用のユーザーアカウントと一般ユーザ用に使うアカウント
がありますよね。
アドミニストレーターとかｒｏｏｔとか言われているものと同じ意味です。

グローバルオペレータなら、一応Ａ−ＶＸのシステム設定をいろいろ
変更するなどいろいろなことができます。
一般ユーザは、いろいろと権限を制限しているので、できることとできない
ことがあります。。
（もちろん設定次第では、グローバルオペレータ並みの権限を持たせる
ことも可能。これは他のソフトやＯＳのユーザアカウントも設定次第で
管理者権限を持たせたり制限したりすることもできるので、同じですよね。）

メッセージの内容から考えて、機能が制限されているアカウント（Ａ−ＶＸだと
オペレータと言う）でＡ−ＶＸに入っているのではないでしょうか。

たぶんほいほいさんのところのサーバーに入っているＡ−ＶＸにも
グローバルオペレータが登録されているはずです。
（無いと管理できませんから。）
カンパニについても、たぶんグローバルオペレータでは、＃ＮＦＬＮＫ
が使えるような状態に設定されているはずです。
（そうでないとグローバルオペレータを使ってサーバーの管理が
できませんから。）
したがって、まずグローバルオペレータのアカウントを探して、そのアカウント
でＡ−ＶＸに入って＃ＮＦＬＮＫを動かしてみることを試みてみるのが
よいのではないでしょうか。


Re:＃ＮＦＬＮＫについて
ＥＸＣＨＡＮＧＥ 2010-3-11 13:14:00  [返信] [編集]

＊　カンパニについての説明は

ターラヤンＴＯＰ　−−＞　Ａ−ＶＸの説明書　−−＞　理論編　−−＞　セキュリティとＯＣＦ　−−＞　３．ＯＣＦ機能　−−＞　　４．カンパニ　を参考になさって下さい。

 新規投稿 | スレッド表示 | ツリー表示 | 投稿順表示 | i-mode | トップ 
« 1 ... 31 32 33 (34) 35 36 37 ... 108 »

BluesBB ©Sting_Band