ＮＥＣのオフコン情報掲示板（ノウハウ系）
| ＮＥＣのオフコンを活用するためのノウハウを話し合うための掲示板です。 |
| 新規投稿 | スレッド表示 | ツリー表示 | 投稿順表示 | i-mode | トップ |
| ■▲▼ | ||
| 1 | レコード領域について | |
| KEN 2008-4-30 23:38:00
[返信] [編集] レコード領域についての質問です。 どなたかご存知でしたら教えてください。 COBOL85の言語説明書に記載されている件ですが、 「ファイルのCLOSEが成功すると関連したレコード領域は参照できなくなる」 とあります。 これはFD句の01レベルで定義したレコード領域の値がCLOSEの実行前と実行後で変わってしまうのでしょうか？ WRITEやREWRITEに関しても同じような記載があります。 （WRITEやREWRITEの場合は、SAME RECORD AREAが指定されていれば使用不能にならないとの記載がありますが・・・） 小生の経験では実行前後でレコード領域の値が変わってしまうという現象を確認した事がありません。 実行後のレコード領域を参照して問題になったことがございません。 実行後のレコード領域を参照しないに越したことはないのですが、A-VXのCOBOLでは変わらない仕様なんでしょうか・・・ 変な質問で恐縮ですが、ご存知でしたらご教授のほどお願いいたします。 | ||
| 2 | Re:レコード領域について | |
| 温泉好きのうさぎ 2008-5-1 14:42:00
[返信] [編集] 「ファイルのCLOSEが成功すると関連したレコード領域は参照できなくなる」という記述を解釈すると、 01レコード領域の値が実行前と実行後で変わってしまうという意味ではなく、実行前の値がそのまま実行後まで残っていることを保証していないという意味です。 実行後に実行前の値と変わっていなかったのは、A-VXのCOBOLでは変わらない仕様になっているからではなく、たまたま偶然にすぎません。 質問者様のプログラムでは、変える原因となる事象がそのタイミングで起こらなかっただけだろうと想像されます。 プログラムの動作に万全を期すためにも、CLOSE、WRITE、REWRITE命令等実行後にレコード領域を参照しないようなコーディングとすることを、お勧めいたします。 | ||
| 3 | Re:レコード領域について | |
| KEN 2008-5-1 17:43:00
[返信] [編集] 温泉好きのうさぎ 様 はじめまして、こんにちは。 早速、詳しいご説明をしていただきありがとうございます。 とても参考になりました。 やはり、「実行前後の内容が同じである保証はない」という解釈ですね。。 試しに実行前後のレコード値の比較を繰り返すバッチPGを作成して一晩中流したり、色々と試してみたのですが、 変わってしまう現象を確認できなかった為、質問させていただいた次第です。。（保証しないとはいえ、その事象にお目にかかったことがないので・・・） と申しますのも、もちろん通常のコーディングでは実行後のレコード領域を参照しないようにしているのですが、 参照しているPGも過去にはあったような記憶がありましたので「変える原因となる事象」や頻度について興味がございました。。 | ||
| 4 | Re:レコード領域について | |
| 温泉好きのうさぎ 2008-5-1 22:13:00
[返信] [編集] こんばんは、KEN様。 A-VXの数あるマニュアルのどこにもそのようなことは書かれておらず、「変える原因となる事象が起こる」というのは、私の想像です。 例えば、実行中のLMに対して、「ロールアウト ロールイン」が発生したとか、オーバーレイ化されたLMのセグメントがメモリから解放されたとかしたときに、タイミングによっては01レコードの内容は保持されていないのかなと思います。 いずれにしても、「ロールアウト ロールイン」や「オーバーレイ」などは、オフコンの初期時代に貧弱なハード環境でプログラムが実行できるよう工夫されたものであり、今のExpress5800/600シリーズなどのメモリに余裕が充分ある状態ではほとんど起こりえないのかもしれません。 | ||
| 5 | Re:レコード領域について | |
| KEN 2008-5-2 1:00:00
[返信] [編集] 温泉好きのうさぎ 様 こんばんは。 度々のご回答をありがとうございます。。 なるほど、ちょっと私は勘違いしていたかもしれません。 ファイル記述項の直後に書くレコード記述項（01レコード）を「WORKING-STORAGE SECTION」に書く変数と同じように考えておりました。 READ命令が成功するとレコードの内容がレコード記述項に定義した01レコード（変数）に移送される動作をイメージしておりました。（変数なのでPG側から操作しない限り内容が変わらない） そうではなくて、レコードを処理するために割り付けられた記憶領域（＝レコード領域）にPGから直接アクセスする手段として01レコードを使用するイメージでしょうか。。。 この記憶領域はCLOSEによって開放され、CLOSE後に01レコードを参照した場合は開放された記憶領域を見ているに過ぎない為、何の保証もないことに納得です。。 | ||
| 全部読む 最新50 1-100 板のトップ リロード | ||
| ■▲▼ | ||
| 1 | ログの抽出をJCLで出来ないか？ | |
| うどん 2008-3-26 8:35:00
[返信] [編集] お世話になります。 STN000で実施している｢ログの抽出｣ですが、 JCLで出来ないのかなと... どっかのマニュアルにはダメと書いてあった様な... | ||
| 2 | Re:ログの抽出をJCLで出来ないか？ | |
| 富山清風 2008-4-4 11:04:00
[返信] [編集] 「ログの抽出」とは、#FLCNVで以下でできませんか？ または、別のことをやりたい？ 的が外れていたら、すみませんです。 | ||
| 3 | Re:ログの抽出をJCLで出来ないか？ | |
0e0e 2008-4-9 10:43:00
[返信] [編集]こんなのでXXXJOBLOG（仮）というファイルに抜けます。 256/1 RELATIVE そのままでは中身が見えませんので、COBOLのプログラムの最初で CALL ”SYSEDWR” を使ってファイルの最後にEODをつけます。 あとは好き勝手にデータ処理できます。 | ||
| 4 | Re:(統合管理ツール）ログの抽出をJCLで出来ないか？ | |
| 江須扇 2008-6-2 12:27:00
[返信] [編集] またまた、亀レス、失礼します。 A-VX01 R4.0 からですが、 統合管理ツールというのがあります。 これでジョブログを見ることも可能と書いてあります。 まだ、私も使ってないので確かなことは言えませんが・・・・ http://www.nec.co.jp/pfsoft/a-vx/AMT/ | ||
| 全部読む 最新50 1-100 板のトップ リロード | ||
| ■▲▼ | ||
| 1 | ラインプリンタからレーザープリンタ | |
| もも 2008-3-12 15:22:00
[返信] [編集] ＣＯＢＯＬで今までラインプリンタに印字するプログラムを作成してきました。プログラムを変更しないで、そのまま使用して、レーザープリンタに印刷できるのしょうか？ ＳＧではレーザー用に印刷するように指定してあるのですが、１行しか印刷されず、しかも、重なって印刷されています。 すみませんが、教えて下さい。 それから、＃ＡＢＣの印刷でもレーザーに印刷できるのでしょうか？ （ＳＧの設定は、きちんと行なわれていると仮定して・・・） | ||
| 2 | Re:ラインプリンタからレーザープリンタ | |
| 回転の達人 2008-3-13 12:22:00
[返信] [編集] NECのMultiWriterなどのN型番のレーザープリンタならプログラムは触らなくても、ＯＫです。 逆にN型版でないとダメですね。 WSEの制限事項にのっていると思います。 昔はエプソンのレーザプリンタなどで、N型にエミュレートされて正常に印字出来ていた事もありますが、今はダメではないでしょうか。 | ||
| 3 | Re:ラインプリンタからレーザープリンタ | |
| c4 2008-4-4 14:05:00
[返信] [編集] ラインプリンタのエミュレータがあれば印字出来るんでしょうが…。 ＣＯＢＯＬにエミュレーションスイッチって無かったでしょうか？ 不確かな記憶で申し訳ありません。 | ||
| 4 | Re:ラインプリンタからレーザープリンタ | |
| オフコン人 2008-4-5 8:45:00
[返信] [編集] SG設定がされてるって記載されるなら、単にラインプリンタのプログラムだけでなく、具体的に記載しないとアドバイスできませんよ。 ラインプリンタ専用の制御をされている場合だと、PrintBridgeを使えばできるようですね。BizReportingでも書式オーバレイの移行をすればこれもできますね。 書式オーバレイや制御が無いのなら、エミュレータ接続のページプリンタに印字できますね。 #ABCだと、何の問題もなく、エミュレータ接続のプリンタに印字できていますよ。 | ||
| 全部読む 最新50 1-100 板のトップ リロード | ||
| ■▲▼ | ||
| 1 | #NFCNV | |
| ひろぴ 2008-2-26 13:26:00
[返信] [編集] X(1) ”A” X(1) ” ” X(1) ”B” をCSV2カンマ区切りでDOS変換した場合 A, ,B となりますが A,,B のようにスペースを詰める方法はないでしょうか？ | ||
| 2 | Re:#NFCNV | |
| うどん 2008-2-26 18:42:00
[返信] [編集] #NFCNVでスペースを詰める方法は無かったような... | ||
| 全部読む 最新50 1-100 板のトップ リロード | ||
| ■▲▼ | ||
| 1 | フロッピーディスクの変換について | |
| Plus 2008-2-19 21:21:00
[返信] [編集] 最近A-VXサーバーが新しくなり、フロッピーディスクへの保存形式が変更になり、PAFDUと言う名前のファイルになっています。 このファイルをWindowsで読めるファイルに変換するユーティリティはないでしょうか？ 初めて書き込むのですが、よろしくお願いします。 | ||
| 2 | Re:フロッピーディスクの変換について | |
| ターラヤン 2008-2-21 1:06:00
[返信] [編集] Plusさん、こんにちは。 Ａ?ＶＸの＃ＮＦＣＮＶというもので変換する方法があります。 ＰＡＦＤＵという名前は、Ｗｉｎｄｏｗｓから見た名前ですが、 ＰＡＦＤＵの中にＡ−ＶＸのファイルとして入っているので、 このＡ−ＶＸのファイルの名前が必要です。 http://www.geocities.jp/tahrayan/utili/nfcnv.html ファイル変換ユーティリティの辺りも参考に。 このページの例では、装置名はMSDxxxになっていますが、フロッピーディスクなので、 装置名はおそらくFDU000です。 | ||
| 3 | Re:フロッピーディスクの変換について | |
| Plus 2008-2-21 10:29:00
[返信] [編集] ターラヤンさん、回答ありがとうございました。 さっそくやってみます。 あと、サーバーのD:AVXの中にFDTool.exeというユーティリティーがあるのですが使用方法はご存じですか。知っておられるようでしたら教えて頂けませんでしょうか。 よろしくお願いします。 A-VXのサイトは少ないので、初心者には心強いサイトですね！ ありがたいです。 | ||
| 4 | Re:フロッピーディスクの変換について | |
| 温泉好きのうさぎ 2008-2-21 19:04:00
[返信] [編集] A-VX01形式のフロッピーの実体であるPAFDU000という名の拡張子の無いファイルは、フロッピー一枚をそのまま一つのファイルにした状態です。 ご質問は、このファイルをA-VXを使わずに、Windowsからデータを参照したいということですよね? このためには、 「データ管理説明書」の 第２章 ボリューム形式とラベル ２．２ フロッピィディスク 第４章 ファイル処理機能 ４．２．４ フロッピィディスク上のファイル形式 このあたりが、ほぼ完璧に理解できているぐらいのスキルの持ち主でもない限り、Windowsからそのファイルの中が見えたとしても、そこから必要なデータを切り出していくのは非常に困難だと思います。 たいへん失礼ながら、「初心者」とのことですので、まず不可能なのではないでしょうか。 具体的なことを書きますと、PAFDU000はオフコンのデータですから、コードセットはEBCDICとなっています。Windowsのメモ帳等で開いてみても、意味不明の文字列しか見えないのはこのためです。 例えば、スペースを表わすEBCDICコードの ””40”” は、ASCIIでは、「@」なので「@」がたくさん見られると思います。 また、漢字等の２バイト系文字は、A-VX の独自コードになっていますので、それをWindows側のコードセットに変換するのは、工夫がいるかもしれません。 さて、PAFDU000のファイルサイズは、1,355,776 バイトですが、有効なデータは、先頭の998,972 バイトのみです。フロッピーディスクに空き領域ができないようにするために、ダーミーデータが付加されていると思われます。 次に、この先頭からボリュームラベルおよびファイルラベルが記録されている VTOC があります。 A-VXでは、データの単位として「セクタ」というものがあります。通常は、1セクタ = 256バイトであり、磁気ディスクや両面倍密度フロッピー (2HD型) がそうなのですが、フロッピーに関しては片面単密度フロッピーとの互換性のために、VTOCの片面のみ 1セクタ = 128バイトとなっています。 ボリュームラベルは重要では無いですが、ファイルラベルの解析は重要です。 そして、このファイルラベルから目的のファイルをさがし、必要なデータがどのアドレスにあるのかを判断しなければなりません。そのアドレスもシリンダ、トラック、セクタによる表現のため、実際に何バイト目を示しているのかを計算するのは非常にやっかいです。 目的のファイルのレコード長が 256バイトであれば、レコード単位でデータを見ることはまだ容易でしょうが、他のレコード長やブロック化されていたりすると、これを展開させるのがまたやっかいなことになります。 そのファイルが順編成や相対編成であれば、データは順番に入っているので、EOF と削除レコードの判断ができれば、これで終了となります。 しかし、索引順編成ファイルであれば、どれが有効レコードなのか、ほとんど判断不能です。索引ブロックが階層化されるぐらいデータ件数が多くなると、もうお手上げ状態です。 以上はデータファイルについてですが、プログラム等の入っている SUL の中から一本の COBOL のソースを読み出したいというのでしたら、無理と判断したほうが早いです。待機編成ファイルの構造が理解されていないと不可能です。 素直に A-VX で SUL からソースを抽出して #NFCNV で変換するのが最善です。 質問者様が具体的に何をなさりたいのかがわかりませんので、長々と書きましたが、有意義な回答であったかどうか。 あくまで、PAFDU000は、A-VXのみで使うファイルであり、Windows側から参照する必要はないと思います。 | ||
| 5 | Re:フロッピーディスクの変換について | |
| ターラヤン 2008-2-21 23:52:00
[返信] [編集] FDTool.exeの使い方は「概要マニュアル」というマニュアルに書いてあります。 昔のフロッピーディスクからPAFDUに変換するものです。 たしかサーバのモデルによって、使える機種と使えない機種があったはずです。 | ||
| 6 | フロッピーディスクの変換についてお礼 | |
| Plus 2008-3-4 8:28:00
[返信] [編集] 皆さん回答ありがとうございました。 結局#NFCNVで変換する事にします。 ただ、オフコンの担当者はハードディスクのデータが心配で使用を渋っていますが一緒にやってみます。 これからも頼りにしていますのでよろしくお願いします。 | ||
| 全部読む 最新50 1-100 板のトップ リロード | ||
| 新規投稿 | スレッド表示 | ツリー表示 | 投稿順表示 | i-mode | トップ |
BluesBB ©Sting_Band