RE: CEEMOUT

We believe that we may have discovered the reason. For whatever the reason, it is somewhat difficult to find a proper prototype definition for CEEMOUT and the one that we have been using and, of course, copying from program to program, looks like this:

// Call system api to write message to screen or job log
dcl-pr WriteMessage extproc('CEEMOUT') opdesc;
@i_msg char(80) options(*varsize) const;
@i_dest int(10) const; // 1=Inter, 2=JobLog
end-pr;

With the call looking like this:
@i_Msg = 'No files waiting to be processed (STAT_10) in ECP308';
WriteMessage( @i_Msg : @c_ToJobLog );

We did stumble across a definition that does NOT define the message parameter as being constant OR varying. If that is true than our program, which believes that it is constant, may use a memory location that could partially overlap a variable believing that it won't be changed when, in fact, it could be changed by the API and thereby change the value of our variable.

Are we correct in our reasoning?

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 Jon Paris
Sent: Wednesday, June 29, 2016 11:36 AM
To: Rpg400 Rpg400-L
Subject: Re: CEEMOUT

The obvious answer is that you have “lied” to CEEMOUT and memory corruption is resulting. It has probably always been happening but to variables that didn’t matter. By recompiling you have changed the memory layout and now it matters.

Show us the call to the API and the field definitions and we may be able to help more.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Jun 29, 2016, at 11:08 AM, Rick Crow <RCrow@xxxxxxxxxxxxxxxx> 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 finally 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?

Thanks,
Rick Crow
Programmer/Analyst

[Description: TCIsmall]
4235 Secor Rd. | Toledo, OH 43623
O: 419-479-5750
rcrow@xxxxxxxxxxxxxxxx<mailto:rcrow@xxxxxxxxxxxxxxxx> |
www.toledoclinic.com<http://www.toledoclinic.com>

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

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