RE: ILE philosophy

[Rich Duzenbury <rduz@xxxxxxxxxxxxxxxxxxx>]

At 11:37 AM 9/20/02, you wrote:
> Again strictly my opinion and may not be the best practise, but I think of
> *SRVPGM as *LIB.  Yes, an OS/400 library object.  I put all my payroll
> specific procedures in one service program.  I put all my utility procedures
> (like number to words, centre text, trig functions) in utility service
> programs.  I segregate them according to function.  I am highly likely to
> need date handling and text manipulation in the same mainline, so all those
> functions are in a single SP.  I only rarely need sockets functions, so they
> live in their own SP.  It's a convenience thing more than anything else.
OK, I've given this a go.

Module: WMMDATE, contains my date handling routines.
Service Program: WMSDATE, contains module WMMDATE
Binding Directory: WMC, contains service program WMSDATE

Now, I want to use this stuff, so here is some 'application' code, compiled
with PDM, #14:

H dftactgrp(*NO) bnddir('WMC')

 * include prototypes for date handling
 /COPY WMCSRV,wmhdate

D today           s               d   inz(*sys)
D $week           s             10i 0

 * Get the week of the current month.
C                   eval      $week = RtvWeekOfMonth(today)
C     $week         dsply
C*
C                   eval      *inlr = '1'


Great, the code compiles.  And it runs.  But, if I remove the library
containing the service program from the library list, it still
runs.  Further, if I delete the service program, it still runs.

I thought service programs had to be resolved at run-time?

I hate to complain about the fact that something is actually **working**,
but I thought the whole service program idea revolved around dynamic
binding, so that if I modified the service program, the application program
would pick up the modified routines on it's next run.  It appears instead
to be static binding.

What have I done wrong?

BTW:  Thank you to all of the contributors on this thread, I'm becoming
enlightened, slowly but surely.

Regards,
Rich