|
Hi Simon, Thanks for clearing that up. It is, indeed, good to know... And thanks to everyone who pointed out the flaw in my original example. I can't believe I never ran across this before... I've probably always added the procedures at the end without realizing the significance! On Fri, 12 Jan 2001, Simon Coulter wrote: > > Hello Scott, > > I wrote: > >As long as the new public (exported) procedure is added at the end of the > >other public procedures in the service program I believe you can change the > >order of the exports in the current signature. > > After having sent that I went to bed and woke up in the wee hours thinking > what a lot of crap that was. I think I need a new job -- thinking about this > stuff while I'm asleep is simply sick! > > I have just completed some trivial testing using the following code > > Calling progam: > D proc1 PR 5I 0 > D parm1 10 CONST OPTIONS(*NOPASS) > D proc2 PR 5I 0 > D parm1 10 CONST OPTIONS(*NOPASS) > > C CALLP proc1 > C CALLP proc2 > C SETON LR > C RETURN > > Service program: > H NOMAIN > > D proc1 PR 5I 0 > D parm1 10 CONST OPTIONS(*NOPASS) > D proc2 PR 5I 0 > D parm1 10 CONST OPTIONS(*NOPASS) > D proc3 PR 5I 0 > D parm1 10 CONST OPTIONS(*NOPASS) > > P proc1 B EXPORT > D proc1 PI 5I 0 > D parm1 10 CONST OPTIONS(*NOPASS) > C RETURN 1 > P proc1 E > > P proc2 B EXPORT > D proc2 PI 5I 0 > D parm1 10 CONST OPTIONS(*NOPASS) > C RETURN 2 > P proc2 E > > Binder source: > STRPGMEXP PGMLVL(*CURRENT) LVLCHK(*YES) > EXPORT SYMBOL(PROC1) > EXPORT SYMBOL(PROC2) > ENDPGMEXP > > I compiled this code using a *NEW activation group for the calling program >and > *CALLER for the service program and ran it through debug and stepped into > PROC1 and then into PROC2. > > I added the following code the end of the service program: > P proc3 B EXPORT > D proc3 PI 5I 0 > D parm1 10 CONST OPTIONS(*NOPASS) > C RETURN 3 > P proc3 E > > and updated the binding source to the following: > STRPGMEXP PGMLVL(*CURRENT) LVLCHK(*YES) > EXPORT SYMBOL(PROC1) > EXPORT SYMBOL(PROC3) > EXPORT SYMBOL(PROC2) > ENDPGMEXP > STRPGMEXP PGMLVL(*PRV) LVLCHK(*YES) > EXPORT SYMBOL(PROC1) > EXPORT SYMBOL(PROC2) > ENDPGMEXP > > I ran this through debug (after ending debug and restarting it because the > debugger does silly things) and watched it step into PROC1 and then step into > PROC3 -- OOPS! > > I also tried the experiment after moving PROC3 between PROC1 and PROC2 in the > serce program so it reflected the order of the exports in the binder source. > I rebuilt only the service program and that also resulted in PROC3 being run > by the calling program -- OOPS! > > Finally, I corrected the binder source by moving the export for PROC3 after > the export for PROC2 but leaving PROC3 in the new position in the service > program and rebuilding it. This time it behaved as expected and the calling > program using the previous signature correctly invoked PROC1 and PROC2. > > I didn't know that would work and actually helps with organising the code in > the service program which is a GOOD THING TO KNOW! > > The ordinal procedure number IS affected by the position of the procedure >name > in the binder source. Changing the order of the exports in the current > signature will change the procedure actually invoked by programs using one of > the previous signatures. I guess there is a single procedure mapping table > generated in the service program which is used to determine the actual > procedure invoked for a given procedure number and it is derived from the > current export information. Something to investigate further on day when I > have nothing better to do .... probably about the 12th of Never ... > > Regards, > Simon Coulter. > +--- | This is the RPG/400 Mailing List! | To submit a new message, send your mail to RPG400-L@midrange.com. | To subscribe to this list send email to RPG400-L-SUB@midrange.com. | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
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
