IBM i のウンチクを語ろう
～ その92：2023年に最も読まれた記事ベスト10（前編）
皆さん、こんにちは。年の変わり目にはきっと、と思いながらも目先の動向に目を奪われてしまい、これまで日の目を見ることがなかった話題をようやく取り上げたいと思います。2023年にe-BELLNET上で新規に公開された全記事137本を通じて、最も読まれた記事ベスト10の発表です。見落としていた記事がなかったか、全体にどのような話題が注目されていたのか、この機会に昨年一年間のIBM i の話題を振返っていただければ幸いです。
第10位：メインメニューの半角カナ文字化けについて
IBM i に接続された5250エミュレータソフトを利用する時、半角カナ（カタカナ）が文字化けしてしまう問題への対策を紹介するものです。実際には問題というほどの深刻さは無いのですが、薄気味悪いのは事実でしょう。こういった記事ではなかなか言及されないのですが、何故このような問題が発生するのか、日本語処理に関する歴史を振返りながら考えてみたいと思います。
今でこそ日本語処理が行えないシステムを探すのは困難ですが、コンピュータと言えば処理できるのは英語のみ、という時代が長らく続いていました。そもそも英語圏で誕生した機械ですので、自然だったとも言えます。英語大小文字、数字、特殊記号、制御文字などを加えても、127文字を収容できる7ビットもあれば、十分な余力をもってこれらを表現することができます。これがいわゆるASCIIコードです。その後ヨーロッパのいわゆるラテン系他言語の文字を収容できるように、そしてコンピュータの基本的な構造との相性の良さから、256文字を収容できる1バイト=8ビットに拡張されています。それでも日本語には平仮名、カタカナ、漢字（常用漢字と呼ばれる、義務教育で習う最低限の漢字だけでも2,136文字）、日本語固有の特殊記号があるので、圧倒的に不足しています。
ところがかつてのコンピュータは非力でしたし、文字を収容するためにわざわざ多くの記憶域を割り当てればコスト高を招き、プログラミングも複雑になってしまいます。そこで編み出された解決策が、英語文字コード表の中に、何とかしてカタカナだけでも埋め込んでしまおうという発想です。曲がりなりにも日本語が使えますし、テクノロジーとしてもそれほどの無理はありません。これがいわゆる半角、すなわち1バイトのカタカナです。ここで二つのやり方が模索されました。
一つはカタカナ中心の考え方です。カタカナ全文字を1バイト・サイズの文字コード表中のまとまった領域に割り当てる代わりに、英小文字を別のバラバラな空白域に移動します。もう一つは既存の割り当てを尊重して、カタカナをバラバラな空白域に収容するもので、英語圏の製品との相性が良いという特徴があります。両者における英大文字の領域は共通ですが、英小文字とカタカナの間に互換性はありません。
現在の日本語環境においては1バイト・サイズの文字コード表に加えて、2バイト・サイズの文字コード表を組み合わせて運用しています。2バイトあれば最大65,536文字を収容できますので、常用漢字だけでなく、10,000超のJISで定義される漢字全てを網羅できます。記事にあるホストコードページ930とか1390はカタカナ中心の1バイト文字コード表と2バイトの日本語文字コード表の組合せ、939とか1399は英小文字中心の1バイト文字コード表と2バイトの日本語文字コード表の組合せ、というわけです。
ではCtrlキーとF3キーを同時に押すことで何が起こるのか、一言で言うと5250エミュレーが想定するIBM i の1バイト文字コード表を、カタカナ中心型と英小文字中心型との間で切り替える役割を果たします。2バイト文字コード表は固定したままです。これによって場合によっては半角カナの文字化けが修正される、というわけです。
文字の取り扱いにおいて、木に竹を継いだような構造になっているわけですが、従来との互換性を維持することが重要視された結果でもあります。目に見えにくい領域ではありますが、こんなところにも資産継承性があるのですね。
第9位：AS400とは（主に呼称について）
IBM AS/400、IBM AS/400e、IBM eServer iSeries、IBM System i、IBM Power Systems、IBM Power。もしくはOS/400、i5/OS、IBM i。メーカーが製品名称を変更しても、市場の方は既に定着したものをそう簡単には変更し追随することはできないのが現実です。ちなみに最初の一群は古い方から並べたハードウェアの名称、次の一群は同様にオペレーティング・システムの名称です。もしかしたら「こんなのあったっけ？」と思われるものが含まれているかもしれません。
かつてのAS/400に対応する現在の製品名はIBM Powerというわけです。ただ、IBM PowerだとIBM i 以外にもAIXやLinuxといったOSも搭載可能ですし、それによってシステムの性格も変わります。そこでマーケティング活動においては、ハードウェア名ではなくOS名を前面に出して、私達はIBM i という呼称を用いているわけです。厳密にはIBM i 搭載IBM Powerですが、長ったらしくて使い勝手がよろしくありません。
長い間製品に携わってきたベテランであれば、「同じ製品のことだよね」で済むものが、初めての方は別製品だと誤解してしまいます。販売店に属する我々も、従来の習慣を引き摺って思わず、またはお客様との会話においてわかり易さのために意図的に、定着済みの古い製品名称を使い続けることがあります。一時凌ぎにはなりますが、新しい製品名を浸透させる役には立ちません。
何故市場に不自由を強いてまで、IBM社は製品名称を変更したのでしょうか。一言で言うと製品の位置付けを変えようという意図の表れです。AS/400は究極の基幹業務サーバーを目指し、IBM i はAS/400の資産を引き継ぎながらも、さらにオープンなテクノロジーを活かした様々なソリューションを統合的に利用することを目指しています。現在のIBM i をAS/400と呼ぶのは、製品の持つポテンシャルのごく一部のみを指していることになります。記事ではこのような思惑には言及しておりませんが、名称変更の背景には製品戦略がある、というわけです。
第8位：クライアントアクセスとは、ピーコムとは（主に呼称について）
再び呼称の問題がランクインしています。第9位のケースとは異なり、同じ系列の製品に別の名前が割り当てられているだけでなく、違う製品なので別の名前を持っているケースが混在している、という意味では、よりややこしいかもしれません。では同じ5250エミュレータ機能を指しているのに製品がどう違うのか、を明確にする必要があります。
PComm（ピーコム : Personal Communicationsの略称）は、IBM i 用の5250エミュレータ、またはIBMメインフレーム用の3270エミュレータを中核機能とするクライアント用のソフトウェア製品です。IBM i のP05とかP10といったプロセッサ・グループとは無縁の料金体系を持っています。
一方のクライアントアクセスは、クライアントと連携することによってIT部門の生産性を高めることを狙いとする、各種ユーティリティを備えたサーバー用製品です。プロセッサ・グループによって料金体系が変わります。製品名称はPC Support/400、Client Access/400、iSeries Access、System i Access、IBM i Accessと変遷してきたように記憶しています。名称として存在感の薄いものを含んでいるため、あまり自信はありませんが。この中で最も新しいIBM i Accessには、対象となるクライアントによってWindows版、Linux版、ブラウザ版などがありました。ACS（Access Client Solutions）は同じファミリー内にあって、これら全てを置き換えるJava版として位置付けられる最新の製品です。様々なクライアント上のJavaを対象とするわけです。
PC Support/400はおそらく唯一の例外になると思いますが、上記全ての製品には5250エミュレータ機能が含まれておりました。PCommには5250エミュレータを中核として拡張機能が備わっているのに対して、ACSなどにおける5250エミュレータは機能の一部に過ぎない、といった位置付けの違いがあります。ご存知のとおり、ACSには5250エミュレータなどエンドユーザー向け機能に留まらず、IBM i システム管理機能、DB管理機能も含んでいます。
5250エミュレータ機能を中心に考えれば、PCommの一部かも知れないし、IBM i Access Windows版の一部、またはACSの一部を指しているのかもしれません。見た目の機能は共通でも周辺にある機能や料金、サポート体制などが異なっています。記事はそのあたりに注意するべきことを述べています。
それにしてもこのように呼称に関する記事が上位にランクインしているということは、混乱している方が多いということの表れなのでしょうか。別製品ならば致し方無いですし、メーカーの思惑もわかるのですが、同一製品の名称変更はほどほどにしておいてもらえるとありがたい、などと思っております。
第7位：ACSをWindows11上で使うと黒い画面が消えません！？（Windows11 22H2でのWindowsターミナル画面）
クライアント上で稼働するプログラムというのは、接続先サーバーのバージョンやPTFレベル、クライアントのOS、バージョン、アップデート、Java バージョンなどの影響を受ける傾向があります。次々と新たに登場する製品、機能、バージョンなどに対応しないわけにもいきませんので、利用にあたっての考慮点が後から出てくるのは日常茶飯事です。ちなみに私自身が現在日常的に使っているのはWindows10ですので、Windows11バージョン22H2において、ガイド内容のような変更があったことは知りませんでした。
ACSはJavaアプリケーションであるわけですが、これを起動するということは、Windows側ではそのコマンドを受け取る環境が必要です。Windows11 22H2においてはディフォルトでWindowsターミナルがその役割を担っており、ACSの起動と共にオープンされ、そのままデスクトップに残るようです。この目障りかもしれない挙動を回避する方法が述べられています。
Windowsを10から11に既にアップグレードされている方がどれだけいらっしゃるのかわかりませんが、日常的に直接触れるACSの記事であることが、アクセス数を増やす要因になっているのでしょう。問題と言うほどの現象ではなくても、そしてもしかしたら実際には未だ使っていなくても、技術情報には目を通しておこうということなのだと思われます。
第6位：今更聞けない！！ACSのダウンロードってどうすればいいの？
再びACS関連の記事がランクインしています。先行製品にあたるIBM i Access Windows版では、5250エミュレータに加えてデータのダウンロードは必ずと言って良いほど使われるので、ACSが後継製品であるためには同様の機能が利用できなければなりません。この記事のタイトルにある疑問を抱く可能性のある方は、これからACSを利用しようとしている、すなわち現在も先行製品にあたるIBM i Access Windows版を利用されているのかもしれません。もしくは既に実施しているデータのダウンロード手順を、あらためて見直そうと思ったのかもしれません。
ここで確認しておきたいのですが、IBM i Access Windows版のサポートは、約5年前の2019年4月30日に終了しています。また、サポート対象となるWindowsバージョンは8.1までであり、そもそもWindows10以降は対象外です。もしWindows10にIBM i Access Windows版をインストールし利用されているとしたら、メーカーの立場からすると、「たまたま動作している」に過ぎないということになります。サポート期限切れと前提条件外というわけです。
実際に利用する製品のテクノロジー刷新は、必ずしもメーカーの思惑通りには進まないものです。だからと言って、トラブルなどに遭遇してもサポートを受けられない状況のままでいるのもうまくありません。もし「たまたま動作しているに過ぎない」状況にあって、ACSへの移行を検討されているのでしたら、急ぎ実施されることをお勧めしたいと思います。
第5位以下は次回の後編にて。ではまた
