Re: Positioning cursor on a subfile record

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


"RPG400-L" <rpg400-l-bounces@xxxxxxxxxxxx> wrote on 03/20/2015 06:22:49
PM:

----- Message from Bill Howie <blhowie66@xxxxxxxxx> on Fri, 20 Mar
2015 14:40:13 -0400 -----

To:

"RPG programming on the IBM i (AS/400 and iSeries)"

<rpg400-l@xxxxxxxxxxxx>

Subject:

Re: Positioning cursor on a subfile record

Michael,

I have tried your suggestion. After the user presses a command key on a
particular record, I set the value of the hidden field associated with
SFLRCDNBR in the DDS to what's in the hidden field associated with
SFLCSRRRN in the DDS (which contains the record number for the record

the

user selected), and then an EXFMT of the subfile control record happens
(there is a WRITE of a different display format immediately before this
that displays command key text). Still positions to the first record

of

the subfile. No DSPATR(PC) in play for this subfile.

Looking at the definition of SFLRCDNBR, it says that using this keyword
displays "the page of the subfile containing the record whose relative
record number is contained in this field". So am I interpreting it

wrong

that it will actually position it to the SPECIFIC subfile record?

Because

there are only 3 records in the entire subfile, so if you take this
definition literally, positioning the cursor to the first record is
technically displaying the page of the subfile that contains the record

the

user selected. Maybe I've got the wrong keyword for positioning on a
specific record?

Bill

On Tue, Mar 17, 2015 at 11:54 AM, <MichaelQuigley@xxxxxxxxxx> wrote:

Bill,

Sorry I've been away from the list for a few days. What you're trying

to

do should work. There are a couple things that've bit me or coworkers

when

we've tried this.

1) You say you're "...moving the field value that goes along with
SFLCSRRRN to the SFLRCDNBR field and updating the subfile." Do you

mean

you're updating the individual subfile record or rewriting the subfile
control record with the new SFLRCDNBR value? You need to rewrite

(i.e.,

update) the control record. You do not need an input capable field.

You do

not need to do a DSPATR(PC).
2) A prior DSPATR(PC) can mis-position the cursor. One common problem

is

to leave the indicator for DSPATR(PC) turned on and update the

individual

subfile record before updating the control record. That or defining PC

on

another field in the subfile record without any indicator.

Those are the big ones. Have you got this working yet?

Michael Quigley
Computer Services
The Way International
www.TheWay.org