同じレコードが出力されているという症状からすると
CURSOR　が効いていないということですから

EXEC　SQL　DECLARE　CSR　CURSOR　FOR　WKSTATEMENT;
EXEC　SQL　PREPARE　WKSTATEMENT　FROM　:SORTSQL;

が怪しいのですが、ずいぶん間接的な表現になっていますので

EXEC　SQL　DECLARE　CSR　CURSOR　FOR　:SORTSQL;

にして実行してみてください。
コンパイル・エラー等があればご自分で修正してください。

EXEC　SQL　FETCH　CSR　INTO　:DSSQL;

の　A,　B　が　:DSSQL　の　DSで定義されているフィールドであると
予想していますが　:DSSQL　のフィールドには　SFLレコードのフィールド名を
そのまま使えば、

//DSから画面へセット
　　　P_SCD　=　A
　　　P_SCD　=　B

は不要となります。その他に大きな問題は見受けられませんので
公開されていないところにも単純な記述のミスがある可能性も含めて
チエックしてください。

CRTSQLRPG　で指定しているパラメータにも注意してください。

使用方法の差異によって簡単に原因を推察することは
できないでしょう。
要はあてずっぽうではなく、ひとつひとつ実験して原因を
突き止める作業が必要です。

・サービスプログラムのプロシージャを使用している
　（自分自身はメインプログラム）
==>　SQL　CURSOR　は親には伝わらなかったという過去の記憶も確かにありますが
　　　　これを原因と仮定するのであれば小さなプログラムを作って
　　　　プロシージャー呼出しのSQL　と、そうでないSQLバインドRPG　とを
　　比較実行して検証する必要があります。
　　
　
　・cursorのSQLの前に、削除のSQLとデータ抽出のSQLを実行している
　（これらはカーソルは使用しておりません。また動作は正常に実行できてい
ます）
===>　これも原因となりうる可能性は高いですね。
　　　初めに示されたSQL　ではなく　FETCH　のつど、このような特殊な操作を
　　　しているのであれば危ない操作であり、できれば避けたいものです。
　
　・サブファイルを６つ使用している
===>　SQL　が正常に処理されFETCH　も正しく進行しているのに　SFLレコードに書き出す
　　　　　RRN　が正しくないとご指摘の症状になる可能性が大いにあります。

===>　データ・ベースを　SORT　するのに無理やりSQL　を使わずとも　LF　を一時的にでも
　　　　　作成して　READ　するほうがパフォーマンスも圧倒的に優れており
　　　処理構造もシンブルで保守も容易です。
　　　　　LF　を作ってはいけない、という事情があれば別ですが(それでも一時的にQTEMPなどに
　　　　　LF　を作成するほうが　IBM　i　には適しています)

　　　　　IBM　i　のある(有名な)経理パッケージを見たことがありますが、開発者がDB2/400の
　　レコード・レベルのアクセス(READ,　READE,　CHAIN,　....)を知らないらしいようで
　　　　すべて　SQLバインドで開発していました。
　　おかげでその経理パッケージはパフォーマンスが悪くてユーザーからクレームが
　　　　多かったようです。
　　別のユーザーでもやはりすべてSQLのみで組んでいるところユーザーもあり、
　　やはりパフォーマンスの問題を抱えていました。

　　IBM　i　には適した方法がありますので肩の力を抜いてシンプルで自然なやり方が
　　スマートです。
　　徒に凝った方法は避けるほうが賢明です。
　　SQL　は、SQL　でなければできないケースにおいてのみ　SQLを使うようにしたほうが
　　　　いいでしょう。
　　　　IBM　i　の場合は数十万レコードのデータ・ベースを扱うのも珍しくありません。
　　　　そのようなケースで　SQLだと実用にはなりません。
　　　　レコード・レベルの操作をお勧めします。

表示順の索引ファイルを、表示するプログラムにする。