RE: Module source naming schemes

Scott,

Try signing off and back on and rerun your test program and see what you
get.  I went through the steps in your example.  I got your results IF after
changing the service program I just reran the program that used it.  BUT, if
I reclaimed the activation group and reran the test program and it displayed
test_open followed by test_read which is as I suspected.  If you don't
reclaim the activation group prior to running the calling program then it
doesn't get the new version of the service program until maybe the next time
you signon or sometime later that the activation group is reclaimed.  I
think when this bit me I probably went through the steps you did and
everything 'seeemed ok' but later I found it was calling the wrong program.

Scott Mildenberger

> -----Original Message-----
> From: Scott Klement [mailto:klemscot@klements.com]
> Sent: Wednesday, January 10, 2001 1:46 PM
> To: 'RPG400-L@midrange.com'
> Subject: RE: Module source naming schemes
> 
> 
> 
> 
> On Wed, 10 Jan 2001, Scott Mildenberger wrote:
> 
> > Scott,
> > 
> > Your description of how to modify a service program was 
> good except for one
> > detail.  When you are a new procedure to a service program 
> you have to put
> > it at the end of the list in the *CURRENT section in the 
> binder source.
> > That is because the programs that are using the service 
> program don't retain
> > the name, just that they are to call the 3rd export from the service
> > program.  In your example below, a program that had 
> previously been bound to
> > this service program and was calling RNF_CLOSE would now 
> call RNF_READP if
> > it wasn't rebound.  In the best case, the program would 
> bomb when making
> > this call.  In the worst case, it won't get an error and 
> appear to work and
> > just do strange things (I have been here and it is not a 
> good place!).  You
> > may already know this but wanted to make sure that anyone 
> new to service
> > programs was aware of this little detail.
> > 
> > Scott Mildenberger
> > 
> 
> Okay, I'm trying to create the problem that you're 
> describing.   For test
> purposes, I created this bindery source, and service program:
> 
> 
> STRPGMEXP PGMLVL(*CURRENT)
>   EXPORT SYMBOL(TEST_OPEN)
>   EXPORT SYMBOL(TEST_CLOSE)
> ENDPGMEXP
> 
>      H NOMAIN
> 
>      D Msg             S             50A
>      D test_open       PR
>      D test_close      PR
> 
> 
>      P test_open       B                   Export
>      D test_open       PI
>      C                   eval      Msg = 'test_open'
>      c                   dsply                   Msg
>      P                 E
> 
> 
>      P test_close      B                   Export
>      D test_close      PI
>      C                   eval      Msg = 'test_close'
>      c                   dsply                   Msg
>      P                 E
> 
> 
> I compiled a simple program that just callp-ed test_open and 
> test_close. 
> and tested it.
> 
> Next, I changed the bindery source to look like this:
> 
> STRPGMEXP PGMLVL(*CURRENT)
>   EXPORT SYMBOL(TEST_OPEN)
>   EXPORT SYMBOL(TEST_READ)
>   EXPORT SYMBOL(TEST_CLOSE)
> ENDPGMEXP
> STRPGMEXP PGMLVL(*PRV)
>   EXPORT SYMBOL(TEST_OPEN)
>   EXPORT SYMBOL(TEST_CLOSE)
> ENDPGMEXP
> 
> and I added a procedure to my service program that looked like this:
> 
>      P test_read       B                   Export
>      D test_read       PI
>      C                   eval      Msg = 'test_read'
>      c                   dsply                   Msg
>      P                 E
> 
> 
> Recompiled/Rebound the service program... but DID NOT 
> recompile or rebind
> the simple program that I was testing it with.
> 
> When I re-ran the test program, I got the SAME output, "DSPLY 
> test_open"
> followed by "DSPLY test_close".   No errors, no problems.
> 
> If what you're saying is true, my 2nd DSPLY would've been "test_read"
> instead of "test_close", but it wasn't.
> 
> Are you sure you're not thinking of switching from EXPORT(*ALL) to
> EXPORT(*SRCFILE)?   Or using bindery source with LVLCHK(*NO)?  Or
> specifying your own signature?
> 
> 
> 
> +---
> | 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
> +---
> 
+---
| 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
+---