システム開発■ 改元の対応試算
2019年5月1日に改元が行われるようです。システム屋としては、これに対応しなければなりません。そろそろ年も変わりそうなので、影響範囲を調べて見ました。
今のシステムは１０年くらい前に作ったものなので、元号の変更対応は出来ているはず。手形の関係とか、一部の機能で和暦を使っていますが、データ自体は西暦だし、西暦と和暦の変換は共通処理になっているので、そこを修正するだけで対応完了・・・の筈だったのですが、実際に調べて見ると誤算がありました。
■ ListCreator（帳票）
まず、帳票に直接「平成」と書かれているものがありました。何かの冗談かと思ったのですが、本当に元号を直打ちしています。
・・・誰だ、こんな帳票作ったのは！
さらなる誤算がListCreatorの和暦表示。ListCreatorというソフトで帳票を作っているのですが、かなりの本数で和暦表示をしていました。
まともに対応すると、１ヶ月以上かかりそうだったのですが、ソフトウェアの変換であれば、何かの設定ファイルの変更とかパッチとかで対応できる気がします。
そう思って調べたのですが、ListCreatorには「和暦のカスタマイズ指定」が可能らしいという情報を見つけました。これで行けるかと思って、自分が使っているパソコン上で設定を弄って見たのですが、ListCreatorデザイナのプレビュー機能では確かに新元号への対応が出来ました。
これで行けるかと思ったのですが、ここに罠が・・・
実際にAPサーバの設定を修正して試して見たのですが、「和暦のカスタマイズ指定」が機能しません。どうしてだろうと思ったのですが、マニュアルを読むとCOBOLからの出力には対応していないとか。
だったら、Javaからだったらどうかと思ったのですが、こちらもダメです。
んで、こちらの理由はListCreatorのバージョン。「和暦のカスタマイズ指定」ってV10.4からの対応だったらしく、APサーバのバージョンはV10.0。
・・・結局、地道に対応するしかなさそうです。
■ 後書き
しかしこれ、富士通（ListCreatorの製造元）はどう考えてるんですかね。せめて修正パッチを提供するのが当然の対応だと思うのですが。対応しているバージョンにアップデートしろと言われても、Solaris（APサーバのOSはSolaris）に対応したバージョンってV10.0までだった気がします。
うーん、プログラムで和暦変換するって手もありますが、それよりも和暦表示を止める方が良い気がします。とりあえず、その前提で見積もりますかね？
ちなみに、Oracleの機能を使用した和暦変換も１機能だけ使っていたのですが、それはプログラムを書き換えることにしました（Javaで作った共通処理で和暦変換する）。Oracleの設定で対応することも可能みたいですが、たった１機能しか使っていないのであれば、プログラムを直した方が早いです。
最新の記事：http://harikofu.blog.fc2.com/
投稿記事の一覧：http://harikofu.web.fc2.com/
--- blog end —
スポンサードリンク
0
0
