アカウント名:
パスワード:
うち電子カルテが富士通系でNetCOBOLのようです。定期的にバージョンアップ(富士通用語ではレベルアップ)しているのでCOBOLerが相当数働いているはず。ちょっと仕様変更(当方としては欠陥の修正)をお願いするだけで高額請求がきているようです。ただ実際コード書いている人にどれだけ配分されているのかは謎です。俺がCOBOLを勉強してコーディングしたいくらい。
20年前のオーダリングシステム(=検査・予約・入退院の管理システム)から継ぎ足して無理やり電子カルテに仕立て上げているので検査オーダーの中にカルテの記事が埋め込まれているようにしか見えない。昔のコードを生かすのもいいけど最初から作り直して見た目だけでもカルテにしてほしかったりする。
#自分は30年前の知識で生きた化石化しているので身の回りの業務用のプログラムはVisualBasicで作製。実際はあんまり大きなことは言えないので富士通さんの前ではできるだけおとなしくしてます。
ちょっとした仕様変更でも結構なお金が掛かるのは、品質を担保作業のための人が裏で沢山動いているからじゃないかな。
だといいんだけどね。天使の取り分に化けていなければ。
昔は丸め誤差の関係で金融系とかではCOBOLが選択されていたと思うのだけど、 状況はかわったのかな?
金融系で未だに使われているの、 過去の資産もあるけれど、 Cと同じでだいたいになれる言語ではCOBOLが一番いいからとかなんじゃないの?とおもっていたりします。
○昔は丸め誤差の関係で金融系とかではCOBOLが選択されていたと思うのだけど◎昔はそもそも言語仕様そのもので十進演算に対応していた処理系が少なかった関係で金融系とかではCOBOLが選択されていたと思うのだけど
所詮スクリプト言語屋にはシビアな金勘定・金利計算の世界は理解できないのです
多倍長整数くらい他の言語でもあるでしょ。
#COBOLerの怖い所は、下手すると多倍長という単語を知らない所だと思ったりする
COBOLって、計算を正確に行うためにBCDベースで数値を表現していなかったっけ。多倍長整数があっても、COBOLが得手とする利息計算とかの会計や金融関係の計算は、そのままではできないと思うけど。
/* COBOLは表記法で挫折した。あれを見てしまうと、MS Basicの末裔やCが使いやすく見えてくる・・・。*/
BCD計算が基本ですけど、2進計算でも構わない項目は2進指定出来ますね。そのほうが速いんで。
つまり、MSX-BASICでも構わなかったわけだ。
ちまたある10進演算ライブラリを使えばいいだけですが、こんなコメントがつくくらい、十進演算の問題点は普通のプログラマには理解されていないので、COBOLの方が安全でしょう。
「ちまたある」はきっと「あまたある」の間違いかと
それだけ。
「何だよそれ」って、マジなコメントなのか?もし、わからなくても、調べりゃすぐ解るようなものだしな。
もし、しらべても、わからんようなら、まともにITの勉強しなおしたほうが将来のためだよ。
ほら、ちゃんとした説明ができない。
だよね整数だなんて言ってるくらいだもんね
多倍長整数/変数なんてアルゴリズム本読めば、大抵の本に乗ってるわ。
COBOLerは恥の上塗りなので黙っていた方が身のためですよ。#まさか図星だったとわ....ホントに知らない人っているんだな。
任意精度演算につかうんでしたっけ。FP1100のC82BASICがそのように実装されていた(から遅かった)という話を聞いたことがある。
バーカ
金融計算で必要なのはせいぜい数十桁の10進数であって多倍長整数ではない
かみあっていないみたいですね。
ここでの話に関係するのは「多倍長整数」ではなくて、「二進化十進」(BCD)なので、他のコメントからはそのズレを指摘されているのでは?
ジョークだったらジョークと書いてよ。
マジでそういう誤解してるのかと思ったわ。#いや時々そういう人がいたりするもんで。COBOLerとか初心者とかに。
恥の上塗りは止めなされ
で、説明はできないの?それとも、調べた結果自分が恥ずかしいことを言ったことに気づいた?
状況は変わっていないのでは?COBOLがCOBOLたる所以であるBCD演算(十進演算)について知らない連中がこんなにいるということは、まともに利息・金利計算のコードを書ける奴もいないということになりますからねだったら、経験を積んだ昔からのCOBOLer雇ってCOBOLで開発するしかないでしょ
BCD演算が欲しければ、BCD演算をする型を定義すればいい話では。
> 昔のコードを生かすのもいいけど最初から作り直して見た目だけでもカルテにしてほしかったりする。
最初からMUMPS(M言語)で開発していれば…
言語はわかるんだけど、ピリオドの有無で予想外の動きするから、あの言語嫌い。
「END-IF」や「END-PERFORM」、「END-READ」なんかを使えばピリオドの有無で動作範囲が変わることも少なくなるよ。
前処理がPERFORM~END-PERFORM.でピリオド一個、主処理と後処理も同様にピリオド一個で書いて読みにくいから書き直せとよく言われました。
そんなのはほかの言語も一緒だよね。 ピリオドに限定しなければ、さらに同類のが出てくる。
やめてください! カンマとピリオドを間違えてロケット落とした子もいるんですよ!
昔のコードを生かすというか、生かさないとどうにもならないこともあります。「コードのやっていることは分かるけど、なんでこうする必要があるか分からない」とかザラだし。前いた会社だと、1つのDBに更新をかけるとそれを別のDBコピーするだけのアプリが山ほどあったし、ひどいものだとそのコピーアプリしか参照していない(様に見える)DBも数十本単位で残ってたりする。
他にも、ハードは既に統合されてるのにソフト側はエミュレーションのまま3つ独立して稼働したままの「いつか統合する予定」のシステム間連携アプリがそれぞれのアプリごとにあったり。
でもこのシステムで通関業務からインボイス発行・シッピングアドバイス(積荷証明)発行・禁輸国判定までしてるから、下手すると外交沙汰になるので正に「触らぬ神」扱いだった。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
うちでは現役 (スコア:3, 参考になる)
うち電子カルテが富士通系でNetCOBOLのようです。定期的にバージョンアップ(富士通用語ではレベルアップ)しているのでCOBOLerが相当数働いているはず。ちょっと仕様変更(当方としては欠陥の修正)をお願いするだけで高額請求がきているようです。ただ実際コード書いている人にどれだけ配分されているのかは謎です。俺がCOBOLを勉強してコーディングしたいくらい。
20年前のオーダリングシステム(=検査・予約・入退院の管理システム)から継ぎ足して無理やり電子カルテに仕立て上げているので検査オーダーの中にカルテの記事が埋め込まれているようにしか見えない。昔のコードを生かすのもいいけど最初から作り直して見た目だけでもカルテにしてほしかったりする。
#自分は30年前の知識で生きた化石化しているので身の回りの業務用のプログラムはVisualBasicで作製。実際はあんまり大きなことは言えないので富士通さんの前ではできるだけおとなしくしてます。
Re:うちでは現役 (スコア:2, すばらしい洞察)
ちょっとした仕様変更でも結構なお金が掛かるのは、品質を担保作業のための人が裏で沢山動いているからじゃないかな。
Re: (スコア:0)
だといいんだけどね。天使の取り分に化けていなければ。
COBOLのいいところは小数点以下の計算だとおもうけど (スコア:0)
昔は丸め誤差の関係で金融系とかではCOBOLが選択されていたと思うのだけど、 状況はかわったのかな?
金融系で未だに使われているの、 過去の資産もあるけれど、 Cと同じでだいたいになれる言語ではCOBOLが一番いいからとかなんじゃないの?
とおもっていたりします。
Re:COBOLのいいところは小数点以下の計算だとおもうけど (スコア:1)
○昔は丸め誤差の関係で金融系とかではCOBOLが選択されていたと思うのだけど
◎昔はそもそも言語仕様そのもので十進演算に対応していた処理系が少なかった関係で金融系とかではCOBOLが選択されていたと思うのだけど
所詮スクリプト言語屋にはシビアな金勘定・金利計算の世界は理解できないのです
Re: (スコア:0)
多倍長整数くらい他の言語でもあるでしょ。
#COBOLerの怖い所は、下手すると多倍長という単語を知らない所だと思ったりする
Re: (スコア:0)
COBOLって、計算を正確に行うためにBCDベースで数値を表現していなかったっけ。
多倍長整数があっても、COBOLが得手とする利息計算とかの会計や金融関係の計算は、そのままではできないと思うけど。
/*
COBOLは表記法で挫折した。あれを見てしまうと、MS Basicの末裔やCが使いやすく見えてくる・・・。
*/
Re:COBOLのいいところは小数点以下の計算だとおもうけど (スコア:1)
BCD計算が基本ですけど、2進計算でも構わない項目は2進指定出来ますね。そのほうが速いんで。
Re: (スコア:0)
つまり、MSX-BASICでも構わなかったわけだ。
Re: (スコア:0)
ちまたある10進演算ライブラリを使えばいいだけですが、こんなコメントがつくくらい、十進演算の問題点は普通のプログラマには理解されていないので、COBOLの方が安全でしょう。
Re: (スコア:0)
「ちまたある」はきっと「あまたある」の間違いかと
それだけ。
Re: (スコア:0)
「何だよそれ」って、マジなコメントなのか?
もし、わからなくても、
調べりゃすぐ解るようなものだしな。
もし、しらべても、わからんようなら、
まともにITの勉強しなおしたほうが将来のためだよ。
Re: (スコア:0)
ほら、ちゃんとした説明ができない。
Re: (スコア:0)
だよね
整数だなんて言ってるくらいだもんね
Re: (スコア:0)
多倍長整数/変数なんてアルゴリズム本読めば、大抵の本に乗ってるわ。
COBOLerは恥の上塗りなので黙っていた方が身のためですよ。
#まさか図星だったとわ....ホントに知らない人っているんだな。
Re: (スコア:0)
任意精度演算につかうんでしたっけ。
FP1100のC82BASICがそのように実装されていた(から遅かった)という話を聞いたことがある。
Re:COBOLのいいところは小数点以下の計算だとおもうけど (スコア:1)
バーカ
金融計算で必要なのはせいぜい数十桁の10進数であって多倍長整数ではない
Re: (スコア:0)
かみあっていないみたいですね。
ここでの話に関係するのは「多倍長整数」ではなくて、「二進化十進」(BCD)なので、
他のコメントからはそのズレを指摘されているのでは?
Re: (スコア:0)
ジョークだったらジョークと書いてよ。
マジでそういう誤解してるのかと思ったわ。
#いや時々そういう人がいたりするもんで。COBOLerとか初心者とかに。
Re: (スコア:0)
恥の上塗りは止めなされ
Re: (スコア:0)
で、説明はできないの?
それとも、調べた結果自分が恥ずかしいことを言ったことに気づいた?
Re: (スコア:0)
状況は変わっていないのでは?
COBOLがCOBOLたる所以であるBCD演算(十進演算)について知らない連中がこんなにいるということは、まともに利息・金利計算のコードを書ける奴もいないということになりますからね
だったら、経験を積んだ昔からのCOBOLer雇ってCOBOLで開発するしかないでしょ
Re: (スコア:0)
BCD演算が欲しければ、BCD演算をする型を定義すればいい話では。
Re:うちでは現役 (スコア:1)
> 昔のコードを生かすのもいいけど最初から作り直して見た目だけでもカルテにしてほしかったりする。
最初からMUMPS(M言語)で開発していれば…
-------- tear straight across --------
Re: (スコア:0)
一か月もかからないよ。オブジェクト指向型COBOLじゃなければ。
# NetCOBOLつかってても新機能は使ってないんだろうな。
Re: (スコア:0)
言語はわかるんだけど、ピリオドの有無で予想外の動きするから、あの言語嫌い。
Re:うちでは現役 (スコア:1)
「END-IF」や「END-PERFORM」、「END-READ」なんかを使えばピリオドの有無で
動作範囲が変わることも少なくなるよ。
らじゃったのだ
Re: (スコア:0)
前処理がPERFORM~END-PERFORM.でピリオド一個、
主処理と後処理も同様にピリオド一個で書いて
読みにくいから書き直せとよく言われました。
Re: (スコア:0)
そんなのはほかの言語も一緒だよね。 ピリオドに限定しなければ、さらに同類のが出てくる。
FORTRANのことかー! (スコア:0)
やめてください! カンマとピリオドを間違えてロケット落とした子もいるんですよ!
Re: (スコア:0)
昔のコードを生かすというか、生かさないとどうにもならないこともあります。「コードのやっていることは分かるけど、なんでこうする必要があるか分からない」とかザラだし。
前いた会社だと、1つのDBに更新をかけるとそれを別のDBコピーするだけのアプリが山ほどあったし、ひどいものだとそのコピーアプリしか参照していない(様に見える)DBも数十本単位で残ってたりする。
他にも、ハードは既に統合されてるのにソフト側はエミュレーションのまま3つ独立して稼働したままの「いつか統合する予定」のシステム間連携アプリがそれぞれのアプリごとにあったり。
でもこのシステムで通関業務からインボイス発行・シッピングアドバイス(積荷証明)発行・禁輸国判定までしてるから、下手すると外交沙汰になるので正に「触らぬ神」扱いだった。