Re: Binder Language and RTVBNDSRC

Jing --

Here is the problem with your example.  If we follow your example, in
one of your scenarios we end up with the following binder language:

   STRPGMEXP PGMLVL(*PRV) LVLCHK(*YES)
     SYMBOL EXPORT('sym1')
     SYMBOL EXPORT('sym2')
   ENDPGMEXP
   STRPGMEXP PGMLVL(*CURRENT) LVLCHK(YES)
     SYMBOL EXPORT('new1')
     SYMBOL EXPORT('sym2')
     SYMBOL EXPORT('sym1')
   ENDPGMEXP

However, this will not work!  A program created using the original
version of service program S (the one with just the two symbols
exported) will use ordinal 1 to call 'sym1' and ordinal 2 to call
'sym2'.  In the calling program, it just calls using the ordinals after
checking that the signature is a valid signature.

But, when I recreate service program S using the above binder language,
I now have ordinal 1 = new1, ordinal 2 = sym2, ordinal 3 = sym1.  Thus,
when I run my original calling program, when it calls ordinal 1,
thinking it's getting sym1, it's actually getting new1!!!  This is
because there is only one set of ordinals maintained for the service
program, not one set per signature and the ordinals are determined
solely by the *CURRENT signature block.

You say:
> The order in the bottom block, PGMLVL(*CURRENT), is not important
> right now - this block is used only by those who rebind (crtpgm
> or crtsrvpgm) AFTER S is changed.

but that's not really true.  It is the order in the bottom block that
determines what ordinal 1 means for ALL callers -- new AND old.  This is
why it was previously said on this list that the current implementation
"renames" the ordinals.

It's also why RTVBNDSRC is of limited use out of the box when adding new
entrypoints.

Gary

Jing Wang wrote:
> 
> I'm new to this group and don't know how to see old messages so I
> haven't read every message on this subject, but I thought I should answer
> some comments/questions.
> 
> RTVBNDSRC retrieves exports from the module.  The order in which symbols are
> exported from the module is determined by the compiler (it may or may not
> reflect the order in which they appear in the C/RPG/COBOL source). So every
> time a source file is modified and recompiled, the resulting new module may
> have exports listed in different order.  RTVBNDSRC
> creates a binder language source or append a STRPGMEXP-ENDPGMEXP block to an
> existing binder language source.  If my service program S was created using 
>the
> following binder language:
>   STRPGMEXP PGMLVL(*CURRENT) LVLCHK(*YES)
>     SYMBOL EXPORT('sym1')
>     SYMBOL EXPORT('sym2')
>   ENDPGMEXP
> Now, if I decided to change the module by adding a new procedure new1.  After
> the module is recreated, RTVBNDSRC can be run to retrieve exports from the new
> module, so my binder language may look like:
>   STRPGMEXP PGMLVL(*CURRENT) LVLCHK(*YES)
>     SYMBOL EXPORT('sym1')
>     SYMBOL EXPORT('sym2')
>   ENDPGMEXP
>   STRPGMEXP PGMLVL(*CURRENT) LVLCHK(YES)
>     SYMBOL EXPORT('new1')
>     SYMBOL EXPORT('sym2')
>     SYMBOL EXPORT('sym1')
>   ENDPGMEXP
> But this binder language is not ready to be used by CRTSRVPGM yet, because
> both STRPGMEXP-ENDPGMEXP blocks have PGMLVL(*CURRENT).  I must change the
> top block (the one with two symbols) to PGMLVL(*PRV). I don't need to use
> the SIGNATURE keyword, because by keeping sym1 and sym2 in the same order in
> the PGMLVL(*PRV) block, it is guarrented that a same signature as previous one
> will be generated (so existing clients of S won't have to rebind).  The order
> in the bottom block, PGMLVL(*CURRENT), is not important right now - this block
> is used only by those who rebind (crtpgm or crtsrvpgm) AFTER S is changed.
> An alternative is not to use RTVBNDSRC.  Instead, manually add SYMBOL EXPORT(
> 'new1') after SYMBOL EXPORT('sym2').  This way, there is only one STRPGMEXP-
> ENDPGMEXP block, but the SIGNATURE('old-sig') must be added to the STRPGMEXP
> statement to ensure the same signature as previous is generated.  If not sure
> what signature S has, do a DSPPGM DETAIL(*SIGNATURE) and cut and past.
> So, basically there are two alternatives when it comes to add a new function 
>to
> S: (1)use RTVGNDSRC and get a new export block, then change the previous 
>PGMLVL
> (*CURRENT) to PGMLVL(*PRV); or (2) add the new function to the end of the
> current export block.  Either one should work just fine, no need to use both.
> As for replacing the symbol name with its ordinal position number, the reason
> is ordinal number gives good execution time performance - a table look up is
> always much faster than a name search.  One of the post suggest the use of
> ordinal number is for renaming exports - that's not true.
> If you have problem using the binder language created/appended by RTVBNDSRC,
> please post the old and new binder language source here (if you haven't done 
>so
> ) or send them to me.
> I better send this out before the line goes down.  More when I return.
> 
> Jing Wang, jhwang@us.ibm.com
> Programming Model
> IBM AS/400, Rochester MN
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator: david@midrange.com
> +---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---