>　興味深い高度な話だと思います。
>　
>　再帰呼び出しの手法は意図的に使用されているのであれば無限再帰(スタック・オーバーフロー)
に
>　ならない限り、問題はありません。
>　再帰呼び出しもテクニックとして利用することもありますので。
>　
>　さてプロシージャー内に定義したSQLカーソルは、一見するとローカル変数として
>　定義されているので、再帰呼び出しでもそれぞれ独立してプロシージャー内で
>　定義されているはず、というのも妥当な推論です。
>　
>　ところで　SQLカーソルは変数なのでしょうか　?
>　SQLのコンパイル・リストおよび　QTEMP/QSQLTEMP　のRPGソースを調べてみてください。
>　SQLのコンパイルはコンパイラーによって　QTEMP/QSQLTEMP　に展開されてから
>　これを最終的にコンパイルする仕組みをとっています。
>　
>　展開されたコンパイル・リストまたは　QTEMP/QSQLTEMP　を精査してみると
>　定義したはずの　SQLカーソルは、どこにも見当たりません。
>　(　SQL　カーソルはコメント・アウトされています。)
>　SQL　カーソルは式として展開されていますがローカル変数として
>　保護する仕組みもないようです。
>　
>　つまり　SQLカーソルとは概念であって変数ではないのです。
>　従ってローカル変数として他から保護されているものではありません。
>　グローバル変数として理解するしかありません。
>　
>　結論として　SQLカーソルはローカル変数とはなりません。
>　
>　--　SQLバインドは　OPM　のときに開発された手法ですので　ILE化によって　SQL展開を変更
する
>　　　のは従来のソフトウェア資産と矛盾することになると　IBM　は考えたのでしょう。
>　　　System　i　は、そうそう通常の使用では不具合はありません。
>　　　　元々これは変数ではないので不具合ではありません。
>　　　簡単にバグだと決めつける記事のほうが論拠に欠けるものです。
>　

すみません。回答をいただいている事を今まで気づいていませんでした。

SQLカーソルは変数ではないということなんですね。

お客様の仕様としてはスタックがオーバーフローするような無限階層の呼び出しではなく、
呼び出し階層の最大値を限定することがＯＫでしたので、最大の階層分のカーソルを定義して
階層に応じたカーソルを使用するようなプログラムに変更したところ、
それはそれで正しく動作したのですが、やはりイマイチです。

結局、SQLで読むことをやめて、
各階層で下位呼び出しの直前に現在の読み込み位置を保存しておき、
下位層からリターンしたときに次の読み込み開始位置を再度設定する、
ということにしました。

実質的には変わりない内容ですが、ソースコードが短くなるのでこちらを採用しました。

ご回答ありがとうございました。