JP1/AJS3でジョブネットやジョブの定義を退避・回復する場合、代表的な方法として次の2種類があります。

ajsprint ＋ ajsdefine

と、

ajsbackup ＋ ajsrestore

です。

どちらもジョブネットやジョブなどのユニット定義情報を退避・回復するために使用できますが、仕組みや向いている用途には違いがあります。

特に重要なのは、

同じサーバー上での退避・回復を重視するのか

それとも、

定義をファイルとして保管したり、別サーバーへ移行したりしたいのか

という点です。

この記事では、両方式の基本的な使い方と違い、実運用ではどちらを選べばよいのかを整理します。

JP1/AJS3には2種類の退避・回復方法がある

JP1/AJS3の公式マニュアルでは、ユニット定義情報の退避・回復方法として次の2種類が示されています。

1. ajsprint / ajsdefine

2. ajsbackup / ajsrestore

ajsprint と ajsdefine は、ユニット定義情報を任意のファイルへ出力して、そのファイルから再定義する方式です。

一方、ajsbackup と ajsrestore は、JP1/AJS3の「退避ボックス」に退避ファイルを保存し、その退避情報を使用して回復する方式です。

概念的には、

ajsprint
   ↓
定義ファイル
   ↓
ajsdefine

に対して、

ajsbackup
   ↓
退避ボックス
   ↓
退避ファイル
   ↓
ajsrestore

という違いです。

まず重要：どちらも実行結果はバックアップしない

ここは最初に理解しておく必要があります。

ajsprint と ajsbackup で退避されるのは、基本的に、

ジョブネットやジョブなどの定義情報

です。

例えば、

ジョブネット名
ジョブ定義
実行ファイル
パラメーター
実行エージェント
スケジュール定義

などです。

一方、

過去の実行結果
ジョブ実行履歴
実行中の状態

などを含めたシステム全体のバックアップではありません。

日立の公式マニュアルでも、ajsprint、ajsbackup、JP1/AJS3 – Viewによる退避ではユニットの定義情報のみが対象であり、実行結果は退避されないと明記されています。

実行結果やデータベースを含めた完全なバックアップが必要な場合は、JP1/AJS3のバックアップ・リカバリー機能を別途検討する必要があります。例えば組み込みDBには jajs_dbbackup / jajs_dbrestore を使用する方法があります。

方法1：ajsprint / ajsdefine を使う

まず、比較的シンプルなのが、

ajsprint
ajsdefine

を使用する方法です。

ajsprintとは
作業前の退避なら ajsbackup

ajsprintとは

ajsprint は、JP1/AJS3に登録されているユニット定義をテキスト形式で出力するコマンドです。

例えば、

ajsprint -a /業務/DAILY_JOB

のように実行します。

-a を指定すると、ajsdefine で再定義できる形式でユニット定義を出力できます。

そのため、実際には標準出力をファイルへリダイレクトして保存します。

ajsprint -a /業務/DAILY_JOB > DAILY_JOB.def

これで、

DAILY_JOB.def

という定義ファイルが作成されます。

公式資料でも、ajsbackup が内部的に作成する退避ファイルは、ajsprint -a で出力した形の情報として格納されると説明されています。

ajsprintで退避するイメージ

例えば次のジョブネットがあるとします。

/業務
 └─ DAILY_JOB
      ├─ JOB01
      ├─ JOB02
      └─ JOB03

これを退避します。

ajsprint -a /業務/DAILY_JOB > DAILY_JOB_20260909.def

結果として、

DAILY_JOB_20260909.def

という普通のファイルとして保存できます。

そのため、

/backup/jp1/

や、

/mnt/backup/

など、任意のバックアップ領域へ保存できます。

ajsdefineで回復する

回復するときは、ajsprint で作成したユニット定義ファイルを ajsdefine に指定します。

概念的には、

ajsdefine DAILY_JOB_20260909.def

のように実行します。

ajsdefine はユニット定義ファイルを読み込み、JP1/AJS3へユニットを定義するためのコマンドです。公式マニュアルでも、ユニット定義ファイルを作成して ajsdefine を実行することでユニットを定義できると説明されています。

なお、同名ユニットがすでに存在する場合は、そのままではエラーになるケースがあります。

必要に応じて、

既存ユニットを削除する
-f
-i

などのオプションを使う

