Re: Weird INFDS problem

[Jeff Young <cooljeff913@xxxxxxxxx>]

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.