アカウント名:
パスワード:
私は意味のあるまとまりを一画面に収めるためには 悪魔に魂を売る方なので、ばんばん GO TO は 使ってました(20年前の話ですが)。 今なら、ループの流れを切らずにうまく書けるのだろうか…… # Casio Standard Language(手抜きCOBOL) では IF と THEN と ELSE と ENDIF が一行を占めてしまうので、 IF 文を二個書いただけで一画面占領してました。 P.S. Packed Decimal の扱いってどういう問題?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
業務用のCOBOLコードの可読性 (スコア:1, 興味深い)
こんな事態になってしまったCOBOLコードもあるわけで [srad.jp]
COBOLを使ったことがないのでAC
Re:業務用のCOBOLコードの可読性 (スコア:1)
-- 哀れな日本人専用(sorry Japanese only) --
Re:業務用のCOBOLコードの可読性 (スコア:1)
「安易にGO TOは使わない」ってのは一般的だったと思うが...
ご指摘のように,たった 3 行のプログラムを
PERFORM XXX USING XXX-PARM. のように呼んでましたっす.
私は Goto 撲滅論者じゃないものの
「下手糞PGがとりあえず動作するようにGotoで繋いだ」ようなプログラムは,
黙って書き直します.
...それよりも Packed Decimal の扱いとかをどーする?とか思ってしまいまつ.
みんつ
Re:業務用のCOBOLコードの可読性 (スコア:1)
私は意味のあるまとまりを一画面に収めるためには 悪魔に魂を売る方なので、ばんばん GO TO は 使ってました(20年前の話ですが)。 今なら、ループの流れを切らずにうまく書けるのだろうか……
# Casio Standard Language(手抜きCOBOL) では IF と THEN と ELSE と ENDIF が一行を占めてしまうので、 IF 文を二個書いただけで一画面占領してました。
P.S. Packed Decimal の扱いってどういう問題?
-- 哀れな日本人専用(sorry Japanese only) --
Re:業務用のCOBOLコードの可読性 (スコア:0)
際には、単に変換 (内部表現の形式からするとそれ程面倒では無さそう) する
だけではないでしょうか。
そもそも内部十進形式は、メモリ
Re:業務用のCOBOLコードの可読性 (スコア:1)
もちろんそれはそれで重要なのですが,一番の目的は,
「無限桁の十進演算を確保する」ことだと思っていましたが.私.
#特に事務処理では重要.
ついでにPacked Decimal(簡単に言えば符号付BCD)はCOBOL独自の形式ではなく,
IBM等のメインフレームならマシン語レベルで実装されています.
みんつ
Re:業務用のCOBOLコードの可読性 (スコア:0)
Re:業務用のCOBOLコードの可読性 (スコア:1)
Packed Decimal って直接扱えませんよね
別途ライブラリ書くとするなら,Z80 だって BCD 演算向けの
Hフラグとか持っていますので,それなりに書けるでしょうけど.
# で,COBOLなどの事務処理では必須と思われるこの数値表現を
# PHPでどう実装しているのかな,ってのが,元の私のギモソ.
みんつ
Re:業務用のCOBOLコードの可読性 (スコア:0)
;; やっぱりコメントのスピードについていけないや。
;; ついでに中身も。
> 「無限桁の十進演算を確保する」ことだと思っていましたが.私.
すみません、勉強不足でしたか。
無限桁と仰っているのは、計算時に中間結果を保持するにあたり、桁数の制限
が無いということでしょうか。
計算の入出力項目自体の桁数は決まりますものね。
もう余り記憶が定かでないのですが、私の少ない経験では、中間結果の桁数は
演算項目の項目間の桁数から、何らかの規則で決まっていた様な気がしてまし
た。何か重ね合わせた様な…
細いことって覚えてないものですね。これが原因
Re:業務用のCOBOLコードの可読性 (スコア:1)
まあ,どうせヨタ話ですんで,気になさらず.
> アセンブラ以外で Packed Decimal が利用可能な言語は無いと思い込んでしまっ
> たので、この様な書き方になってしまいました。
つうか,昔の汎用機なんて事務処理のためにある(=COBOLが主体)ようなもんですから,CISCの極致としてそういった命令が実装されているんでしょう.ニワトリが先なだけな気がします.
IBM S/360 あたりの edit and mark 命令なんて COBOL の DISPLAY 形式への変換等(たとえば 9(10) -> 9,999,999,999)の動作そのものを実行する命令ですし,translate table 命令なんざ「指定されたテーブルによって指定したメモリ領域内の文字コードの変換を行う」なんていう,とても機械語命令とは思えない仕様 (^^; ですし.
#しかも一命令の実行中にCPUに対して割り込み可能 (^^;;;
そういったシステムの上で実行する前提で作られたソフトウェアをPHP に変換したりすると,単なるインタプリタライブラリの集大成になってしまうのではないかな,もしそうでなければ,期待する計算結果が違ってしまったりするんではないかな,と思った次第です.
みんつ
Re:業務用のCOBOLコードの可読性 (スコア:0)
> IBM S/360 あたりの edit and mark 命令なんて COBOL の DISPLAY 形式への変換等(た
> とえば 9(10) -> 9,999,999,999)の動作そのものを実行する命令ですし,
勉強になります。 ;; もう使うことはないのかもしれませんけど…
本当に COBOL 主体だったんですねえ。
> translate
> table 命令なんざ「指定されたテーブルによって指定したメモリ領域内の文字コードの
> 変換を行う」なんていう,とても機械語命令とは思えない仕様 (^^; ですし.
こんなの知らずにアセンブラ書いてたプログラマも居た気がし
Re:業務用のCOBOLコードの可読性 (スコア:0)
> > translate
> こんなの知らずにアセンブラ書いてたプログラマも居た気がします。
はーい、ここにも。Edit and MarkやTranslateの存在を知りませんでした。
Cコンパイラはこれらの命令を出力しないから...。(言い訳)
# EBCDICの世界でC使いなのでAC