「HULFT」タグアーカイブ

HULFT連携：Javaからユーティリティコマンドを呼び出す実装例

2025年10月1日管理者コメントする

HULFTには「送受信ジョブを定義して使う方法」以外に、utlsendなどのユーティリティ系コマンドを直接呼び出してファイル転送や加工を行う手段があります。
これらは事前の送受信定義が不要で、コマンド実行時に条件を指定できるため、テスト送信・スポット利用・簡易処理に非常に便利です。

本記事では、JavaでHULFTコマンドを実行する例をご紹介します。

utlsend : ファイル送信
utlrecv : ファイル受信
utlconcat : ファイル連結
utlsplit : ファイル分割

Javaから外部コマンドを実行する基本

Javaでは ProcessBuilder を使うことで、外部のHULFTコマンドを呼び出せます。
エラー出力も標準出力にまとめる設定をすれば、ログ管理が容易になります。

共通の呼び出しテンプレートは以下の通りです。

import java.io.*;

public class HulftCommandRunner {
    public static void runCommand(String... command) {
        try {
            ProcessBuilder pb = new ProcessBuilder(command);
            pb.redirectErrorStream(true);
            Process process = pb.start();

            BufferedReader reader = new BufferedReader(
                    new InputStreamReader(process.getInputStream(), "MS932")); // Windows日本語環境想定
            String line;
            while ((line = reader.readLine()) != null) {
                System.out.println(line);
            }

            int exitCode = process.waitFor();
            System.out.println("終了コード: " + exitCode);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

import java.io.*;

public class HulftCommandRunner {

public static void runCommand(String... command) {

try {

ProcessBuilder pb = new ProcessBuilder(command);

pb.redirectErrorStream(true);

Process process = pb.start();

BufferedReader reader = new BufferedReader(

new InputStreamReader(process.getInputStream(), "MS932")); // Windows日本語環境想定

String line;

while ((line = reader.readLine()) != null) {

System.out.println(line);

}

int exitCode = process.waitFor();

System.out.println("終了コード: " + exitCode);

} catch (Exception e) {

e.printStackTrace();

}

以降の例では、この runCommand を利用して各ユーティリティコマンドを実行します。

1. ファイル送信（`utlsend`）

事前の送信定義が不要で、対象ファイルと宛先ノードを直接指定できます。

public class ExampleSend {
    public static void main(String[] args) {
        HulftCommandRunner.runCommand(
            "utlsend",
            "-f", "/data/test.txt",
            "-n", "NODE001"
        );
    }
}

public class ExampleSend {

public static void main(String[] args) {

HulftCommandRunner.runCommand(

"utlsend",

"-f", "/data/test.txt",

"-n", "NODE001"

);

}

-f : 送信するファイルパス
-n : 宛先ノード名（HULFTに登録済み）

2. ファイル受信（`utlrecv`）

受信ジョブを登録せず、コマンドだけでファイルを取得できます。

public class ExampleRecv {
    public static void main(String[] args) {
        HulftCommandRunner.runCommand(
            "utlrecv",
            "-f", "/data/recv.txt",
            "-n", "NODE001"
        );
    }
}

public class ExampleRecv {

public static void main(String[] args) {

HulftCommandRunner.runCommand(

"utlrecv",

"-f", "/data/recv.txt",

"-n", "NODE001"

);

}

-f : 保存先のファイル名
-n : 送信元ノード名

3. ファイル連結（`utlconcat`）

複数のファイルを1つにまとめたいときに使います。

public class ExampleConcat {
    public static void main(String[] args) {
        HulftCommandRunner.runCommand(
            "utlconcat",
            "-o", "/data/merged.txt",
            "-f", "/data/file1.txt",
            "-f", "/data/file2.txt"
        );
    }
}

public class ExampleConcat {

public static void main(String[] args) {

HulftCommandRunner.runCommand(

"utlconcat",

"-o", "/data/merged.txt",

"-f", "/data/file1.txt",

"-f", "/data/file2.txt"

);

}

-o : 出力ファイル名
-f : 結合対象のファイル（複数指定可）

4. ファイル分割（`utlsplit`）

大きなファイルを分割して処理したいときに使います。

public class ExampleSplit {
    public static void main(String[] args) {
        HulftCommandRunner.runCommand(
            "utlsplit",
            "-f", "/data/bigfile.txt",
            "-l", "1000"
        );
    }
}

public class ExampleSplit {

public static void main(String[] args) {

HulftCommandRunner.runCommand(

"utlsplit",

"-f", "/data/bigfile.txt",

"-l", "1000"

);

}

-f : 分割対象ファイル
-l : 分割する行数（例：1000行ごと）

運用上の注意点

PATHの設定
Javaから呼び出す際は、utlsend.exe などのHULFTバイナリがPATHに通っている必要があります。
通っていない場合はフルパス指定が必須です。
終了コードの確認
- 0 : 正常終了
- 0以外 : エラー（詳細はHULFTマニュアルのエラーコード参照）
ログ管理
実際の業務バッチでは process.getInputStream() の内容をファイル出力してログ管理することを推奨します。

まとめ

utlsend でファイルを即送信できる
utlrecv で即時受信が可能
utlconcat でファイルを連結
utlsplit でファイルを分解

これらをJavaから呼び出すことで、柔軟なファイル連携や加工処理が実現できます。

HULFT, Web開発, ブログ

HULFTの転送速度はどのくらい？大容量ファイル送信を高速化するチューニング術

2025年9月24日管理者コメントする

企業システム間のデータ連携で定番の HULFT（ハルフト）。
日次バッチや帳票ファイルの受け渡しで使っていると、「転送が遅いのでは？」と感じることもあるでしょう。

この記事では、HULFTの転送速度の目安と、大容量ファイルを高速・安定的に送信するためのチューニング術をまとめます。
さらに、WinSCP や AWS CLI との比較も紹介します。

1. HULFTの転送速度の目安

HULFT自体は内部的に64bit整数でファイルを扱えるため、理論的な制限はほぼありません。
実際の速度は ネットワーク帯域 × HULFTの処理オーバーヘッド に左右されます。

📊 ファイルサイズ別の目安（1Gbps環境・実効70〜80%の場合）

ファイルサイズ	転送時間の目安	備考
100MB	1〜2秒	LAN環境なら一瞬
1GB	10〜15秒	WAN越しだと数分に延びることも
5GB	1〜2分	S3の1オブジェクト上限(5TB)には余裕あり

💡 100Mbpsの回線では、1GB送信に2分前後かかります。
つまり「回線帯域の影響が支配的」と言えます。

2. 回線速度ごとの目安

HULFTのオーバーヘッド込みで実効値を 70〜80% と仮定した場合の目安です。

回線速度	理論値	実効値(目安)	1GB転送時間
1Gbps回線（LAN内）	125MB/s	90〜100MB/s	約10〜12秒
100Mbps回線（VPN/クラウド接続）	12.5MB/s	8〜10MB/s	約100〜120秒（2分程度）
50Mbps回線（遅めのVPN）	6.25MB/s	約5MB/s	約200秒（3〜4分）
10Mbps回線（制限回線など）	1.25MB/s	約1MB/s	約15〜20分

👉 このように、回線帯域がボトルネックになるケースが大半です。

チューニングで改善できるのは「オーバーヘッド部分」ですが、根本は回線速度に依存します。

3. HULFTと他の手段の速度比較

同じ回線での「体感スピード」の比較イメージです。

手段	転送速度の傾向	特徴
HULFT	実効70〜80%（安定）	商用の運用性・再送制御が強い。監査/ジョブ連携向き
WinSCP (SFTP/FTP)	実効50〜70%	GUIで扱いやすいが大容量の再送制御は弱め
AWS CLI (S3 cp/sync)	実効80〜90%（並列化可）	高速だがジョブ管理や監査は限定的

👉 HULFTは「最高速」ではなく「確実性と運用性を優先した転送」という位置づけです。

特に基幹システム間の「失敗できない転送」ではHULFTが選ばれる理由があります。

4. 転送速度に影響する要因

HULFTの転送性能は、次の要素で大きく変わります。

ネットワーク帯域：1Gbpsか100Mbpsかで10倍以上の差
HULFTのバッファサイズ：デフォルト64KB → 1MBに拡張すると効率UP
再送制御：エラー時の挙動設定によって安定性と速度が変わる
ファイルシステムのI/O性能：HDDよりSSDの方が有利
暗号化や圧縮の有無：CPU負荷が上がると転送速度が落ちる

5. 高速化のためのチューニング術

大容量ファイルを送る際に有効なチューニング方法を整理します。

(1) バッファサイズ調整

パラメータ SEND_BUFFER_SIZE を 1024KB（1MB）程度 に拡張
WAN越しでもスループットが改善

(2) マルチパートアップロード（S3利用時）

HULFT Storage Option では 並列転送 に対応
1GBクラスなら1パートで十分だが、数GB以上なら 4〜8並列 に設定すると効果大

(3) 部分再送を有効化

転送途中で中断しても 途中から再開 できる
WAN経由や夜間バッチでの安定性向上に必須

(4) 圧縮の利用

CSVやテキストは圧縮転送で大幅短縮
バイナリ（PDFやZIP）は圧縮効果が薄い

(5) ネットワーク調整

TCPウィンドウサイズやNIC送信バッファを拡張
Linux例：

net.core.wmem_max=16777216 net.ipv4.tcp_wmem=4096 87380 16777216

1
2

net.core.wmem_max=16777216
net.ipv4.tcp_wmem=4096 87380 16777216

6. 運用上の工夫

速度チューニングだけでなく、運用面でも工夫が必要です。

ピーク時間を避けてスケジューリング（夜間バッチに実行）
再送回数を3回程度に設定し、エラー時のリカバリを自動化
ログ監視（HULFTの送受信ログ＋S3側のCloudWatch）で転送成功を二重確認
日付付きファイル名で履歴管理を容易に

まとめ

HULFT自体は大容量に強く、理論上は数TB〜EBまで対応可能
実効速度は 回線帯域 × バッファ調整 × 再送設定 がカギ
100MBなら数秒、1GBなら十数秒〜数分 が目安
HULFTは最高速よりも「確実性・運用性」を重視する製品
バッファ拡張・並列化・部分再送 で安定高速な運用が可能

HULFT, トラブル対応, ブログ

HULFTで「完了コード250 エラー」が発生したときの対応手順

2025年9月20日管理者コメントする

HULFT (UNIX/Linux 環境) でファイル配信を行った際、「完了コード250」が返されることがあります。公式ドキュメントではこのコードを “A server error” としており、集信側（受信側）で異常が発生したことを示しています。⇒ HULFT

本記事では、完了コード250の意味、原因、公式で推奨されている対処方法、実践的なチェックポイント、および再発防止策をまとめます。

完了コード250とは？

項目	内容
エラーコード	250
英語名称	A server error HULFT
意味	「集信側に異常が発生したと考えられます」 HULFT
詳細	完了コード250が設定された場合、さらに詳細コードが設定されており、それが集信側の完了コードとなります。 HULFT

つまり、完了コード250は「送信側から配信は試みられたが、受信側で何かしら正常でない処理が起きて失敗した」ということを示す総称的なエラーで、原因の切り分けには “詳細コード” を見る必要があります。HULFT

主な原因（公式の可能性を含む）

ドキュメントに明記されている「完了コード250 → 集信側に異常が発生」の具体的な事例としては以下があげられます。これらは「詳細コード」によってどのような異常かが特定されます。HULFT

ディスク容量不足など、受信側で書き込みができない状態 HULFT
ファイルアクセス権限エラーやファイルロック状態 HULFT
テキスト転送で「1 レコードのデータ長が最大値を超えている」 HULFT
配信途中でファイルの編集や移動・削除など、ファイルの整合性が保てなくなる操作が行われた場合 HULFT
フォーマットミスマッチ・バージョン不一致など、データ形式やコードセットに関する不整合 HULFT

対応手順（公式の指示＋実践的対応）

以下は、公式ドキュメントの「対処（処置）」に加えて現場でよく使われるチェック項目を織り交ぜた手順です。

ステップ 1：ログ・詳細コードの確認

HULFT の hulog、trnlog もしくは配信ログを確認
完了コードが 250 の行を探す
その行に 詳細コード（集信側の完了コード）が記録されているか確認 HULFT
詳細コードに応じて原因の方向性を絞る

ステップ 2：受信側（集信側）の環境チェック

以下を重点的に確認します。

項目	チェック内容
ディスク容量	受信ディレクトリのあるファイルシステムの空き容量を確認
ファイルアクセス・ロック	該当ファイル名が他プロセスにより使用中でないか、書き込み権限があるか
ファイル操作	配信中に受信側でファイルを移動・削除・名前変更などしていないか
フォーマット・レコード長	テキスト転送時に1レコードの長さが制限（32768バイト）を超えていないかなど HULFT
バージョン・コードセット	転送や受信のフォーマット定義、文字コード変換などが正しく一致しているか

ステップ 3：通信経路・送受信設定の確認

ネットワーク切断、遅延、ファイアウォールによる通信遮断等の影響がないか
送信側・受信側両方の HULFT 定義（配信パラメータ、フォーマットID、文字コードなど）が整合しているか
マウントされているネットワークファイルシステム（NFS等）を使っている場合、属性キャッシュやマウントオプションが影響していないか確認 HULFT

ステップ 4：修正・再実行

問題箇所が見つかったら修正（空き容量確保、権限修正、ファイルの整合性維持、フォーマット修正など）
修正後、再度配信ジョブを実行
再送前に、テスト環境や限定ファイルで動作を確認できるならそれを行う

再発防止策

公式仕様と実践双方から以下が有効です：

監視体制の整備
- ディスク容量の自動監視
- ファイルシステムの状態／マウントオプションの監視
- HULFT ジョブのステータス監視（完了コードを含む）
設定の標準化とレビュー
- フォーマット定義・文字コード・レコード長などをドキュメント化
- 新しいノードや定義を追加する際のチェックリストを整備
テスト運用
- 転送前に小さなデータでテスト送受信を行う
- 大容量／長レコード／特殊文字を含むデータの事前検証
エラー通知システムの活用
- 完了コード250やその詳細コードをトリガーにアラートをあげるように設定
- 関係者に通知が行くようにすることで早期対応

ケーススタディ（想定例）

例 1：テキストファイルの 1 レコードが長すぎる

ある送信ジョブで、伝票データを1行にまとめすぎてしまい、1 レコードの文字数が制限（32,768バイト）を超えていた → 詳細コードが 251 の可能性あり。HULFT
対策：レコードを分割するか、フォーマットを見直す

例 2：受信側のディスクフル

受信サーバ上のディスク容量がゼロ近く、書き込みができずにエラー
対策：不要ファイルの削除、ディスク拡張、ログのローテーション設定など

まとめ

完了コード 250 は「受信側での異常」を示し、詳細コードにより原因の絞り込みが可能
ログの確認 → 環境チェック → 設定見直し → 修正・再実行が基本の流れ
再発防止のための監視・標準化・テストが重要

HULFT, Web開発, ブログ

HULFTでCSVをバイナリ指定するとどうなる？使い方と注意点まとめ

2025年9月17日管理者コメントする

はじめに

企業間やシステム間のデータ連携でよく利用されるファイル転送ソフトウェア「HULFT」。日常的にCSVやログファイルをやり取りしている方も多いと思います。
その際に必ず出てくるのが「ファイルモードの指定」。HULFTには 「テキスト指定（レコード指定）」 と 「バイナリ指定」 の2種類があり、どちらを使うべきか迷うケースが少なくありません。

本記事では 「CSVをバイナリ指定で送った場合どうなるのか？」 を中心に、メリット・デメリットや注意点を整理します。

バイナリ指定とは？

HULFTにおける「バイナリ指定」とは、ファイル内容を1バイト単位のデータとしてそのまま送受信するモードを指します。
この場合、HULFTは以下のような変換や処理を一切行いません。

改行コードの変換（CRLF⇔LFなど）
文字コードの変換（Shift-JIS⇔UTF-8など）
レコード単位の制御（固定長・可変長）

つまり「HULFTが何も手を加えずにコピーする」のがバイナリ指定です。

バイナリ指定のメリット

内容がそのまま届く
改行コードや文字コードが勝手に変換されないため、送信元のデータを完全に保持できます。
ファイル形式を問わない
CSVに限らず、Excel、PDF、ZIP、画像ファイルなども問題なく転送可能。
→ そのため「とりあえず壊れたくないファイルはバイナリ指定」で安全に扱えます。
異なるOS間でも安心
WindowsからLinux、Linuxからホスト系など、環境差異を気にせず転送できます。

バイナリ指定のデメリット

文字コード変換がされない
送信側がShift-JIS、受信側がUTF-8を前提としている場合、そのままでは文字化けします。
改行コードもそのまま
WindowsのCSV（CRLF）をLinuxで処理すると、アプリ側がLFを期待していた場合に不具合の原因になります。
レコード単位の扱いができない
COBOLやホストシステム連携など「固定長レコード前提」のファイルを扱う場合は不向きです。

CSVをバイナリ指定で送るとどうなる？

結論から言うと、基本的に悪影響はありません。
CSVは単なるテキストファイルですが、HULFT側で勝手に改行コードや文字コードを変換しないので、送信元と全く同じファイルが届きます。

ただし以下のケースでは注意が必要です。

文字コードが異なる場合
送信元がShift-JIS、受信先がUTF-8で解析 → 文字化けの可能性あり。
改行コードが異なる場合
Windowsで作成したCSVをLinuxで使うと、改行が意図通りに扱えないことがある。

そのため「受信側のシステムがどの文字コード・改行コードを想定しているか」を事前に確認しておくことが大切です。

まとめ

バイナリ指定は「ファイルをそのまま送りたいとき」に有効。
CSVを送る場合も基本的に問題はないが、受信側の文字コードや改行コードの前提条件によっては注意が必要。
迷ったらまずは「バイナリ指定」で送り、必要に応じて受信側で変換処理を入れるのが無難です。

👉 実際の業務では「相手先がどんなシステムで受けるのか」を確認してから指定するのが鉄則です。
もし「文字コード変換が必要」や「固定長レコード前提」のような要件がある場合は、バイナリ指定ではなくテキスト指定を選ぶ方が安全です。

HULFT, Web開発, ブログ

HULFTで日付付きファイルを配信元ファイル名のまま受信する方法

2025年9月11日管理者コメントする

HULFTを使ったファイル連携では、バッチ処理などで日付が付与されたファイル名を扱うケースが多くあります。
例えば、送信側で以下のように日付が付与されたファイルを生成する場合です。

sales_20250911.csv
sales_20250912.csv

受信側でもこのファイル名をそのまま維持して保存したい、という要件はよくあります。
本記事では、その場合に利用できる HULFTの動的パラメータ $SNDFILE を使った方法を解説します。

`$SNDFILE`とは？

HULFTには送受信時に利用できる動的パラメータが用意されています。
その中の一つが $SNDFILE で、これは 「送信元ファイル名」 を表します。

つまり $SNDFILE を指定することで、送信側が持つ実際のファイル名を受信側でそのまま利用することが可能です。

設定例

受信側（集信定義）の「受信ファイル名」に $SNDFILE を指定します。

C:\recv\$SNDFILE

この設定を行うと、送信されたファイル名のまま受信先に保存することが出来ます。

例：送信元のファイルが `sales_20250911.csv` の場合

配信元： /data/sales_20250911.csv
受信定義： C:\recv\$SNDFILE
保存結果： C:\recv\sales_20250911.csv

利用上の注意点

受信先でファイル名を固定して指定すると上書きされる
例えば C:\recv\sales.csv のように固定名を指定した場合、複数ファイルを送信すると最後のファイルで上書きされてしまいます。
→ $SNDFILE を使うことで、送信元ファイルごとに別々のファイルとして受信できます。
動的パラメータが有効になっている必要がある
$SNDFILE はHULFTの動的パラメータ機能を利用するため、システム環境設定で動的パラメータが有効化されていることを確認してください。
ディレクトリは固定、ファイル名だけ動的
C:\recv\ 部分は固定ですが、ファイル名部分に $SNDFILE を置くことで柔軟に対応可能です。

まとめ

$SNDFILE を使うことで、送信元のファイル名をそのまま受信側に引き継げる。
日付付きファイルや動的に生成されるファイル名を扱う場合に便利。
受信定義に C:\recv\$SNDFILE のように設定するだけで利用可能。

HULFTの運用では「配信元のファイル名をそのまま使いたい」という要件は多いため、覚えておくと便利なテクニックです。

Javaから外部コマンドを実行する基本

1. ファイル送信（utlsend）

2. ファイル受信（utlrecv）

3. ファイル連結（utlconcat）

4. ファイル分割（utlsplit）

運用上の注意点

まとめ

関連記事

1. HULFTの転送速度の目安

📊 ファイルサイズ別の目安（1Gbps環境・実効70〜80%の場合）

2. 回線速度ごとの目安

3. HULFTと他の手段の速度比較

4. 転送速度に影響する要因

5. 高速化のためのチューニング術

(1) バッファサイズ調整

(2) マルチパートアップロード（S3利用時）

(3) 部分再送を有効化

(4) 圧縮の利用

(5) ネットワーク調整

6. 運用上の工夫

まとめ

関連記事

完了コード250とは？

主な原因（公式の可能性を含む）

対応手順（公式の指示＋実践的対応）

ステップ 1：ログ・詳細コードの確認

ステップ 2：受信側（集信側）の環境チェック

ステップ 3：通信経路・送受信設定の確認

ステップ 4：修正・再実行

再発防止策

ケーススタディ（想定例）

例 1：テキストファイルの 1 レコードが長すぎる

例 2：受信側のディスクフル

まとめ

関連記事

はじめに

バイナリ指定とは？

バイナリ指定のメリット

バイナリ指定のデメリット

CSVをバイナリ指定で送るとどうなる？

まとめ

関連記事

$SNDFILEとは？

設定例

例：送信元のファイルが sales_20250911.csv の場合

利用上の注意点

まとめ

関連記事

「駑馬十駕」を信念に IT系情報を中心に調べた事をコツコツ綴っています。

1. ファイル送信（`utlsend`）

2. ファイル受信（`utlrecv`）

3. ファイル連結（`utlconcat`）

4. ファイル分割（`utlsplit`）

　関連記事

　関連記事

　関連記事

　関連記事

`$SNDFILE`とは？

例：送信元のファイルが `sales_20250911.csv` の場合

　関連記事