> オリジナルのvz.defにBlだけ8192に変更したものを読んで起動し、0007.cgiを開いた
> ところで0007.cgを挿入して、無事に正常挿入。うれしい！

テストデータを対象にバグを回避しているだけなので他で問題が出ると思います。
テスト版はマクロの読み込み関連でバグがあるようですのでご注意ください。

> ということで、これから確認したい項目。
> 80桁未満で桁折しても状況が発生しそう、ということから、例えば、以前、文太さん
> に提供していただいたニフティのログを使って、ファイルサイズを0007.*と同じに
> したものを作って状況がどうなるか。

検証はよろしくお願いします。m(__)m

> Blとかのバッファの開始ポイントのアドレスをVzのマクロで取得するには、どう
> すればよろしいのでしょうか？
> あまり関係はないとは思いますが、今回のテスト版で、もし以前の版と大幅に変化
> しているかどうか確認できれば、と思いまして。

BLの相対アドレス情報などは、めざらさんが出してくれたので（ありがとうございます）
VTDOS環境での絶対アドレスは

vzk07t01 　vzk07t02 test
D192	pq..148		lbuf		8192
F192	pq..149		tmpbuf4		256

スタック領域なので、コードの修正分サイズが増えても変わりませんね。
常駐／非常駐とも同じです。
同じマクロ環境で、高橋版は
vzt 
CFFE	pq..148		lbuf		8192
EFFE	pq..149		tmpbuf4		256

この差は、#if 文でマクロの構成が違うからかなぁ。
オリジナルVZとマクロでは

vzo
777C	pq..148		lbuf		2048
7F7C	pq..149		tmpbuf4		256

BLは変えてるかもですが、だいぶ余裕がありますね。
このラインバッファのサイズで挙動が変わるのは、メモリ転送ルーチンで
ラインバッファを一時バッファとして使っているのが関係しているのかなぁ？

> 常用環境の場合は、なにかがFFFFhを超えてしまいそうだし

pq..149 は、tmpbuf4 で、ソースでは使われていないようです。
緩衝領域として２５６バイト設定しているのは、プッシュポップのスタックが後ろから積まれるからかも。
そうだとすれば、この領域を使うのは危険ですね。
pq..149 が、FF00h を超えていたらバッファを減らさないと危険ということでしょうか。

げげ、私知らないで私家常用版で使ってしまっていました。(>_<)
見直さなくては。(^^;;

> test版の時は8000hをまたいでいるし。
あ、そうか、ラインバッファが8000hをまたぐバグってこれを言っていたんですね。

うちのオリジナルVZとマクロでは
vzo
777C	pq..148		lbuf		2048
7F7C	pq..149		tmpbuf4		256

テスト版vzとオリジナルマクロでは
7822	pq..148		lbuf		2048
8022	pq..149		tmpbuf4		256

この環境で、8000h をまたぐバグが出るかどうか確認すればいいのか。
ん？ 高橋版で直っていたかしらん？ ちょっと過去ログの海に潜ってみます。