Uniface 9.4: Local Proc with no parameters throws error when called with 1-n arguments

Author: daniel.iseli@uniface.com (diseli)

People migrating to version 9.4 might encounter the following issue, which has been recognized as bug report #28722 and has been
fixed with the patch R107 (and higher):

Bug Report #28722: UF94: Local Proc with no parameters throws error when called with 1-n arguments

Description:
When in Uniface 9.4.01 a Local Proc Module with no parameters is called with one or more arguments then an error is thrown
($status = -1 and $procerror = -1122 - Wrong number of arguments), but in Uniface 8 and 9 the call returned no error.

It is considered correct behavior when Uniface throws an error in the above described case. This will be the behavior in Uniface
9.5. To grant customers a grace period allowing them sufficient time to locate the invalid calls to a local proc (using the Cross
Reference functionality of Unifafe 9.3 and higher) and subsequently correct the instances found, a compatibility switch will be
provided in patch R107. Setting this switch will allow migration to Uniface 9.4 without the immediate need for proc code changes.

This switch will e removed in 9.5.01. The Uniface 9.5 Migration Guide will provide a clear statement about the required change
(under the topic "Changes in Proc").

Note: The above described problem occurs in 9.4.01, and also in version 9.3.02 patch P208; for the 9.3.02 code line this has been
repaired - since it's a compatibility issue - in the patch P209.

Solution:
A temporary switch in the assignment file section, $NoEntryEmptyParamsCheck, is made available to set compatibility with the incorrect
behavior of Uniface 8.4.06 and 9.2.03 + P209 and higher. The default value for this Boolean switch is 'False'. To maintain
compatibility with previous versions the switch must be set to True explicitly. Be aware that corrections must be applied before
migrating to Uniface 9.5.

* <Switch not defined > check is performed, i.e. correct behavior is enforced, not compatible with UF8.4.06 / UF9.3.02
* $NoEntryEmptyParamsCheck = False similar to <Switch not defined>, i.e. check is performed, not compatible with UF8.4.06 / UF9.3.02
* $NoEntryEmptyParamsCheck check disabled, compatible with UF8.4.06 / UF9.3.02 + P209 and higher
* $NoEntryEmptyParamsCheck = True check disabled, compatible with UF8.4.06 / UF9.3.02 + P209 and higher

Page 1 / 1

Uniface 9.4: Local Proc with no parameters throws error when called with 1-n arguments

Author: daniel.iseli@uniface.com (diseli)

People migrating to version 9.4 might encounter the following issue, which has been recognized as bug report #28722 and has been
fixed with the patch R107 (and higher):

Bug Report #28722: UF94: Local Proc with no parameters throws error when called with 1-n arguments

Description:
When in Uniface 9.4.01 a Local Proc Module with no parameters is called with one or more arguments then an error is thrown
($status = -1 and $procerror = -1122 - Wrong number of arguments), but in Uniface 8 and 9 the call returned no error.

It is considered correct behavior when Uniface throws an error in the above described case. This will be the behavior in Uniface
9.5. To grant customers a grace period allowing them sufficient time to locate the invalid calls to a local proc (using the Cross
Reference functionality of Unifafe 9.3 and higher) and subsequently correct the instances found, a compatibility switch will be
provided in patch R107. Setting this switch will allow migration to Uniface 9.4 without the immediate need for proc code changes.

This switch will e removed in 9.5.01. The Uniface 9.5 Migration Guide will provide a clear statement about the required change
(under the topic "Changes in Proc").

Note: The above described problem occurs in 9.4.01, and also in version 9.3.02 patch P208; for the 9.3.02 code line this has been
repaired - since it's a compatibility issue - in the patch P209.

Solution:
A temporary switch in the assignment file section, $NoEntryEmptyParamsCheck, is made available to set compatibility with the incorrect
behavior of Uniface 8.4.06 and 9.2.03 + P209 and higher. The default value for this Boolean switch is 'False'. To maintain
compatibility with previous versions the switch must be set to True explicitly. Be aware that corrections must be applied before
migrating to Uniface 9.5.

