We run our EntireX services in batch (z/OS). When we migrate modified subprograms to production, the batch sessions often retains the old version in the buffer pool for some time. This can lead to runtime errors. Our only solution right now is to stop the job and resubmit it. This obviously affects our system availability.
I found a program USR0340P in SYSEXT which executes USR0340N. This seems to provide some scope for using an RPC call to USR0340N to flush the buffer for a specific program.
has anyone tried to use USR0340N for this purpose?
has anyone got a different solution to this problem?
Yes, USR0340N can be used for this purpose. I’ve written a simple wrapper subprogram for some clients that would accept the library name and create an RPC request to call that wrapper to flush the buffer pool for that library and/or program.
If you are using the local buffer pool and have NTASKS greater than 1, you should modify the NTOS parameter LBPNAME to a non-blank value. This will allow all your instances of the RPC server in that job to share the same local buffer pool. Otherwise you would have to call the USR0340N routine repeatedly until all tasks had flushed…not a very deterministic solution. I haven’t found any reason yet to not share the LBP within an RPC server.
Another option is to use the global buffer pool and have the RPC Servers use it. If you migrate your programs in an online environment that shares the same GBP as the RPC servers, they will immediately have the new version available to them.
Thanks for the reply, its good to know I am on the right track.
Do you know if the proper arguments to USR0340N and their meanings are documented anywhere? USR0340P lists the parameters etc but does not seem to provide any guidance on how to use USR0340N, such as what fields are required etc.
Library SYSEXT gives sample program and documentation on the Natural API’s including USR0340N. Use the MENU, put a ? on the selection field to see the options.