といった対応が必要になります。公式メッセージ資料でも、ajsdefine や ajsrestore で同名ユニットが存在する場合には、削除後の再実行または -f / -i の指定が案内されています。

ajsprint / ajsdefine の大きなメリット

この方式の大きな特徴は、

バックアップデータが普通のファイルになる

ことです。

例えば、

DAILY_JOB.def
MONTHLY_JOB.def
BILLING_JOB.def

のように管理できます。

そのため、

ファイルサーバーへ保存
バックアップソフトで保存
日付付きファイルとして世代管理
Gitなどでバージョン管理
別サーバーへ転送

といった運用がしやすくなります。

別サーバーへ移行できる

ajsprint / ajsdefine の非常に重要な特徴が、

別サーバーへの移行に利用できる

ことです。

日立の公式マニュアルでは、ajsbackup で退避したユニットは同一サーバーでのみ回復可能とされています。

別サーバーへユニットを移行する場合は、

移行元
 ↓
ajsprint
 ↓
定義ファイル
 ↓
ファイル転送
 ↓
移行先
 ↓
ajsdefine

を使用するよう明記されています。

つまり、サーバー更改や環境移行を考える場合、

ajsprint / ajsdefine の方が重要

になります。

ajsprint / ajsdefine の運用例

例えば、毎日ジョブネット定義をバックアップするとします。

mkdir -p /backup/jp1

そして、

ajsprint -a /業務/DAILY_JOB \
  > /backup/jp1/DAILY_JOB_20260909.def

翌日は、

DAILY_JOB_20260910.def

というように保存します。

これなら、

20260907
20260908
20260909

と世代管理できます。

また、テキスト形式なので、

diff DAILY_JOB_20260908.def DAILY_JOB_20260909.def

とすれば、変更点を比較することもできます。

これは ajsprint 方式の大きなメリットです。

方法2：ajsbackup / ajsrestore を使う

次に、

ajsbackup
ajsrestore

を使う方法です。

こちらはJP1/AJS3が用意している「退避ボックス」という仕組みを使用します。

ajsbackupとは

ajsbackup は、指定したユニットを退避ボックスへ保存するコマンドです。

例えば、

ajsbackup -m -n BACKUP /UNIT

とすると、

BACKUP

という新しい退避ボックスを作成し、

/UNIT

をそこへ退避します。

この例は公式マニュアルにも掲載されています。

退避ボックスとは

退避ボックスは、退避ファイルをまとめて保存するディレクトリです。

イメージとしては、

退避情報ディレクトリ
   │
   └─ BACKUP
       ├─ .ajsbkup
       ├─ 0001
       ├─ 0002
       └─ 0003

のようになります。

0001 から 1024 の番号が退避ファイル名として使用されます。

一つの退避ボックスには最大1,024個の退避ファイルを作成できます。

ajsbackupのメリット

例えば、

会計システム

に関連する複数のジョブネットを変更するとします。

その場合、

ACCOUNT_BACKUP

という退避ボックスを作成し、

JOBNET_A
JOBNET_B
JOBNET_C

をまとめて退避できます。

つまり、

ACCOUNT_BACKUP
   ├─ JOBNET_A
   ├─ JOBNET_B
   └─ JOBNET_C

という単位で管理できます。

公式マニュアルでも、退避ボックスを使用することで複数のユニットをまとめて管理できる点が特徴として説明されています。

ajsrestoreで回復する

退避したユニットを回復する場合は、

ajsrestore

を使用します。

例えば、

ajsrestore -t -n BACKUP

とすると、まず BACKUP 退避ボックスの内容を確認できます。

そのうえで対象の退避ファイルを指定して回復します。

ajsrestore を使う場合は、JP1/AJS3が管理している退避情報をそのまま利用できるため、同一サーバー内での「変更前へ戻す」用途には分かりやすい方式です。

例えばジョブネット変更前に退避する

本番環境で、

/業務/DAILY_JOB

を変更するとします。

変更前に、

ajsbackup -m -n BEFORE_CHANGE /業務/DAILY_JOB

としておきます。

変更後に問題が発生した場合、

BEFORE_CHANGE

から ajsrestore を使って戻せます。

このような、

「変更作業前に一時的に退避して、問題があれば戻す」

という用途では、ajsbackup / ajsrestore が非常に分かりやすいです。

両方式を比較

大まかな違いを整理すると次のようになります。

