VSCodeを使用したメインフレーム・アプリケーション開発 - (2)z/OS基本操作

# はじめに
まずはVSCode(+Zowe Explorer,Zowe CLI)を使用したz/OSの基本的な操作を試してみます。

## 関連記事
[VSCodeを使用したメインフレーム・アプリケーション開発 - (1)概要](https://qiita.com/tomotagwork/items/085b91098fce3aabaeaf)
[VSCodeを使用したメインフレーム・アプリケーション開発 - (2)z/OS基本操作](https://qiita.com/tomotagwork/items/9496dbc121cc5bf17b29)
[VSCodeを使用したメインフレーム・アプリケーション開発 - (3)ソース編集](https://qiita.com/tomotagwork/items/f4008d1ead61e8a263ae)
[VSCodeを使用したメインフレーム・アプリケーション開発 - (4)ソース管理ツール/ビルドツール連携](https://qiita.com/tomotagwork/items/4bdd0b5a7284b5102d10)
[VSCodeを使用したメインフレーム・アプリケーション開発 - (5)デバッガーの利用](https://qiita.com/tomotagwork/items/2ce806f5747bc72f9474)
[VSCodeを使用したメインフレーム・アプリケーション開発 - (6)FTP経由での接続](https://qiita.com/tomotagwork/items/a2f82db16d18a8fd9d21)

# 基本操作
ここでは、prof_Wazi01というプロファイル(接続先はWazi Sandbox)を使用する前提で手順を記載します。(z/OSMFとの接続構成は済の前提)

## PDSメンバー編集
Zoweの画面でDATA SETSの右側の+ボタンをクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132331/088d9c4f-2f8e-e24e-e851-aa50d25d3004.png)

接続先に対応するプロファイルを選択します。
(事前に作成しておいたz/OSMFに対するZowe CLIのプロファイル。「Create a New Connection to z/OS」を選択すればここで新たにプロファイルを作成することもできます。)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132331/ffcd5f91-cc3a-bda8-fffa-3f302767ec4c.png)

追加した接続プロファイルの右の虫眼鏡アイコンをクリックし、表示したいデータセットのHLQを指定します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132331/9e56dba4-7739-49d1-b38a-f9557c1305a0.png)

指定したHLQのデータセットの一覧が表示されます。
そこから編集対象のデータセット、メンバーを探してクリックするとエディターが開いて編集が可能となります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132331/98274bb8-d129-99f4-b682-55c0d7c9b4bc.png)



## PDSデータセット作成

DATA SETS以下の当該Profileの横の虫眼鏡アイコンをクリックし、HLQを入力してEnter
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132331/02cf3357-effc-e023-038a-0fdc613abd68.png)

"Create New Data Set"のアイコンをクリック
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132331/5cb74505-cabf-74f6-8baa-86aa98c3f022.png)

Data Set Partitionedを選択
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132331/b3d54988-0193-976c-a149-e3081f236164.png)

作成するPDSの名前を指定。ここでは`TAGUCHI.JCL`を指定
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132331/fe64db9c-1652-2391-6338-54fc4ca4ad8e.png)

作成されました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132331/72f48854-0267-5b7f-2779-237a94c88f7c.png)

作成されたデータセットを右クリック - "Show Data Set Attributes"
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132331/5e9679f6-c029-8507-03b5-0bf995861219.png)

データセットの情報を確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132331/865e6838-ed5e-f340-c4c7-6f97282e8aea.png)

PCOMでデータセットのInformationを確認してみると、以下のようになっています。

```
                             Data Set Information                       
                                                                        
Data Set Name . . . . : TAGUCHI.JCL                                     
                                                                        
General Data                          Current Allocation                
 Management class . . : **None**       Allocated cylinders : 1          
 Storage class  . . . : SCBASE         Allocated extents . : 1          
  Volume serial . . . : B4USR1         Maximum dir. blocks : 5          
  Device type . . . . : 3390                                            
 Data class . . . . . : **None**                                        
  Organization  . . . : PO            Current Utilization               
  Record format . . . : FB             Used cylinders  . . : 1          
  Record length . . . : 80             Used extents  . . . : 1          
  Block size  . . . . : 6160           Used dir. blocks  . : 1          
  1st extent cylinders: 1              Number of members . : 1          
  Secondary cylinders : 1                                               
  Data set name type  : PDS           Dates                             
  Data set encryption : NO             Creation date . . . : 2021/01/28 
                                       Referenced date . . : 2021/01/29 
                                       Expiration date . . : ***None*** 
```

