ＮＥＣのオフコン情報掲示板（ノウハウ系）
| ＮＥＣのオフコンを活用するためのノウハウを話し合うための掲示板です。 |
| 新規投稿 | スレッド表示 | ツリー表示 | 投稿順表示 | i-mode | トップ |
| ■▲▼ | ||
| 1 | DAT装置が無い場合の#BKUPによる退避について | |
| けんさん 2015-8-26 14:37:24
[返信] [編集] 機器の更新に伴いDAT装置がNASに変更されました。 バックアップ環境設定ツールでNASのフォルダがCTU設定されているようです。 これまでは#BKUPで必要ファイル(場合によってはボリューム)をDATにコピーしていました。 このNASにバックアップされた情報をコピーする方法はあるのでしょうか。 作業用のライブラリ、ファイルをコピー等するのに困っています。 AVXのバージョンはA-VX02 R3.6です。 | ||
| 2 | Re: DAT装置が無い場合の#BKUPによる退避について | |
| けんさん 2015-8-27 11:03:22
[返信] [編集] A-VXディスクバックアップ機能を利用する事で解決しました。 | ||
| 全部読む 最新50 1-100 板のトップ リロード | ||
| ■▲▼ | ||
| 1 | AT END が無視されて、再度、DELETE処理を行い、 不正十進数エラーで アボートしてしまいます | |
| GAI 2015-7-14 16:12:14
[返信] [編集] こんにちはいつも大変お世話になっております。 ＣＯＢＯＬ85で、 下記の処理をした場合、 最終レコードを削除した後、 AT END が無視されて、再度、DELETE処理を行い、 不正十進数エラーで アボートしてしまいます。 それなりにスキルのある前任者が作ったプログラムです。 最終レコードが削除されたら、レコードがなくなるので、AT END になると思うのですが、 なぜAT END GOTO ABC-090が無視されてしまうのでしょうか？ どう処置すればいいでしょうか？ １．RDBファイルを順読み ２．削除する ３．次のレコードを読む（最終レコード） ４．削除する（最終レコード） ５．次のレコードを読む（AT ENDになるはず） ６．削除する → 不正エラー！！？ ABC-010. READ XX-FILE AT END GOTO ABC-090. DELETE XX-FILE . GO TO ABC-010. ABC-090. 【例】 READ レコード 99997 →DELETE READ レコード 99998 →DELETE READ レコード 99999 →DELETE READ E M0021: (PRG=XXXXXX,ADR=00051C12) 不正十進数エラ― | ||
| 4 | Re: 久々ＣＯＢＯＬ８５を見ました。（AT END が無視されて、再度、DELETE処理を行い、 不正十進数エラーで アボートしてしまいます） | |
| 江須扇 2015-7-16 11:02:27
[返信] [編集] 私も久々に見るので、記憶違いかもしれませんが、 プログラム内でＦＩＬＥ ＳＴＡＴＵＳを一か所も使ってない場合は ＡＴ ＥＮＤ で再読み込みを実行すると命令実行順序エラーで エラー表示するのではと記憶しております。 しかしながらＦＩＬＥ ＳＴＡＴＵＳを使っている場合は その命令でＯＳからのエラーは表示されず。 次の行で必ずＳＴＡＴＵＳをＩＦ命令で確かめる必要が あると思います。 また、ＤＥＬＥＴＥ命令で不正十進数はエラー出ないと記憶しております。 説明上省略してあるのでしょうがＲＥＡＤの後、何らかの処理でエラーが出ていると考えます。 対応方法は １．全てのＦＩＬＥ ＳＴＡＴＵＳをコメントにして ＯＳのエラー機能のみで実行する ２．全ての入出力命令（ＯＰＥＮ、ＣＬＯＳＥ、ＲＥＡＤ、ＤＥＬＥＴＥ等）の直後でＳＴＡＴＵＳを確認して全て自己管理にする のどちらかにする必要があります。 中途半端（すいません言葉がきついかも）にＳＴＡＴＵＳを確認すると正しい判定ができません。 まずはそこをご確認ください。 ＰＳ： それにしても旧１００からＣＯＢＯＬがあったのでそれを引き継いだプログラムが多いので ＧＯ ＴＯ ありありのプログラムはやむを得ないかもしれませんが 新規であればＣＯＢＯＬ８５はＥＮＤ−ＸＸＸとＰＥＲＦＯＲＭ を使った構造化プログラムが作成が可能になります。 データベースのＳＥＬＥＣＴと命令と組み合わせると かなりすっきりしたプログラムになります。 いまさらですが参考の為に蛇足を書きました。  | ||
| 5 | Re: AT END が無視されて、再度、DELETE処理を行い、 不正十進数エラーで アボートしてしまいます | |
| GAI 2015-7-17 11:24:11
[返信] [編集] ファイルステータスですね？！ やり方調べて実施してみます！ ありがとうございます” | ||
| 6 | Re: AT END が無視されて、再度、DELETE処理を行い、 不正十進数エラーで アボートしてしまいます | |
| gai 2015-7-17 11:53:31
[返信] [編集] ありがとうございます。 おっしゃるとおり、それなりに実績があるといいつつ、 あるというわけではないですよね。 10年以上毎月動いているＰＧですが、 もしかしたら過去もあったのかもしれません。 ORGANIZATION IS INDEXED となっております。 ＲＤＢを索引順に読みながら、 ある条件に合致した、古いレコードを削除する、 という処理です。 | ||
| 7 | Re: 久々ＣＯＢＯＬ８５を見ました。（AT END が無視されて、再度、DELETE処理を行い、 不正十進数エラーで アボートしてしまいます） | |
| gai 2015-7-17 13:14:47
[返信] [編集] ありがとうございます。 ＦＩＬＥ ＳＴＡＴＵＳでソースを検索したところ、 FILE-CONTROL.で なんこかのSELECT で FILE STATUS IS XXXXX と書いてありました。 file statusとは この記述のことでしょうか？ ここで定義しておきながら、 実際のprocedure divisionでは、 file status xxxx は使っておりませんが。 したがって、FILE status を全処理で DISPLAYしてみます。 | ||
| 8 | Re: AT END が無視されて、再度、DELETE処理を行い、 不正十進数エラーで アボートしてしまいます | |
| gai 2015-7-17 14:09:40
[返信] [編集] こんにちは。 各所にDISPLAYを入れて、 fileSTATUSを表示してみました。 最後のレコードがDELETE されたあと、 再度READ命令を実行した際、 READ XXXX NEXT AT END の直後に DISPLAY したところ ”１０” が表示されました。 10はAT ENDですよね？ 表示したあと、そこで 十進数エラーになります。 もしかしたら、KEYに HIGH-VALUE を入れているからいけないのでですか？？ READ XXXX NEXT AT END DISPLAY STS UPON AAA-GDD MOVE HIGH-VALUE TO XXXX-KEY2. と書いてあります。 | ||
| 9 | Re: AT END が無視されて、再度、DELETE処理を行い、 不正十進数エラーで アボートしてしまいます | |
| GAI 2015-7-17 15:57:23
[返信] [編集] こんにちは。 ためしに、 MOVE HIGH-VALUE TO XXXX-KEY2. ↓ MOVE 88888888 TO XXXX-KEY2. とやったら、エラーにならなくなりました。 上位のロジックでは、 XXXX-KEY2 が 88888888 だったら、 処理修了的に手続きを仕込みました。 とりあえず無理やりですが、これで運用はできそうですが、 なんで HIGH-VALUE を入れたら 十進数エラーなのかは不思議です。 | ||
| 10 | Re: AT END が無視されて、再度、DELETE処理を行い、 不正十進数エラーで アボートしてしまいます | |
| ＥＸＣＨＡＮＧＥ 2015-7-19 16:24:12
[返信] [編集] ☆ 拝見させていただいて、前任者はかなり古風なソフト書法をご存じの方と思います。ひょっとしたらＡ−ＶＸ以外でのＣＯＢＯＬを使っておられた経験者かも？low-value high-valueをendがらみで使われているところなんかそれっぽい感じがします） ☆それはともかく、私は江須扇さんのご指摘が（現在なら）妥当な書法ではないかと同感いたします。 以下、（江須扇氏より引用） >それにしても旧１００からＣＯＢＯＬがあったのでそれを引き継いだプログラムが多いので >ＧＯ ＴＯ ありありのプログラムはやむを得ないかもしれませんが >新規であればＣＯＢＯＬ８５はＥＮＤ−ＸＸＸとＰＥＲＦＯＲＭ を使った構造化プログラムが作成が可能になります。 >データベースのＳＥＬＥＣＴと命令と組み合わせると かなりすっきりしたプログラムになります。 | ||
| 11 | AT ENDは正しく動いているのでは？ | |
| ターラヤン 2015-7-22 0:23:55
[返信] [編集] HIGH-VALUEを8888・・に直してうまく動くようになったのでしたら、良いとは思いますが・・・ もともとのご質問は 「最終レコードが削除されたら、レコードがなくなるので、AT END になると思うのですが、 なぜAT END GOTO ABC-090が無視されてしまうのでしょうか？」 だったと思います。 「最後のレコードがDELETE されたあと、 再度READ命令を実行した際、 READ XXXX NEXT AT END の直後に DISPLAY したところ ”１０” が表示されました。」 ということならば、 AT ENDの直後のDISPLAY文が実行されたということですので、 「最終レコードが削除されたら、レコードがなくなるので、AT ENDになっている」 のではないでしょうか。 プログラムの一部分しか見えないので、はっきりとはわかりませんが、 実はGOTO文の前にHIGH-VALUEをMOVEする処理もあるようですし、 例えば、MOVEとGOTOの間の別の命令があって不正十進エラーになっているとか、 XXXX-KEY2が英数字項目で定義されていて、HIGH-VALUEを入れた後に どこかでXXXX-KEY2を使って計算して（例えばCOMPUTE A=XXXX-KEY/2のように） 不正十進エラーになっているとか AT ENDとGOTOの間が空いているのなら、GOTOでジャンプしない経路があり予想外の場所を実行しているとか どこかにロジックに誤りがあるのではないか、という気もします。 | ||
| 12 | Re: AT ENDは正しく動いているのでは？ | |
| gai 2015-7-23 15:07:40
[返信] [編集] 説明わかりづらくてすみません。 省略してシンプルに書きすぎたのと、 情報開示の問題で大変わかりづらくなってしまいました。 階層構造になっており、�／董´∋辧´Ｂ� となっております。 ただし、これでもさらに上位階層のルーチンがあります。 そこまで疑うとキリがありませんし ファイルレイアウトがどうなってるんだとか、 ＤＢの詳細はどうだとかいう話にもなってしまいますので、 あきらめます。 でもずいぶんスッキリしました。 ありがとうございました！ *********************************************************** � �PERFORM DELETE-PROC UNTIL WK-DNO NOT = XXXX-DNO. *********************************************************** �� *********************************************************** DELETE-PROC SECTION. KK-010. DELETE XXXX-F INVALID KEY MOVE MSG-ABC TO KB-MSG1 MOVE XX-KEY TO KB-MSG2 PERFORM MSG-RTN THRU MSG-EXT. PERFORM READ-PROC. KK-DELETE-EXIT. EXIT. *********************************************************** �� *********************************************************** READ-PROC SECTION. K-010. READ XXXX-F NEXT AT END MOVE HIGH-VALUE TO XXXX-KEY2. READ-EXIT. EXIT. *********************************************************** XXXX-KEY2 は数字項目 集団項目 XXXX-DNO 9(06) XXXX-KNO 9(02) WK-DNO 9(06) はブレークしたときXXXX-DNOを退避するワーク項目 | ||
| 13 | Re: AT END が無視されて、再度、DELETE処理を行い、 不正十進数エラーで アボートしてしまいます | |
| MAKI 2015-8-4 14:53:18
[返信] [編集] HIGH-VALUEは内部コードはFFなんで数値項目にMOVEしようとすると 不正十進数エラーになっているということではないでしょうか。 わざとアボートさせてプログラムを終了させているなんてことは ないでしょうね？ | ||
| 全部読む 最新50 1-100 板のトップ リロード | ||
| ■▲▼ | ||
| 1 | A-VXデータの移行について | |
| レガシー始末屋 2015-5-31 20:06:21
[返信] [編集] Windows2000ServerのA-VXデータをバツクアップ用のWindows2003ServerのA-VX環境に移行復元したいと思います。 #BKUPでDAT経由でBKUP=>RESTOREで簡単にできると思っていたら、 Windows2003ServerのDATがDAT72で、RESTOREできません。DATを使用せずに、移行する方法について、お願いします。 | ||
| 13 | Re: A-VXデータの移行について | |
| レガシー始末屋 2015-6-4 14:27:05
[返信] [編集] 早速、ご指摘の設定EXEを実行しました。 当初ﾊﾞﾂｸｱｯﾌﾟ先がI:\bak\CTO000\となっており、直近で実行したﾊﾞｯｸｱｯﾌﾟの実行した痕跡ﾃﾞｰﾀが保存されておりました。 ちなみに保存ﾌｧｲﾙ名はCTU000.tbmとCTU000.tbuでした。 ご指導のように、「解除」を実行して、念のために、Serverも再起動して、A-VX4で退避したDATをｾｯﾄして、CATALOGUを実行してみもしたところ、ｴﾗｰとなってしまいました。 ｴﾗｰ表示 O U33D7:(CTU000)退避媒体ではありません・・・です AVXBKUPSET.EXEを再度起動して、設定画面を確認するも、退避先ﾃﾞﾊﾞｲｽはCTU000となっております。 SGﾘｽﾄでも、SCSI-ID 4 DAT CTU000 となっております。 どうも、AVXBKUPSET.EXEでの設定変更がされていない、「解除」が実行されていない感じです。 原因として思い当たる点がありましたら、引き続きご指導ください。 | ||
| 14 | Re: A-VXデータの移行について | |
| 温泉好きのうさぎ 2015-6-4 18:52:58
[返信] [編集] 解決したと思ったのにまだダメなようですね。 AVXBKUPSET.EXE の設定画面で、SG情報と関連付けファイルの欄はどのように表示されているのでしょうか。 関連付けが解除されていれば、ファイル名のところは「未登録」となっているはずです。 また、AVXBKUPSET.EXE と同じフォルダに同じ名前の LOGファイルがありますので、その内容も確認してください。登録や解除の履歴が記録されています。 なお、AVXBKUPSET.EXE の設定画面を使わずに関連付けを強制的に解除してしまうには、同じ名前の INIファイルを削除 (またはファイル名 or 拡張子を変更) することで可能です。 そのうえで、試しにバックアップを実行し、CTU000.tbm と CTU000.tbu の更新日時が変更されていなければ、関連付けは正しく解除され、DATテープにデータが出力されたと判断できるでしょう。 さて、「退避媒体ではありません」のエラーメッセージですが、DAT装置がテープを読みにいって A-VX の #BKUP のデータであると認識できなかったということです。 具体的には、 1. 新品もしくは A-VX 以外で使用されていたテープを装着した 2. 集合型と単体型を混用した 3. オプションの高速モードで退避したものを、同機能適用以前の古いサーバで参照した 4. 拡張形式ファイルシステムで退避したものを、同機能適用以前の古いサーバで参照した 5. DAT装置の記録ヘッドの汚れ または 消耗 6. DATテープの劣化 といったことが考えられます。 このうち、1. 〜 4. では無いことは明らかなので、やはり物理的な I-Oエラーが発生しているのではないか思われます。 対策は、ヘッドクリーニングをして新品のテープを使うしかないですね。 DAT装置も新しい物ほど記録密度が高くなっており、非常にデリケートになっています。同じ装置で退避したデータは読めるけど、他の装置で退避したデータは読めないということもよくあります。 これでダメなら、DATを使用せず、2000Server 側もディスクバックアップ機能にしてしまうしかないですね。 動作保証はありませんが、Server2003 側にモジュールがあるのでそれをそのまま利用できると思いますよ。 | ||
| 15 | Re: A-VXデータの移行について | |
| オフコン人 2015-6-4 19:43:23
[返信] [編集] 急な出張で戻って、びっくりしています。 温泉好きのうさぎさん、色々ご苦労様です。 >どうも、AVXBKUPSET.EXEでの設定変更がされていない、「解除」が実行されていない感じです。 >原因として思い当たる点がありましたら、引き続きご指導ください。 何を根拠に、そのように断定されるのかわかりません。 ディスクバックアップ機能の設定ツールで解除されているなら、テープへ一度バックアップし、それをリストアできるか確認されたらいかがでしょう。テープにアクセスしているかは装置のランプで確認ですね。 その後、Windows2000のサーバでテープへバックアップし、Windows2003のサーバでリストアの確認をされればいいんじゃないでしょうか。 また、明日はサイトの確認ができません。 | ||
| 16 | Re: A-VXデータの移行について | |
| オフコン人 2015-6-4 19:50:12
[返信] [編集] 追伸：基本SGの装置定義は、必須ですが、CTU000をテープとして利用する場合は、ディスクバックアップ機能の設定はしません。 CTU000にドライブ\フォルダの設定がされている場合には、テープへアクセスしません。 テープへアクセスしたい場合は、設定を解除すればいいだけです。 | ||
| 17 | Re: A-VXデータの移行について | |
| レガシー始末屋 2015-6-4 20:44:32
[返信] [編集] 懇切丁寧な上、迅速な皆様のご回答に感謝申し上げます。 今までいただいたご回答をもう一度検証してみます。 最終的にどうなったかは、後日ご報告申し上げます。 | ||
| 18 | Re: A-VXデータの移行について | |
| レガシー始末屋 2015-6-4 20:56:40
[返信] [編集] Windows2003Xerver A-VX01 R5.01で、#BKUPを起動して、DATへの退避及びCATALOGU処理は、正常にできました。(最初DATにﾃｰﾌﾟｾｯﾄしないで、退避ﾊﾟﾗを切ったら、装置が用意されていないと怒られましたのでｱｸｾｽしてます) やはり問題は、Windows2000Server A-VX4 R5.01で退避したDATが正常に処理出来ないという点です。 A-VX4のｻｰﾊﾞｰとA-VX01ｻｰﾊﾞｰともに同じﾌｧｲﾙｱﾛｹｰﾄされています。 もう一度、皆様からの情報を整理して、再検討してみます。 | ||
| 19 | Re: A-VXデータの移行について | |
| 温泉好きのうさぎ 2015-6-4 23:03:31
[返信] [編集] OSがA-VX4 R5.01 は、ディスクバックアップ機能の適用対象外です。 2015-6-4 18:52の投稿の最後の2行は無かったことにしてください。 | ||
| 20 | Re: A-VXデータの移行について | |
| レガシー始末屋 2015-6-5 13:56:05
[返信] [編集] Windows2003Server A-VX01側のDAT装置は、とりあえず正常に動作していると判断しまして、ご指摘の5.6.について、トライしました。 Windows2000Server A-VX4側のDATのﾍｯﾄﾞｸﾘｰﾆﾝｸﾞと新しいDDS3ﾃｰﾌﾟを用いて、BACKUPして、DAT72にｾｯﾄして、CATALOGU,RESTORE処理を 実行してみました。 結果は、OKでした。嘘のような結末ですが、ご指摘の通りでしたね。 お陰様で、A-VX4からA-VX01へのDAT経由でのﾃﾞｰﾀ移行が出来そうです。 今回皆様の貴重な情報で、良い結果が得られて、大変感謝してます。改めて、御礼申し上げます。 それにしましても、今回のような処理は、通常Serverがﾀﾞｳﾝしない限り実際に実行する機会が無いかもしれない処理だけに、複雑な心境ですね。 A-VXもいよいよ2019年３月末で完全終了となります。NECのｻﾎﾟｰﾄは商業的に終了かもしれませんが、引き続き暫くは継続稼動させねば ならないﾕｰｻﾞｰはかなりいると思いますので、皆さん大変ですね。 ある時期まで、A-VXを利用しなければならないﾕｰｻﾞｰにとって、このような掲示板があることは、大変心強いですね。 もう暫くは、ﾚｶﾞｼｰと付き合わなければならないﾕｰｻﾞｰの為にも、発信し続けて下さい。 | ||
| 21 | Re: A-VXデータの移行について | |
| オフコン人 2015-6-6 8:11:52
[返信] [編集] 無事解決したようですね。よかったです。 ところで、2019年3月じゃなく、2020年3月と聞いていますよ。それを過ぎると保守も受けられなくなりますので、それまでに何とか移行を終えないといけません。（頑張るしか・・・） しかし、今回のようなことは、買われた販売店は何もしてくれないのですか？ 私は販売店へ問い合わせて、それなりに助けてもらっています。ま、最近は新しいことをしないので、聞くこともほとんど無くなっていますが。 お互い、頑張りましょうね。 | ||
| 22 | Re: A-VXデータの移行について | |
| レガシー始末屋 2015-6-6 15:53:27
[返信] [編集] NECのA-VX対応については、ﾃﾞｨｰﾗｰから、販売完了が2014/３月、ｻﾎﾟｰﾄ、保守終了は、２０１９年３月と聞いております。ﾃﾞｨｰﾗｰの販促用でしょうか(笑) ﾃﾞｨｰﾗｰもそれなりに対応してくれるのですが、ｵﾌｺﾝ全盛の頃に比べて、要員がﾘｽﾄﾗされてしまっていて、以前の様に気楽にSEやCEに相談できなくなっております。 うっかり相談すると、有償と言われそうですね。 兎に角、今回のDATによるﾃﾞｰﾀ退避、復旧にメドがついて、ﾎｯﾄしてます。 何時ｻｰﾊﾞｰが致命的なﾀﾞｳﾝをするか、予測つかないので、次期ｵｰﾌﾟﾝｼｽﾃﾑに移行が完了するまで、ﾚｶﾞｼｰA-VXには、最後の力を振り絞って、頑張ってくれと祈ってます(笑)。 | ||
| 全部読む 最新50 1-100 板のトップ リロード | ||
| ■▲▼ | ||
| 1 | ディクファイルのディアロケートJS生成方法 | |
| レガシー始末屋 2015-5-15 18:13:57
[返信] [編集] ハードディスクの不要ファイルをCID単位でいっきに削除したいのですが、ディアロケートJSL生成方法をご存知でしょうか。 %DISKMという裏LMを使うと、プログラムエラーが発生するので、他にディアロケートJSL生成方法は無いでしょうか。 | ||
| 2 | Re: ディクファイルのディアロケートJS生成方法 | |
| 富山清風 2015-5-18 16:15:00
[返信] [編集] ファイルを一括で削除する方法はしりません。が、 デアロケートをせっせせっせと1ファイルづつ削除するのが、よさそうですね。 もし、私だったら、デアロケートの件数をみて、 少なければ｢せっせせっせ｣で行い、 多ければ、ＪＳを作りますが、 マップリストをみながら、ファイル名をＪＳに手打ちするか、 SYS@FDFより引用するかは、それも、件数によります。 どちらにしても、｢不慣れ｣であれば、｢せっせせっせ｣が、 いいとおもいます。 | ||
| 3 | Re: ディクファイルのディアロケートJS生成方法 | |
| レガシー始末屋 2015-5-19 20:22:45
[返信] [編集] ご指摘ありがとうございます。 整理したいファイルが3500件余有るので、お知恵をお借りしたかったのですが･･････頼りにしていたNEC裏LMがアプリケーション・エラーを発生してしまっております。ただ、非公開LMなので、他言できない弱みがあります。 とりあえず、「地道にコツコツ」ですかね。(^_^;) | ||
| 4 | Re: ディクファイルのディアロケートJS生成方法 | |
| 富山清風 2015-5-20 12:38:24
[返信] [編集] 3000以上あるとなればJSですね。 長文になりますが、ご勘弁を。 概要 JS11/JS12:置換機能&0を使用してのJS JS2:削除するファイル名を羅列するJS 装置名MSD001/カンパニ"TT"等は現状にそって変更してください。 JS11: /RUN #ABC,DEV=MSD; MN1=01_MN2=01_MN3=02_PA1=MSD001_PA2=&0_O02=YES_CID=TT_O03=YES_EXP=NO_ MN1=99_ /> ; JS12: /RUN #ABC,DEV=MSD; MN1=01_MN2=01_MN3=02_PA1=MSD001_PA2=&0_O02=YES_CID=TT_O03=YES_EXP=NO_ UOD=ALL_ MN1=99_ /> ; JS11/JS12の使い分けはUOD=ALLが必要か否かですが、 エリアのアロケート時に使用した、ユーティリティによります。 JS11:#ABC等でアロケートか？ JS12:表定義よりアロケートか？ JS11/JS12の違いについては、自信がありません。 JS2: /RUN JS11,FIL=SYS@JSL,DEV=MSD,(FILENAME1); /RUN JS11,FIL=SYS@JSL,DEV=MSD,(FILENAME2); /RUN JS11,FIL=SYS@JSL,DEV=MSD,(FILENAME3); JS11/JS12とJS2を作成し、JS2を実行すればファイルがデアロケートされるとおもいます。 そこで、 JS11/JS12は#ABCのパラメータ登録機能で作成し、 ファイル名を&0に加工 JS2は下記の要領で作成 前提: F80:レコード長=80のORG=SEQのファイル #FLCNV; IDE=MSD001 IFI=SYS@FDF ODE=MSD OFI=F80 OUT=(@***@),(9,17),(@+++@) SEL=(7,2,C,EQ,@TT@)A(26,2,C,NE,@I0@) ←アイオーではなくアイゼロです 上記を実行すると、下記のような内容のファイルができます ***FILENAME1 +++ ***FILENAME2 +++ ***FILENAME3 +++ 次に、 TYP=JCL で#TEDITを起動し R MSD F80 とし、上記ファイルを読み込む 置換機能を利用し S ALL S"***","/RUN JS11,FIL=SYS@JSL,DEV=MSD,(" 再度、置換機能を利用し S ALL S"+++","); " すると、下記のようになります /RUN JS11,FIL=SYS@JSL,DEV=MSD,(FILENAME1 ); /RUN JS11,FIL=SYS@JSL,DEV=MSD,(FILENAME2 ); /RUN JS11,FIL=SYS@JSL,DEV=MSD,(FILENAME3 ); 名前をJS2にして、登録します。 (注)複数索引ファイルの場合、キーファイルから削除しないといけないのですが、 面倒なので、JS2を2回実行し、｢ファイルなし｣､｢キーファイルがある｣的なエラーは リセットで読み飛ばすようにすれば、全ファイル削除できるとおもいます。 | ||
| 5 | Re: ディクファイルのディアロケートJS生成方法 | |
| 温泉好きのうさぎ 2015-5-21 18:41:17
[返信] [編集] 削除の対象となるファイルが多数あるようで大変ですね。 私の手元にも、$DISKM という%メニューのLMが有りますが、リンク日が88年となっているので昭和の時代のもので、最近の大容量ディスクと大量のファイル数には対応できてないのかもしれません。 さて、ディアロケートのJSを作るとしても、ファイル名を置換パラメータで与えねばならず、かなり手間がかかります。 そこで、次のようなやり方はどうでしょうか。 1.ボリューム全体をバックアップする。 2.ディスクを初期化する。 3.必要なファイルのみリストアする。 または、 1.必要なファイルのみバックアップする。 2.ディスクを初期化する。 3.バックアップしたファイルをリストアする。 #BKUPでは、ファイル名の指定に集積名やワイルドカードが使用できるので、対象のファイルを全件入力する必要が無く楽です。 また、CID単位に全ファイルが必要なのか不要なのかに分かれているのなら、指定方法は非常に簡単です。 なお、ディアロケートのJSを作られるのでしたら、上の方も書かれているようにパラメータが微妙に異なりますので、やっかいです。 理由は、ファイルをアロケートしたのが、 (1) #ALLOC (2) #ABC 領域用オプションの確保方法がSTATIC (3) #ABC 領域用オプションの確保方法がDYNAMIC の違いです。 そこで、どんなファイルでも削除可能な #SGALC を使えば楽です。 具体的には /RUN #SGALC,FIL=SYS@LBM; ACT=DLP_VOL=_DEV=&0_NAM=_CID=&1_FIL=&2_GEN=98_ACT=END_ /> ; ACT=DLP_とGEN=98_のところが通常は無いパラメータです。 また、DEV=およびCID=のところは置換パラメータとせず、それぞれの装置やカンパニごとに個別のJSを複数作成しても差し支えありませんので、やり易い方で。 | ||
| 6 | Re: ディクファイルのディアロケートJS生成方法 | |
| 富山清風 2015-5-22 12:13:47
[返信] [編集] ｢#SGALC｣は知りませんでした。 今後の参考にさせていただきます。 | ||
| 全部読む 最新50 1-100 板のトップ リロード | ||
| ■▲▼ | ||
| 1 | WS# = 00 E W 49 と表示されるだけで起動できなくなりました。 | |
| 藤田勉 2015-5-15 10:24:22
[返信] [編集] 初めて投稿いたします。 専任の運用者は既に退職してしまっていて困っています。 ホストは NEC SYSTEM7200/70 で、 毎朝手動で電源を投入し、 システム3100/10（ステーション番号00） の電源を投入して、 業務を開始しています。 いつもはそれで使えていたのですが、 今朝に限って システム3100の画面には 0行目に WS# = 00 E W 49 とだけ表示されて、先に進めない状況です。 これがどういう状況なのか、 わかる方がいらっしゃれば、ご教示ください。 よろしくお願いします。 | ||
| 2 | Re: WS# = 00 E W 49 と表示されるだけで起動できなくなりました。 | |
| 藤田勉 2015-5-17 18:45:50
[返信] [編集] たぶん、この端末が 「システムステーション」と呼ばれるものだと思うのですが、 このままでは、 ＷＳエミュレータetc は接続する事が出来ないのですよね？ どこに障害があるのかが、分かれば 有り難いのですが。 | ||
| 3 | Re: WS# = 00 E W 49 と表示されるだけで起動できなくなりました。 | |
| 藤田勉 2015-5-18 14:13:09
[返信] [編集] システム 3100/10 が繋がっていたケーブルを外し、 動くかどうかよくわからない、 SYSTEM 7100/10BEAT（N1141-23）を繋いで 起動してみたところ、無事に操作開始状態になり、 WSエミュレータを繋ぐ事が出来るようになりました。 ありがとうございました。 | ||
| 4 | Re: WS# = 00 E W 49 と表示されるだけで起動できなくなりました。 | |
| 富山清風 2015-5-18 16:27:09
[返信] [編集] 日本電気フィールディングに聞く。とか ＮＥＣファーストコンタクトセンターに聞く。とか、がよさそうですね。 上記のような回答をしよう。よ、思っていましたら、自己解決されたようですね。 ＷＳ番号の変更手順はご存知だったようで何よりです。 ｢WS# = 00｣の00はステーション番号00の意味であり、 7100/10BEATのＷＳ番号を00に変更された結果、 うまく動作した。と、いうことですね。 ｢E W 49｣の意味は、私もわかりません。 とにかく、無事、解決されてよかったですね。 | ||
| 5 | Re: WS# = 00 E W 49 と表示されるだけで起動できなくなりました。 | |
| あ 2015-5-18 22:20:00
[返信] [編集] 49の原因 ＷＳよりデータ送信時ＳＩＦアダプタ またはＳＩＦケーブルに異常が発生した ＯＰ／ＴＣが不正データをセットして 送信したかまたは受信側（ＷＳ）が 不正に受信した ケーブルの接触不良またはハード 異常 対策 ケーブルの接続部確認、ケーブル断線 確認、ハードウェア交換 | ||
| 6 | Re: WS# = 00 E W 49 と表示されるだけで起動できなくなりました。 | |
| 藤田勉 2015-5-19 7:25:24
[返信] [編集] 富山さん、あさん。 お返事ありがとうございました。 >> 7100/10BEATのＷＳ番号を00に変更された結果 WS番号の「変更手順」は、分かりません。 たまたま、7100/10BEAT の方も ステーション番号が00であったという事でしょうか。 SIFケーブル周りも、もう一度 確認してみようと思います。 | ||
| 7 | Re: WS# = 00 E W 49 と表示されるだけで起動できなくなりました。 | |
| 富山清風 2015-5-19 12:09:40
[返信] [編集] ちよっと余談ですが、 本掲示板内にＷＳアドレスの変更方法が載っていましたので、アドレスを記述しておきます。 h*tp://www.offcom.jp/modules/bluesbb/thread.php?thr=14&sty=2&num=t2 の後半に ｢＊ なお、ＷＳアドレスの変更方法は、Ｎ３１００／１０以降のタ イプでしたら、以下のように行います。｣ 今後の、参考にしてください。 h*tpからhttpの変更をお忘れなく | ||
| 8 | Re: WS# = 00 E W 49 と表示されるだけで起動できなくなりました。 | |
| 名無しさん 2015-5-19 13:14:08
[返信] [編集] 富山さま、情報ありがとうございました。 掲示板もずっと眺めていたのですが、 途中で諦めてしまって、 2003年までは遡っていませんでした。 終端の設定を端末で行うとか、 初耳の情報が沢山ありました。 ありがとうございました。 | ||
| 全部読む 最新50 1-100 板のトップ リロード | ||
| 新規投稿 | スレッド表示 | ツリー表示 | 投稿順表示 | i-mode | トップ |
BluesBB ©Sting_Band