Thank you to all who responded and to Barbara Morris for this response. We will be fixing this in all of our programs.
Rick Crow
Programmer/Analyst
4235 Secor Rd. | Toledo, OH 43623
O: 419-479-5750
rcrow@xxxxxxxxxxxxxxxx | www.toledoclinic.com
-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Barbara Morris
Sent: Wednesday, June 29, 2016 5:08 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: 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.
--
Barbara
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
midrange.com
