More from: 備忘録

トラッキング情報が判り難い件(汗)

eBayで注文した商品(ThinkPad E540用の液晶パネル)が一昨日の夜に日本に到着し、昨日通関処理を終えた。
国内に入ってしまえばあとは東京から北海道までなら中一日で届く筈。
なので今頃はどの辺かなぁ?と思ってトラッキングしてみた。
そうしたら、
Delivery Attempt Chiba-Shi, JP 2017-07-14 02:39:00 pm
と表示された。
あれ?配達できなかったって?
しかも何故千葉市なの?
もしかして誤配達しようとして不在だったので持ち帰ったとか?
いや、でも、配達先は北海道の私の住所になっているし、一体何が起きたのだろう?
配送はFedExらしいので、そちらのトラッキングシステムを使ってみると、
2:39 pm Delivery exception CHIBA-SHI JP
Customer not available or business closed
と出てきて、やはり千葉市のどこかに届けようとして不在もしくは営業していなかったとなっている。
おかしいな、と言うことでググってみると、千葉市にはFedEXの配送を委託している業者があって、そこへの配送が出来なかったということらしい。
というわけで誤配でもなんでも無かったということだけど、もうちょっと判り易くしてくれないとなぁ、この辺が国内の業者と違うところだなぁ。

ちなみに昨日の記事に書いた”parceltracking.pb.com”というサイトからFedExのトラッキングシステムへ飛ぶことが出来るが、表記が全て英語で少々判り難い。
そこで、FedExのトラッキングシステムのurlを一部書き直すことで日本語で表示させれば随分と楽になる。
具体的には
https://www.fedex.com/apps/fedextrack/?tracknumbers=トラッキングNo&cntry_code=us
のラストの”us”を下記の様に”jp”に書き直して再表示すれば日本語で表示される。
https://www.fedex.com/apps/fedextrack/?tracknumbers=トラッキングNo&cntry_code=jp
トラッキングNoの部分は修正しなくてOK。

←クリックしてくれると嬉しいです。

無限ループは解決したけど

昨日書いた「Ridoc Document Routerの無限ループ」はなんとか解決した。
今日の朝Ricohに問い合わせたところ、複数の原因が考えられるがとりあえず出来ることを教えてもらえたので、現場に行ってやってみた。
ループに陥る原因としては、受信したデータを処理中にサーバがダウンしたために、処理が中途半端になったデータがあることや、処理するデータが大量にあるために処理に時間がかかり一見無限ループに陥ってしまったように見える場合もあるとのこと(いや、それは判りますがね)。
他には実行ファイルそのもの(Dds.exe)の破損も考えられるということだったが、今回は敢えて考えないことにした。
今回のはIO機器から送ったデータがA4一枚分しか無いことや、サーバを何度再起動しても変化が無いことからデータ量が多過ぎるということが原因とは思えず、やはり処理途中の中途半端な状態のデータがある為に配信サービスのプロセスが処理を終了できないでいると考えた。
そこで処理途中の中途半端な状態のデータを捨てることで正常な状態に復帰するのではないか(いや、「復帰して欲しい」が正解か)と思い、IO機器から送られたデータがどのように処理されるかを教えて貰い、正常に処理がされていればデータが存在しないはずのフォルダにあるファイルを消すことにした。
以降のフォルダ名の先頭の「RidocCab」はインストール時に指定したデータフォルダ名を指すので、ドライブレターやフォルダ名はその指定したものになる(例えばデータフォルダを「C:\Ricoh-data」とした場合は「C:\Ricoh-data\FtpRoot\”機器NO”」のようになる)。
IO機器から送られたデータは、最初に「RidocCab\FtpRoot\”機器NO”」に入り、処理に伴い「RidocCab\DR\Spool\Compose」→「RidocCab\cabinet\WG_Root\”各フォルダ”」の順に移動して行くので、最初の2つのフォルダにはファイルは残らない(筈)。
#ここで言う”機器NO”とは、各IO機器が持っている固有のNoで、配信管理ツールでFAX配信ログやスキャナー配信ログの”配信元機器”に表示されるNOのこと。
なので、「RidocCab\FtpRoot\”機器NO”」及び「RidocCab\DR\Spool\Compose」内のファイルをフォルダごと消すことにした。
まず最初に作業中にIO機器からのデータを受信しないように、タスクマネージャを使ってDds.exeの動作を止めて配信サービスを終了させた(配信管理ツールからでは停止できなかったため)。
次に念のため「RidocCab\DR\Spool」以下のフォルダとファイルを全て他の場所にバックアップとしてコピーした(幸い「RidocCab\FtpRoot\”機器NO”」以下にはファイルは無かったので「RidocCab\DR\Spool」以下だけで済んだ)。
その後「RidocCab\DR\Spool」以下のフォルダ(「Compose」「Entries」「Error」「JobList」)内のファイルとフォルダを全て削除した。
削除が完了したところでサーバを再起動し、起動後にタスクマネージャで負荷を見たところ、それまでは100%だったのがDds.exeが動作している状態でも数%まで下がっていたので、試しにFAX機からデータを送ったところ無事に指定したフォルダにデータが格納された。
これでなんとかIO機器からのデータを正常に処理することが可能になったが、サーバ自体はHDDにエラーがあって動作が不安定のままなので、早急にHDDを交換して再構築しなくてはならない。
HDDを交換して「EASEUS Drive Copy」を使ってディスク全体をコピーするつもりだけど、エラーのあるHDDを正しくコピーすること出来るのかな?

←クリックしてくれると嬉しいです。