内部的にはZowe CLI経由でz/OSMFに対してREST APIが発行されてPDSデータセットが作成されますので、サイズなどのパラメーターは以下のデフォルト値が使われているようです。(Primary:1 cylinder, Secandary: 1cylinder, volはSMSに従う)
https://docs.zowe.org/stable/web_help/?p=zowe_zos-files_create_data-set-partitioned

データセットのサイズなどを設定で変更可能です。
VSCodeのメニューからファイル-ユーザー設定-設定を選択します。
設定ウィンドウで、拡張機能の中のZowe Explorer Settingを選択し、Zowe-Default-Datasets-PDS の下の"settings.jsonで編集"をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132331/fe6daa73-97b3-c511-7c6c-d01a0ee9c6b7.png)

以下のように、デフォルト値を変更したいパラメーターを指定します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132331/22af5c77-2655-2220-1968-d2bb8684db87.png)
上の例はCYLINDER単位にPrimary:5, Secondary:2で作成するように指定しています。

パラメーターは以下のz/OSMF REST API用のものが使用できるようです。
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.izua700/IZUHPINFO_API_CreateDataSet.htm


## PDSメンバー作成
データセット右クリック - "Create New Member"を選択
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132331/708f80dc-7566-c837-c472-d254cc50d817.png)

メンバー名を指定
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132331/2c515b14-5d19-5074-edf5-83f416f9c627.png)

ここでは、LISTCATするJCLを作成します。
以下のようにJCLの中身をエディターで記載して、Ctrl+Cで保存します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132331/13ce0753-70d2-a398-16d7-4965e675d951.png)

これでPDSメンバーが作成されました。

※JCLという名前のデータセットにしたので、ここに含まれるメンバーは自動的にJCLであると判断されてSyntaxハイライトなどがおこなわれています。この辺の詳細はまた別記事で取り上げます。

## USSファイル編集
USS上のファイルについても、Datasetと同じように編集などが行えます。(詳細は割愛)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132331/2c994263-9050-c4ec-d617-241d2baec7bc.png)

## JCLサブミット

上で作成したLISTCというJCLをサブミットしてみます。

サブミットしたいPDSメンバー"LISTC"を右クリックして、"Submit Job"を選択します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132331/268c3b47-6bdc-0fa1-fe90-26ab67f3c107.png)

右下にポップアップでJOBがサブミットされた旨のメッセージと、JOBIDが表示されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132331/3a553e7c-7059-44fd-4f6a-1e4204a489a3.png)

これでJOBのサブミットは完了です。

## JOBLOG確認

上のメッセージのJOBIDのリンクをクリックすると、左下のJOBSの欄からJOBLOGが開きます。ここでCCが確認できますし、DD毎にJOBLOGを確認することもできます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132331/118b4c95-285c-9a34-73bb-a0f488c4f517.png)

JOBSメニューのプロファイルの横の虫眼鏡アイコンをクリックすると、Owner/JOB名のPrefexによる検索、JOBIDによる検索が行えます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132331/89e193c1-b0bc-cd00-5aa5-5b422d75a6fd.png)

ACTIVEなJOBについても確認できるので、SYSLOGもここから確認することができます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132331/28f3f093-435a-9d43-0a6e-aa4ac8bd223c.png)

## MVSコマンド実行
F1キーを押して、zowe:と入力すると、zowe関連の機能が表示されるので、Issue MVS Command...を選択
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132331/3e578bc5-840e-3a21-a037-2374e05315d7.png)

接続先のプロファイルを選択
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132331/32d7f3f2-8cdf-2a25-c040-a3aad84f8823.png)

実行したいMVSコマンドを入力してEnter
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132331/168396eb-4cb1-ab9d-243f-a5fc9142f453.png)

MVSコマンドが実行されて、出力ウィンドウに結果が表示されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132331/b5824caf-8461-42b7-ab0e-6d1ad1c401aa.png)


# 補足
## 文字コード変換について

VSCodeからz/OSにアクセスする際は、Zowe CLI経由でz/OSMFにアクセスすることになります。この時、Zowe CLIの構成でz/OSMFに対する接続構成を行いますが、ここで接続先のコードページを指定することができます(プロファイル作成時、zowe profiles create zosmf-profiles ... --encoding 1399) 。

