×
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.
On Fri, Mar 16, 2018 at 8:21 AM, Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:
BUT - that will impact all existing callers of the routine because the
external name will be different. I guess you could get round it with a
mixed-case named stub that calls the upper case version.
Not really, as names only matter during bind time.
If the /COPY with the PR currently has
dcl-pr mixedCaseName extproc;
and the binder source for the *SRVPGM has
STRPGMEXP SIGNATURE('MYSRVPGM')
EXPORT SYMBOL('PROC1')
EXPORT SYMBOL('PROC2')
EXPORT SYMBOL('MIXEDCASENAME')
EXPORT SYMBOL('PROC4')
ENDPGMEXP
You can change the PR to
dcl-pr mixedCaseName extproc(*dclcase);
and the binder source too
STRPGMEXP SIGNATURE('MYSRVPGM')
EXPORT SYMBOL('PROC1')
EXPORT SYMBOL('PROC2')
EXPORT SYMBOL('mixedCaseName')
EXPORT SYMBOL('PROC4')
ENDPGMEXP
And rebuild the *SRVPGM.
Without affecting or needing to rebuild anything using it. They will
continue to call exported procedure #3....thus the reason it's normally
important not to change the order of exports in the binder source.
As existing callers are modified, they will be using the mixedCaseName from
the PR to resolve to exported procedure #3.
The only possible problem would be if you have something like Alan Campin's
trigger mediator, which dynamically activates *SRVPGM and resolves to a
procedure at run-time.
I supposed if you've defined MIXEDCASENAME as an external SQL UDF, that
would also be a problem.
Charles
midrange.com
