ＮＥＣのオフコン情報掲示板（ノウハウ系）
| ＮＥＣのオフコンを活用するためのノウハウを話し合うための掲示板です。 |
| 新規投稿 | スレッド表示 | ツリー表示 | 投稿順表示 | i-mode | トップ |
| ■▲▼ | ||
| 1 | COBOL74とCOBOL85の違い | |
| ６４０Ｘｉ 2010-3-26 10:18:00
[返信] [編集] こんにちは。 先日、温泉好きのうさぎさんから、COBOL74とCOBOL85の 違いを、次のように教えていただきました。 「COBOL85になってからは、64KBを越えたらコンパイラが自動的に 区分化してしまうので、明示的にSECTIONで分ける必要は無い」 私は、「SKIP」キーと「ENTER」キーの使い分けが可能になっただけと 誤解して、これまで運用してきました。 今更ながら、これ以外にも魅力的な違いがあるのかが知りたいので、 ご存知の方は教えてください。 | ||
| 2 | Re:COBOL74とCOBOL85の違い | |
| 富山清風 2010-3-26 12:08:00
[返信] [編集] マニュアル：ＣＯＢＯＬ８５プログラミング手引書 の 付録Ｂ：ＮＡＴＩＶＥモードとＣＯＢＯＬ７４モード差異比較 あたりが参考になるかも。 | ||
| 3 | Re:COBOL74とCOBOL85の違い | |
| ６４０Ｘｉ 2010-3-26 17:54:00
[返信] [編集] 富山さん、コメントありがとうございます。 早速マニュアルを確認しました。 いかにマニュアルを読んでいないかがバレバレですね（汗） 今後の開発の参考にします。 ありがとうございました。 | ||
| 4 | Re:COBOL74とCOBOL85の違い | |
| あか 2010-3-31 12:45:00
[返信] [編集] 大昔、汎用機で開発やってた時にコンパイラをCOBOL85に切り替えたらEVALUATE文が使えるようになってた記憶がありますが、74でも使えてたんでしょうか？・・・ その前はCだったので、「COBOLにはCASE文がないの？」って思ってました。 | ||
| 5 | Re:COBOL74とCOBOL85の違い | |
| ＥＸＣＨＡＮＧＥ 2010-4-1 19:30:00
[返信] [編集] ＊ 多分使えなかったのではないでしょうか？ ＊ ＩＦ （条件１） （絶対命令の列１） ＥＬＳＥ ＩＦ （条件２） （絶対命令の列２） ＥＬＳＥ ＩＦ （条件３） （絶対命令の列３） ＥＬＳＥ （絶対命令の列４） 「ピリオド」 などいった表現で行くしかないでしょうね。。 ＊ あと、ＣＡＳＥ構造とかいって ＧＯ ＴＯ ラベル１ ラベル２ ラベル３ ＤＥＰＥＮＤＩＮＧ ＯＮ Ａ． ＧＯ ＴＯ ラベル４． ラベル１ （記述の列１） ＧＯ ＴＯ あっちの方 ラベル２ （記述の列２） ＧＯ ＴＯ あっちの方 ラベル３ （記述の列３） ＧＯ ＴＯ あっちの方 ラベル４ （記述の列４） あっちの方． （続きの記述。。。） ＊ いずれも ４の部分が ＷＨＥＮ ＯＴＨＥＲ に該当します。 ＊ 当時のオフコンはＣＯＢＯＬといっても ＵＳＡＣのオフコンのＣＯＢＯＬなんて ＩＦ （条件） （絶対命令）． だけて、ＥＬＳＥ以下が記述できなかったり、 ＰＥＲＦＯＭ （サブルーチン）． だけで、ＵＮＴＩＬ などが記述できなかったり 等々、きわめて低水準だったと思います。 ＊ その点、ＮＥＣはマシだったのだろうか？ 当時はＮＥＣのマシンなど高価な物はさわったことが ありませんでして、ＣＯＢＯＬ以前のアセンブラや 独自言語みたいな物しか使えないマシンを 使っておりましたゆえ、よく分かりません。 | ||
| 全部読む 最新50 1-100 板のトップ リロード | ||
| ■▲▼ | ||
| 1 | データ部１単位領域の大きさ | |
| ６４０Ｘｉ 2010-3-24 18:14:00
[返信] [編集] いつもありがとうございます。 １点教えて下さい。 COBOLプログラムをコンパイルすると、 「F N0004 データ部の１単位領域の大きさが 64K バイトを超えた」というFATALエラーが発生しました。 本メッセージの通り、データ部は非常に大きいのですが、 どの項目も外すに外せない項目なので苦慮しています。 何とかコンパイルを通したいのですが、裏技などありましたら 教えて下さい。 | ||
| 2 | Re:データ部１単位領域の大きさ | |
| 富山清風 2010-3-24 19:21:00
[返信] [編集] 苦労していますね。 小生は下記の方法により対応していますが、 ６４０Ｘｉさんの場合の当てはまるかどうかは、わかりませんが・・・ 内容： もともと、｢TBL-AREA｣だったのですが「TBL-AREA-1」､「TBL-AREA-2｣、・・・「TBL-AREA-6｣と分けて対応しています。 01レベル１ヶのバイト数が64Kを超えないように分割しています 参考になれば幸いですが・・・ 以上 | ||
| 3 | Re:データ部１単位領域の大きさ | |
| ６４０Ｘｉ 2010-3-24 20:05:00
[返信] [編集] 富山さん、早速のレスありがとうございます。 私も、富山さんと同様に、01レベル１ヶのバイト数が 64Kを超えた場合は、作業領域を分割しています。 （コンパイルエラーが出てから対応していますが。。） その際のエラーメッセージは、 「F F0041 単位領域の大きさが 64K バイトを超えている」 です。 このエラーメッセージの場合は、どの作業領域がサイズオーバー かを、コンパイラが行潤・ﾅ教えてくれます。 しかし、今回のエラーメッセージ、 「F N0004 データ部の１単位領域の大きさが 64K バイトを超えた」 は様子が違い、どの作業領域がサイズオーバーなのか教えてくれません。 もしかしたら、確認漏れで01レベル１ヶのバイト数が64Kを超えている のかも、と、見直してみましたが、制限を超えてはいませんでした。 DATA部全体で 64K を超えるとＮＧなのか？とも思いましたが、 それでは、他のプログラムも余裕で制限を超えてしまいます。 同じようなエラーメッセージですが、２種類あるところから、 意味合いが違うような気もします。 勉強不足ですみませんがヒントでも構いませんので お気づきの点を教えていただければと思います。 | ||
| 4 | Re:データ部１単位領域の大きさ | |
| 桃太郎 2010-3-25 11:59:00
[返信] [編集] こんにちは、桃太郎と申します。 もしかしたら、そのプログラムは入力系とかでPROCEDUREのステップ数の 多いものではないですか？ そうだとしたら、PROCEDUREの中で64Kバイトを超えている可能性が考えられます もしそうだとしたら区分化機能で回避することが出来ます。 PROCEDUREの中をSECTION文で区切るだけです、 詳しくはCOBOL85プログラミング手引書の区分化機能の項をご覧下さい。 参考になれば良いのですけど？ | ||
| 5 | Re:データ部１単位領域の大きさ | |
| ６４０Ｘｉ 2010-3-25 21:31:00
[返信] [編集] 桃太郎さん、ご回答ありがとうございます。 ご指摘の通り、入力系で、ステップ数が多いものです。 区分化機能は設定していたのですが、もっと細かく区分してみます。 後程、結果を報告します。ありがとうございました。 | ||
| 6 | Re:データ部１単位領域の大きさ | |
| 温泉好きのうさぎ 2010-3-26 0:53:00
[返信] [編集] COBOLの時代なら手続き部での区分化は必要でしたが、COBOL85になってからは、64KBを越えたらコンパイラが自動的に区分化してしまうので、明示的にSECTIONで分ける必要は無いはずです。 従って、#LINKでオーバレイなど特殊なリンク方法をとらないのであれば、手続き部のSECTIONは全て取り払って、区分化をコンパイラにまかせてしまったほうが良いと思います。 | ||
| 7 | Re:データ部１単位領域の大きさ | |
| ６４０Ｘｉ 2010-3-26 9:58:00
[返信] [編集] 桃太郎さん、おはようございます。 区分化を再度見直し、細分化しましたところ、 エラーがなくなりました。 ありがとうございました。 | ||
| 8 | Re:データ部１単位領域の大きさ | |
| ６４０Ｘｉ 2010-3-26 10:03:00
[返信] [編集] 温泉好きのうさぎさん、おはようございます。 本プログラムは、COBOL74で作成されております。 本来であれば、COBOL85へ組み替えしなければいけませんが、 私の怠慢でできておりません。 実は、温泉好きのうさぎさんのご回答の下記仕様を知りませんでした。 とても魅力的ですので、本プログラムと、他にCOBOL74で構築している プログラムをCOBOL85へ組み替えていきます。 >「COBOL85になってからは、64KBを越えたらコンパイラが自動的に区 > 分化してしまうので、明示的にSECTIONで分ける必要は無い」 有益な情報をありがとうございました。 | ||
| 9 | 区分化の件、 | |
| 桃太郎 2010-3-26 15:39:00
[返信] [編集] 温泉好きのうさぎさん、こんにちは。 3100時代にCOBOL85で64KBを超えたらエラーになっていたので、 そう思っていましたが、温泉好きのうさぎさんのコメントを読んで 改めて現在の600で同じプログラムをSECTION文を外して 同じパラメーターでコンパイルしてみたところ、 エラーが出ないですね、 良いことを教えて頂き、ありがとう御座います。 長年携わっていると、思い込みと惰性で仕事をしているものですから(^^ゞ | ||
| 全部読む 最新50 1-100 板のトップ リロード | ||
| ■▲▼ | ||
| 1 | ＣＯＢＯＬ８５のＳＥＬＥＣＴ命令について（再度質問） | |
| ＥＸＣＨＡＮＧＥ 2010-3-18 20:01:00
[返信] [編集] ＊ どなたかご存じないでしょうか、以前にも質問させて頂いたのですが、再度質問させて頂きます。 ＊ 以前は出来ませんでしたが現在のＡＶＸＲＤＢにおいては、結合表のセカンダリテーブル上の項目での検索条件指定はＲＤＢＱ２等では可能です。動作を見ているとワークエリアへ一旦出力するするなどの中間処理を経て検索可能です。 ＊ またＡＶＸＲＤＢのマニュアルなどにもセカンダリテーブルの項目を検索条件にしたＳＥＬＥＣＴ命令について言及されています。 ＊ しかし実際にはＣＯＢＯＬにてＳＥＬＥＣＴ命令の条件指定にてセカンダリテーブルの項目を含めるとデータ数がごく少数の時以外、実行結果が正しくなく、またＦＩＬＥ ＳＴＡＴＵＳを定義しておくとエラーコードが返されてきます。 ＊ ＲＤＢＱ，ＲＤＢＱ２で出来るのに。。という思いがどうしても残ります。 ＊ どなたかこの件についてご存じの方はおられないでしょうか？ ＮＥＣ側にてバグ有りのまま放置されているのか、それとも何か可能になるような記述指定の仕方があるのか？ ＊ ＣＯＢＯＬ上でこれが可能になればデータベースの正規化がぐっとやりやすくなります。 | ||
| 2 | Re:ＣＯＢＯＬ８５のＳＥＬＥＣＴ命令について（再度質問） | |
| 温泉好きのうさぎ 2010-3-25 0:45:00
[返信] [編集] 回答できる保証はありませんが、差し支えなければ、もう少し詳しく具体的な内容を教えていただけませんか。 ・表定義情報・RDBQでの検索条件 ・COBOL(CBL85)のコーディング ・返ってきたエラーコードの値 ・その他．．． 同じ環境を構築して試してみます。 | ||
| 全部読む 最新50 1-100 板のトップ リロード | ||
| ■▲▼ | ||
| 1 | RDBQ2について | |
| ぅな 2010-3-17 14:24:00
[返信] [編集] ＲＤＢＱ２でＤＤＦの定義が1000を超えている場合に数字で表の指定が出来なくなりました。 表名(漢字)で指定しても選択されません。 ＃ＤＤＭでは表の番号が「０００」と表示されております。 表定義を１０００未満になるように定義を削除すれば良いのですが、平行でプロジェクトが動いているため容易に削除ができません。 お助けくださいれば幸いです。 | ||
| 2 | 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; /> ; | ||
| 全部読む 最新50 1-100 板のトップ リロード | ||
| ■▲▼ | ||
| 1 | ＃ＮＦＬＮＫについて | |
| ほいほい 2010-3-10 1:43:00
[返信] [編集] このような掲示板があることを今知って 早速質問させてください。 ファイル連携機能というものが存在することも 最近知ったので＃ＮＦＬＮＫで登録しようと したのですが、＃ＮＦＬＮＫを起動したところで 「使用することができません」のメッセージが出ます。 ファイル連携機能を使用するのに３つのファイルが 必要なようですが、SYS@CAT、SYS@DDFともう１つのファイル すべて一応定義はされています。 根本的に何が問題かおわかりの方教えてください。 なおもう少し情報が必要であれば、会社の方でまた 書き込みさせて頂きます。 | ||
| 5 | Re:＃ＮＦＬＮＫについて | |
| ほいほい 2010-3-11 9:41:00
[返信] [編集] ＃ＮＦＬＮＫを起動した直後のエラーメッセージの内容は 以下のとおりでした。 「本オペレータからファイル連携ユーティリティを 使用することはできません。」（メッセージ番号(0192)） またもう１つのファイルはSYS@NTPAFでした。 ちなみにレコード件数は0となっています。 | ||
| 6 | Re:＃ＮＦＬＮＫについて | |
| ＥＸＣＨＡＮＧＥ 2010-3-11 12:10:00
[返信] [編集] ＊ やはり、グローバルオペレータでＡ−ＶＸにログインしていないためと思われます。 ＊ そちらでは操作開始時に「部門コード」（２桁）というのを入力していませんでしょうか？それがカンパニＩＤです。 ＊ ＃ＮＦＬＮＫは部門コード（カンパニＩＤ）が空白２桁です。 ＊ カンパニＩＤについてはターラヤンのこのＨＰを参照して下さい。 ＤＯＳのカレントディレクトリ、ＡＳ／４００のカレントライブラリのようなものです。 例えばＤＯＳの場合 コマンドプロンプトがＣ：￥ＡＡ ＞ となっていれば Ｃ：￥ＡＡ￥ＯＯＯ．ｅｘｅを ＯＯＯ．ｅｘｅだけで指定できますよね。 グローバルとはルートディレクトリと言ったところでしょうか。 うまく説明できなくてごめんなさい。 | ||
| 7 | Re:＃ＮＦＬＮＫについて | |
| ＮＦＬＮＫ太郎 2010-3-11 12:20:00
[返信] [編集] 「本オペレータから・・・」とあるということは、 ＥＸＣＨＡＮＧＥ様のいう通りかも知れません。 小生は「カンパニ付きの」には詳しくありませんので、 これで退室します。 がんばってください。 以上 | ||
| 8 | Re:＃ＮＦＬＮＫについて | |
| ＥＸＣＨＡＮＧＥ 2010-3-11 13:14:00
[返信] [編集] ＊ カンパニについての説明は ターラヤンＴＯＰ −−＞ Ａ−ＶＸの説明書 −−＞ 理論編 −−＞ セキュリティとＯＣＦ −−＞ ３．ＯＣＦ機能 −−＞ ４．カンパニ を参考になさって下さい。 | ||
| 9 | Re:＃ＮＦＬＮＫについて | |
| ターラヤン 2010-3-12 0:17:00
[返信] [編集] ほいほいさん、こんにちは。 グローバルオペレータは、Ａ−ＶＸの管理者権限を持つユーザのことです。 ＷｉｎｄｏｗｓやＵＮＩＸやＯｒａｃｌｅデータベースでも何でも、 管理者用のユーザーアカウントと一般ユーザ用に使うアカウント がありますよね。 アドミニストレーターとかｒｏｏｔとか言われているものと同じ意味です。 グローバルオペレータなら、一応Ａ−ＶＸのシステム設定をいろいろ 変更するなどいろいろなことができます。 一般ユーザは、いろいろと権限を制限しているので、できることとできない ことがあります。。 （もちろん設定次第では、グローバルオペレータ並みの権限を持たせる ことも可能。これは他のソフトやＯＳのユーザアカウントも設定次第で 管理者権限を持たせたり制限したりすることもできるので、同じですよね。） メッセージの内容から考えて、機能が制限されているアカウント（Ａ−ＶＸだと オペレータと言う）でＡ−ＶＸに入っているのではないでしょうか。 たぶんほいほいさんのところのサーバーに入っているＡ−ＶＸにも グローバルオペレータが登録されているはずです。 （無いと管理できませんから。） カンパニについても、たぶんグローバルオペレータでは、＃ＮＦＬＮＫ が使えるような状態に設定されているはずです。 （そうでないとグローバルオペレータを使ってサーバーの管理が できませんから。） したがって、まずグローバルオペレータのアカウントを探して、そのアカウント でＡ−ＶＸに入って＃ＮＦＬＮＫを動かしてみることを試みてみるのが よいのではないでしょうか。 | ||
| 10 | Re:＃ＮＦＬＮＫについて | |
| ＥＸＣＨＡＮＧＥ 2010-3-13 15:56:00
[返信] [編集] ＊ グローバルという用語について私のほうで少し認識違いしていたようですので訂正しておきたいと思います。 説明は単純化していますので、細かい点は省かれています。 ＊ まずカンパニＩＤですが、これはファイルやライブラリのグルーピングに使うものなので カンパニＩＤなし（＝カンパニＩＤがスペース２桁、ＣＩＤ＝＾＾）が、カンパニありの上位にあるわけではありません。 Ａ−ＶＸの論理ボリューム（ＭＳＤＸＸＸ）の直下には 例えば、カンパニコードＡＡのファイル群と、カンパニコードＢＢを持つファイル群と、それからカンパニコードなしのファイル群がある、といった具合です。 ＊ それから、ファイル、ライブラリ、ライブラリのメンバはそれぞれ（英字１桁＋数字１桁）からなる権限（セキュリティコード）を定義できます。（例：Ａ３） ＊ Ａ−ＶＸにおけるオペレータとはＷｉｎｄｏｗｓで言うところの「ユーザ」、ＡＳ／４００のユーザプロフィールです。 オペレータにはそれぞれ、カンパニＩＤ、セキュリティコード、を付与できます。 ＊ 例えば、Ｕ０１というオペレータがカンパニＩＤ＝ＣＣ、セキュリティコード＝Ｓ３である場合を考えると、 Ｕ０１は、 カンパニーコードＣＣのグループに属するファイルと カンパニーコードなしのグループに属するファイルが見えている状態になります（つまり、この範囲のファイルを探索できる） また、Ｕ０１が探索して見つけたファイル、メンバ（実行プログラムも含む）を使用できるかどうかはＳ３というセキュリティコードと照合して判定されることになります。ここでは照合の規則についてはこれ以上立ち入りません。 ＊ Ｕ０１は libpath=msd , libpath=msdcc の状態です。 ＭＳＤはＭＳＤ０００を含むすべての論理ボリュームです ＊ もし、Ｕ０１に付与されたカンパニＩＤがなし（空白）の場は、カンパニＩＤなしのファイルのみが探索の対象となります。 ＊ 以上の説明の中で出てきたカンパニＩＤなしのファイルというのがＡ−ＶＸで言うところのグローバルファイル（こちらはファイル！！）と呼んでいる物かと思います。 ＊ グローバルオペレータというのは、また別の概念で、 カンパニＩＤがなし（＝空白）で、かつセキュリティコードがＺ９（管理権限）をもつオペレータのことです。 このオペレータはユーティリティなどを使った場合、カンパニＩＤを指定することによって（その都度、絶対パスを指定することによって）あらゆるファイルにアクセス出来ます。 しかしグローバルオペレータにカンパニー配下のディレクトリにたいしてライブラリパスが追加されているわけではありませんので、 （１）ユーティリティに於いては常にカンパニＩＤの入力が求められる（絶対パスの指定が必要） （２）ＲＵＮ＝＾＾＾＾（コマンドプロンプト？）においてはカンパニＩＤなしの領域のメンバしか起動できない。（注１） （３）カンパニＩＤありの領域の実行形式メンバ（＝プログラム）をカンパニなしの領域へ移動してきても、プログラムの内部で使われているデータファイルの定義が相対パスなのでデータもカンパニなし領域へ移動し、プログラムでのファイル定義、またはデータベースでの表定義を変更（主にカンパニＩＤというパスを変更）しなければ「ファイルが見つからない」というエラーになるでしょう。 ＊ 以上まとめですが、 グローバルファイル（カンパニＩＤなし）のファイルは、カンパニをまたいでのファイルの受渡などに使うケースが多いようです。 これは別々のカンパニＩＤをもつオペレータが起動したプログラムから共通でアクセスできる領域だからです。 個々のカンパニコードを持ってＡ−ＶＸにログインしているユーザからは空白以外の別のカンパニ配下にある領域のファイルは見えませんし、絶対パスを指定してアクセスすることも出来ません。 ＊ それからだいぶほいほいさんの質問から遠ざかってしまいましたが、＃ＮＦＬＮＫは前述グローバルオペレータ（オペレータのほうです）でないと起動できないみたいなので、カンパニＩＤが空白でかつ、Ｚ９（管理権限）をもつユーザを捜す（もしくはシステムを構築したベンダに問い合わせる）ことが必要でしょうね。 （追記） （注１）の部分は例外というか指定方法があって起動が可能かもしれません。自信がありません。だれか確実な方がおられましたらお教え下さい。 （さらに追記） カンパニと言う用語はちょっと不適切な用語かな、と思います。リコーのＲＩＣＯＭのＯＳ「ＣＯＭＰＯＳＳ」で使っていたＧＩＤ（グループＩＤ）のほうが適切な用語でしょうね。（最もこの考え方はＮＥＣからのパクリですけどね） リコーの場合は、オペレータという考え方がなく、セキュリティの考え方はありませんでした。単にＰＡＳＳの設定です。メニューの定義の中にＧＩＤが記述できて、操作員がジョブメニューから、起動したいプログラムまたは子メニューを番号で選んだ時点で呼び出し側のメニューに定義されたＧＩＤ（グループＩＤ）が付与される、つまりファイルの探索範囲が付与される＝ＰＡＳＳが設定される、というやり方でした。 従って子メニュー、孫メニューと伝っていく毎にＧＩＤを変更することも出来ました。 その点ＮＥＣのは堅い（融通がきかない）なあ。。と思います。 なお、カンパニという用語はＮＥＣも後日不適切と思ったのでしょうね。いつの間にかログイン画面では「部門コード」という名称に変わっています。 | ||
| 11 | Re:＃ＮＦＬＮＫについて | |
| ほいほい 2010-3-15 11:45:00
[返信] [編集] グローバルオペレータについて詳細な説明 ありがとうございました。 当社ではカンパニＩＤは設定していません。 ＃ＯＣＦＭでオペレータを見たところ４つオペレータＩＤが 存在していますがすべてセキュリティコードは未設定でした。 当然Ｚ９に設定することは出来ませんでした。 最後にもう１つ質問ですがグローバルオペレータは ＃ＯＣＦＭでは見ることが出来ないものであり、 絶対に存在するものなのでしょうか？ 単に当社の場合グローバルオペレータが未設定（ありえるのか どうか分りませんが・・・）ということも考えられます。 最終的にはＳＥに聞く方向しか解決策はなさそうなのは 分りました。 | ||
| 12 | Re:＃ＮＦＬＮＫについて | |
| 温泉好きのうさぎ 2010-3-16 0:16:00
[返信] [編集] セキュリティコードが未設定ということですから、ローカルのオペレータコードからであっても #OCFM により新しくグローバルのオペレータコードを作成することができます。 グローバルのオペレータコードが未設定あるいは不明なのでしたら、新規にグローバルのオペレータコードを作成し、それで #NFLNK の設定をされてはいかがでしょうか。 #NFLNK 設定後、不要であればそのグローバルのオペレータコードを削除しておけばよいでしょう。 | ||
| 13 | Re:＃ＮＦＬＮＫについて | |
| ほいほい 2010-3-18 9:50:00
[返信] [編集] 皆様ありがとうございました。 結論から言うと、システム構築のときにカンパニなし／セキュリティコードなしで設定がされているようです。 カンパニなし／セキュリティコードありであれば ＃ＯＣＦＭから設定ができ＃ＮＦＬＮＫも使用できると いう結論に自分の中で到りました。 現在は＃ＯＣＦＭにて登録するときにセキュリティコードがまず 飛ばされます。ＢＫＳＰでカーソル戻して英字１桁＋数字１桁を 入力しても入力エラーとなります。 今回ハードをリプレイスするに当たりＩＢＭフォーマットのＦＤが使えなくなるため、ＰＧでダイレクトにＦＤ読み書きしている 場合、今回＃ＮＦＬＮＫで対応しようと思いましたが 仕方がないのでＰＧでディスクに出力し＃ＮＦＣＮＶで対応する方向で考えます。 | ||
| 14 | :（ＦＤの変換について） | |
| ＥＸＣＨＡＮＧＥ 2010-3-18 19:43:00
[返信] [編集] ＊ ほいほいさんのＦＤ受渡の前提環境は存じませんが ＩＢＭフォーマットＦＤ、ＤＯＳフォーマットＦＤ間の媒体での変換は、ＮＥＣが提供するユーティリティ、ＩＯデータ社のＵＳＢ版３モードＦＤ装置などを組み合わせてＰＣ上で可能だと聞いています。 ＊ 他にもシステムポート社の「仮想ＦＤファイル変換」というシェアウエアがあります。使ったことがないので仕様内容は分かりませんが、なんでもＩＢＭＦＤの内容を圧縮してメールなどで添付送信できるなどと聞いております。なにか使えるかも。。 ＊ ６００シリーズ＜−−＞６００シリーズ間でしたら最近リリースされた＃ＢＫＵＰディスクバージョンを双方で使って受渡が可能でしょうね。 やったことありませんので実際の事はよくわかりませんが。。 | ||
| 全部読む 最新50 1-100 板のトップ リロード | ||
| 新規投稿 | スレッド表示 | ツリー表示 | 投稿順表示 | i-mode | トップ |
BluesBB ©Sting_Band