Re: Binder Language problems -- MIDRANGE-L

Gary L Peskin wrote:
> 
> (1) What kind of "create errors" do you get if the new set of exports is
> at the bottom?
> 
> (2) If you do a DSPSRVPGM on your service program, do both sets of
> signatures show up?
> 
> (3) If you do a DSPPGM on your CALLING program and then hit enter until
> it shows the service programs, does the signature shown match the
> ORIGINAL signature of the service program?
> 
> (4) Are you explicitly specifying the LVLCHK or SIGNATURE parameter of
> the STRPGMEXP statement?
> 
> Gary
> 
> Nelson Smith wrote:
> >
> > I'm with you on everything you said below except for two small areas.
> > First, I get create errors when trying to create the service program if
> > I don't move the new set of exports (shown at the bottom of your source)
> > up to the top of the source. Once I move it there, the service program
> > creates fine. However, this may be the source of my second problem.
> >
> > In your next to last paragraph, you said your original program "B"
> > references the first export in the ORIGINAL block of source.  That is
> > not my experience. In my case it references the first export in the NEW
> > block of source which in the example below is a newly added export.
> > Unexpected results occur because the parameters are usually different.
> >
> > Do you have no problem recreating the service program with the binder
> > source shown as below, with the new set of source exports at the end?
> > If not, what am I doing wrong?  What are your parameters set to on the
> > CRTSRVPGM command?
> >
> > Gary L Peskin wrote:
> > >
> > > Nelson --
> > >
> > > I don't mean to be dense here.  But let me give you an example so that
> > > you can explain to me where my misunderstanding is.
> > >
> > > I have a *PGM ("A") which consists of one module ("AM") which I recently
> > > created using the following binder language:
> > >
> > > STRPGMEXP PGMLVL(*CURRENT) LVLCHK(*YES)
> > >   EXPORT SYMBOL('sym1')
> > >   EXPORT SYMBOL('sym2')
> > > ENDPGMEXP
> > >
> > > After *PGM A is created, I create program B which calls procedure sym1.
> > >
> > > Now, I enhance module AM and add a new entry point, called 'new1'.
> > >
> > > Say I place this procedure before 'sym1' in AM.  By the way, I think the
> > > RTVBNDSRC creates the exports in an order specified by the compiler.
> > > The C compiler places the exported symbols in the same order as they
> > > appear in the program -- don't know about the other compilers.)
> > >
> > > Now, I do a RTVBNDSRC, adding to my previous source.  After the command
> > > runs, I get:
> > >
> > > STRPGMEXP PGMLVL(*CURRENT) LVLCHK(*YES)
> > >   EXPORT SYMBOL('sym1')
> > >   EXPORT SYMBOL('sym2')
> > > ENDPGMEXP
> > > STRPGMEXP PGMLVL(*CURRENT) LVLCHK(*YES)
> > >   EXPORT SYMBOL('new1')
> > >   EXPORT SYMBOL('sym1')
> > >   EXPORT SYMBOL('sym2')
> > > ENDPGMEXP
> > >
> > > The first four lines were in my binder source member from before I ran
> > > the RTVBNDSRC command.
> > >
> > > I change the binder source by replacing all but the last *CURRENT to
> > > read *PRV so now the source looks like this:
> > >
> > > STRPGMEXP PGMLVL(*PRV) LVLCHK(*YES)
> > >   EXPORT SYMBOL('sym1')
> > >   EXPORT SYMBOL('sym2')
> > > ENDPGMEXP
> > > STRPGMEXP PGMLVL(*CURRENT) LVLCHK(*YES)
> > >   EXPORT SYMBOL('new1')
> > >   EXPORT SYMBOL('sym1')
> > >   EXPORT SYMBOL('sym2')
> > > ENDPGMEXP
> > >
> > > Since I haven't explicity specified a signature, the system will create
> > > a different unique signature for each STRPGMEXP .. ENDPGMEXP block.  New
> > > programs which call "A" will use the *CURRENT export block and will have
> > > that signature embedded in them.
> > >
> > > However, my old program "B" will still work, without recreating it,
> > > because "B" references the first slot in the ORIGINAL export block
> > > (which it locates based on the signature still embedded in "B") which is
> > > still 'sym1'.
> > >
> > > Programs compiled under an earlier signature will reference the earlier
> > > signatures exports in that signatures ordinal order.  Are you overriding
> > > the signature or not retaining old signatures?
> > >
> > > Gary
> +---
> | 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
> +---
(1) I'll have to go back Monday and see if I can recreate the error.  I
don't get them anymore since I started rearranging the output from
RTVBNDSRC. I don't remember the exact message number.

(2)&(3) At the time I was having the problems, the signatures are
something I checked closely and everything matched up as it should.

(4) No. I'm using the STRPGMEXP statement exactly as generated by
RTVBNDSRC.  If I remember correctly, LVLCHK defaults to *YES and
SIGNATURE is only used to override the normally generated signature to
something you hardcode.

You didn't explicitly say so, but can I assume from your questions that
you do not get any errors when you leave your newly created set of
exports at the bottom of the source member?
-- 
Nelson Smith
"Standards are Wonderful....cause there's so many to choose from!"
ncsmith@gate.net
+---
| 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
+---