Release : 20.0
Component : CA SYSVIEW Performance Management Option for DB2 for z/OS
These two simple queries were used to recreate a similar result more or less accurately:
select * from sysibm.syspackstmt where SEQNO=22 order by STMTNO;
select * from sysibm.syspackstmt where SEQNO=22;
The output of the first query is here:
And this is the output of the second query:
As you can see the CPU time did not change significantly and the SORT elapsed reported in the first query is also close to 100% as in your case.
It is a normal situation though, because the way IDB2 calculates this elapsed time is by pairing IFCIDs 95 and 96. IFCID95 is produced once the sort starts, IFCID96 is produced once the sort ends. I believe that in both my case and yours the sort started as soon as the first row was fetched, and ended only when all rows were fetched, leading to a somewhat misleading statistic.
To double-check this I captured the raw ifcids 95 and 96 for my query:
The third fullword is the ACE, so we can see that these two IFCIDs relate to the same query, and the 5th and 6th fullwords are the timestamp. The timestamps as well as their conversions with the STCKCONV macro are:
D881B1C7CA276B12 ~ 14520066 31580000 20200911 = 11 Sep 2020 14:52:00.66
D881B1CDD5E9E864 ~ 14520700 27820000 20200911 = 11 Sep 2020 14:52:07.00
As you can see the elapsed sort time simply subtracting the timestamps is around 6.34 seconds, and the 'sort elapsed' time on the first screenshot is 6.339 seconds.
Summing it up, what you see is correct data. But in order to make a decision whether sort was the actual bottleneck of your query you would need to go through the SORT SUMMARY report just as Tom mentioned in an earlier comment.