日記

主だったメール関連の技術は、いいかんじに枯れてきてる印象がある。
なのでここ10年ぐらい telnetでアクセスなんてこともなかったが、昨日からPHPのIMAP関連を触っていて。
それで しばらくぶりに、sendmailにコンニチワしたら、「さくらのレンタルサーバー」のメールでは これまで非対応と言われていた MD5系（CRAM-MD5やDIGEST-MD5）が返ってきた。

お！ と思った。

さくらインターネットさんは「STARTTLS」と「サブミッションポート」は公表しているけど、MD5系への対応についてはアナウンスしてなかったと思うんだよね。
これ対応したの、いつからなんだろうね。

auth CRAM-MD5 と入力したらチャレンジが返ってきた。

ただ、POP3 や IMAP (Courier IMAP) は2018年8月現在 MD5系には対応していないようだ。
IMAPの143ポートは次のように応答があった。

* OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION STARTTLS] Courier-IMAP ready. Copyright 1998-2015 Double Precision, Inc.  See COPYING for distribution information.

まぁ over SSL を使ってるのなら、あえてMD5までやらんでもとは思うが、使えるなら使っとくということでメーラーの設定を変えた。

しばらくこれで様子をみようと思う。

DAブラックホール1.8の主要 3機能が、おおむね完成。

いずれも旧版にあった機能だが、まったく新しく作り直した（後述）。
ただ、外観はできるだけ1.7を踏襲するよう努力した。
いまのところRC2までは、このUI（仕様）の予定。

なぜあたらしく作り直したか

これまで（～1.7）はインクルード/ピンポイント/シーケンサーが、単発解析（手動解析）を代行する扱いだった。ユーザーの代わりに解析ボタンを押してくれる機能と言っていい。このため「インターバル」も、解析と解析の間の「ウェイト」としての扱いだった。

しかし、1.8では1クライアントに最大12台のTA・通信端末が接続できるので、たとえば12個の電話番号が「どん！」と同時に解析されることもある。インクルードが、いきなり12個も進むといった具合だ。
そうすると従来の解析間「ウェイト」という考え方は、実態にそぐわない場合も出てくる。

ただウェイトっぽい機能は残しておきたい。

そこで導入したのが「周期」で、ほぼウェイトと同じ使い方ができる。内部技術的には、ここで定めた秒数毎に割り込みが入り、解析をリクエストする。
もしTA・通信端末がビジー、またはリクエスト上限にあるときは次の周期を待つ。

非なるものを似せるわけなので、インクルード/ピンポイント/シーケンサー すべて 作り直すことになった。

3大機能の同時使用ができる

これまで三大機能の同時使用は、
～1.6「解析順番が来たとき、ポートが空いていれば解析できないこともない（結果は保証しない）」
1.7「三大機能および外部データベース連結のいずれかが使用中の時は、他の代行機能は動作しない」
という仕様だったが、1.8では同時使用が可能になっている。
1.8には独立した解析ハンドラーが常駐し、適切にリクエストマネージメントを行っているためである。

マルチランゲージに対応

公式機能としてアナウンスするかはまだ決めていないが、マルチランゲージ対応している。

フォーム上の語句を、設定ファイル（実装上はレジストリの編集）で変更できるようにしている。
これはユーザーサポートに、日本語がネイティブでない方からの問い合わせが何度かあったので、それに合わせることにした。

なおこの機能を使って「1.7モード」にすることも可能だが、実際にその設定ファイル例を出すかは決めていない。

それにしても

1.8は「最後の大型アップバージョン」という前提で一から設計しなおしているので、将来の拡張性はまったく考慮しなくて済んでいる。このため各機能の洗練度（削り込み）っぷりが格段に高い。
2.0とネーミングしてもいい出来だが、1.x系列にほぼ完全な上位互換を持っており、フレームワークも安定したVB6ライブラリを使っているので、やはり 1.8 とするのが適切だろう。

当然、この1.8がDAブラックホールのシリーズ中、最高の出来になっていることは、自信を持って言える。

今週、Office365のオフラインインストール環境で、「外部データ連結」を介したxls/xlsxへの書き戻しに不具合が生じるという報告があった。

事象の概要

Office365のオフラインインストール環境（2013か2016かクイック実行形式かは不明）にインストールしたDAブラックホール1.7で、
「外部データ連結」を介したxls/xlsxの「読み取り」はできるし解析結果も表示されるけど「書き戻し」だけが反映されないにという不具合報告であった。

