不要になったCOBOL業務アプリをオープンソースに 108
ストーリー by yoosee
資源再生計画 部門より
資源再生計画 部門より
Anonymous Coward曰く、"IT Proの記事より。NPO法人のOSCARアライアンスが、古くなったCOBOL業務アプリケーションのソースコードを買い取ってオープンソースにする事業を開始するそうです。OSCARアライアンスによるプレスリリースによると
COBOLで開発された業務アプリケーションは、運用費用や新規アプリケーションとの連動などメンテナンス性の不便さから、やむを得ず別に同じ用途のシステムを時代のニーズをもとに再構築するケースがあります。そのような中、当NPO法人は、古くなり見捨てられたCOBOLシステムをオープンソース化することで、同じ業務を利用するユーザーをはじめ、様々な分野に活用していただくことを目的としています。とのこと。買い取ったCOBOLアプリケーションのソースコードは、変換ツールを使ってLinuxやUNIX上で動くPHPコードに変換し、GPLをベースとしたライセンス体系で公開して機能追加や改変に応じて進化させていく方針だそうで、もしうまくいけば画期的なCOBOLコードの再利用となるかもしれませんが、果たして業務用のCOBOLアプリケーションのソースコードをそう簡単に売るところがあるかどうか?疑問に思います。"
むしろ... (スコア:2, すばらしい洞察)
Re:むしろ... (スコア:2, 興味深い)
ちょっとしらべてみると。
同じ住所の会社が、そういうサービスを販売していることがわかるんですけどね。
ある意味コネと実績とテスト用のスクリプトがほしいのでしょう。
#ACはこういうときに使うものかな。
Re:むしろ... (スコア:1)
Re:むしろ... (スコア:1)
今だったら、COBOL→Java変換の方が流行るのでは?
#ひょっとして、もうあるのかな?
#私はPHPの方が好きですので、今回の件は歓迎。
どうだろう? (スコア:1)
Re:どうだろう? (スコア:2, おもしろおかしい)
It's not who is right, it's who is left.
まさか・・・ (スコア:1, 興味深い)
日本医師会から6億以上も使って作ってるのに、
導入はベンダに別料金(数百万円)が必要で、
一向に導入が進まない。巨額の開発費が適切
だったかどうか、問題になってるけど。
(まだ訴訟は起こってないのかな)
ORCAは元々どっかのCOBOLソースを、
何かのツールでCに変換してるんだってさ。
これ、PHPに変換する猛者が出てこないかなぁー。
Re:これのこと? (スコア:2, 興味深い)
そうかな。
「入力の効率」と、「出力(検索や閲覧)の効率化、
入力された情報の効率的利用」を比較してどちら
をとるかという話でしょう。
もともと「コスト」削減が主目的ではなくて、電子化された
医療情報の活用、たとえば引越しても前に通ってた病院
から自分の治療歴をとりよせてより効果的な治療をして
もらうとか、会社の定期健康診断の履歴情報を転職し
ても継続して引き継ぐとか、統計的にデータマイニング処理
して医学の進歩を図るとかそういう「効率的」な利用を
はかるというのが主眼なのではないでしょうか。
もちろん、個人情報漏洩の危険性などのリスクも踏ま
えての話ではあるのだけど。
あと普通に考えて、ドイツ語手書き
紙ベースってのは何か変。
20年近く前 (スコア:1, 参考になる)
まだ使ってるのかどうか不明だけど、こういう事の為なら提供して
もらえる可能性もそれなりにありそうな予感。
# 卒業式には出なかったけど確か卒業出来てた覚えがあるのでAC
Re:20年近く前(オフトピ) (スコア:1, 参考になる)
95年には既に使用されてました。それ以前は分かりませんが。
# 2001年に脱出した記憶があるのでAC
Re:20年近く前 (スコア:1, 参考になる)
思われるのでCOBOLでしょう。
FORTRANは分野的にありえないし、後はPL/I……。
で、図書館なら
・本/雑誌の受け入れ登録
・検索
・貸し出し管理
がメインだけど、
・UI部分が各社固有の(ダム端末用)ライブラリに依存
・ファイルシステムが汎用機用の特殊な構成
・印刷も罫線多用のためこれまた特殊なオーバーレイが必須
・外字の扱いがメーカ依存(っていうか文字自体ASCII体系でない)
と全然使い回せそうにありません。
#10年以上前に図書館システムを開発したSE
Re:20年近く前 (スコア:1, 興味深い)
もっとも、大学図書館のシステム関係ではNIIの仕様変更 [nii.ac.jp]があったりしましたので、使い回せる部分は受入と貸出の基本ロジック以外残っていません。
文字コード体系はUCSに移行しましたので、その辺の処理も再作成対象です。
もし仮にオープンソースなものを作るとしても、もっと後から作られたシステム(例えばkoha [koha.org]など)をベースにした方が低コストで形になる状況だと思います。
帳票は…近年、基本データ吐かせてあとはユーザ処理に委ねるベンダも結構あったりします。ユーザが仕様をまともに作れないのもありますが、それ以前に儲からないシステムですし。
# ユーザなAC。どこかで間接的にお世話になってるかも知れません。
疑問2 (スコア:1)
無断で売っちゃう人、はいないんでしょうか?
業務用のCOBOLコードの可読性 (スコア:1, 興味深い)
こんな事態になってしまったCOBOLコードもあるわけで [srad.jp]
COBOLを使ったことがないのでAC
Re:業務用のCOBOLコードの可読性 (スコア:1, 参考になる)
Cのように業界標準の参照本(K&R, はじめてのC etc.)のような体勢が出来る前から脈々と使われてきた言語ですし、ユーザによっては一子相伝的な継承をしているところもあるくらいですから、ちまたに出回っているCソースよりもずっと難読でしょうね。
C言語と違ってデータの流れや目指しているロジックをソースコード側から推測することはかなり難しいです(だからこそCOBOLを多用していた企業ほど仕様書や変更履歴などの紙を大切にするわけですが)し。
Re:業務用のCOBOLコードの可読性 (スコア:2, すばらしい洞察)
目指しているロジックがソースコード(英文)としてそのまま読める
言語であるはづなのだが:)
ある意味「データの流れやロジックをソースで示す能力」については,
C言語と同等なレベルであるはづなのだが:)
#複雑なループや制御は事務処理には存在しない!という前提の上で.
#200個のファイルを一度にオープンして処理しようとしたら,
#CはCOBOL以上に複雑難解になるに違いない.
#要は適用分野ってことで.
みんつ
Re:業務用のCOBOLコードの可読性 (スコア:1)
-- 哀れな日本人専用(sorry Japanese only) --
Re:業務用のCOBOLコードの可読性 (スコア:1)
ちゅうか, いわゆる構造化COBOLの類でしょ. 各社いろいろ出していたはずですから.
# DATA DIVISIONをマクロ化できて局所変数が使えれば, どうにかなると考えている下手物プログラマなのでID
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コードの可読性 (スコア:1)
もちろんそれはそれで重要なのですが,一番の目的は,
「無限桁の十進演算を確保する」ことだと思っていましたが.私.
#特に事務処理では重要.
ついでにPacked Decimal(簡単に言えば符号付BCD)はCOBOL独自の形式ではなく,
IBM等のメインフレームならマシン語レベルで実装されています.
みんつ
Re:業務用のCOBOLコードの可読性 (スコア:1)
Packed Decimal って直接扱えませんよね
別途ライブラリ書くとするなら,Z80 だって BCD 演算向けの
Hフラグとか持っていますので,それなりに書けるでしょうけど.
# で,COBOLなどの事務処理では必須と思われるこの数値表現を
# PHPでどう実装しているのかな,ってのが,元の私のギモソ.
みんつ
GOTOなしCOBOLプログラム (スコア:1)
その頃使っていたマシンのコンパイラでは既にCOBOL85で標準になったインラインPERFORMやIF~END-IFがサポートされていたので、それを 使いまくりでしたけど。
ちなみにその頃は「GOTOはSECTIONの末尾に飛ばす時にしか使わない」を信条にしていました。
Re:業務用のCOBOLコードの可読性 (スコア:1)
> # COBOL85 ? 誰か必要としていたか ?
規格を策定することを生業とする人。
COBOL85 (スコア:1)
センター側のバカでかいオンライン帳票出力システムには手を付けず、現場のリモートプリンタ側で帳票イメージのデータ横取りする分散システムを構築していたワシはすごく欲しかったが。(意味数値編集項目から数値項目への転記)
売却されるソースコード (スコア:1)
そう考えるとそれを再利用したとしても保守性に難があるものになるのでは?
旅に出ます.(バグを)探さないで下さい.
実際問題 (スコア:1)
さて、ここで問題です。以下の用語について解説して下さい。
・CICS
・AIM
・VIS
・VSAM
・VSAS
・SNA3270
・ETOS52G
・FOCUS
・MANTIS
この後は他のジジイな人に任せた。(^_^;
たのむ (スコア:1)
メーカー別に分けてくれ (スコア:1)
人には分かりません。とりあえず
*NEC
**VIS(ACOS-4用のトランザクションシステム)
**ETOS52G(画面制御を行なうエミュレータ)
です。あと、VIS入れるなら、
**TDS(TDS-MS/TDS-AF :ACOS-6用のトランザクションシステム)
**RIQS(NECのリレーショナルDB)
**INQ(同上:これは知っている人少ないか)
なんかもほしかったりします。
あと、変換と言っても、各会社のCobolには固有の方言が
あるので、それをどこまで吸収できるかどうか。
特に、ACOS-6の36ビット=1word環境って吸収できるのかな。
Re:実際問題 (スコア:1)
・AIM(Advanced Information Manager だったかな)
オンライン系の制御を行うコンポーネントだったかと。
・VSAM(Virtual Storage Access Method)
ファイルのアクセス形態の総称。一般ファイルとは別に専用の領域をハードボリュームに作成して使用します。
当然、ファイルの管理方法も別。大体がAIM配下に置かれています。
SNA3270は通信プロトコルだったかな。IBM系がSNAで富士通系がFNAとだったかと。
VSAS、JCL、何もかも懐かしい・・・。 (スコア:1)
Re:VSAS、JCL、何もかも懐かしい・・・。 (スコア:1)
同士よ
#医療系システムなんて未だにオンライン系がCOBOLだよ...
#三十路まであと二百数十日だけどID
仕様書は (スコア:1)
コードはただの英数字の塊でしかないような気がします。
変数名や関数名がX050012ABとか・・・
仕様書と規約書とソースとコボラーをセットで・・・
Re:仕様書は (スコア:1)
COBOL毛嫌いされてますよねー
案外かわいいやつなのに
#というかCOBOL以外あんまし使った記憶が無いだけ
Re:仕様書は (スコア:1)
#当てずっぽうでしか無いけどID
Re:仕様書は (スコア:1)
こういう状況なら台帳管理というのも仕方がないのかなぁ、とか思ったり(当然そんなのはイヤだけど)。
ところで今でもソースコード残ってるシステムってどの程度あるんですかねぇ?
2000年問題の時は「ソースきぼんぬ」な案件がかなりあったという話もあるようですが。
ソースがあっても権利関係があやふやなものも多そうな予感。
Re:仕様書は (スコア:1)
もっとも、COBOLは新入社員教育で使っただけで、その後業務で使うことはありませんでしたが。
あと、いわゆるcoding standardのことを「標準化」と呼んでいた事にも違和感おぼえたなぁ。「標準化」じゃなくて「標準」だろう、と。「標準」に合わせることが「標準化」だろう、と。
Re:仕様書は (スコア:1)
推奨もされているけど、現実はそうで無い。
#うちの会社がそうっぽいのはヒミツ。
実は (スコア:1, 興味深い)
簡単には汎用性のあるソースとしては利用できないんですよね。
最も多い独自仕様はスクリーン制御の辺りでありここが一番の問題、
次にプリンターに罫線を印刷する時に制御コードを送ってる場合や
フォームを使う場合等の差異から簡単には利用できませんね。
だからPHPに変換して公開するんだろうけど、
変換プログラムの性能によっては人的にコンバードする部分が多すぎて
単純に最初からPHPで書いたシステムをオープンソースで公開する方が楽ではないのかと…。
COBOLのコード自体より (スコア:1)
色々会社の色々な業務を集めて分析し、フレームワークを作れればR/3の一ちょ上がり。
実は (スコア:1)
PHPの文字列リテラルの定義にCOBOLソースが直接記述されていて、
COBOL実行関数にその文字列を・・・
これならPHPのソースであることは間違いない。
機械的に作業すると・・・。 (スコア:1)
変換する事に関して異論はないのですが、
仮に機械的に変換してお終いになると怖い結果になる気がします。
昔、CASEツールというのがありましたが、
あのツールからできるソースは目を覆い隠したくなるモノしか
ありませんでした。
ツールの完成度にもよりますが、出来上がりのソースは少なくとも
オブジェクト指向が含まれる生成物であって欲しい事を願います。
でなければ、人の手を介在して、
まともにメンテナンスできる形態である事を願います。
そもそもCOBOLというよりも.... (スコア:1)
いやがらせ? (スコア:1)
coboler.com [coboler.com]
クレクレタコラで申し訳ないけど... (スコア:1, 興味深い)
個人情報の入力がうっとうしく感じます。
「オープンソース・ビジネスリーグ by OSCAR」利用許諾契約約款第1.1版 より
(ソースコードの複製及び公衆送信)
第3条 甲は、乙に対し、乙が以下の各号の条件を満たす場合に限り、乙は、オープンソースプログラムのソースコード又はその複製物を、いかなる媒体においても複製又は公衆送信すること(送信可能化状態にすることを含む)を許諾する。
(1)複製物に適切な著作権表示をすること
(2)複製物に無保証である旨の文言を表示すること
(3)本約款を複製物と共に配布すること
とのことで、再配布の制限は「著作権表示」「無保証明言」「約款との配布」だけのようなんですが、
どこかに個人情報入力無しでgetできるミラーサイト等はないでしょうか?
# ペンギンオフィス2に興味があるんですけど...
考えようによっては (スコア:1)
PHPに移植もしてもらえるんだよね?
特に秘密にする理由がなければけっこうおいしい話なんじゃなかろうか?
...まぁ 秘密にする理由があって公開できないことの方が多いんだろうけど
Re:ソースだけでなく (スコア:2, おもしろおかしい)
というのがあるそうです。
...他意はありませんとも。
Re:オープンソースで公開する理由 (スコア:1)
バブル崩壊前後の就職組の方が、先をみる力を養ってないので、よっぽど使えない。
そーゆーバカの下にいることに疲れて辞めるところなのでID
fj.jokes出身:
Re:オープンソースで公開する理由 (スコア:1, おもしろおかしい)
事だと思ってた
Re:上流層 (スコア:1)
これだけ様々なシェルやスクリプト言語があるなら、「UNIX/Windowsで動くJCL環境」があってもおかしくない、と探してみたことがあるのですが見つけられませんでした。
どなたか、ご存知でしょうか?