Re: CEEMOUT

On 6/29/2016 11:08 AM, Rick Crow wrote:

All,
We had a strange anomaly with CEEMOUT yesterday and I'm wondering if anyone can explain why this was happening. I made a couple of changes to a program that uses that API but the changes were unrelated to it. The program has a couple of internally defined file status variables that are used to update a file status field on the record being processed. After running the program I noticed in the file that the status field appeared to be blank (it is a character field) but SQL would not retrieve them based on a blank value. The program, somehow, put hex zeros in the field. I debugged the program in RDi and found that the internal status variable values changed to hex zeros immediately after the call to CEEMOUT. No matter how I changed the call to CEEMOUT the same thing happened. I final
ly redefined the variables with a different name and deleted the old variables which took care of the problem. My only assumption is that, for some reason, the call to CEEMOUT used an area
of memory that overlapped and, therefore, overlaid the values. This concerns me because we use this in many, many different programs. This is the first time, however, that I've ever seen this occur.

Has anyone ever seen this same behavior or know what could be causing this?

The problem is almost certainly to do with the missing third parameter. The API documentation uses the term "optional" for parameters that you don't have to pass at all. It uses the term "omissible" for parameters that must be passed, but that you can pass *OMIT for.

When you don't pass any parameter at all for the omissible feedback parameter, the API still looks for that parameter. Most of the time there will not be a valid pointer where it looks for the parameter, but occasionally there will be valid pointer that is left over from some previous call.

All (almost all?) the CEE functions have an omissible feedback parameter. When I hear about random or new storage corruption problems involving CEE functions, the first thing I look for is whether the feedback parameter is being passed. Some people are unlucky enough to get away with not passing the feedback parameter for years, then suddenly some little thing changes in their code or the system and the problem with the missing parameter surfaces.

I doubt there is a problem with the first parameter. The documentation says "A valid ILE string, passed by reference with a descriptor". You are passing a descriptor, so if this API call is usually working, then the API is fine with your CHAR parameter.