項目	ajsprint / ajsdefine	ajsbackup / ajsrestore
退避先	任意のファイル	退避ボックス
データ形式	テキスト形式のユニット定義	JP1管理の退避ファイル
定義情報	○	○
実行結果	×	×
同一サーバー復旧	○	○
別サーバーへの移行	○	×
複数ユニットの一括管理	手動管理	退避ボックスで管理しやすい
ファイル名を自由に付ける	○	×（0001～1024）
Git管理	しやすい	向かない
diffによる差分確認	しやすい	向かない
JP1/AJS3 – Viewとの連携	基本CLI	可能
作業前の一時退避	○	特に向いている
サーバー更改・移行	向いている	向かない

一番大きな違いは「別サーバーへ持っていけるか」

両者を比較すると、一番重要な違いの一つがこれです。

ajsprint / ajsdefine
→ 別サーバーでも利用可能

ajsbackup / ajsrestore
→ 基本的に退避元と同一サーバーで回復

公式マニュアルにも、退避ボックス方式で退避したユニットは同一サーバーでだけ回復でき、別サーバーへ回復する場合は ajsprint / ajsdefine を使用するよう明記されています。

そのため、

サーバー更改

本番→検証環境への定義移行

旧サーバー→新サーバー

DR環境への定義展開

などでは、ajsprint / ajsdefine の方が使いやすくなります。

ajsbackupの実体もajsprintに近い

興味深いのは、ajsbackup で作られる退避ファイルです。

公式マニュアルでは、退避ファイルは、

ajsprint -a で出力した形式

で格納されると説明されています。

つまり内部的な考え方としては、

ユニット定義
 ↓
ajsprint -a相当
 ↓
退避ファイル

です。

違いは、

自分でファイル管理する

のか、

JP1/AJS3の退避ボックス管理に任せる

のか、と考えると分かりやすいでしょう。

では、どちらを使うべきか

用途によって選ぶのがおすすめです。

作業前の退避なら ajsbackup

例えば、

本番ジョブネットを修正する

という作業なら、

ajsbackup -m -n BEFORE_CHANGE /業務/DAILY_JOB

としておけば、

「問題があれば元に戻す」

という操作が分かりやすくなります。

つまり、

短期的な退避・回復

には ajsbackup / ajsrestore が向いています。

長期バックアップなら ajsprint

一方、

毎日定義を保存する

1年間保存する

変更履歴を管理する

別サーバーへ保管する

といった用途なら、

ajsprint -a /業務/DAILY_JOB > DAILY_JOB_20260909.def

のようにファイルとして保存する方が管理しやすいでしょう。

特に、

diff

で変更前後を比較できる点は非常に便利です。

Gitで管理するならajsprint

ジョブネット定義の変更履歴をGitで管理したい場合にも ajsprint が向いています。

例えば、

jp1-definition/
 ├─ DAILY_JOB.def
 ├─ MONTHLY_JOB.def
 └─ BILLING_JOB.def

としてGitリポジトリへ登録します。

すると、

誰が

いつ

どこを変更したか

を履歴として管理できます。

JP1/AJS3 – Viewだけで定義を管理している環境でも、定期的に ajsprint を取得しておけば、定義変更の監査やトラブル調査に役立ちます。

両方使う方法もおすすめ

実際の運用では、どちらか一方に統一する必要はありません。

例えば、

日常の変更作業
 ↓
ajsbackup

長期保存
 ↓
ajsprint

と使い分ける方法があります。

例えば本番変更前には、

ajsbackup -m -n CHG_20260909 /業務/DAILY_JOB

を実行します。

さらに長期バックアップとして、

ajsprint -a /業務/DAILY_JOB \
  > /backup/jp1/DAILY_JOB_20260909.def

も取得します。

これなら、

短期回復
→ ajsrestore

長期回復
→ ajsdefine

別サーバー移行
→ ajsdefine

という柔軟な運用ができます。

登録済みジョブネットを回復するときの注意

重要な注意点があります。

実行登録されているジョブネットを退避した場合、

ajsprint
ajsbackup

のどちらを使っていても、

ajsdefine
ajsrestore

で回復すると、ジョブネットは登録解除状態になります。

これは公式マニュアルにも記載されています。

そのため、

ジョブネット回復
 ↓
終わり

ではなく、

ジョブネット回復
 ↓
定義確認
 ↓
必要に応じて再登録

