古いCOBOLシステムをどうするか――。安定稼働しているものの、今後の保守要員の確保やクラウドサービスとの連携は解決しなければいけない。そう考えるユーザー企業に1つの解決策が見えてきた。 無料でCOBOLをJavaに変換 COBOLプログラムをJavaプログラムに変換するツール「opensource COBOL 4J 開発者版」がそれである。オープンソースビジネスを推進するOSSコンソーシアムが2020年7月1日にソースコード共有サイト「GitHub」に公開した。オープン・ソース・ソフトウエア（OSS）なので誰でも無料で利用できる。 opensource COBOL 4J 開発者版はプログラムを変換するとともに、必要なモジュールを生成する。SAMやISAMへのファイルアクセスはJavaプログラムに変換後も利用できる。現時点で「COBOL85」といったCOBOLの標準仕様にのっとったプログラ
損害保険ジャパン日本興亜は、基幹システムの刷新を進めている。従来のCOBOLアプリケーションの大半をJavaに切り替えるという。 日本オラクルは2016年4月19日、損害保険ジャパン日本興亜（以下、損保ジャパン日本興亜）が進めている基幹システム再構築プロジェクトを支援すると発表した。 システムの検証に利用するクラウド型のJava実行環境を提供するほか、損保ジャパン日本興亜に特化したJava技術者の育成プログラムを提供する。今後2年間で最大40名のJavaリード・アーキテクトの育成を目指す。 損保ジャパン日本興亜は現在、フィンテックの実現などに向けて基幹システムの刷新を進めている。計画では、従来のCOBOLアプリケーションの大半をJavaアプリケーションに切り替える。これに伴い、Javaの開発力と技術力、迅速に検証可能なクラウド型のJava実行環境などを必要としている。Javaの国際的標準化
最新の分散環境でのシステム開発においても、COBOLが最も適切なプログラミング言語である理由を解説します。 1) ビジネスロジックの記述力 COBOLは COmmon Business Oriented Language です。以下のような情報処理の世界で必要十分な機能が言語の文法としてサポートされています。 順・相対・索引編成のファイルアクセス ソートマージ 31桁までの十進演算 金額編集等の印刷形式への変換 非手続き型の帳票印刷機能 Javaや.NETなどでは、このような機能は言語とは別のライブラリを使用することになり、プログラムの可読性が低下します。 2) 保守性・可読性の高さ 企業の情報システム部では、30年前に書かれたCOBOLプログラムが今も保守されて業務で活躍している例が多くあります。もちろんはじめにプログラムを書いた人はとっくに担当ではなくなっています。C や BASICで
1980年代には「COBOLは衰退するので、ほかのプログラミング言語に移行しなければならない」などと言われた。実際に1970～1990年代に書かれた細かなCOBOLプログラムのほとんどは新しいシステムと新しい技術に置き換えられている。しかし、銀行、保険会社、製造業、小売チェーン、医療機関といった大企業のミッションクリティカルなシステムは依然として大昔にCOBOLで書かれたコードによって運営されている。多くの企業はこれらのシステムを何度も入れ替えようとしたが、システムが全体が巨大で複雑な上、重要なビジネス・プロセスに統合されていること、また問題なく動いていることからこうした取り組みの多くは失敗した。 ITWORLDの記事によると、こうしたCOBOLで書かれたシステムを支えてきた団塊世代プログラマの引退が近づいているという（ITWORLD、本家/.）。 今は大学のプログラム講座などでは教えるこ
先の宣言 に基づき、COBOLを勉強している。 テキストは『 入門COBOL 』を使用。 処理系には OpenCOBOL を使用。 お勉強の成果をレポートしてみる。 今のところの印象としては、はっきり言ってこれは素晴らしい言語だ。激しく興奮しながらテキストを読んでいる。 確かに汎用言語としてはかなり貧弱だし、これしか知らないCOBOLerがそのままの感覚でネットワークプログラムなんかを設計した日には悲惨なことになるのは目に見えている。私なんか、過去に単価や日付が文字列で格納されているRDBを見ただけでのけぞってしまったし。 でも、なるほどCOBOLは会計処理DSLとして素晴らしい。DSL厨としては興奮せずにはいられない。 これを超える金融DSLは今のところない というのも頷ける。 大規模なソフトウェアを書こうと思ったときに落とし穴になりそうな仕様はどっさりあるけれども、そんなことは触る前か
GnuCOBOL (formerly OpenCOBOL) is a free, modern COBOL compiler. GnuCOBOL implements a substantial part of the COBOL 85, X/Open COBOL and newer ISO COBOL standards (2002, 2014, 2023), as well as many extensions included in other COBOL compilers (IBM COBOL, MicroFocus COBOL, ACUCOBOL-GT and others). GnuCOBOL translates COBOL into C and internally compiles the translated code using a native C compile
COBOLプログラミング入門 COBOLプログラミングについてはじめての方でもわかるように図解を取り入れわかりやすく解説しているCOBOL入門サイトです。 KIDLE出版 2021/6/11追記 最新のCOBOLバージョンに対応したKindle本を作成しました。本サイトの内容を大幅に加筆修正した内容となっています。 本サイトの内容は執筆してから年数が経過しているため、こちらをお読みいただけると幸いです。 第１章 COBOL概要 COBOLとは 第２章 COBOLプログラムの構成 COBOLプログラムの全体構成 見出し部（IDENTIFICATION DIVISION） 環境部（ENVIRONMENT DIVISION） データ部（DATA DIVISION） 手続き部（PROCEDURE DIVISION） 第３章 COBOLコーディングルール コーディングフォーマット コーディングルール
この歴史的背景から、COBOLもFORTRANもソース行の形式が固定カラムになっています。COBOLではソースの一行は以下のような領域で構成されます。 1～6けた目 行番号を書く領域 7けた目 ここに「*」を書くとコメント行扱いとなる、継続行であるときはここに「-」を書く 8～11けた目 主に見出しやラベルを書く領域 12～72けた目 本文を書く領域 73～80けた目 注記を書く領域、本文には影響しない 2.長ったらしい記述 普通のCOBOLプログラムの1行目には、 と書いてあります。これがプログラムの見出しを記述する構文です。 当然、1文字でもスペルミスがあるとコンパイルエラーとなります。Javaに慣れたプログラマが初めてCOBOLのソースを見ると「これがプログラミング言語か？」と首をかしげるでしょう。それほどに COBOLの記述は冗長に見えます。 これは言語の設計目標の1つとして英語の
今cobolでゲームを作っています。 シュミレーションゲームなのですがうまく流すことができません。 文法チェックをかけたのですがエラーはでません。 ソースを貼るので、わかるかたがいましたら回答お願いします。 今cobolでゲームを作っています。 シュミレーションゲームなのですがうまく流すことができません。 文法チェックをかけたのですがエラーはでません。 ソースを貼るので、わかるかたがいましたら回答お願いします。 IDENTIFICATION DIVISION. PROGRAM-ID. 戦闘シュミレーションゲーム． プログラマ miaou. ENVIRONMENT DIVISION. INPUT-OUTPUT SECTION. FILE-CONTROL. SELECT RANDOM1-TBL ASSIGN TO "A:RANDOM1.TXT". SELECT SYUTURYOKU ASSIG
私は株式会社ジェイ・イー・エスという会社で、業務アプリケーションソフトの開発に携わっておりました。平成14年5月6日より、同社開発部より営業部に配置換えを命じられました。ソフトウェア開発の営業に携わったことがない技術者の私が営業に転身したのです。最初は営業に対する不安がありました。しかし技術者の気持ちは人一倍わかると自負しておりました。何故ならば自分自身が技術者だったからです。 営業活動を行っている内に、一つの疑問が湧いてきました。「COBOLの案件はある一方、仕事がないCOBOL技術者が大勢いる」という疑問です。確かに案件確保できないのには、できない理由がありました。例えばスキル不足、年齢が高い、生活の事情で止む無く残業が出来ないなどです。 その頃は人余りの時代。ユーザーはあまり考えなくても技術者の確保ができる時期でした。そのためユーザーは利益追求にのみ目が向けられ、技術者の生活や気持ち
【要旨】 メインフレーム上で長期間稼働しているシステムの多くは、維持管理コストの高止まり、ビジネスの変化への柔軟な対応が困難などの課題を抱えており、これらの課題を解決する手段としてのITモダナイゼーションが注目されている。ITモダナゼーションの手法として、現行資産の業務ロジックを維持したままオープン環境への移行を行うリホスト・リライト手法があるが、これらの手法は技術的にも成熟し、希望する移行先プラットフォームへの、低コスト・低リスクでの確実な移行が実現できるようになってきている。 一般的な移行プロジェクトでは、アプリケーションの移行に焦点があたりがちであるが、基盤の考慮は非常に重要である。NRIではリホスト・リライト手法と、クラウド上のPaaS（Platform as a Service）として提供する高信頼性・高生産性仮想アプライアンス基盤とを組み合わせたソリューションを提供している。
富士通と富士通アドバンストソリューションズ（FASOL）は2012年8月15日、企業情報システム向けの「設計書化モダナイゼーションサービス」を発表した（図1）。同日より販売活動を開始する。 このサービスでは、富士通およびFASOLの担当技術者が顧客企業のメインフレームを調査。COBOLやPL/Iなどで書かれているアプリケーションのソースコードを解析し、日本語の設計書に置き換える（図2）。アプリケーションの保守担当者はソースコードではなく日本語の設計書によってアプリケーションの仕様が把握できるため、アプリケーションの保守性が向上するという。 また、日本語の設計書から新規システム用のJavaソースも生成可能。この作業で富士通側はFASOLの開発支援ツール「InterDevelopシリーズ」を使う。同ツールはテスト関連の機能も備えており、設計書からJavaソースの動作テスト項目の候補を自動抽出す
あるSIerの下請けをしていたときの事でした。 RDBMSをつかったよくあるWebシステムの開発だったのですが、休日などのマスターテーブルのを編集する画面の設計書に「レコード番号」という項目があるのを見つけて唖然としました。 RDBMSを使ったシステムでいまどきレコード番号はねぇだろ！！とおもいつつ、このレコード番号を削除してもいいか相談しにいったら、「いや、客が言ってるからレコード番号は必要なんだ」とか、「レコード番号で管理するとデメリットがどうだ」とかで、1時間くらい時間が無駄になりました。 結局レコード番号は無しになったけど。 もし、客からの指示だったとしても、マスタテーブルのレコード番号での管理はやめるべきです。 特にレコードが重複して存在したら困るようなマスタテーブルでならなおさらです。 素直に主キーを使って管理していれば、余計なコーディングをする手間も、バグを作り込むリスクもな
50年前に事務処理用に開発されたCOBOLは、いまでも多くの企業で使われ続けている。基盤部分が近代化してもCOBOLは生き残るかもしれない（編集部） 今回からいよいよCOBOLの文法などの詳細に進みます。第1回「Java／.NET開発者のための『ここが変だよ、COBOL』」で述べたとおり、COBOLはその機能の大部分を言語の構文によってサポートしているため、言語の文法を学習するには比較的多くの時間を必要とします。そこでこの連載では基本的な構文要素を学習するにとどめることにします。 なお、現在のCOBOLはオブジェクト指向要素も追加され、多様な記述が可能になっています。しかし、現存するCOBOLソースの大多数は単一のプログラムを定義するような古典的なものです。そこで、本記事でも話題をこの範囲に限定します。 また、読み易さのために意図してリファレンス的な記述を避けていますので、さまざまな例外的
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: ［改訂新版］ 実践COBOLプログラミング入門: 結城圭介: 本
