|
On 15/03/2006, at 10:03 AM, Lim Hock-Chai wrote:
When I run the caller program, I'm gettting the MCH0602 error. I was under the impression that I do not need to recompile caller program as long as the change that I made to the service program doesn't cause the signature to change. Is that a wrong assumption?
Yes, it's wrong. The signature is calculated on the order of the exported items. That is procedure names and data item names. It does not verify parameter types or sizes nor the order of the parameters. It also does not include the return value if any. When changing the interface to a procedure you must ensure you do so in a backwards compatible manner otherwise you'll experience this sort of problem in which case you'll have to recompile the consumer.
Whether you need to recompile the consumer depends on how the procedure handles the parameters. As long as the procedure either:
midrange.com
1) Allows the caller to specify the length of character variables or
2) Uses CEEDOD to determine the length of character variables
then the caller should be immune to changes in the procedure parameters.
However you are changing the return value and CEEDOD won't help here.
In this case there is no easy way to change the return value without
also recompiling the caller.
There are some rules you must follow when modifying a procedure if you want to avoid forcing a recompile of all consumers:
1) Never change the return value
2) Always make new parameters optional
3) Always know the length of character variables:
a) Use VARSIZE and CEEDOD,
b) or allow the caller to provide lengths,
c) or never change the size of existing parameters
4) Never change the size or precision of numeric variables
A special case of 3 is to use VARYING character variables but even here
both the caller and callee must use the same maximum length.
Having said all that it surprises me that you receive MCH0602 which normally only occurs when using MI instructions. It is possible that by increasing the length of the return value you have corrupted storage that then causes this exception when that storage is referenced by another op-code or instruction.
Regards, Simon Coulter. -------------------------------------------------------------------- FlyByNight Software AS/400 Technical Specialists http://www.flybynight.com.au/ Phone: +61 3 9419 0175 Mobile: +61 0411 091 400 /"\ Fax: +61 3 9419 0175 \ / X ASCII Ribbon campaign against HTML E-Mail / \ --------------------------------------------------------------------
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.
