PART 2　VSCode+Code for IBM i復習 ～直接操作とローカル操作のそれぞれの特徴　｜特集　VSCode＋生成AIで加速するIBM i開発

VSCodeとその拡張機能であるCode for IBM iをまだ触ったことがないという人もいると思うので、使用時のポイントを解説しておこう。誌面の都合上詳細な説明は省くが、先ほど紹介した過去記事（2023 Winter号特集「Code for IBM i」、i Magazineサイトに全編掲載）とともに読んでいただくとスムーズに理解していただけると思う。

IBM iの開発にVSCodeを利用するには、拡張機能であるCode for IBM iを利用する。

Code for IBM iの2025年4月28日現在の最新バージョンは2.15.3である。2023 Winter号で紹介したバージョンは1.6.8でかなり古いが、基本的な使い方は変わっていない。VSCodeを単なるエディタとして利用するのであれば必要ないが、IBM iの開発には必須と思っていただいてよいだろう。VSCode + Code for IBM iで、RDiに近い開発環境を実現することができる（図表1）。

Code for IBM iは、ソースコードをどこに置くかで2通りの使い方がある。

・従来のようにIBM iのソース・ファイルのメンバーを直接参照する
・ソースコードをVSCodeが稼働するPC（ローカル）に置いて編集する

では、それぞれの特徴を見ていこう。

直接操作

VSCodeからIBM iのソース・ファイルのメンバーを直接操作する利点は、気軽に試せることにある。VSCodeにCode for IBM iをインストールすれば、ソースコードをローカルにダウンロードする必要もなく、すぐに操作が可能だ。SEUとの違いや操作感を体感できるので、ぜひ気軽に使ってもらいたい。

IBM iにあるソースメンバーを直接操作するので、当然だがIBM iへの接続設定を作成して接続した状態で行う必要がある。詳細は過去号を参照してほしい。

気軽に使えるという利点はあるものの、気をつけておくべき点もいくつか存在する。

ソース・メンバーの行ごとの日付

SEUはソース・ファイルのメンバーを編集するためのツールなので、IBM iオブジェクトとしてのソース・ファイルのレイアウト（レコード様式）は当然ながら知っている。ソースの各行には日付フィールド（SRCDAT）があり、行が追加および変更されたタイミングでその日付フィールドをSEUが更新する。

それに対して、Code for IBM iはデフォルトの設定では日付フィールドを無視するので、ソースを保存した場合はすべての行の日付フィールドを000000にリセットしてしまう。

日付フィールドの値を見て「この行はいつ変更になったのか」を参照しながら開発している現場では、この挙動は後々問題になる可能性がある。そのため最初は自分のソース・ファイルにメンバーをコピーして、それを対象にCode for IBM iをテストするなど、現状の開発フローに支障がないよう工夫してほしい。

日付フィールドの扱いについては、Code for IBM iのSettingsのSourceCodeタブにある「Enable Source Dates」にチェックを入れることで、SEUと同様に振る舞うよう設定も可能である（図表2）。

メンバー・ロックされない

Code for IBM iでは、ソースコードを保存するときは、IBM i側でそのメンバーがロックされていない（SEUで編集目的で開いていない）ことが条件となるが、SEU側ではCode for IBM iでソース・メンバーが編集中であっても、編集目的で開くことができる。つまりCode for IBM i側で編集中かどうかはSEUからは判別できない。そのため、たとえばCode for IBM iでメンバーを編集中に、SEUでそのメンバーを修正して保管し、その後でCode for IBM iの変更を保存すると、SEUの編集が上書きされてしまうので注意が必要だ。

プロンプト機能がない

コードを修正するエディタはVSCode上のものを使用するので、SEUで利用可能なプロンプト機能は使えない。RPG Ⅳの場合は、RPGLE拡張機能の設定によりカラム・アシストを表示できるが、RPG Ⅲでは表示されない（図表3）。

固定形式のシフト文字の扱い

ご存じのようにIBM iの5250環境では漢字の前後にはシフト文字が必要で、SEUではシフトアウトおよびシフトイン制御コードも1桁とカウントしてコーディングする。それも含めてその行のすべての項目が定位置に記述されていないと、SEUは構文エラーと判断する（定位置形式のコードの場合）（図表4）。

これに対して、VSCodeでソースを表示する場合は文字コードが異なりシフト文字の概念がないので、その桁がブランクではなく詰まって表示されてしまう。つまり、図表5のようにズレて見える。

図表5 VSCodeでソース表示すると桁ずれを起こす

もちろんこれは文字コードが異なることによる表示上の話であり、IBM iのソースメンバーにそのまま保管されれば、シフト文字は自動的に挿入されるので問題ない。　しかし、VSCode上で桁位置を揃えてしまった場合は、上記の例では結果のフィールドの桁位置が右側にずれることになり、コンパイルすると構文エラーになるので注意が必要だ。

Git管理ができない

ソースコードは従来どおりソースメンバーとしてIBM iのソース・ファイルに保存するため、VSCodeを介したGit管理はできない。5250環境でGit管理を行いたい場合は、前述の2024 Summer号の特集「5250環境でGitを利用する」を参照してほしいが、根本的な解決策としては、やはりローカル環境でのGit管理が必要だ。

コンパイル

Code for IBM iでは、コンパイル・コマンドを事前にアクションとして保管しておくことで、VSCodeのインターフェースからコンパイルを実行できる。コンパイルはRPGプログラムだけではなく、CLプログラムやDDSを使用した各ファイルなども対象となる。コンパイル・リストもVSCode内に表示されるので、慣れてくれば5250画面よりも効率よく開発を行えるはずだ。

ローカル操作

では次に、プログラムのソースコードをPC上に置いて、それをVSCodeで編集する方法を見ていこう。コードはローカルにあるので作業の間つねにIBM iに接続している必要はないが、コンパイルの際はIBM iにソースコードをプッシュする必要があり、その時は接続が必要だ。

Code for IBM iを使えば、ローカルのファイルに修正を保存した後にコードをプッシュおよびコンパイルできる。修正およびプッシュ・コンパイルの一連の流れを何度も行う場合は、IBM iに接続した状態で行うとよい。

Gitとの連携

ソースコードはローカルに保存されるので、VSCodeのインターフェースを使用してGitによるソースコードのバージョン管理を行うことができる。もちろん GitHubやGitLabなどのリポジトリサーバーとの連携も可能なので、Gitのブランチ機能などを駆使しながら他のプラットフォームと同様のチーム開発が可能だ。

プッシュ先

ローカルに保存されたファイルのプッシュ先はIFSの指定したディレクトリのみである。ソース・ファイルのメンバーにはプッシュできないので注意しよう。RPG Ⅲのコンパイラー（CRTRPGPGM）は、プログラムのソースとしてはソースメンバーしか指定できないので、通常はこの方法では保守することはできないが、オープンソースの CRTFRMSTMF コマンドを使えば、IFS からもコンパイルできるようになる。

プロンプト機能がない

これは直接操作の場合と同様、エディタはVSCode上のものなので利用できない。

固定形式のシフト文字の扱い

これも直接操作と同じく注意が必要な点である。しかし、桁位置依存のコードでなければ、この問題は無視できる。FF RPGは桁位置に依存しない書き方なので、この問題は関係ない。

Code for IBM iを使えば、RDiのリモート・システム・エクスプローラー（直接操作）や、iプロジェクト（ローカル操作）と同様の操作を行えることがおわかりいただけたと思う。しかし、あくまでも直接操作は最初の入口であり、最終的にはGitの管理を前提にローカル操作で運用することが重要である。