× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Thanks - that's the result I would have expected.

As Joe says, you turned off the warning light when you used CONST - and maybe some other keywords. There was some note in the quote I posted where there may still be a compiler warning or error.

I guess the question is, do you need to use CONST? The main reason I do is, I can use expressions and literals instead of variables. But that might not be a good-enough reason in your circumstances, esp. when you want to preserve the compiler checking.

HTH and regards
Vern

On 3/27/2012 8:37 AM, Dave wrote:
Vern,

I passed data that was 50+ characters long in a 100A field to a
procedure expecting a 40A parameter field and lost the 10+ characters
at the end. If I'd tried to pass a variable of a different type, I'd
have known at the development stage and not, as it happened, during
testing.

Le 27 mars 2012 15:11, Vern Hamberg<vhamberg@xxxxxxxxxxx> a écrit :
dave

I still do not understand what bit you. What was the bad result that
occurred because of this. Did something fail to complete? Did a report
have incomplete information?

So far this is more of a theoretical problem - yes, parameters should
match. But I don't see any real issue yet - such as a truncated entry in
a log, say.

Now if CONST is not used and OPTIONS(*VARSIZE) is not used - here is a
part of the documentation for this option -

When OPTIONS(*VARSIZE) is specified, the passed parameter may be shorter
or longer in length than is defined in the prototype. It is then up to
the called program or subprocedure to ensure that it accesses only as
much data as was passed. To communicate the amount of data passed, you
can either pass an extra parameter containing the length, or use
operational descriptors for the subprocedure. For variable-length
fields, you can use the %LEN built-in function to determine the current
length of the passed parameter.

Note that this means that the notification of a mismatch will not take
place.

Is there perchance an OPTIONS(*VARSIZE) on that parameter, as well?

And please tell us what the end result is that is wrong - you have not
yet told us that - only that the compiler isn't telling you something
you think it should.

Regards
Vern

On 3/27/2012 6:05 AM, Dave wrote:
It was a CALLP

Le 26 mars 2012 21:59, Hiebert, Chris<chris.hiebert@xxxxxxxxxxxxxx> a écrit :
Was the Called program actually using the Prototype and Procedure Interface? Or was it still using a *ENTRY.


Chris Hiebert

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Dave
Sent: Monday, March 26, 2012 5:26 AM
To: RPG programming on the IBM i / System i
Subject: Re: passing parameters longer than expected

So I'm surprised by how you say this "bit you" and that you wish the
system would warn you? What problem does it cause?
Hi Scott,
I was using code that was already used and did not realize the error
before well into my tests. The same problem could be produced
elsewhere, as other developpers have copied this same error. There was
absolutely no reason to pass the parameters in this way. As we use
CONST on all input parameters, the situation that you describe is not
likely to happen, but if CONST were not used, I am also supprised that
there is no message from the compiler. I do not think that all in our
shop are aware of the result that would produce. It seems to me that
prototyping only offers an aid to compiling and not complete
protection from passing wrong parameters.
--
This is the RPG programming on the IBM i / System i (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.

--
This is the RPG programming on the IBM i / System i (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.


--
This is the RPG programming on the IBM i / System i (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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.