までを運用手順に含めておく必要があります。

文字コードにも注意

ajsdefine で定義ファイルを読み込む場合、ファイルの文字コードにも注意が必要です。

公式マニュアルでは、コマンド引数として指定するファイル内容は、

AJSCHARCODE

環境設定パラメーターで指定されている文字コードに合わせる必要があるとされています。

別サーバーへコピーした際に、

UTF-8

Shift_JIS

EUC-JP

などの文字コードが意図せず変更されると、定義エラーなどの原因になる可能性があります。

巨大な定義ファイルにも注意

大量のジョブネットを一つの定義ファイルに出力する場合も注意が必要です。

公式マニュアルでは、ajsdefine に指定するユニット定義ファイルが大きすぎてメモリー不足になる場合、

200MB以下になるようファイルを分割する

ことが案内されています。

通常のジョブネットで問題になるケースは多くありませんが、全ユニットを一括出力するような運用では覚えておいた方がよいでしょう。

ネストジョブネットのスケジュールにも注意

さらに少し高度な注意点として、ネストジョブネットのスケジュール定義があります。

特定条件では、

退避元

と、

回復後

で有効になるスケジュール定義が異なる場合があります。

これは、

ajsbackup
ajsprint

のどちらにも関係します。

公式マニュアルでは、環境設定パラメーター、

AJSPRINTNETSCHPRF

を適切に設定することで、退避元と回復先のユニット定義情報を一致させる方法が案内されています。

古いバージョンから長期間アップグレードして使用している環境では、一度確認しておく価値があります。

結局どちらがおすすめ？

目的別にまとめると、

ちょっと変更する前に戻せるようにしたい
→ ajsbackup / ajsrestore

定義を長期間保存したい
→ ajsprint / ajsdefine

定義変更前後をdiffで比較したい
→ ajsprint / ajsdefine

複数ユニットを退避ボックス単位で管理したい
→ ajsbackup / ajsrestore

別サーバーへ移行したい
→ ajsprint / ajsdefine

と考えると分かりやすいでしょう。

まとめ

JP1/AJS3のユニット定義には、

ajsprint / ajsdefine

と、

ajsbackup / ajsrestore

という2種類の退避・回復方法があります。

どちらも基本的には、

ジョブネットやジョブの定義情報を退避する仕組み

であり、実行結果までバックアップするものではありません。

最大の違いは管理方法です。

ajsprint / ajsdefine
＝定義ファイルとして自分で管理

ajsbackup / ajsrestore
＝JP1/AJS3の退避ボックスとして管理

という違いがあります。

さらに重要なのが、

ajsprint / ajsdefine
→ 別サーバーへの移行可能

ajsbackup / ajsrestore
→ 同一サーバーでの回復を前提

という点です。

そのため実運用では、

日常の変更前退避には ajsbackup / ajsrestore

定期バックアップ、変更履歴管理、サーバー移行には ajsprint / ajsdefine

という使い分けが分かりやすいでしょう。

そして重要なジョブネットなら、どちらか一方だけにするのではなく、

変更直前
→ ajsbackup

長期保管
→ ajsprint

と両方を組み合わせる方法も有効です。

JP1/AJS3の退避・回復は、単に「バックアップを取る」だけではなく、

何のために退避するのか

を考えて方式を選ぶことが重要です。

JP1/AJS3には2種類の退避・回復方法がある

まず重要：どちらも実行結果はバックアップしない

方法1：ajsprint / ajsdefine を使う

ajsprintとは

ajsprintで退避するイメージ

ajsdefineで回復する

ajsprint / ajsdefine の大きなメリット

別サーバーへ移行できる

ajsprint / ajsdefine の運用例

方法2：ajsbackup / ajsrestore を使う

ajsbackupとは

退避ボックスとは

ajsbackupのメリット

ajsrestoreで回復する

例えばジョブネット変更前に退避する

両方式を比較

一番大きな違いは「別サーバーへ持っていけるか」

ajsbackupの実体もajsprintに近い

では、どちらを使うべきか

作業前の退避なら ajsbackup

長期バックアップなら ajsprint

Gitで管理するならajsprint

両方使う方法もおすすめ

登録済みジョブネットを回復するときの注意

文字コードにも注意

巨大な定義ファイルにも注意

ネストジョブネットのスケジュールにも注意

おすすめ運用

結局どちらがおすすめ？

まとめ