Re: Weird INFDS problem

The DDS keyword that you need is:
RTNCSRLOC(&CSRREC &CSRFLD)
A CSRFLD 10A H
A CSRREC 10A H
Where CSRFLD is the name of the field the cursor is positioned to and CSRREC is the name of the record.

Also, the keyword CSRLOC(CROW CCOL) can be used to get the actual row/column of the cursor.
CCOL 3S 0H
CROW 3S 0H

For a subfile, use the keyword SFLCSRRRN(&LINRR1) on the SFLCTL record to get the actual record number in the subfile that the cursor is positioned on.
LINRR1 5S 0H

Hope this helps,

Jeff Young
Sr. Programmer Analyst
IBM -e(logo) server Certified Systems Exper - iSeries Technical Solutions V5R2
IBM Certified Specialist- e(logo) server i5Series Technical Solutions Designer V5R3
IBM Certified Specialist- e(logo)server i5Series Technical Solutions Implementer V5R3









----- Original Message ----
From: James Lampert <jamesl@xxxxxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Sent: Wednesday, November 21, 2007 6:00:15 PM
Subject: Re: Weird INFDS problem

Simon Coulter wrote:

Well, the obvious thing is to ask what changed between October and
now? I found a German web site referencing the same problem. In their
case the program worked, PTFs were applied, program failed. A
recompile of all related programs fixed it in their case.

I did a quick search for INFDS and MCH3601 at IBM Support but no hits.

Are you sure the MCH3601 is occurring on a reference to the INFDS and
not to some other field such as a parameter that was not passed?

Thanks, Simon.

Nothing changed. That's the weird part. I was away on vacation, and
nobody else has access to that particular box. It was powered up and
shut down a few times, on a weekly exercise cycle, but that's all.
Recompiling the programs didn't change anything. Neither did using a
version that had been untouched for over a year. And as I said, the new
version works fine on a different box.

And YES, it's coming from a statement that accesses an INFDS.

Also: at one point, I did a dump from the error, and not just the
offending INFDS, but both of the two INFDSs in the program were listed
as "NOT ADDRESSABLE" in the dump.

And yet other programs have no trouble accessing their display files'
INFDSs.

In this particular case, I'm using bytes 370-371 to retrieve the cursor
position. I vaguely recall that there's another way to get this,
something with the display file itself, but I don't recall exactly how.
While I'd really like to know what the %@#$$ is going on here, I'd
settle for an alternative.