ふむ、2010に対する完全な後方互換ではないかもしれないねぇ → 2013/2016

そもそも Office 2013/2016 をクイック実行でインストールした環境では、ODBCドライバーが入っていないという問題があって。このことから、Office 2013/2016 は ODBC ドライバや OLEDBコンポーネントを自身では使っていない可能性が示唆されていたんだよね。
すなわち後方互換性のために、ODBC ドライバや OLEDBコンポーネントをパッケージしているにすぎないのではないか、という印象を持った。

ベンダーがこのあたりを使ってないなら、もしODBCやOLEDB周辺に潜在的な問題があったとしても、ベンダー側に認知されにくいのではないかと思ったのだわ。

DAブラックホールでは

DAブラックホール1.7は、どのバージョンのデータベースエンジンであっても「動けばそれでよい」という思想に基づいて、実装している。

プログラムでは、起動時に
dablack.accdb (DAブラックホールの解析結果保存ファイル)
を
Provider=Microsoft.ACE.OLEDB.12.0 (Microsoft ACE OLEDB)
で開き、
そこでエラーがスローされれば、必要な Office System Driver が入っていないと判断して、

を表示する。

インストールメディアに同梱されている、AccessDatabaseEngine.exe は、Microsoft Access データベース エンジン 2010 再頒布可能コンポーネントの32bit版と同じものであり、通常はこれをインストールすることでDAブラックホール1.7が使用可能になる。
（※64bit環境では他の選択肢があることがサジェッションされる）

逆に言えば、Microsoft ACE OLEDB が使用できる状況であれば、DAブラックホール1.7はなんら案内を行うことなく起動する。データベースのバージョンは問わない。

このため、後方互換（上位互換）のデータベースエンジンが入っているときも、特に警告は出さないので、そのエンジンに問題があったとしても、ユーザーは気が付きにくいかもしれない。

データベースエンジン対応表

DAブラックホール1.7は Microsoft ACE OLEDB を使用するので、基本的には Office 2010 またはそのエンジンを用いるのが最もよい。

ただし環境や将来設計によって、32bitと64bitを使い分ける判断が必要になることもあるので、以下に対応表を示す。

 

環境条件		Windows 10,8,7, Vista SP1,XP SP3	Windows Vista, XP SP2
MS Office2007/2010 をインストールしている		追加エンジン不要	追加エンジン不要
MS Office2007/2010 のいずれもイン ストールしてい ない	OS は 32bit	2010 Office system ドライバ AccessDatabaseEngine.exe	2007 Office system ドライバ AccessDatabaseEngine.exe
	OS は 64bit	2010 Office system ドライバ AccessDatabaseEngine.exe または AccessDatabaseEngine_X64. exe
2007/2010 以外 の Office をイン ストールしてい る ( またはその予 定がある )	32bit 版	2010 Office system ドライバ AccessDatabaseEngine.exe
	64bit 版	2010 Office system ドライバ AccessDatabaseEngine_X64. exe

※赤字はメディアに同梱しているデータベースエンジン

Office 2013/2016で、もし問題が生じた場合は、Office 2010またはそのエンジン（2010 Office system ドライバ）をインストールする、という順序でもいいのではないかと思う。

偶然重なったのかもしれないけれど、ここ数日で この「Windows ファイアウォールによりライセンス認証が行えない問題」が2件・サポート報告で上程された。
たまーに、ある。この事象。

事象の概要

オンラインによるライセンス認証機能を持つDAブラックホール1.5～1.7で、Windows ファイアウォールによりアプリケーションの通信がブロックされているときには、ライセンス認証が有効にならない、という現象が起きる。

まぁ、当然なんだけどね。

このときDAブラックホールは、「ライセンス認証が行えませんでした。」というクリティカルメッセージボックスを表示する。

厄介なのは、DAブラックホールにとっては「OS」が「正常に遮断」しているので、なんらOSのエラーを拾えないまま、しかし認証結果だけは返ってこないので、自動的な障害判定ができないことである。（ユーザーに対して、こういった原因で処理が行えませんでした、というサジェッションができない）

さらに厄介なことに、Windows ファイアウォール で レシーブだけカットするような設定であれば、当社サーバーは「正常に処理を行った」というログを残していくので、問い合せを受けた際の異常の検出に時間を要する。（細かく調べればわかるのだけど）

