どもっ、KHさん、
この板は暫く見ていなかったので、Ogoさんからの呼出しメール(^^;)で参上仕り候。
え〜、さてこの手のエラーは私自身は承知しています。以前、csvファイルを対象に
して、１年分365日弱のファイル数のデータを扱っていて出くわしたことがあります。
原因は（詳細後述しますが最終的には）ファイル数によっています。
でも、テキスト系のGrepは既存のより優れたアプリに委ねた方がベターだと思ったこ
とにプラス、主要な対象となるであろうkevやcmdに関して（ひとつのフォルダ内で）
そんなに沢山のファイルを扱うことは無いだろうとの読みもあって、放置して来まし
た。……もちろん放置してきたのはそれだけの理由ではないけど。(^^;)

引っ掛かっているのは次のところだと思います。
----------------------------------------------
proc FILEs取得()
　&i=1,&FILEs=""
　繰り返し
　　&file=#ファイル検索(&ﾌｫﾙﾀﾞ+"*."+&拡張子,&i)
　　cond(&file="")　繰り返し中止
　　&FILEs=&FILEs+","+&file,&i=&i+1
　繰り返し終了
　if(&FILEs="")
　　確認　&拡張子+"ファイルは有りませんでした"
　else
　　&FILEs=#sstr(&FILEs,2)　　/*先頭のカンマを除去*/
　end
end
----------------------------------------------
ここでは、ひとつの変数&FILEsに、全てのファイル名を（フォルダ名付きで）カンマ
区切りでどんどん貯めて行っています。後で、このファイル名群から「#対応文字列」
関数で個々のファイル名を取り出すためです。
いずれにせよ、これだと、文字列変数の値が4000文字（桐の仕様）を超えてしまう可
能性がある訳で、この度のKHさんの使い方がそれに該当してしまったと云うことです。

対策（の考え方）は実は簡単です。過日、【多遊】さんの（こちらではない方の）板
で、例えばアックンから出ていた話題に触発されたこともあるのですが、要するにこ
ういうことです。
ファイル名群をひとつの変数にカンマ区切りで取得しようとしたことがいかんかった
のです。変数ではなく表のデータで縦に展開させれば、それこそ無尽蔵に対応できる
シロモノだったのです。
これを桐だけで済ますこともできます。上の処理を少し変えれば可能ですね？　取り
出す時は今度は「#対応番号」ではなく、表データで「ジャンプ　行番号=+1」を使う
ことになります。あ、そのための作業表がひとつ必要となります。
これを「方法１」とすれば、もうひとつ、DOSのコマンドである"dir"を使う方法、つ
まりリダイレクトでテキスト化したものを桐の表に読み込むと云うもの。DOS窓が出て
くるので、あるいは麗しさを減ずるかもしれませんが、でもこれを使うと、サブディ
レクトリも含めて対象にすることもやや簡単に実現できそうではあります（こちらは
「方法２」とします）。
と云う訳で、その内検討してみますが、今は無理です。「方法１」を自作改変で試し
ていただくってのでどうでしょう？
本格改訂についてはですね、どうせなら（表やテキスト系のデータはさておいても）
「kev .or cmd」をサポートしたいとか、検索文字列の「 .or 」指定も取り入れてみ
たいとか、検索文字列や対象フォルダの履歴化・再利用も試したいとか、上述の「方
法２」を使ったサブフォルダの問題もあったり……、それやこれやで却って着手しに
くくなったり……。(^^;)

※余談ながら、検索文字列の「 .and 」については、特に必要性を感じていません。
つーか、必要な場合は、最後の結果の表表示画面で、[値]で絞り込み／比較式させれ
ばいいだけだから。(^^;)