Re: Positioning cursor on a subfile record

[Booth Martin <booth@xxxxxxxxxxxx>]

May I make a case for using SFLMSG?  Hopefully I will do it accurately 
and concisely.

SFLMSG allows any number of error conditions to be identified on any 
number of subfile rows & fields.
SFLMSG allows the marking for correction of every error in the subfile 
in one validation cycle.  There is no user time wasted fixing one error, 
enter, fixing the next error, enter, fixing the next, until all errors 
are cycled through, one at a time.
Cursor positioning is automatic, no programmer effort involved.
Subfile positioning is automatic, no programmer effort involved
SFLMSG shuts off its own indicator, no programmer effort involved.
SFLMSG allows the use of MSGFs.
SFLMSG allows the use of RI and of COLOR().
SFLMSG is, by comparison, easily debugged.

And, in this particular situation has the advantage of being a different 
way to view the same problem; always an advantage.

On 3/23/2015 12:39 PM, MichaelQuigley@xxxxxxxxxx wrote:
> Bill,
>
> I've been busy again--so lots of discussion here.. This should work
> correctly. The whole point of the SFLRCDNBR keyword is to get the cursor
> positioned on the specified record. DSPATR(PC) shouldn't enter into it,
> etc. I've used SFLRCDBNR for decades to do processing just like
> this--including subfiles with no input-capable fields.
>
> The only other thing that's thrown me off sometimes is when I write a
> different record after the Subfile Control Record. It sounds like you're
> writing the footer record (with the function keys) after the Subfile
> Control Record, that could throw it off. I see Buck has asked you to post
> the DDS and HLL code. Give us a look at the actual coding driving this and
> let's see if we can figure it out.
>
> If the code requested above seems like too much, an alternative would be
> to debug the program and check the value of the SFLRCDNBR field from the
> control record right before you write the record.
>
> If you can't find anything by debugging and nobody can see anything in the
> coding, can you open a PMR? Get IBM to explain what's wrong and then
> report back to the list. We'd all like to understand what's causing the
> failure here.
>
> Michael