対応方法

サポートに問い合わせると、回答フローの最初のほうで

• ルーターがHTTPS（TLS）通信を閉塞していませんか？
• アプリケーションの外部通信に制約・遅延を与えるソフトウェアはありませんか？

と案内されるので、その時点でだいたいの人はピンとくる。（FWを設定するぐらいのユーザーであれば特に）

気がついてしまえば

コントロールパネル→Windows ファイアウォール→Windows ファイアウォールを介したアプリまたは機能を許可

で、DAブラックホールを許可してしまえばいいだけなんだけどね。

だけど、アプリケーション単位のFW設定なんて、安定して長いこと使ってるPCなら、設定していることを忘れることあるもので、そうなるとユーザーサポートへの問い合わせまでに、わりと長時間、ドはまりしてしまう方もいるかもしれない。
初心者ほど「ぱっ」と聞いちゃうものだが、もしFW設定を自らするような上級者であれば、問い合せまでに時間を要することもあるだろう。

特定プロトコルだけの閉塞または開放忘れを、クライアント側のアプリケーションだけで自動判定するのは荷が勝ちすぎているかもしれないが、これを機に、何か考えてみようと思う。

次期DAブラックホール・1.8を、CDにプレスするべきか悩ましい。

ビジネスソフトであれば、リリース後も、どこかをたえずアップデートしてるもの。
いまや ほとんどのソフトウェアは、（CDなどから）インストールしたら、ただちに
「ネットワークアップデート」
するのが普通である。
ならばCDではなく、最初からネットワークで（ダウンロードして）インストールするのが常道だと思う。

ただ、一方で

• 可搬型メモリ（USBメモリ等）の使用は禁止されているが、CDに関してはおとがめがない
• ネットワークが外部接続していないので、CDからインストールできないと困る

という企業・団体もあって、そうなると CDになってないことが、完全にクリティカルになる。
以前（1.3）はCD-Rで その時点の最新の版を送付していたが、じつは その頃が一番 ユニバーサルに堅かったんじゃないかという気もする。

いまのところ、ISOイメージの頒布を考えているが、やはりCDメディアがあると
「買いました感」
もあって、わりとこれ無視できない感覚だから、いろいろ悩ましい。

正直、もうちょっと別のところにリソース配分することで、満足感を上げたいんだけど。（使用感や便利さとか）

エラーといえば、サポートに上がってくるDAブラックホールの「致命的なエラー」の上位2つが
データベースエラー
である。

1. 「データベースの不具合があります。- n  サポートにご相談ください。」
   nには -2147467259 が入るケースが多い。その場合はデータベース損傷である。ファイルが壊れているため、システムを再起動したとしても改善することは少ない。
   破損の場所によっては、DAブラックホールの起動そのものができなくなることもある。
2. 「解析結果のデータベース記録に異常が発生しました。( n ) 解析を中止しますか？」
   nには -2147024882 が入るケースが多い。その場合はメモリ不足またはストレージ不足（HDD/SSD）である。

この2つのエラーは、どちらか一方というよりは、「どっちが先に出やすいか」みたいなところがある。

背景と原因

2000年代前半のDAブラックホールでは、これらのエラーはよく出た。
Jetエンジンを使用していたということもあるが、解析結果の記録に必要なマシンリソースが足りなければ、容易にOSが処理を中断してアプリケーションを強制終了させていたからである。そうなると、何割かの頻度でデータベースファイルに不整合が生じ、結果としてファイルが開けなくなった。
あるいは、処理に必要なメモリが足りなくなって頻繁にスワップが生じ、タイムアウトして強制終了したときは、メモリ不足を表示した後、再起動すると、ファイルまで壊れている、開かないといった順序。
いずれも、必要な処理量に対してPCのマシンリソースが追い付いていないときに、よく起きていた。

これも、2000年代後半になると、PCの価格に対する性能（価格性能比）が向上してきて、標準的なPCであれば、データベースエラーはめったに起きなくなった。
起きたとすれば、旧式なPCでのリソース不足か、ノートPCの排熱不足などシビアコンディションにあるかのどちらかであることが大半だった。