* <Switch not defined > check is performed, i.e. correct behavior is enforced, not compatible with UF8.4.06 / UF9.3.02
* $NoEntryEmptyParamsCheck = False similar to <Switch not defined>, i.e. check is performed, not compatible with UF8.4.06 / UF9.3.02
* $NoEntryEmptyParamsCheck check disabled, compatible with UF8.4.06 / UF9.3.02 + P209 and higher
* $NoEntryEmptyParamsCheck = True check disabled, compatible with UF8.4.06 / UF9.3.02 + P209 and higher

Daniel,

In 9.3.01 Uniface returns $status = -1 and $procerror -1109 when you call a Local Entry with the wrong number of params.

In 9.3.02 .01 (P207) it returns a 0 for $Status and $Procerror.

Regards

Paul

Author: aikon1694 (uniface@koldijk.com)

Uniface 9.4: Local Proc with no parameters throws error when called with 1-n arguments

Author: daniel.iseli@uniface.com (diseli)

People migrating to version 9.4 might encounter the following issue, which has been recognized as bug report #28722 and has been
fixed with the patch R107 (and higher):

Bug Report #28722: UF94: Local Proc with no parameters throws error when called with 1-n arguments

Description:
When in Uniface 9.4.01 a Local Proc Module with no parameters is called with one or more arguments then an error is thrown
($status = -1 and $procerror = -1122 - Wrong number of arguments), but in Uniface 8 and 9 the call returned no error.

It is considered correct behavior when Uniface throws an error in the above described case. This will be the behavior in Uniface
9.5. To grant customers a grace period allowing them sufficient time to locate the invalid calls to a local proc (using the Cross
Reference functionality of Unifafe 9.3 and higher) and subsequently correct the instances found, a compatibility switch will be
provided in patch R107. Setting this switch will allow migration to Uniface 9.4 without the immediate need for proc code changes.

This switch will e removed in 9.5.01. The Uniface 9.5 Migration Guide will provide a clear statement about the required change
(under the topic "Changes in Proc").

Note: The above described problem occurs in 9.4.01, and also in version 9.3.02 patch P208; for the 9.3.02 code line this has been
repaired - since it's a compatibility issue - in the patch P209.

Solution:
A temporary switch in the assignment file section, $NoEntryEmptyParamsCheck, is made available to set compatibility with the incorrect
behavior of Uniface 8.4.06 and 9.2.03 + P209 and higher. The default value for this Boolean switch is 'False'. To maintain
compatibility with previous versions the switch must be set to True explicitly. Be aware that corrections must be applied before
migrating to Uniface 9.5.

* <Switch not defined > check is performed, i.e. correct behavior is enforced, not compatible with UF8.4.06 / UF9.3.02
* $NoEntryEmptyParamsCheck = False similar to <Switch not defined>, i.e. check is performed, not compatible with UF8.4.06 / UF9.3.02
* $NoEntryEmptyParamsCheck check disabled, compatible with UF8.4.06 / UF9.3.02 + P209 and higher
* $NoEntryEmptyParamsCheck = True check disabled, compatible with UF8.4.06 / UF9.3.02 + P209 and higher

Paul,

The behavior of version 9.3.02 up to patch P208 is incorrect!

In patch P208 the problem #28522 ("Operation called with too few parameters returns 0 instead of -1") has been resolved. But the fix for #28522 caused that side-effect that has been recognized as problem #28571 ("Function call to non-existing entry sets $status to -1 in calling entry") and was resolved with the patch P209.

With patch P209 (or higher) Uniface will return $starus = 0 when a Local Entry with no parameters is called with one or more arguments. Since version 9.4.01 Uniface will always return an error in case a Local Proc is called with the incorrect number of arguments - this is intended behavior. And for compatibility reasons the ASN setting $NoEntryEmptyParamsCheck has been introduced (see solution for problem #28722)

Hope this helps.

Kind regards,
Daniel

*** Usual disclaimer ***

Author: diseli (daniel.iseli@uniface.com)