Incompatible data types in expression or assignment (using O

Never seen it. As you know I don't use inheritance, when I refactor legacy I remove it. Maybe you could use parameter objects (eventually google for the "parameter object" refactoring)? New your objects in the constructor of them, assign them to private set public get properties. Easy to pass around a param object: no list of params in a certain order needed, easy to maintain (more objects needed? just add them to the param object).

Stefan, he only seems to have one character parameter as input to that method so I would find it hard to extract that to a ‘parameter object’ :)

Grr Marian, is it really so difficult to see what I mean? You can just skip commenting my remarks also if you only care to provide negitive criticism. Do something useful instead. Just providing your tips can be enough. I do not mean to "use the parameter object refactoring" but look into this refactoring to see what a parameter object is (if unknown to the reader) and for what you can use it. Maybe it is not an interesting solution in this case, I have not seen the application as a whole, only a small piece of code.

Could be caused by different definitions of class CreateChargeOperation

Are you hitting exact same class when writing fully quallified class name app.Production.Treating.ScannedCharges.MobileOps.CreateChargeOperation?

If not then you will get error!

Solution can be to cast return to correct class.

Thanks for the tips Marian,  I am very open to the possibility that it is a platform-specific issue on HP-UX since there have been quite a number of those.  In fact I've almost stopped developing on HP-UX altogether since it seems to be such an odd duck.  I wouldn't go near it at all except for the fact that we still use it in production.

Your other tips about the possibility of PROPATH and namespace problems are also interesting.  They might explain why the on-the-fly compilation was a little bit happier when I started to use fully-qualified namespaces for my class names.  I thought the USING statements would be enough to resolve the location of my classes for the compiler (especially since Progress requires that class names and namespaces align with filenames and paths).

It sounds like you might have had some of these types of experiences yourself.  Have you ever come across code that Progress OE didn't accept when using "on-the-fly" compilation but was happy to compile into r-code?  This may be a first for me.  The weirdest part (IMHO) was the (1) platform-specific behavior, and the (2) difference in behavior between state-reset appserver and running the same code in the editor (whereby neither scenario uses r-code).  But then, like you said, I may be overlooking some subtle environment variable or another subtle environment-related factor.

I was hoping someone would pipe in and say they know about a specific KB/bug related to either the message "incompatible data types" or the message that seems to preceed it ("Could not locate method...with matching signature in class").  But I suppose that the problem my involve *both* the use of  OO *and* HP-UX, in which case I may be on my own. ;)  I will package up the project and send it off to support when I have some spare time.  Hopefully Progress still has an HP-UX server sitting around somewhere.

Fortunately we always run compiled classes in production.  I guess for now I will also have to compile in development too.

Thanks everyone for the tips.  If those specific messages don't look familiar to anyone, then I will have to go to Progress with this problem.  One motivation I had in creating this posting was to try to generate another search result for google.  If you search for these things in relation to OE ...

• "Incompatible data types in expression or assignment"
• "Could not locate method ... with matching signature in class"

You get very little.  I'm not sure exactly why that might be, but at least now there will be one more search result.  Perhaps sometime soon there will also be a KB as well...

Since you're on a *nix platform - could incorrect casing of classes vs their file names be an issue?

I've had repeated issues in PDS w/class caching - particularly when I move a class from one location to another. For example I had a class in x/y/c.cls that I moved to x/y/z/c.cls - and PDS'll still remember the old location and put in a USING  statement that points to the old location.

When it goes to compile it naturally doesn't find it and I get the same kind of "Data type" error reported by the OP. I've had to re-arrange the USING statement to hold the correct location and put it before a USING that points to some other code in the old location.

Hi David:

From a Language perspective, you are identifying that ABL code compiles successfully on non-HP-UX systems and fails to compile on HP-UX.  Given that observation, your conclusion to contact Progress Technical Support and log an issue is appropriate.  OpenEdge Development would need to investigate this scenario to understand why your code does not compile on HP-UX.  From the compilation perspective, the operating mode of the AppServer (state-reset vs. state-free) should be unrelated to the issue you are raising.

Thanks

I finally figured out what I had done wrong that confused the appserver so badly.

I had created my appserver by copying from another and ended up with a bad PROPATH.

[UBroker.AS.dev_lumbertrack_dkb]
    autoStart=1
    portNumber=3107
    PROPATH=${PROPATH}:${OLDWORKDIR}
    ...
    uuid=1234108e8ddd6422:122206:103300801e9:-8000
    workDir=${NEWWORKDIR}

... where $OLDWORKDIR was a bad/duplicate code location that was not applicable to this new copy of the appserver.  When I had copied from another appserver's configuration, I had fixed the "workDir" to use ${NEWWORKDIR} (and I fixed other things like portNumber, and uuid) but I had apparently overlooked the PROPATH....  Turns out that we don't really need to specify the working directory in the PROPATH anyway.

As a result of the poorly copy/pasted config, the $OLDWORKDIR location was occasionally being used for some of the executing code (especially when it had r-code available in there - and the class names weren't being fully qualified in the calling source code at $NEWWORKDIR ).

The two locations for ABL programs ($OLDWORKDIR and $NEWWORKDIR) are pretty far removed from one another in the file system, but were unfortunately both accessible from the save development machine.  There wasn't much in the appserver log that alerted me to the problem, even though I imagine that the flow of control was probably bouncing back and forth between two entirely different sets of code (albeit they'd sync up with each other on certain days , once my programming changes were pulled from source control).

I suppose if I had configured the appserver's *broker* log to dump all its properties, including the PROPATH, I might have eventually seen the problem.  I only found the problem after rebuilding my state-reset appserver line-by-line.  As Evan had pointed out, state-reset and state-free should never have been behaving differently in the first place.  Apparently the reason for difference in behavior was that was that only one of them had a bad PROPATH.

Thanks for the tips everyone.  My first suspicion was a bug in HP-UX because there have been a number of HP-UX-specific problems over the years.  I suppose next time I see differences between Windows and HP-UX, I will be a bit slower to point fingers.