```
c:\>zowe profiles list zosmf-profiles --show-contents
-
  name:     prof_Wazi01
  contents:
    host:               OCPW01
    port:               31917
    user:               managed by @zowe/secure-credential-store-for-zowe-cli
    password:           managed by @zowe/secure-credential-store-for-zowe-cli
    rejectUnauthorized: false
    encoding:           1399
...
```

この例では1399を指定しているので、ホスト側(EBCDIC)のコードとして1399が使われます。VSCodeでホスト上のテキストを編集する際は、一度PC上のテンポラリーのディレクトリにファイルを転送してきてそれをエディターで開いているイメージになります。編集して保存するとホスト側に転送されて上書きされます。
PC<=>z/OS間でファイルの送受信が行われることになりますが、このときPC側:UTF-8 <=> z/OS側:EBCDIC(1399)でのコード変換が行われることになります。

PDSメンバーとして保持されているテキストは基本的にEBCDICで扱われるので基本的にこの動きで問題無いと思いますが、USS上のファイルはEBCDICだけでなくUTF-8など別のコード体系のものが含まれていたりします。

### USSファイルのハンドリング
USSファイルをVSCodeから扱う場合どうなるのかを少し試してみます。

まず、teratermからsshでWaziのUSSに接続して操作してみます。今回Unicodeのファイルを扱うので、環境変数として`_BPXK_AUTOCVT=ALL`を設定したシェルで操作します。
参考: 
[_BPXK environment variables](https://www.ibm.com/docs/en/zos/2.4.0?topic=variables-bpxk-environment)
[Controlling text conversion for z/OS UNIX shell commands](https://www.ibm.com/docs/en/zos/2.4.0?topic=reference-controlling-text-conversion-zos-unix-shell-commands)

普通にviでebcdic.txtというファイルを作成し、中身を適当に編集します。

```
TAGUCHI:/u/TAGUCHI/Test01: >cat ebcdic.txt
aaa
bbb
ccc

TAGUCHI:/u/TAGUCHI/Test01: >ls -laT
total 34
                    drwxr-xr-x   2 TAGUCHI  SYS1        8192 Jan 29 16:45 .
                    drwxr-xr-x   5 TAGUCHI  SYS1        8192 Jan 29 15:27 ..
m IBM-1047    T=off -rw-r--r--   1 TAGUCHI  SYS1          13 Jan 29 16:45 ebcdic.txt
```

デフォルトではEBCDICでデータが保持されます。
これをiconvでUTF-8に変換して別ファイルを作成します。

```
TAGUCHI:/u/TAGUCHI/Test01: >iconv -f IBM-1047 -t UTF-8 ebcdic.txt > utf8_withoutTag.txt
TAGUCHI:/u/TAGUCHI/Test01: >ls -laT
total 36
                    drwxr-xr-x   2 TAGUCHI  SYS1        8192 Jan 29 16:56 .
                    drwxr-xr-x   5 TAGUCHI  SYS1        8192 Jan 29 15:27 ..
m IBM-1047    T=off -rw-r--r--   1 TAGUCHI  SYS1          13 Jan 29 16:45 ebcdic.txt
t IBM-1047    T=on  -rw-r--r--   1 TAGUCHI  SYS1          13 Jan 29 16:55 utf8_withoutTag.txt
TAGUCHI:/u/TAGUCHI/Test01: >cat utf8.txt
///篠ﾂﾂ柴ﾄﾄ試TAGUCHI:/u/TAGUCHI/Test01: >
```

utf8のファイルなのですが、EBCDICと認識されている状態なのでcatで見ようとすると文字化けします。
これを別名でコピーし、UTF-8のタグを設定してあげると、catなどで扱えるようになります。

```
TAGUCHI:/u/TAGUCHI/Test01: >cp utf8_withoutTag.txt utf8_withTag.txt
TAGUCHI:/u/TAGUCHI/Test01: >chtag -t -c UTF-8 utf8_withTag.txt
TAGUCHI:/u/TAGUCHI/Test01: >ls -laT
total 38
                    drwxr-xr-x   2 TAGUCHI  SYS1        8192 Jan 29 16:58 .
                    drwxr-xr-x   5 TAGUCHI  SYS1        8192 Jan 29 15:27 ..
m IBM-1047    T=off -rw-r--r--   1 TAGUCHI  SYS1          13 Jan 29 16:45 ebcdic.txt
t UTF-8       T=on  -rw-r--r--   1 TAGUCHI  SYS1          13 Jan 29 16:58 utf8_withTag.txt
t IBM-1047    T=on  -rw-r--r--   1 TAGUCHI  SYS1          13 Jan 29 16:55 utf8_withoutTag.txt
TAGUCHI:/u/TAGUCHI/Test01: >cat utf8_withTag.txt
aaa
bbb
ccc
```

さて、この状態で、これらのファイルをVSCodeで開いてみます。

ebcdic.txt => UTF-8に変換されて普通に開きました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132331/5cd9292d-3440-0e7b-ac28-98ecf1683f1c.png)

utf8_withoutTag.txt => 文字化けしました。元のファイルはUTF-8なのですが、おそらく1399=>UTF-8への変換が行われたためだと思われます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132331/3f577202-0ddc-c82e-de2f-a4cde805cbd1.png)

