ＭＴ４用ＥＡ開発時代 － 「ERR_COMMON_ERROR」再び。。

さて前回は、デモ口座上のＭＴ４用ＥＡで発生した、「ERR_COMMON_ERROR」にどう対処するのか検討している様子を書きました。今回は、新たに発見した「ERR_COMMON_ERROR」発生とその原因の仮説をかいてみたいと思います。

まずは今回の記事の発端は、ＭＴ４の「Ｅｘｐｅｒｔ」タブに出力しているログで、エラー検出しているものを抽出して精査してみて気付いたから。

とりあえず、どういう環境で何をなぜログを精査したのかという話から。

まず以前の記事で書いたデモ口座環境の詳細を書いてみると。

【デモ口座環境詳細】

－－－－－－－－－－－－－－－－－－－－－－－－

１．テスト用デモ口座１（口座開設予定ＦＸ業者(Forex.com)のＭＴ４）

　　「旧SmoothMADIシステム」（５分足版）×６通貨ペア

　　テスト用ＥＡ（５分足）×４通貨ペア

２．テスト用デモ口座２（口座開設予定ＦＸ業者(Forex.com)のＭＴ４）

　　「旧SmoothMADIシステム」（本来設定：４Ｈ足版）×４通貨ペア

３．テスト用デモ口座３（FREEZELEVEL設定ＦＸ業者(FXDD)のＭＴ４）

　　「旧SmoothMADIシステム」（５分足版）×６通貨ペア

　　テスト用ＥＡ（５分足）×４通貨ペア

４．テスト用デモ口座４（ＥＣＮ系ＦＸ業者(ODL)のＭＴ４）

　　「旧SmoothMADIシステム」（５分足版）×６通貨ペア

　　テスト用ＥＡ（５分足）×４通貨ペア

－－－－－－－－－－－－－－－－－－－－－－－－

次は、上記４つのデモ口座で一体何をしているのかという話。

【今どんな評価をしてるいるのか】

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

最初は、実際に使う予定の「旧SmoothMADIシステム」を５分足にすることで売買回数を増やして、潜在バグを見つけようとしていたけど、売買ルールの特性上、せっかくエラーが発生しても、OrderModify()がほとんど。なので、OrderSend()とOrderClose()の回数をもっと増やした共通部品テスト用のＥＡを作成して途中から追加。

テスト用ＥＡを追加したもう一つの理由としては、「旧SmoothMADIシステム」では「成り行き注文」と「決済指値」は使わないので、そこもテストしたかったから。

そして今回、「Expert」タブに出力しているログファイルの中からメール通知されない”[[INFO]]"レベルのログを抽出して、精査してみた。（ログ出力レベルを定義した記事はコレ）

"[[WARN]]"/"[[CRITICAL]]"レベルはメールで通知されているから、発生したことがわかっているけど、
"[[INFO]]"レベルの発生事象については、メール通知しないので、ログの精査が必要。

本番になったら、異常が発生しない限りログを見る事はほとんど見ないと思うけど、今はまだテスト段階なので、精査して異常な動きが無いかを見るべき時期。

つまり、ログを精査することで、いろんな異常や改善点に気付けるから。

●元々の「テスト計画」はどこいった？

　以前のブログ記事で書いた「テスト計画」を本来は進めたいけど、いかんせん初のＭＴ４でのＥＡ

　プログラミング。実際に動かして何が起きるのかを把握しておかないと、緻密にテストしたところで

　的外れなロジックになっていたら意味が無い。

　なので、今回「警告メール」で見つけたバグ改修を優先させて、ＥＡの動作が落ち着いてから

　「テスト計画」に基づいたテストをする事に変更した。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

そして、ログ精査をやってみると。

「ERR_COMMON_ERROR」発見！！

【なぜ「ERR_COMMON_ERROR」がメール通知されなかったのか】

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

なぜ「ERR_COMMON_ERROR」が、メール通知されない"[[INFO]]"レベルのログ出力になっていたかと言うと、OrderClose()失敗時にはエラーコードによらず、チケット番号指定でOrderSelect()して、OrderCloseTime()がゼロじゃなければ（つまり決済されていれば）、"[[INFO]]"レベルのログ出力はするけど、メール通知しないロジックにしていたから。

ちなみに前回記事でも「ERR_COMMON_ERROR」が発生したのは、OrderClose()時。

じゃあなぜ前回記事では"[[CRITICAL]]"レベルで、今回は"[[INFO]]"レベルなのかという事なんだけど、前述のOrderSelect()時では、以前の記事に書いたOrderSelect最新化処理が抜けていたから。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

また修正箇所増えちゃった。。。

【結局、前回発生した「ERR_COMMON_ERROR」の原因は？】

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

つまるところ、OrderClose()時に既にＳＬ／ＴＰによる決済がされていたら、「ERR_COMMON_ERROR」が返ってくるという仮説がでてきた。

ヘルプを読む限り、実在チケット番号で決済済みポジションを操作しようとした場合、「ERR_INVALID_TRADE_PARAMETERS」が返却されるべきなので、結論としては、おそらくサーバ側バグ。

今回も前回も「ERR_COMMON_ERROR」が発生していたのは、「４．テスト用デモ口座４（ＥＣＮ系ＦＸ業者(ODL)のＭＴ４）」だけ。

ただ、この「ＯＤＬ」の環境でも、OrderModify()時に既にＳＬ／ＴＰによる決済がされていた場合は、ちゃんと「ERR_INVALID_TRADE_PARAMETERS」が返却されている。

次に、他のデモ口座環境のログを２つのエラーコードで発生状況を調べてみると、「ERR_COMMON_ERROR」は発生してなくて、OrderModify時に「ERR_INVALID_TRADE_PARAMETERS」が発生していただけ。

なので、結局のところ、サーバ固有の問題なのか、サーバ共通的な問題なのかは不明。

少なくとも、OrderClose()時に「ODL」のサーバが返却したエラーコードの「ERR_COMMON_ERROR」はサーバ側のバグ。他のサーバは同じバグがあるのかが不明。
★2011/06/15 追記
　その後、「Forex.com」のサーバ でも同様の事象が発生した事を確認

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

で、前回「ERR_COMMON_ERROR」の発生原因が不明なまま、発生時の対処方法を決めたが、今回で原因が判明。じゃあ、前回決めた対処はどうするのかという話。

【共通部品として「ERR_COMMON_ERROR」への対応はどうする？】

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

今回のブログ記事での検討結果によって、前回のブログ記事で書いた「ERR_COMMON_ERROR」への対応内容を変更すべきかどうか考えてみた。

すくなくとも前回「警告メール」で発生した「ERR_COMMON_ERROR」エラーは、決済済みオーダに対するOrderClose()が原因。

原因が判明して、他の原因で「ERR_COMMON_ERROR」は発生していない事を考えると、「ERR_COMMON_ERROR」は、なかなか発生しないエラーコードと考える事もできる。

ただ、前回ブログ記事での判断材料のひとつに、「その後のＭＴ４動作に異常は無かった」というのもあるけど、前回記事で書いた絵の構造がほぼ正しいとすると、やっぱり対処方法を変更する必要は無いと思う。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

ついにヨメから、

「オチ無くなったよね」

って言われた。。

そして、ＥＡプログラムソース修正が進まず、「FXシステムトレード初心者奮闘記」の「ＭＴ４用ＥＡ開発時代」は、新たなバグが出ない限り、「OrderSelect問題」仮説の検証に進むかもしれないのでした。

＃今回初めて、デモ口座で使ってるＭＴ４のＦＸ業者名を出してしまった。。。