(2019-02-27) IBMからの情報「 元号の変更に伴う IBM i の対応について 」に詳細情報が記載されました。当ページは役割を終えたと考え、更新を終了します。
今年(2019年)の5月に元号が変わります。
今回は、IBM i での新元号/改元対応について考えたいと思います。
和暦対応処理を行っていなければ特別な対応は不要
現在の IBM i の内部クロックには協定世界時(UTC)が使われています。西暦で運用していれば、当然、改元の影響は受けません。特別に和暦に対応した処理を行っていなければ、改元への対応は不要です。
和暦対応として考えられるのは、下記の3つでしょう。
- システム日付/QDATEに和暦を使っている
- データや表示・印刷に和暦を使っている
- 元号合字を表示・印刷に使っている
システム日付/QDATEに新元号を使うには
現在、システム日付/QDATE を和暦/平成で運用している場合で改元後は新元号で運用をする場合の設定です。西暦で運用しているのであれば対応は、この項の対応は不要です。
現在の IBM i の内部クロックは UTC が使われています。システム値 QTIMZON に UTC からの時差やサマータイムの情報を含むタイムゾーン(*TIMZON)を指定することでローカルタイムである QDATE や QTIME が決まります。
タイムゾーンにはローカルカレンダーの年が西暦と何年違うかを指定する「年オフセット(YEAROFS)」パラメーターがあります。新元号をシステム日付にする場合、新しいタイムゾーンを作り、西暦と新元号の差である「-18」を設定します。
タイムゾーンの名前は任意です。下記では仮に「JP_NEW」という名前でタイムゾーンを作成しています。
CRTTIMZON TIMZON(JP_NEW) OFFSET(+540) YEAROFS(-18)
作成したタイムゾーンを QTIMZON にセットすれば、QDATE は即時に新元号に切り替わります。制限状態や IPL は不要です。
CHGSYSVAL SYSVAL(QTIMZON) VALUE('JP_NEW')
ユーザーデータに新元号を使う/西暦－和暦変換機能
西暦－和暦の変換を行っている場合、どのような方法で実行しているかを調査します。
IBM i の COBOL/RPG/SQL には、直接、和暦対応機能や西暦－和暦変換機能はありません。アプリケーションで独自に実装している場合は、新元号への対応もアプリケーションの改修で対応します。
ILE CEE Date and Time APIs
ILE用のAPIは和暦に対応した機能を持っています。
CEEDAYS, CEEDATE, CEESECS, CEEDATM といった ILE CEE Date and Time APIs を使って和暦の処理を行っている場合は、IBM i の対応を待つ必要があります。
これらのAPIでは<JJJJ>で和暦であることを示します。
Java
Javaにも和暦対応の機能があります。
IBM i 用のJAVAとして現在サポート期間中ものもは7.0、7.1、8.0です。Java 6.0のサポートは2017年12月31で終了しています。
Javaの更新が提供されるのを待てない場合やサポートされていないJavaを使っている場合はプロパティファイルの変更,Javaバージョン別の改元(新元号)対応まとめで対応できるようです。
ロケール
ユーザープロファイルにはロケールが設定されます。日本語用のロケールには和暦情報が含まれています。
このように実行すると、和暦表示が確認できます。
STRQSH CMD('date "+%EY"')
C/C++ の strftime() もロケールを使った和暦処理が可能です。
PASE
IBM から「元号の変更に伴うAIXの対応について」が公開されました。
PASE は AIX のバイナリーを利用しているため「4-1. 時刻の元号表示 (AIX)」にあるようにPASE環境用のロケールによる和暦表示機能を持っています。
UNICODE 国際コンポーネント
5770-SS1 オプション 39 UNICODE 国際コンポーネントは、多国語処理を行うオープンソースプロジェクト International Components for Unicode (ICU) 提供する C++ 用のAPI 群 ICU4C を IBM i 用の移植したものです。ライブラリー QICU に *SRVPGM の形式で提供されています。
新元号に対応するために ICU を用いて和暦の動作確認をする によれば、ICUの新元号対応は63.1からだそうです。
元号合字の利用
「㍾・㍽・㍼・㍻」のように漢字一文字に元号をまとめた文字があります。新元号も決定後に合字になる予定です。
元号合字を表示・印刷していなければ、この項の対応は不要でしょう。ユーザーデータの中に元号合字が出現することは、一般的には考え難いと思います。
CCSID 5026/5035(ホストコートページ 930/939)には元号合字は存在しない
IBM i で古くから使われている CCSID 5026/5035(ホストコートページ 930/939) には、元号合字はありません。
システムが、この範囲で稼働している場合、既存の元号合字は存在していません。利用していないはずであり、対応は不要です。
新元号の合字には Shift_JIS コードは割り振られない
Microsoftは新元号の合字にはShift_JISコードは割り振らないことを発表しています。そのため Shift_JIS を利用するシステムでは、新元号の合字を利用することはできません。どうしても必要な場合、合字の代わりに新元号の一文字目を利用するなどの対応を取ることになるでしょう。
CCSID 1399では利用可能になる予定
CCSID 1399 にはUNICODEに採用された元号合字が存在します。
新元号の合字には UNICODE の U+32FF が割り振られます。
対応するEBCDICとして CCSID 1399 に x'E860' として割り振られる予定です。
新元号の合字を利用するには下記の両方での対応が必要です。
- 表示・印刷のためのフォント
- 製品内の変換テーブル
合字の表示・印刷のためのフォント
通常、表示・印刷のためのフォントには Windows などクライアント上のものが利用されます。
そのため、利用するのであれば、クライアント上のフォントが更新されるのが前提です。
プリンター上のフォントを利用している場合、そちらの更新が前提になります。
IBM i 上にも表示・印刷用のフォントが存在します。
AFP印刷の場合、IBM i 上のフォントが利用可能です。
しかし、IBM Advanced Function Printing DBCS Fonts for AS/400 (5769-FN1) は、そもそも CCSID 1399 に対応しておらず、そもそも元号合字を持っていません。こちらを利用の場合は、現在、元号合字を利用していないはずのため対応は不要です。
IBM AFP Font Collection for IBM i product (5733-B45) は元号合字を持っています。そのため、利用している可能性があります。元号合字を利用しているか調査し、利用している場合は、新元号も合字を利用するか検討したうえで、フォントが更新されるかを IBM に問い合わせてください。
5770-SS1 オプション 43 追加フォントでは TrueType フォントを提供しています。WebQuery のグラフの凡例表示に利用されているものです。このフォントは他のIBM製品にもバンドルされて提供されています。やはり、元号合字を利用しているか調査し、利用している場合は、新元号も合字を利用するか検討したうえで、フォントが更新されるかを IBM に問い合わせてください。
製品内の変換テーブル
Pcomm や ACS の 5250 エミュレーションで新しい合字を利用するには製品内のUNICODE-EBCDICのテーブルへの追加が必要です。JT400/Toolbox for Java や ODBC、データ転送での利用も同様です。
これらは各製品の更新を待ちに、利用環境へ導入する必要があります。元号合字を利用しているか調査し、利用している場合は、新元号も合字を利用するか検討したうえで、更新されるかを IBM に問い合わせてください。
合字の利用をやめる方法も
合字を利用するにはフォントと製品内の変換テーブルの両方の更新を待ち、配布・導入する必要があります。
複数の更新ステップが必要になりながら、利用可能性・時期について自分でコントロールできない部分が非常に大きなものになっています。
一方、合字は、ユーザーデータの中にいきなり現れるものではなく、通常は印刷の決まった場所に使われる程度でしょう。
そこで、現在、合字を利用していてもやめてしまう対応方法もあります。
「㍾・㍽・㍼・㍻」を「明・大・昭・平」や「M・T・S・H」にしてしまう方法です。幸い、報道によればこれらと被らないように選定がすすむようです。
西暦化の推進も
電車の定期や銀行の通帳も西暦化が進んでいます。運転免許証も西暦が併記されるようです。
和暦を使い続けるための対応も重要ですが、これを機会に和暦/改元に依存しないようにシステムやアプリケーションを改修するのも、ひとつの方向でしょう。
IBM からの情報
IBM からの情報は下記にまとめられています。
IBM i に関するフラッシュの公開が確認できました。2019年2月27日に確認したとこと、遺伝と同じ2019年2月20日でしたが、詳細な内容に変更されていました。
更新記録
2019/01/09
-タイポの修正
-IBM Shift_JISには、そもそも元号合字がないことを明記
2019/01/16
-新元号の合字のUNICODEのコードポイントの誤りを訂正
-Javaの対応のリンクを追加
2019-01-21
-合字のIBM Shift_JIS に対する記述に誤りがあったため、本文から削除. 旧JISベースのCCSID 932/943には元号合字は含まないが、新JISベースのCCSID 943には含んでいる
2019-01-28
-タイポの修正
2019-02-04
-「和暦対応処理を行っていなければ特別な対応は不要」を追加
- 全体の調整
2019-02-13
- ILE CEE Date and Time APIs が和暦対応機能を持っていることを記載
- サポートがある Java のバージョンを記載
- ロケール、PASE、ICUを記載
- IBM からの情報を記載
- 全体の調整
2019-02-21
- IBM からのIBM i を対象にしたフラッシュを追記
2019-02-27
- IBM からの詳細情報提供開始に伴い、当ページの更新終了を宣言