データの移行（β版）その１ ＴＰからの抽出
遅ればせながら・・・あけましておめでとうございます。
このブログを読まれている方が一人も居ないかもしれませんが、皆々様にとって良き一年でありますように。そしてオープン系への移行を考えている方、移行中の方、一緒に頑張りましょう～（＾＾）/
さてデータの移行です。
東芝ＴＰ系を使われている方なら十二分に理解されているかと思いますが、データ形式がちょっと特殊です。厳密に調べた事はありませんが、どうも東芝オリジナルっぽい感じです。
※厳密と言うのは、ＦＤの内容をダンプしてＩＢＭフォーマットと比較した・・・などなど、手間を掛けて調べたことが無い、と言う意味です。
一般的にデータの移行と言えば、外部媒体へＳＡＭ形式で出力→読み込み・変換→登録です。
元々東芝ＴＰのＳＡＭ形式は、ＰＣでそのまま読み込むことが不可能です。ＭＳ－ＤＯＳ形式での出力ルーチン（ＡＰＰ？）をお持ちなら、それも可能ですが。。。ちなみにウチのＴＰもＭＳ－ＤＯＳ出力ルーチンは組み込まれていますが、データ量が多いことと、何よりもＦＤＤがお亡くなりになられているので、ＦＤは最初ッから眼中にはありませんでした。。。
おそらく多くのＴＰユーザーも似たような状況ではないでしょうか？オフィス・サーバーなのに埃で直ぐ壊れちゃうんですよね。。。ウチの場合、障害時の起動はＭＯから行っていましたので、余計ＦＤを使う機会はありませんでした。
結論から言うとデータの抽出には「ＴＯＰＬＩＮＫ／Ｗ」を使用します。
念のため説明しますと、ＰＣとＬＡＮ接続し、ＰＣをクライアントとして使用するためのソフトです。端末エミュレータ機能（ＤＳＦ）の他、マイクロメインフレーム機能（ＭＭＬ）およびデータ転送機能（ＦＯＬＤＥＲ）があります。ウチではＴＰ９０／Ｆ導入時からＴＯＰＬＩＮＫ／Ｗを使用し、データをＰＣへＣＳＶ形式で転送していましたので、今回も同様に行おうと思いました。
※※※もしＦＤもＴＯＰＬＩＮＫ／Ｗも使えない状況なら？？※※※
東芝さんがＴＰのサポートを原則として行わない状況では、かなり深刻であると言えます。一度購入先へ相談されることをお薦めいたします。もしかしたらＨＤＤから抜き出せるかもしれません（未確認です）。ＭＯ上のデータもオリジナルらしく、ＰＣで読めますが形式は不明です。ＦＤが生きていてＭＳ－ＤＯＳ出力が可能なら自力でも可能だと思いますが現実的では無いようにも思います（データ量によりますが）。
東芝さんでは「ＴＰ／ＣＡＲＥ」というＣＯＢＯＬ８５＋Ｊａｖａを使用して従来通り動作できるシステムを出されていますので、導入が前提なら問題解決に向けて最大限の努力をしてくれると思います。私はＴＰ／ＣＡＲＥのデモをしてもらいました。ＪＣＬもそのまま使用できますし、ＳＯＲＴのみならずＦＩＬＭＡＮ等ユーティリティも動作する優れものです。しかしながらプログラムの移行作業が少々煩雑な感じがしたのと、デモ担当者がしきりに「先は無い」を連呼したので導入しませんでした（＾＾；
ちなみに、ＴＯＰＬＩＮＫ／Ｗは純粋にＰＣ用のソフトですが、端末エミュレート以外の機能（ファイル転送）を使用する場合、ＴＰ側にＯＡＬＩＮＫというＡＰＰが必要になります。つまりＴＯＰＬＩＮＫ／Ｗ単体では機能制限となってしまう訳で。。。この辺りの所は東芝さんの販売目的なので理解できますが、ＴＯＰＬＩＮＫ／Ｗ未導入で、これから移行したいユーザーにとっては頭の痛い所、いえ、腹の立つ所です。ＡＰＰの提供はもちろん、ＰＣＬ登録のサポートは絶望的ですので。。。最悪の場合、データの印刷→パンチャーに依頼、しかないように思います。一応、以下の本文が、何らかのヒントになれば幸いに思います。
本題に戻ってＴＯＰＬＩＮＫ／Ｗでのデータ転送についてです。
当初は従来通りＣＳＶで転送しようと思いました。ここで最初の壁に当りました。ファイル転送機能では項目ごとにパラメタを切らなければならないのですが、上限があります。Ａ、Ｂ、Ｃ・・・・・と続いてＥｘｃｅｌ的に数えていくのですが、ＢＬまで、つまり６４フィールドしか定義できません。これは困りました（＾＾；
６４フィールドでは足りないレコードがありましたから、ＴＰ側で分割処理を作成しなければならないかと考えてみたり、でも結合処理も作らなければならなくなるし、面倒だし。。。と、ここでファイル転送機能にＣＳＶ以外の形式もあることに気が付きました。
ＡＳＣＩＩ（区切記号あり）とＡＳＣＩＩ（区切機能なし）です。これまで使う機会も必要も無かった（ＣＳＶ→Ａｃｃｅｓｓ）という運用でしたので、挑戦してみることにしました。大事なのは何でもやってみることですね。
試行錯誤・検証を重ねた結果
ＡＳＣＩＩ形式で漢字以外は１フィールド（キャラクタ）として定義し、区切記号なしで取り込む
のが正解のようです。区切記号は無い方がＰＣ側での処理が楽だと思います。つまりレコード長そのままで読み込めるからです。無論、区切記号付きでも読み込めますが、
従来使用しているコピー句をそのまま使った方が間違いが少ない
と言うものです。
なぜ漢字フィールドは単一フィールドとして定義するのか？、ゾーン形式ならいざ知らずパック形式はどうするねん？と思われるかと思います。（・・・思わないかな）
・漢字について
ＴＰはＪＩＳマシンなので、漢字もＪＩＳコードです。しかしながらＰＣ（ＷＩＮＤＯＷＳ）はシフトＪＩＳなので変換が必要です。流石に自力で変換をする気力も無いですし、折角ＴＯＰＬＩＮＫ／Ｗが変換してくれるのですから、単一フィールドにする方が確実です。
・数値データについて
ゾーン形式はそのまんまなのでキャラクタで良いわけです。
パック形式も符号はＰＣでも同一
なので実は問題ありません。ＰＣ側でそのまま使えます。
蛇足＆推測ですが、ＴＰは限りなくＰＣに近い、もしかしたらＰＣかもしれない？と、随分前から感じていました。基盤などにもＳＣＳＩの表記もありますし、ＭＯもＰＣに流用できたりします（＾＾；
恐らくＭＯやＨＤＤも要件さえ満たせば・・・と考えた事もありますが、確かめてはいません。
と、結論だけ書くとＴＯＰＬＩＮＫ／ＷでＡＳＣＩＩ＆キャラクタ定義で転送可能と簡単な話ですね。。。
ただタイトルにあるようにβ版としたのは、本当にこれで良いという確信が持てない部分があるからです。それはデータのズレが発生している節があるからです。
実はデータの転送テストの際、別の処理でも試していました。それは昔々東芝のＳＥさんから内緒？で貰った転送プログラムです。これはデータ（ＳＡＭ、ＩＳＡＭ）のみならず、ライブラリ中のソースもＰＣと相互に交換できる物です。このプログラムでは、レコード長を指定してＰＣに取り込むことができますし、レコード単位にＣＲ（キャリッジ・リターン）を付けて取り込むこともできます。（惜しいのは漢字データの変換ができないことです。。。）
このプログラムで抽出したデータと、ＴＯＰＬＩＮＫ／Ｗで取り込んだデータを比較すると、稀に桁ズレが発生するレコードがあるようなのです。「あるようだ」と言うのは発生頻度が少ない為、検証が難しいのと、テストしているうちにハッキリしなくなった為です（＾＾；
これはＰＣ側での変換処理（ＣＯＢＯＬ２００２）を幾度と無く作り変えたのと、プログラム移行を急いでいたため途中でＯＫにしてしまったからです。最終的には再度検証しますが、ほぼ問題はないと考えています。結果については、追々ここで報告いたしますので、今の所はご容赦くださいませ。
余談ですが・・・この転送プログラム、動作環境が今一つ不明（ＯＡＬＩＮＫ系が必要かどうか）ですが、ＴＯＰＬＩＮＫ／Ｗがあれば最悪の場合使えるツールかと思います。漢字が変換できませんが、それ以外のデータは救える可能性が残されていますので。無論、最終的には試してみなくてはわかりませんので保障する話ではありません。が、可能性には掛ける価値あり。かと思います。
最終最悪、ＴＯＰＬＩＮＫ／Ｗが無くてもＬＡＮ基盤が入っていれば何とかなると思うのですが。。。
次回は「データの移行（β版）その２ ＰＣでの変換」について述べます。