utf8_withTag.txt => 普通にUTF-8として開きました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132331/49816ff3-3066-5fce-c335-79fb74ff1549.png)

つまり、USS上で指定されているタグの情報が有効でそれに合わせて文字コードの制御が行われているようです。

次に、VSCode上から新規にファイルを作成してみます。
ここでは、newOnVSCode.txtというファイルを作成してみました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132331/50b6093a-67bb-1ccc-a986-106aa33bcaca.png)

teratermで見てみると、デフォルトではタグなし、EBCDICで作成されていました。(PC:UTF-8 => z/OS:1399変換が行われてファイル転送されている)

```
TAGUCHI:/u/TAGUCHI/Test01: >ls -laT
total 40
                    drwxr-xr-x   2 TAGUCHI  SYS1        8192 Jan 29 17:23 .
                    drwxr-xr-x   5 TAGUCHI  SYS1        8192 Jan 29 15:27 ..
m IBM-1047    T=off -rw-r--r--   1 TAGUCHI  SYS1          13 Jan 29 16:45 ebcdic.txt
- untagged    T=off -rwxr-xr-x   1 TAGUCHI  SYS1          19 Jan 29 17:23 newOnVSCode.txt
t UTF-8       T=on  -rw-r--r--   1 TAGUCHI  SYS1          13 Jan 29 16:58 utf8_withTag.txt
t IBM-1047    T=on  -rw-r--r--   1 TAGUCHI  SYS1          13 Jan 29 16:55 utf8_withoutTag.txt
TAGUCHI:/u/TAGUCHI/Test01: >cat newOnVSCode.txt
aaa
bbb
ccc
ddd
eeeTAGUCHI:/u/TAGUCHI/Test01: >
```

## ファイルの排他制御について

VSCode上でz/OS上のリソースを取り扱う場合、基本的にPC上に転送したファイルを参照/編集することになります。この時z/OS上のリソースに対する排他制御はかかっていません。
例えば、TAGUCHI.COBOL(I01DLY01)というPDSメンバーをPCOMとVSCodeで編集しようとすると、同じメンバーを同時に編集することができます。

PCOMで4行目に"aaa"という文字列を追記します。(まだ保存はしない)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132331/86048c0b-4591-346e-d135-48bf9510c00e.png)

同時にVSCodeで同じメンバーを開き、同じ箇所に"bbb"という文字列を追記します。(まだ保存はしない)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132331/31b708d1-b61e-dadd-5f97-013ea61fd33b.png)

PCOMの変更を保存し(PCOMのエディターは開いたまま)、その後VSCode側でも変更を保存してみます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132331/12d0d5d3-e8a9-1bd6-f3cb-43a05ba09552.png)
PCOM側でEditモードで同メンバーを開いている状態なので上書きできないのでエラーになっています。
参考: [Error reporting categories](https://www.ibm.com/docs/en/zos/2.4.0?topic=interface-error-reporting-categories#ErrorReportingCategories_4RESTfiles__Category6Errors_4RESTfiles)

次に、PCOM側の編集を終了してEditモードを解除します。その後再度VSCode側での編集を保存してみると、今度は以下のようなメッセージが出力されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132331/c181684d-c85f-5e2f-45d7-9e183dc44836.png)

VSCodeで編集した内容を保存しようとした時点でホスト側リソースとの内容を比較し、両者に差異が出ているためこのようなメッセージが表示されています。
"上書き"をクリックすると、VSCodeの変更内容を正としてそのまま上書きすることになります。ここでは"比較"をクリックしてみます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/132331/a46de58b-478d-bf12-c444-e6d5cb49caed.png)
左側:z/OS上のソースの状態、右側:VSCode上(PC上)のソースの状態が表示され、差異がある部分が強調表示されます。適宜確認しながら、変更を破棄するか上書きするか(もしくは差分を見ながら追加で修正を加えるか)判断できます。