|
From the API doc, I'd do it like so:dcl-pr WriteMessage extproc('CEEMOUT') opdesc;
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:to a program that uses that API but the changes were unrelated to it. The
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
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.
this?
Has anyone ever seen this same behavior or know what could be causing
is for the sole use of the intended recipient(s) and may contain
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,
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.
--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
--
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.
--
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
