▲ZTシステム構成図7.ZELの直系血族図を#201 noduleでソートしてPAIRLIST::Removeの(bundletop->CheckSamePoint())エラーで停止した．202 NODULEなどでも起きている．⇒開いただけでは発生しない．系統並び替えを実行すると起きる．起動して終了では起きない．障害は系統並び替え冒頭の基本世代枠リストのcancelで起きている．
Removeで削除されているのは#20597で#20166と端点共有になっている．#20597が削除された後，#20166は別のチャンネルにある#21074と端点共有になる．このようなことはあるのではないだろうか？端点共用には，①右終点共有，②左終点共有，③左始点共有，④右始点共有，⑤端点共有しないの別がある．
PAIRBOX#20166は#19882 linktable(1)→ #776 linktable(0)，#21074：#20773はundosys(1)→ #758 undosys(0)だ．ちなみに#20597は#20297 namesort(1)→ #785 namesort(0)で，#20597と#20166は左始点共有だ．
上の図ではnamesortとlinktableが端点共有になるのは分かるが，linktableとundosysが端点共有になる理由は分からない．垂直線分の描画が不調なのでこの問題は保留とし，ダンプだけ出して停止しないようにしておこう．⇒いや，むしろここでは端点共有の調整も検査も行わないという方が正しいのではないか？メインの通常フローで削除された場合なら，Removeの中で調整しなくても事後に対処されているはずであるし，終末期であればもちろん調整しても意味がない．⇒「ノード対削除後に端点共有束を調整しない」オプションを設置した．
▲同上サンプルの全体図：#81 complistで系統並び替え中NAMEBOX：RetrieveGhostでCheckSamePointエラーが発生した．いや，基準ノードは#82 SIMPLEGRAPHかもしれない．⇒確かにそのようだ．今度は上記とは逆のエラーだ．つまり，設定は端点共有で実際には端点共有なしという状態だ．これは上の修正からの当然の帰結だ．
この障害はTRIBELIST::MakePairListClean→ CheckPairList→ CheckShiftedPairBox→ PairBoxGeneChange→ RetrieveGhostで起きている．TOPOLOGY::CheckShiftedPairBoxでは「チャンネル切り替えにより巻き戻し」ということを実施しているので，外側の処理に任せてもよいのではないかという気がするのだが…
TOPOLOGY::CheckPairListでは前段でCheckShiftedPairBoxを実行した後，後段でCheckPairEndPointを実行して端点共有の調整を行っている．端点共有は大域的な処理なので，部分的に調整しても意味がないような気がする．実際，PAIRLIST::Removeで行っている調整では端点共有束の先頭ノードの属性変更しか実施されていない．これではほとんど意味がないように思われる．むしろ，ノード対の削除によって副次的に端点共有の不整合が発生することを認めた方がよいのではないか？⇒RetrieveGhostでも「ノード対削除後に端点共有束を調整しない」を適用するとしてみよう．
▲同上サンプルの法定親族図：#171 MARGBOXを開いて，repairCommonEndPointで停止した．出口のCheckSamePointに引っかかった．これはかなりまずいのではないか？この関数は共有端点束の調整を目的とするものだ．⇒基準ノードはその次の#172 ownerだ．
入口のCheckSamePointでは「ノード対区間ゼロで端点共有不可」と診断されている．おそらく，repairCommonEndPointはこのような状態を修復する手段を持っていないのだろう．このようなノード対は危険対（始点終点が同一座標のノード対の組 端点共有不可）と呼ばれている．このようなノード対の端点を共有すれば誤読が発生することは避けられないことからそのように呼ばれているのだろう．⇒いや，「危険対」というのはもう少し違うのではないか？
危険対枝グラフの循環検定というのがあるが，これは「始点終点が同一座標で逆転」というものだが，ここで言う始点終点が同一座標というのは一つのノード対が同一座標の始点・終点を持つという意味ではなく，｛始点，終点｝→｛始点，終点｝→…｛始点，終点｝のような連鎖があったときの一番最初に出てくる始点と最後の終点が同じで連鎖が閉路を形成しているようなものを言っているはずだ．障害の起きているノード対は#18512：#8855 MDB(1)→#974 MDB(0)．
水平連結線長さがゼロであるようなノード対にはまったく誤読の危険性はあり得ない．単純に上から下へ垂線が通っているだけなのだから，他の連結線がどこから入ろうが，どこへ出てゆこうが問題は起きない．従って，「ノード対区間ゼロで端点共有不可」であったとしても，そのことから派生するリスクは存在しない．つまり，端点共有束の中にあっても外にあってもまったく問題は生じない．間違いがあるとすれば，これを共有端点束に入れるという操作そのものだろう．
上図で問題となっている「ノード対」はMDB（イエロー）の直上にあるlinktableから入ってくる垂線以外の何ものでもない．従って，①CheckSamePointはこのようなノード対をエラーとすべきではない，②このようなノード対は端点共有としない，としなくてはならない．CheckSamePointは端点共有の「間違い」を見つける関数なので，それとは別に端点共有候補であると判定ないし検査関数があるはずだ．⇒CRITICALPAIR属性を与えてしまうのが一番簡単なのではないか？
CheckSamePointの判定は誤ってはいない．CheckSamePointは端点共有の「間違い」を見つける関数なのだから，始点終点同一座標で端点共有設定されているものを「間違い」と指摘しているだけだ．ただし，このノード対はどこにでも置けるのだから，あえて「間違い」としなくてもよいのではないか？実際そのように修正してエラーは解消した．このノード対がどこで端点共有に設定されているのかを見てみよう．⇒最初にノード対が生成された時点で端点共有になっている．この判定はAvailableChannelで行っている．⇒「実ノードと仮ノードの水平座標が同一の場合は任意のチャンネルに置いてよい」とした．
▲BRect.Width()が負値を返す場合があり得るので，MAXKEISANGOSAの関わる計算すべてで絶対値を取るようにした．
なぜだろう？図式がまったく変わってしまった．
この結婚枠はtopologyの子ども枠なので本来なら中吊りしなくてはならないところだが，当初は先頭のPDBで吊っていたのが，末尾のkeisengraphに移ってしまっている．かなりおかしい．どこで何が変わったのだろう？ノード対のチャンネルの話だけでここまで変わるというのはかなり問題がある．topologyは結婚枠を2つ持っている．#146と#153だ．前者はgoodson空で，後者のgoodsonは#1163keisengraph(0)だ．この図面ではなぜかtopologyだけではなく，GCでない子ども枠はすべて末子で吊られている．
当初#146（最初の子ども枠）は#965 PDB(0)がgoodsonになっていたのだが，「拡張子ども枠で下流結婚枠のgoodsonが返された」として拡張子ども枠#153の#1073 SymmetryList(0)に切り替わり，その後同じ理由で#1163 keisengraph(0) に切り替わっている．これらの動きはすべてSETRELATIVEフェーズで起きていて，その後は調整されていない．
拡張子ども枠は拡張枠の中央にもっとも近いノードをgoodsonとしている．この意味ではSymmetryList(0)が正解ということになるのだが… おかしい．何も修正していないつもりだが，動作がまた変わってしまった．最初の状態（PDBがgoodson）に戻っている．⇒MARGBOX：makeGoodSonにひどいミスがあった．計算式の中で符号が反対になっている項があった．⇒ここで一度バックアップを取っておこう．
▲同上サンプルを#136 PrimaryでソートしてPAIRBOX::CalcPairBoxで停止した．NOCOMMONPAIR属性を持つノード対が端点共有でダブっている．NOCOMMONPAIRノード対はNOCOMMONENDPT属性持つ実ノードを持つノード対で，「終点がgoodsonのノード対は最大区間を除き端点共有不可」とされる．