ＮＥＣのオフコン情報掲示板（ノウハウ系）
| ＮＥＣのオフコンを活用するためのノウハウを話し合うための掲示板です。 |
| 新規投稿 | スレッド表示 | ツリー表示 | 投稿順表示 | i-mode | トップ |
| Re: SKYLINKで文字化け | |
| 素人 2014-8-20 14:24:36
[返信] [編集] ＥＸＣＨＡＮＧＥ様 ＃ＤＤＭの画面を確認しましたら、 入力編集という項目 9.Ｃ の設定がされていませんでした。 システム担当者がお手上げだったのでですが、 この設定変更を指示したら即解決できました。 ありがとうございました。<m(__)m> | |
| Re: SKYLINKで文字化け | |
| ＥＸＣＨＡＮＧＥ 2014-8-20 5:37:16
[返信] [編集] ＊ 最初に確認ですが、 まさかいきなりＳＹＳ＠ＤＤＦでテーブル定義（表定義）をしてませんよね？ ローカルにて ＨＯＧＥ−ＤＤＦに表定義をしてから、ＳＹＳ＠ＤＤＦにマージ（併合）しているという前提で説明します。 ＊ Ａ−ＶＸ側にて以下の通り設定して下さい。 （１）＃ＤＤＭを起動し、ＨＯＧＥ−ＤＤＦ上の 問題となっている表を更新（変更）にて呼び出します。 （２）問題となっている項目の定義の「オプション属性」 （タイトルにＯＰと表示されている部分です）の中の 入力編集という項目を 9.Ｃ（混在データ検索）に セットしてください。 （３）更新（変更）が完了したらＨＯＧＥ−ＤＤＦへ出力して 書き込んだ後、 ＳＹＳ＠ＤＤＦへマージ（併合）して下さい。 ＊ 以上の設定にてＳｋｙｌｉｎｋを実行すればたぶん 日本語２バイト、ＡＮＫ１バイトの混在表示が可能になると 思います。お試しください。 ＊ なお、上記の混在検索設定は、基本表、仮想表それぞれ別々に設定できます。 | |
| SKYLINKで文字化け | |
| 素人 2014-8-19 14:58:23
[返信] [編集] 表示文字数の関係で１バイト系と２バイト系を混在して使っている項目があるのですが、SKYLINKでエクセルに抽出すると文字化けします。 ＲＤＢＱの画面では文字化けせずに表示されています。 Ａ−ＶＸでどこの何を確認・変更すれば改善されるでしょうか？ 全くの素人なので、できるだけ詳しく教えていただけると助かります。 よろしくお願いします。 | |
| Re: オフコンシステムをWindows化されている方への帳票設計の質問です | |
| 岩石 2014-5-24 5:29:00
[返信] [編集] はじめまして ＞設計者と開発者が別人の場合でも、プリントレイアウトはかかないのですか？ 弊社では開発者が配置（イメージが分かるものでカラム位置までは考慮してません）と項目属性、桁が分かる程度のものを作成しています。 ＞また、開発者が社外の場合はどうしてますか？ 規模にもよりますが業者さんに作成して頂いております。 ケースバイケースではないでしょうか | |
| Re: オフコンシステムをWindows化されている方への帳票設計の質問です | |
| ころすけ 2014-5-23 20:13:54
[返信] [編集] 設計者と開発者が別人の場合でも、プリントレイアウトはかかないのですか？ → 別人でも書きません。新人や後輩にお願いしてますが書いてません。 オープンしか行っていない後輩はおそらく見たときがないです。 項目だけつたえて配置してから見せてくる方法です。（そんなに時間はかかりません） 指定用紙の場合はEXCELやWORDで作成して印刷業者にだしますがＡＶＸの時とは違い インチ単位ではないので、業者もそんなにいわなくなりました。業者の方がちゃんと設計します。 また、開発者が社外の場合はどうしてますか？ →社外には出していません。 帳票のプログラムを作成してもＡＶＸの時は最低でも3時間から1日はかかると思いますが、オープンでは 最初の一本目でなければ、30分から2時間以内で作成できると思います。（当然個人差はありますが） ＡＶＸの帳票はあんまりやりたくないです。（特にFORMや枠付き） ただ、プログラムを作成した達成感もなくなってしまいましたが・・・ 来週にFORMを作成しますので、がんばりたいと思います。 | |
| Re: オフコンシステムをWindows化されている方への帳票設計の質問です | |
| オフコン太郎 2014-5-22 18:36:24
[返信] [編集] >プリントレイアウトは書きません。いきなり開発ですね（データ>項目を配置するので視覚的にできます 設計者と開発者が別人の場合でも、プリントレイアウトはかかないのですか？ また、開発者が社外の場合はどうしてますか？ 皆様の開発事情/開発体制も教えてください。 | |
| Re: RDBQ2の機能（集計の最大）をCOBOLで | |
| ろろけい 2014-4-23 19:32:18
[返信] [編集] ターラヤンさま 遅いお返事になってしまい申し訳ありません。 情報ありがとうございます。 COBOL内でSQL文。 普通に使えたら、可能性がさらに広がったでしょうね。 試しに、書いてみました。 「'EXEC'が誤っている」 で怒られました（爆） あたりまえですよね(^^; 失礼いたしました。 | |
| Re: 返信ありがとうございます。（オフコンシステムをWindows化されている方への帳票設計の質問です） | |
| 江須扇 2014-4-18 11:26:24
[返信] [編集] 返信ありがとうございます。 誤解があるといけませんので追記します。 ＞改行ピッチを｢８．６ポイント｣にすると ＞⇒66行/頁(上下余白5��)印字可能 ワードで確認しました。 上下余白５ｍｍで 行間隔０．５文字で ６．５ポントで６４行 また、左右余白１４ＭＭで 同じく６．５ポントで１３８文字 ＞２バイト系文字ピッチを｢１１．２ポイント｣にすると ＞⇒136文字/行(左右余白なし)印字可能ということになる。 いえ２バイト系文字なので６８文字です。 ＞すなわち、66行かつ136文字を死守したい場合は、８．６ポイントを使用し、 ＞左右余白が大きくなりすぎるがガマンする。ということになるのですか？ 開発ソフトでピッチとサイズが別々に指定できるので あれば自由にできると思います。 ＞前提条件：150文字/行 ＞で設計しています。 「ガチガチに現在のオフコンと同じレイアウトでないとダメ」 ということでなければ もっと自由でよいのでなないですか？ 利用者が見やすいフォントサイズ、行間隔にした 新標準の行数、桁数でよいのではないでしょうか？ 現状や目的を理解してないの気ままなことを言ってすいません。 お気を悪くされたと誤ります。 | |
| Re: オフコンシステムをWindows化されている方への帳票設計の質問です | |
| ころすけ 2014-4-17 21:03:13
[返信] [編集] ころすけと申します。 オフコン一筋からWindowsオープン系の両方になったのが1996年頃になります。 当時、私も行・桁等を考えていましたし、設計書もプリントレイアウトから行うものばかりだと思っていました。 桁数・行数に関してはいまでは考えたときがないです。 ポイントについては 10ポイント〜14ポイントです。システムでなるべく統一してます。14が多いかな 一覧表なら20明細ぐらい 桁は考えてません（桁落ちしないように） プリントレイアウトは書きません。いきなり開発ですね（データ項目を配置するので視覚的にできます） オフコンでも書かなくなりました。（ダメダメのプログラマーです） 設計書で残す場合は出力したものをそのまま残します。（HELPファイルでも使用しますので） あと設計書には使用フォントを書いて、ポイントは書きません。 行や桁に関しては久しぶりに聞いたような感じで懐かしいです。 （まだ現役のコボラーですが） | |
| Re: オフコンシステムをWindows化されている方への帳票設計の質問です | |
| オフコン太郎 2014-4-17 16:18:43
[返信] [編集] 江須扇さん、すばやい回答/考察 ありがとうございます。 江須扇の部分引用 >ポイントに直すと >改行ピッチ．．．．．．７２ｘ０．１１９＝ ８．６ポイント >１バイト系文字ピッチ・７２ｘ０．０７８＝ ５．６ポイント >２バイト系文字ピッチ・７２ｘ０．１１７＝ ８．４ポイント > ７２ｘ０．１５６＝１１．２ポイント 改行ピッチを｢８．６ポイント｣にすると ⇒66行/頁(上下余白5��)印字可能 ２バイト系文字ピッチを｢１１．２ポイント｣にすると ⇒136文字/行(左右余白なし)印字可能ということになる。 ということですよね？ 上記では仮に改行ピッチ８．６ポイント、２バイト系文字（１１．２ポイント）を採用したとすると、 ｢上下で印字かぶり(部分重複)」が発生するということになるのですか？ すなわち、66行かつ136文字を死守したい場合は、８．６ポイントを使用し、 左右余白が大きくなりすぎるがガマンする。ということになるのですか？ −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 現在、小生は 前提条件：150文字/行 で設計しています。 ｢150文字/行｣:136文字だと全角0.15インチピッチを採用していた帳票の設計が桁不足で設計できないもので・・・ (Windowsでは全角0.15インチピッチが存在しない。とおもいこんでいるので) 150文字/行を採用した場合、 文字ポイントは１０．０(左右余白15��)(計算式は付２を参照) 印字行数は４８行ぐらい。(48行は根拠はありません) になりました。 皆さんの設計時の、 使用文字サイズのポイントは？ 文字数/行は？ 行数/頁は？ 自分の設計にいまいち自信がないもので・・・ すでに、設計/運用されている方々の回答をお待ちしております。 (付１) ｢２バイト系文字ピッチ・７２ｘ０．１１７＝ ８．４ポイント｣は考察していません。 理由は、Windowsの0.15インチピッチが存在しない？のではと考えたからです。 (付２) 297-15-15 ⇒267(297:Ａ４横の��/-15:左余白/-15:右余白) 267/25.4 ⇒10.512インチ(25.4:1インチ=25.4��) 10.512*7.2 ＝75.686(7.2:10ポイント文字は1インチに7.2文字入る) 75.686*2 ⇒151.372(*2:全角計算から半角計算にするため) すなわち10.0ポイント≒150文字(半角)となる | |
| Re: オフコンシステムをWindows化されている方への帳票設計の質問です | |
| 江須扇 2014-4-15 16:17:46
[返信] [編集] 初めまして江須扇と申します。 ＞オフコンシステムをWindows化されている方への質問です。 Ｗｉｎｄｏｗｓ化してないのでちょっと的はずれかもしれませんが ＞WindowsのシステムでＡ４横印字の場合、 ＞｢標準｣では、どのような設計をされていますか？ ＢｉｚＲｅｐｏｒｔｉｎｇとＰｒｉｎｔＶｉｅｗや 複合機の１１ｘ１５→Ａ４横へのＰＲ２０１エミュレータで 出力していたので考えなしで出力しておりました。 ちょっと考察してみました。 ミリメートルとインチと単位が違うのでややこしいですね インチで考えてみます。 汎用紙サイズは 縦 ＝１１．０インチ 横 ＝１５．０インチ 最大印字幅＝１３．６インチ Ａ４縦＝２１０ミリ＝ ８．２６インチ 上下は余白がないのですがＡ４の余白を上下５ミリと考えると Ａ４縦＝２００ミリ＝ ７．８７インチ Ａ４横＝２９７ミリ＝１１．６９インチ 上下は余白がないのですがＡ４の余白を上下５ミリと考えると ７．８７÷１１．０＝０．７１５ 左右の余白をそのままで考えると １１．６９÷１５．０＝０．７７９ つまり上下の縮小率で考えるとかなり小さくなるということです。 改行ピッチは １／６インチ 文字ピッチは１バイト系は ０．１インチ ２バイト系は ０．１５インチ、０．２インチ ここで縮小率をかけると 改行ピッチ．．．．．．．.０．１１９インチ １バイト系文字ピッチ・・・０．０７８インチ ２バイト系文字ピッチ・・・０．１１７インチ、０．１５６インチ ポイントに直すと 改行ピッチ．．．．．．７２ｘ０．１１９＝ ８．６ポイント １バイト系文字ピッチ・７２ｘ０．０７８＝ ５．６ポイント ２バイト系文字ピッチ・７２ｘ０．１１７＝ ８．４ポイント ７２ｘ０．１５６＝１１．２ポイント 計算値では上記のようになるので 上記のピッチに合ったフォントサイズを選ぶと良いのでは考えます。 Ｗｉｎｄｏｗｓの開発者でないので的はずれかな？ | |
| オフコンシステムをWindows化されている方への帳票設計の質問です | |
| オフコン太郎 2014-4-14 11:05:54
[返信] [編集] ｢Windows化」の質問なので、本掲示板には似合わない質問ではないかな。と思いましたが、よろしく、お願いします。 オフコンシステムをWindows化されている方への質問です。 オフコンの印字ですが、一般的には136文字/行、66行/頁だと思いますが、 WindowsのシステムでＡ４横印字の場合、 ｢標準｣では、どのような設計をされていますか？ Q1:ポイントは :使用文字ポイントは何ポイントですか？ Q2:文字数は :136文字/行---> Q3:行数は :66行/頁------> 質問にいたった理由： ・66行/頁で印字しようとすると、ポイントが小さくなりすぎるのでは？ また、136文字/行では左右に｢空｣がありすぎるので、・・・ (設計のやり方にも問題があるのではないかな。と思っていますが・・・) ・現在、66行/頁でぎっしり埋まっている帳票があり、 帳票フォームを大幅に変更するか、ポイントで調整するか、悩んでいます。 以上よろしく、お願いします。 | |
| Re: RDBQ2の機能（集計の最大）をCOBOLで | |
| ターラヤン 2014-4-13 22:55:32
[返信] [編集] 昔、オフコンのCOBOL用でSQL文を使えるようにするSQLEXTENSIONという 別売りのオプションがありました。（今はもう販売終了しているようです。） それを使うと、A-VX RDBに対してCOBOL中でSQL文が使えるようになります。 PERFORM X THRU Y. EXEC SQL SELECT MAX(A) INTO B FROM C-FILE GROUP BY D END-EXEC. MOVE B TO E. ・・・ のような感じで、EXEC SQLとEND-EXECで挟んで、SQL文を書けます。 オープンCOBOLで、OracleDBにアクセスする為のPRO*COBOLというものと ほとんど同じ書き方なので、もし普及していれば、オフコンからオープン COBOLに持っていくのに便利だったのですが。 | |
| Re: カタログ機能（RDBQ2の機能（集計の最大）をCOBOLで） | |
| ろろけい 2014-4-9 18:04:23
[返信] [編集] 江須扇さん 情報をありがとうございます。 カタログ作戦、試してみました。 これをＪＳに組み込めば、うまく使えそうですね。 今回はシンプルな抽出条件なので、COBOLでひたすら読み込み作戦を採用しますが、 今後のために選択肢が増えたのでよかったです。 ありがとうございました。 | |
| Re: カタログ機能（RDBQ2の機能（集計の最大）をCOBOLで） | |
| 江須扇 2014-4-7 23:00:34
[返信] [編集] 始めまして江須扇と申します。 ＣＯＢＯＬではできないですね。 カタログ機能を使って結果をＤＢファイル出力し それを使っておりました。 | |
| Re: ％ユーティリティがあれば良いのですが（ｓｙｓ＠ｓｕｌ のプログラムを ＃ＬＢＭ で全部削除 復旧できますか？） | |
| 江須扇 2014-4-7 22:07:47
[返信] [編集] 始めまして江須扇と申します。 ％ユーティリティのライブラリメンテがあれば良いのですが・・・ 有るとすればＳＹＳ＠ＰＬＭＬに入っていると思います。 ない場合はご担当の販売店かＮＥＣにご相談ください。 ％ユーティリティは下記を参照ください。 以下「苦労人」さんの過去ログ h*tp://www.geocities.jp/tahrayan/geo/log003.txt -------------------------------------------- 731 Re:「％」､「％２」､「％３」とはなんですか？ 苦労人 2006/02/14 14:24 ---- こんにちは！ 弊社のＡＶＸ（開発マシン）に入っている「％」には 1. ソース 一列印字 2. ソース 二列印字 3. ソース 二列印字（改定版） 4. 文字列 検索 5. リビジョン チェッカー 6. ＱＬサブヘッダー メンテ 7. ＪＳ／ＰＭ ＲＵＮコマンド 8. ＳＭＡＲＴパラメータリスト 9. ＣＵＬ ダンプリスト 10. ＬＭＬ ダンプリスト 11. ＥＡＳＹ ＣＯＰＹ 12. ライブラリ 障害復旧 13. アロケートＪＳ生成 14. デアロケートＪＳ生成 96. ＊ ＊ ＊ ＊ ＊ 98. ＊ ＊ ＊ ＊ ＊ ・・・と、以上の機能が選択できます。 ちなみに96を選択すると「％２」が起動され、98は何も起動されません。 「％２」では 1. 有償ロック メンテ 2. ＳＹＳ＠ＦＤＦ メンテ 3. ライブラリ メンテ 4. ＥＵＦカタログ メンテ 5. 拡張ボリューム ダンプ 13. 神 経 衰 弱 14. オ セ ロ 以上の機能が選択できます。 13,14はご愛嬌でしょう。（うちの環境では選択するとｽﾃｰｼｮﾝｺﾏﾝﾄﾞｴﾗｰでコケてしまいます） そして謎の「％３」（％からは連動してません）ですが 01 ... カタログメンテナンス 02 ... 色指定 03 ... ％ＤＥＬＳＶ 04 ... 辞書ユーティリティ 05 ... ＳＹＳ＠ＦＤＦ チェック 06 ... 漢字変換ツール(JIPS <-> S7200) 07 ... 文字列検索 08 ... 漢字コード変換 09 ... アロケート件数計算 10 ... カレンダー 11 ... ＣＯＰＹ ＆ ＣＡＬＬ 一覧表 12 ... 電卓 13 ... 日付指定メンバ抽出 14 ... Ｉ／Ｏマトリックス 15 ... 文字列一括変換 16 ... ＲＤＢキー階層チェック 17 ... ＮＣタイプへの変換 18 ... プリンタ占有 19 ... ボリュームイニシァライズ処理 20 ... ％４ 「％４」はLMが無くて起動できないゲームメニューでした。 何れの機能も、使えるものや使えないもの様々です。 ちょっと起動するのに躊躇するようなメンテナンス機能もあり、未だかつて起動した事の無いものもあります。 ％の文字列検索なんて、ソースライブラリの中から特定の文字列を含むものを検索してくれ、結構便利に使用してます。 | |
| ｓｙｓ＠ｓｕｌ のプログラムを ＃ＬＢＭ で全部削除 復旧できますか？ | |
| 弘前ｊｋ 2014-4-7 11:56:47
[返信] [編集] むりかな！！！ | |
| Re: RDBQ2の機能（集計の最大）をCOBOLで | |
| ろろけい 2014-4-5 9:25:55
[返信] [編集] ころすけさま お返事ありがとうございます。 おっしゃるとおりですね。 今までどれだけ、オフコンの堅牢な順読み処理にお世話になってきたことか。 処理自体はシンプルなのだから、素直に順読み処理で作ってみます。 てか、作ってみて、試してみました。 １２万件のデータを、５分で処理してくれました。 ちょっと古めなハードでこれですから、ぜんぜん問題なかったです。 ありがとうございました。 正直、社内では、オフコンへのバッシングが日々強くなってきています。 時代の流れ、仕方のないことだとは思うのですが、最後まで、オフコンと仲良く付き合っていきたいと思っております。 余談でした。 | |
| Re: RDBQ2の機能（集計の最大）をCOBOLで | |
| ころすけ 2014-4-3 20:48:23
[返信] [編集] オフコンの真髄はシーケンシャルファイルにあり。 ひたすら読み込む事がスピード的にあっていると思います。 スピート気にせず、楽をしたいのでありば顧客毎でSELECTするとか（邪道）、または顧客・売上日でキーファイルを作成してSTARTで逆読みして取得するとかかな・・・ 邪道な事をしてもスピード的に遅くなるので、やっぱり普通に昇順がいいと思います。 | |
| RDBQ2の機能（集計の最大）をCOBOLで | |
| ろろけい 2014-4-3 13:47:03
[返信] [編集] いつもお世話になっております。 RDBQ2で実現できるある機能を、COBOLで、コーディングではなく機能として、 実現できないものかと思い、質問させていただきました。 やりたいことは、RDBQ2の「集計」の「最大値」を取得することです。 日々の売上情報が蓄積されているデータがあり、そこから、 「顧客コード」ごとの「最新の売上日」を取得したいのです。 RDBQ2だと、顧客コードでグループ指定し、売上日の集計欄で最大を選べば、 瞬時に結果を得られますよね。 COBOLでこれを実現するにはやはり、コーディングでなんとかするしかないですかね？ ちなみに、コーディングでの「技」なんかも紹介してくださると嬉しいです。 私は普通に、顧客コード＋売上日の昇順でひたすら読み込み、 顧客コードが変わったときに直前の情報を保存していく、 という発想しか出てこないのですが…。 みなさまよろしくお願いいたします。 |
| 新規投稿 | スレッド表示 | ツリー表示 | 投稿順表示 | i-mode | トップ |
BluesBB ©Sting_Band