Whoops, SFLCSRRRN Bug!

From: Steve Cherkas To: All

The new (V2R2M0) DDS keyword SFLCSRRRN is great for determining the subfile RRN where the cursor is located, but there may be a bug-one of our programs is not returning the correct RRN. It always returns the RRN of where the cursor is-minus 1! Sounds unbelievable but it's true; it works correctly only when the cursor is on RRN #1. All of the other programs are working fine. Has anyone else run into this problem?

From: Neil Clark To: Steve Cherkas

I ran into that very same problem; the RRN being returned is one less than the actual RRN corresponding to the cursor's position. The PTF for this is SF11495. After I applied this PTF, the correct RRN was returned.