「HULFT」タグアーカイブ

HULFT, Web開発, ブログ

HULFTの転送速度を理論値で算出する方法：単独転送と間欠転送で何が変わる？

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

HULFTで大容量ファイルを送信する際、
「単独転送と間欠転送では速度がどれくらい違うのか？」
と気になる場面は多いはずです。

特に、S3送信やネットワーク負荷対策で間欠転送を設定した場合、
「どれだけ転送時間が増えるのか？」を事前に把握しておきたいところです。

本記事では、HULFTの転送処理を理論値（数式）で算出する方法をわかりやすく解説します。

1. HULFT転送の基本：ブロック単位で送られる

HULFTはファイルをそのまま送るのではなく、
一定サイズ（ブロック長）に分割してブロック単位で送信します。

例えばブロック長を 16KB に設定している場合：

1ブロック = 16KB
1MBのファイルなら 1,048,576 ÷ 16,384 ≒ 64ブロック

という計算になります。

この「ブロック数 × ブロックあたりの処理時間」が転送時間に大きく影響します。

2. 単独転送の理論値：最速で送るシンプルな動作

単独転送（=間欠転送なし）は、
ブロックを休まず連続で送っていく動作です。

■ 単独転送の理論値計算式

※実効転送速度（Throughput）はネットワーク・HULFTヘッダなどのオーバーヘッドを含む実測値。

■ 例：500MBのファイルを100Mbpsで送信する場合

理論上は40秒となります。

実際にはHULFTヘッダ分のオーバーヘッドで数秒増える程度。

3. 間欠転送の理論値：休止時間の積み重ねで大幅に遅くなる

間欠転送は、各ブロック送信後に**休止時間（インターバル）**が入ります。

HULFTの設定例：

ブロック長：16KB
ブロック回数：100回
休止時間：30ms

■ 間欠転送の理論計算式

ここが最も重要なポイント。

ブロックが多い場合、休止時間が膨れ上がります。

4. 実例：500MBファイルを間欠転送で送るとどうなる？

★ 前提

ブロック長：16KB
500MB = 32,768ブロック
単独転送時間：40秒（前述）
休止時間：20ms

■ 間欠転送の追加時間

■ 合計転送時間

→ 実際の現場でも「間欠転送は数倍遅くなる」理由はここにある

ブロック数 × 休止時間 → これが爆発的に効いてくるためです。

5. 実効転送速度（Throughput）の簡易算出方法

実測値を1回取るだけで、理論値がもっと正確になります。

■ 実測からの計算式

例えば

100MBのファイル
送信実測15秒
→ 実効速度 = 100MB ÷ 15 = 6.6MB/s（53Mbps）

これを単独転送の基準値にすることで、
間欠転送の予測精度が向上します。

6. 間欠転送の「適切な使いどころ」

間欠転送は遅くなるため万能ではありませんが、
以下の目的では効果的です。

S3/クラウド側で転送速度制限がある場合
受信側の負荷分散が必要な場合
夜間バッチでNW帯域を食いすぎるのを避けたい時
他システムの処理性能に合わせたいケース

速度ではなく安定性や負荷分散を目的に使うのが本来の用途。

7. 間欠転送設定によるエラー（S3Timeout など）について

休止時間を入れると、
1ブロックあたりの処理が遅くなる → 全体が長くなる → タイムアウトに近づく
という問題があります。

特にS3送信では

S3Timeout（約60秒）
NW機器の制限
プロキシのタイムアウト

などに引っかかるケースが多い。

✔ 大容量ファイルほど間欠転送はリスクが高い

500MB・1GB級のファイルではブロック数が膨大になるため、
一気にタイムアウト領域に入ります。

まとめ

項目	単独転送	間欠転送
速度	最速	休止時間分だけ遅い
仕組み	ブロックを連続送信	ブロック送信→休止の繰り返し
理論値算出	単独転送時間のみ	単独転送＋(ブロック数×休止時間)
メリット	最速で送れる	負荷を抑え安定性を上げる
デメリット	帯域を多く使う	極端に遅く、タイムアウトを誘発

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

HULFT「間欠転送あり」と「なし」で何が変わる？S3送信で発生するエラーの原因と対策

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

💡 はじめに

HULFTでS3（クラウドストレージ）へファイルを送信する際、「間欠転送」という設定があります。
この機能は通信の安定化を目的としたものですが、実際には設定値によって転送が失敗したり、タイムアウトを引き起こすケースもあります。

この記事では、「間欠転送あり」と「間欠転送なし」で何がどう変わるのか、そしてS3送信でエラーが起こる原因と具体的な対策を整理します。

🔹 間欠転送とは？

間欠転送は、大きなファイルを一定サイズごとに区切って、間隔を空けながら送信する仕組みです。

通常転送が「連続的なデータストリーム」なのに対し、間欠転送は次のような動きになります。

この「16KB」は、転送ブロック長（4KB）×ブロック数（4） の場合の動作例です。

🔹 通常転送との違い

