× 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.


  • Subject: Binder Language and RTVBNDSRC
  • From: Jing Wang <jhwang@xxxxxxxxxx>
  • Date: Tue, 11 Aug 1998 16:51:20 -0400

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
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.