ところが2015年以降から、じわりとではあるがデータベースエラーの報告が増え始めてきた。
当社では再現しない（もう起きない）ので、ユーザーのイベンログを送ってもらったところWindows (8/8.1)/10の Windows Update による強制再起動が原因のひとつとなっていた。

また、「SSDが原因」というケースも見受けられた。
データベースファイルの処理落ちを防ぐためにSSDを用いる、という この一見 優等生的な環境で起きていたのは「肥大したデータベースファイルの放置」によって、データのロード時にメインメモリが足りなくなりエラー停止、あるいはSSDの小柄な領域を圧迫していたということもあった。こちらは、どちらかというと完璧ゆえの油断といえるのかもしれない。

---

予防方法

Windows Update については防ぎようがないこともあるが、シビアコンディションについては予測や予防が可能であることが多い。

たとえばdablack.accdb のファイルサイズが メインメモリの1/2（半分）を超えないようにすると、ある程度 有効に防げることがわかっている。
とはいえども、いちいち監視はできないと思うので、数カ月から1年に1回程度、ファイルサイズを確認してメインメモリの1/2を超えていないか確認する、というペースで 多くの人は大丈夫なんじゃないかと思う。
もしオーバーしていた（またはオーバーに近づいていた）ときは、DAブラックホールと同時インストールされている
DABHREFL.exe
を使って、余分な領域を削ぎ落すといい。

復旧方法

もしDAブラックホールの起動ができるなら、最も容易な復旧方法は「最新版アップデート」で、データベースごとシステムを再構成することである。この方法であれば、もともとの解析データは
rollback*
というバックアップフォルダに入るので、Microsoft Office Access 2007 以上を用いて開くことができれば、解析データもムダにならないかもしれない。

もしDAブラックホールの起動ができない場合は、残念ながらアンイストール後に再インストールを行うのが一般的である。その際のインストールメディアは、当社ダウンロードサイトから取得した最新のインストーラーを用いることをおすすめする。（最新版で運用していたところに旧式のCDからインストールすると、環境によっては必要なファイルがインストールされないおそれがあるため）

DAブラックホールで連続解析（シーケンサーやインクルード）を前日からまわして、結果を翌日に見よう、という運用はよくある。
だけど、翌日の朝 開いてみたら、昨夜9時ぐらいにエラー停止して、1割ぐらいしか解析終わってなくてアタマをかかえてしまうことがある。

「なんでエラーなんだよ！」と。

でも、これね。

エラーが起きたときはちゃんと停止させないと、解析事故（課金）が 恐い。
仮に課金事故でなくても、エラー停止する以上は 回線かTAに瞬間的にでも「問題」が発生したということである。そのまま解析を続行したとしても「取得したデータの信頼性が損なわれているおそれ」があるんだよね。
そういったこともあって、エラーについては「発生させないセッティング」が第一であることには変わりない。（エラーに至った機序についてはイベントログにも吐き出されているので、読める人はぜひ読んだほうがいい）

とはいえ、切断時間を切り詰め ATコマンドも工夫してカリカリにチューニングしている環境だと、1/10,000の程度のTAのエラーは スルーしてほしいこともある。

そういうとき、リスクや細かい背景は承知の上でなら、解析中に発生するエラーメッセージを表示させない方法はある。

解析する電話番号に 6101 を入れて、その下のDAブラックホールのエンブレムをクリックする。

すると Yes/Noダイアログが表示される。
エラーメッセージを非表示にする場合は、[はい(Y)]を選択する。

この操作によって、解析で発生するWarning/Nortice/Information レベルのエラーメッセージは表示されなくなる。（表示されないというだけで 問題そのものは存在している点には留意）

一方 CriticalやEmergencyレベルのエラーメッセージは 引き続き表示される。
つまりDAブラックホールが掌握しているレベルのエラーは表示しなくなるけれど、OSが表示するエラー（データベース損傷など）は引き続き表示される、という理解を持ってもらえるといい。

この操作は「通常の解析」（連続解析を含む）のエラーメッセージを対象としており、マルチタップや他の機能のエラーメッセージには影響しない。
もしマルチタップによって発生するエラーメッセージも非表示にする場合は「6102」で同様の操作を行う。

いずれも本来はユーザーサポートから指示があった場合に限って使ってほしい機能ではあるので、使用する場合はある程度の覚悟をもって行ってほしい。

---

なお、元に戻す方法は、

設定(P)→出荷時の設定に戻す

である。