× 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: RE: Module source naming schemes
  • From: Scott Klement <klemscot@xxxxxxxxxxxx>
  • Date: Wed, 10 Jan 2001 14:45:40 -0600 (CST)



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.