Re: Weird INFDS problem

[Simon Coulter <shc@xxxxxxxxxxxxxxxxx>]

On 22/11/2007, at 10:00 AM, James Lampert wrote:

> 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.

Every time I hear that "nothing changed" it usually transpires that  
something did--just that it was unexpected or overlooked.

Bunch of questions follow, mostly just to help you think about the  
problem.

Is the different box on the same OS release? If so, then are PTF  
levels the same?

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

A test operation (which would be self contained) or a move operation  
(which must also reference another variable)?

> 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.

I found a reference to a similar problem when the data structure was  
BASED and MODS. PTFs issued to fix QteDumpModuleVariables API.

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

That's what makes me think it's actually a coding defect. However, if  
as you say the program hasn't changed and the same compiled object  
runs fine on a different system then perhaps the display file is the  
cause (although that really doesn't make sense to me). Have you tried  
recompiling the display file?

Just to be thorough: Are you sure the code that runs is the code you  
think it is? No silly library list issues, etc.

> 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.

DDS keywords: RTNCSRLOC and SFLCSRRRN

Also the DSM API QsnGetCsrAdr

Regards,
Simon Coulter.
--------------------------------------------------------------------
   FlyByNight Software         OS/400, i5/OS Technical Specialists

   http://www.flybynight.com.au/
   Phone: +61 2 6657 8251   Mobile: +61 0411 091 400        /"\
   Fax:   +61 2 6657 8251                                   \ /
                                                             X
                 ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------