Re: wrong copy of module remains in service program

Michael,

I'm pretty the object that was included is correct. Unfortunately, UPDSRVPGM does not update the associated information (like the library) properly. I find that behavior quite disconcerting, since we rely on the basic object information to be correct...

-mark

On 1/27/2016 12:29 PM, Koester, Michael wrote:

I have a service program in our Production library, TFSCM1. I created a copy of that in my test library, MKOESTER, using CRTSRVPGM, which picked up all the modules from the production library (on purpose), except for one module from my test library, which I had neglected to delete after sending my updates to Production last Monday. (I discovered that during a SEP-debug session when the debugger couldn't find the source, which had been removed from my source file last Monday).
Okay, so I deleted the GETNOVASTS module object from my library, and ran "UPDSRVPGM MKOESTER /NEONOVAAPI MODULE(*LIBL/GETNOVASTS)". I thought that would find no such GETNOVASTS module in my library and pick up the one from the TFSCM1 library (Production) further down the library list.
Message after UPSRVPGM indicated that 1 of the 24 modules was successfully updated, but when I run "dspsrvpgm mkoester/neonovaapi detail(*module)", all modules listed as being in the production library, except the GETNOVASTS, which is still (according to dspsrvpgm) in MKOESTER.
I verified that there is no mkoester/getnovasts object, and that the *MODULE object IS in TFSCM1, and that TFSCM1 is in my library list. And I have *USE and *execute authority on TFSCM1 library.

So how does the UPDSRVPGM pick up a module from a library with no such object? What am I missing?

Many thanks,
Michael Koester