Cached program definitions not updating

, ,
1

I have two subprograms that I am trying to develop as a web service. I am able to add the service to an existing package, create the connection, and create the service based on the IDL. I am then able to test the programs successfully using the Run As option in Designer.

The problem I run into is that when I subsequently make a code change and copy it into the library where the service pulls it from, it seems that the new code does not take effect. I’ve tried completely removing the service (including the connection) and building it again but no luck. In fact, I’ve changed the footprint of the service (the definition of the parameter area) and now get a NAT0935 error saying I have conflicting number of parameters. This is after I have removed the old service and rebuilt a new one using the IDL Extractor for Natural.

I suspect that there is a cached copy of the program somewhere that I need to delete. I’ve tried clearing the cache at both the package level and the service level through the IS administrator but to no avail. Experience has shown that if I wait until tomorrow, after our dev environment is refreshed from production, then the new definition will be picked up when I first copy the program into the correct library. So I suspect that the issue is something in Natural on the mainframe, rather than within Integration Server.

Any help would be appreciated. Being able to make and test only one set of changes a day really slows down development.

2

I assume you are connecting to an Natural RPC Server on the mainframe? running in batch? using its own local buffer pool?

If so, you (or your Natural Administrator) can do one of these:

  • restart the Natural RPC Server when you need to refresh the local modules
  • If your online uses a global buffer pool but batch doesn’t, have the batch job use the same Global Buffer Pool as your online session does - use library SYSBPM or check with your Natural Administrator on which GBP to use and how to specify it for your batch job (dynamic parameter BPNAME)
  • If global buffer pool is not an option for you, make sure the Natural RPC Server is using a non-blank LBPNAME (parameter of NTOSP or subparameter of OSP dynamic parameter). Wrap the API subprogram USR0340N as a service and call it when you want to flush the buffer pool of the running Natural RPC Server
3

Terminating the RPC server on Natural did it. Thanks for the help, Douglas. It was good talking to you again. You set up webMethods for us in the first place.

4

Good to hear that helped and hope all is going well with your webMethods applications.

You should look at the other options also as it will help avoid having to recycle the Natural RPC Server everytime you make a program change. (Gives you similar options when it comes time to deploy to production too.)