項目	通常転送（間欠なし）	間欠転送（あり）
仕組み	ファイルを連続して送信	小分けして間隔ごとに送信
メリット	高速・設定不要	通信の途切れを防げる（S3Timeout対策）
デメリット	長時間通信で切断される可能性あり	設定次第で速度低下・不安定化する
想定環境	LAN・オンプレ間など安定回線	WAN・VPN・S3などクラウド宛て

🔹 なぜS3で間欠転送が重要なのか

S3ストレージオプションは、HULFT内部で HTTP(S)通信 を使用しています。
この通信は、一定時間データの送受信が行われないと「タイムアウト扱い」となり、セッションが切断されます。

そのため、定期的に通信を行う間欠転送を使うことで、S3側が「接続が生きている」と判断しやすくなり、転送が安定します。

⚠ S3送信でエラーになる原因

間欠転送なしで送信してエラーになる場合、間欠転送にすることでエラー解消する場合もあります。

ところが、実際には「間欠転送をONにしたら逆に転送が失敗した」という報告も少なくありません。
主な原因は以下の通りです。

原因	内容	対応策
① 設定値が極端（間隔0msやブロック1など）	通信制御が細かすぎて不安定になる	ブロック長4KB／ブロック数4／間隔20〜30msへ修正
② S3Timeoutが短い	デフォルトの60秒では間欠の待機中に切断される	hulft_s3.confに S3Timeout=120 以上を設定
③ 送信側と受信側の間欠設定が不一致	双方で動作パターンが異なりセッションが破綻	同一設定で統一する
④ ファイルサイズと設定バランスが悪い	大容量（数百MB）で間隔が長いと時間切れ	間隔を短く・ブロックを大きく調整
⑤ ウイルス対策やVPN干渉	小刻み通信が検査対象になり応答が遅延	除外設定または専用ポート経由に変更

🧭 S3送信における安定化の推奨設定

設定項目	推奨値	解説
転送ブロック長	4096 bytes（4KB）	標準的でメモリ効率が良い
転送ブロック数	4	16KB単位で通信制御が安定
転送間隔	20〜30ms	応答を維持しながら速度低下を抑制
S3Timeout	120〜180秒	デフォルト60秒では短すぎる
終了コード（RC）	RC=0が正常、RC=8以上は異常	メッセージではなくRCで結果を判定

この設定であれば、150〜350MBクラスのファイルを3〜9分程度で安定して送信できます。

🧱 間欠転送が逆効果になるケース

LAN内やオンプレ同士など、もともと通信が安定している環境では、間欠転送を入れることで逆にCPU待ちや余計な遅延を生むことがあります。
そのため、以下のように使い分けるのがベストです。

環境	推奨設定
社内LAN・閉域網	間欠転送なし（高速重視）
S3・WAN・VPN	間欠転送あり（安定性重視）

🧩 トラブルシューティングの手順

間欠転送をOFFに戻して再送信
　→ 正常に送信できるか確認して比較ベースを作る。
ONにした状態でログを確認
　→ 通信エラー・再送メッセージなどを確認。
設定を微調整（間隔20→30msなど）
　→ エラー頻度が下がるかを検証。
S3Timeoutを延長
　→ hulft_s3.conf に S3Timeout=180 を追記。
VPN・FW・ウイルス対策干渉をチェック
　→ 小刻み通信の検査を除外する設定を追加。

🧠 まとめ

間欠転送は「S3など不安定回線向けの安定化機能」。
ただし設定値を誤ると、通常転送より不安定になる。
4KB×4ブロック・20〜30ms間隔・S3Timeout120秒以上が実運用で最も安定。
ジョブの成否は**終了コード（RC）**で判定し、メッセージ内容は原因分析に利用する。

HULFT, Java, ブログ, プログラミング

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

1. HULFT転送の基本：ブロック単位で送られる

2. 単独転送の理論値：最速で送るシンプルな動作

■ 単独転送の理論値計算式

■ 例：500MBのファイルを100Mbpsで送信する場合

3. 間欠転送の理論値：休止時間の積み重ねで大幅に遅くなる

■ 間欠転送の理論計算式

4. 実例：500MBファイルを間欠転送で送るとどうなる？

★ 前提

■ 間欠転送の追加時間

■ 合計転送時間

→ 実際の現場でも「間欠転送は数倍遅くなる」理由はここにある

5. 実効転送速度（Throughput）の簡易算出方法

■ 実測からの計算式

6. 間欠転送の「適切な使いどころ」

7. 間欠転送設定によるエラー（S3Timeout など）について

✔ 大容量ファイルほど間欠転送はリスクが高い

まとめ

関連記事

💡 はじめに

🔹 間欠転送とは？

🔹 通常転送との違い

🔹 なぜS3で間欠転送が重要なのか

⚠ S3送信でエラーになる原因

🧭 S3送信における安定化の推奨設定

🧱 間欠転送が逆効果になるケース

🧩 トラブルシューティングの手順

🧠 まとめ

関連記事

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` の場合

　関連記事