【初心者歓迎】最新COBOLについての質問スレ
■ このスレッドは過去ログ倉庫に格納されています
みんなでCOBOLの話題をしましょう。
質問あったらどうぞ。
最新リリース COBOL 2002
http://ja.wikipedia.org/wiki/COBOL
■ フリーCOBOL
OpenCOBOL
http://jp.opencobol.org/
TinyCOBOL
http://tiny-cobol.sourceforge.net/index.php
第4次COBOL規格 COBOL2002のご紹介
http://www.cobol.gr.jp/knowledge/next_standard/standard002.html
COBOL2002では、全体で約150の追加変更が行われています。ただし、追加変更項目の互換性の保持には
十分に注意がはらわれており、従来のCOBOLプログラムから外れるものではありません。大きな追加機能項目として次の項目があります。
1. コンパイル時指示機能
2. 自由形式の正書法
3. ビット操作機能
4. 漢字等の多オクテット文字機能
5. 浮動小数点データ操作機能
6. ポインタ項目とアドレス付け機能
7. 利用者定義のデータ型機能
8. 利用者定義の関数機能
9. ファイルの共用と排他制御の機能
10. 画面処理機能
11. 例外割り込み処理機能
12. データの妥当性検査機能
13. オブジェクト指向機能
14. 言語間連絡の拡張
15. 標準算術演算と３１桁への拡張
16. その他（POSIＸのロケールに対応した地域・文化固有機能、既存プログラムとの互換） >>159
やっぱり使えないのか。ありがとう。
>>160
まさにそのマイグレーション案件なんだわ >>161
すごいね
オンラインとかどーすんのよ？ >>162
オンライン部分はOpenCOBOLじゃないだろ
OpenCOBOLは基本的にバッチ処理メイン
UI部分は他の言語で実装してんじゃね
>>161
変数名はJavaみたいにアルファベットでローマ字読みぐらいにするしか無いと思うぞ >>161
こういう例は元々、移行元がOS依存の漢字をシステムオープン化する事想定せず運用してたツケだろうな
それなのにオープン化するってプロジェクトそのものが失敗し易い所からスタートしてる事になる なお、これは長崎県庁での汎用機のOpenCOBOL+Perlへのオープン化事例だが
https://docsplayer.net/41528190-Osc_opencobol-pptx.html
UI部分はPerlでそれをCOBOLに引き継いでると思われる
RDBアクセスもPerl
バッチ処理はCOBOLで印刷部分は色々と工夫はしてる様だ >>162
>>163
オンラインもバッチもCOBOLのまま動かすんだよ。オンラインはjavaからCOBOLを動かす。163が言う通り変数名は辞書作って変換するしかない。
>>164
日本のCOBOLが気を利かせすぎなんだよ。 >>166
>>JavaからCOBOL
出た!!
UI自体はJavaで裏でOpenCOBOL稼働か
Javaのライセンスうんぬんはプロジェクトリーダーは理解してんかな? JAVA＋opencobolなのね
東京システムハウスもそんな感じでやってたな
あと困るのは、データベースへのアクセスだろな
既存がREAD WRITEインターフェースでデータベースアクセスしてるなら、RDBにした場合、アクセスサブ作んなきゃならんので、大変そう RDBアクセス部分はJavaで専用オブジェクトクラス作成だろうな
で、OpenCOBOLからも呼び出してRDBアクセス処理を任せるパターン 呼び出すとCALLインターフェース使うってこと？
READWRITEからCALLにCode直すのが面倒じゃない？ >>170
元々の汎用機でのCOBOLの実装はREAD、WRITEでSAMファイルやVSAMファイルを扱ってるが、この部分は汎用機での固有コーディングなのよ
でOpenCOBOLにするとCOBOLの実装の中でSQL文を組み立ててRDBに対して実行するか、RDBにアクセスするオブジェクトをCALLしてデータ貰うか、OpenCOBOLの固有コーディングになる
どの道、汎用機でのCOBOLコーディングはそのまま使えないので、RDBアクセス部分はJava使う方がOracle使おうがSQL Server使おうがMySQL使おうがMariaDB使おうがPostgreSQL使おうが、Java側で対処する様にしとけば、OpenCOBOL側は何のRDB使ってるか意識せず実装出来る Java(OpenJDK?)からJDBC使ってRDBにアクセスするロジックを作っておく
OpenCOBOLからは、それを利用する様にするだけ OpenCOBOL→GnuCOBOLになってから大部進化してんだな
https://www.softantenna.com/wp/software/gnucobol-2-2/
>>166
オンラインもOpenCOBOL(GnuCOBOL)で動かすとしてるが、汎用機でのプログラムはそのまま使えないし、汎用機のUIとオープンシステムのUIなんて同じには出来ない
マイグレーション出来ると思ってるんかね? BerkeleyDBならREADWRITEインターフェースで、そのままアクセス可能だけどね
オンラインだと、ポスグレなどのRDBにしたほうが、後々便利なんだろうなぁ
ただ、アクセス部分を汎用的に作れないのがイタイ
個別に作るのが面倒なんだよねぇ
レコード定義から、COBOL＋SQLでのアクセスサブルーチンを生成するツールみたいのを
公開してくれたらありがたいんだけど DB連携ツール openCOBOL ESQLを使えば、CURSOR制御で順次アクセスはすぐ作れるけど、
エラー制御とか何処まで必要か分からんのよね >>174,175
>>BerkeleyDB
実用事例が少ないDBは採用されない
>>レコード定義から、COBOL＋SQLでのアクセスサブルーチンを生成するツールみたいのを公開してくれたらありがたいんだけど
そこの部分をJavaで作っとけって話 >>176
BerkeleyDBはISAM使った場合の、gnucobol標準サポートだけどね
直接アクセスできるツールやユーティリティが無いからなぁ
javaで作るとどんな感じになるのか、気になるな
COBOLプログラムの
READ FILE1 INVALID KEY
をCALL に変えるんだよね？ >>177
RDBアクセス部分はGnuCOBOLで外部モジュール化は出来ると思うが、JavaでOracleやMySQL、PostgreSQLにJDBC経由でアクセスする例は過去から事例が多い
そのノウハウ持ってるSierは他の案件で開発した実装事例を持って来るだけだと思う
後はGnuCOBOLからCALLして呼び出すメソッドを定義付けすれば良いだけかと
まあ、書き込み有ったヤツのプロジェクトがどういう方針か不明なので何とも言えんが https://sugaryo1224.hatenablog.com/entry/2018/02/14/053410
新人にCOBOLをやらせる会社が悪い、と言うかやらせる新人にも向き不向きが居るからな
それを見極められない会社も悪い
そもそも可読性重視のCOBOLの重要度を否定してる時点でこのHPのヤツはプログラマとしては二流だな >>166
http://rinta.hatenablog.com/entry/20110114/p1
COBOL→Javaに移行してもCOBOLに近い実装になってしまう事実
それならCOBOLのままオープン化した方が安くつく >>166の案件はEclipseでも使ってるんだろうな
COBOLとJavaのソース混在してるんだろう >>181
オンラインの画面制御ミドルをjavaで動かすんじゃないか？
富士通なら、表示ファイルのDCFILEか、メッセージファイル作ってCOBOLに渡せばいい
うちのシステムもマイグレしたいが、リスク取れないから、次もXSP動作機構で動かすんだろなぁ >>182
なるほどね
画面制御をJava、PHP、Perl、Ruby、Python、JavaScript色々選べそうだが
画面制御JavaでOpenJDKで収まるんかな
でないとライセンス発生する >>184
Java EEってSEじゃないでしょ
OpenSDK=Java SEだし 273 デフォルトの名無しさん [sage] 2018/09/04(火) 08:29:51.03 ID:TKsJiWYY
信用の問題だろ
OracleがOpenJDKを潰そうと思えば直接的な法的手段を用いるまでもない
Oracleはいつでもディストリビュータに対するTCKの提供を停止することができ、それにより既にGPL化で配布されたOpenJDKも即座に破綻する
OracleはTCKのテストケースに対して著作権を有しており、これを侵害することなく互換テストを再構築することは事実上不可能だ
これが現在想定される最悪のシナリオだが、Oracleならやりかねないと思われてしまったこと自体が問題 ライセンスは過去に遡って(既にライセンスを受けたライセンシーに対して)変更出来るものじゃないと思うけど >>184
そもそもJava8以降、JDBCはJDKから外れた
https://docs.oracle.com/javase/jp/7/technotes/guides/jdbc/bridge.html
JDBCは使うDB毎にインストール必要だが、そこの部分がJDKから外れる以上、ライセンスの発生するネタになる
つまりJavaでOpenJDKの範囲内でDBアクセスオブジェクトなど作れないって事
これだけでJavaはオワコン いままで無償で使用できたのが異常なだけで
値段も高くないし普通にOracleに金払えば済む話じゃん 30代のCOBOLのSEに
君のFILLERを埋めるよ？
と言ったら爆笑されて，
食事の約束こぎ着けた プログラミング言語「COBOL」がTwitterトレンド入り AWS Lambdaのサポート言語に追加、技術者がざわつく
http://www.itmedia.co.jp/news/articles/1811/30/news102.html >>176
Berkley DBはUNIXの世界ではとても実績があるDBで、クライアント(?)ツールも多いが、もう新規で使う理由はないだろうな。 >>UNIXの世界
Linuxのシェア考えれば少ない >>165
長崎県庁事例のUI部分はPHPまたはCurl言語だよ
PHP→php_opencobol.so→opencobolで生成した.soファイル
→CALL文でlibperlを使ったFUNCTION呼出→perlのDBD/DBIでmysqlアクセス 富士通のNetCOBOLのライセンス料金が半端無い
Linuxで動かせるけど運用コスト半端無いので導入企業は限られるな >>202
長崎県の例は他に転用しづらい
PHPのUIって後々のメンテとか大丈夫なの?
MySQL使ってるの良いとしてPostgreSQLも使える方が良いと思うけど 今時Postgresql使っている情弱なんているの？
普通にH2でいいじゃん 自宅は今も Postgre だが。
まあ、BSDを今も使ってる変わり者だけどな。 初心者でわからないんですが、COBOLのバッチプログラムってなんでサーバーへの転送先や入力ファイルの配置先などパラメータファイルをいちいち作ってそれを読み込んで、出力して橋渡しで作らないといけないんですか？
直接パラメータをバッチに書いてはいけないのでしょうか？
JP1という日立のジョブ動かすツールがいまいち意味がわからないです。
バトン渡しで全部ファイルでの受け渡しする意味がわからない サブルーチンへcall分でアクセスしてる方法が意味わらかん
どういう方法で関数じみたサブルーチンへアクセスしてるのかやからん それって単にボクが大好きな言語とやりかた違うのはゆるさないじょ！というお気持ち表明でしかないのでは？ COBOLのソースを追跡するマクロを教えて欲しいです
サクラエディタでありますでしょうか？ >>212
JP1の汎用性考えてそうしてるんでは? 初心者ですみませんが、IF分の（)のつけ方で以下の場合、挙動変わりますか？
パターンA
IF （A ＝ 1 or 2 and （B = 1 or 2))
パターンB
IF ((A ＝ 1 or 2) and （B = 1 or 2)) ■ このスレッドは過去ログ倉庫に格納されています
