I once created a broker process that executed various services via exits. Most of them resided in service programs. These exits remained active once called, and also retained object locks on files. Sometimes I needed to close the files to do things to the files that required a lock. The solution was to have the exits run in a named activation group. I could send a message to the broker to have it suspend operations, and close the named activation group which closed the files and released the object locks. Once I was done with the process that needed the lock, I could notify the broker to resume operations, and everything would start back up normally. The key was the named activation group as I was never sure which transactions had run through which broker at any given time, so there was no way to call a procedure to close the files. Performance was fast as the named activation group only needed to be started once, and all the exits ran in it. I also didn't need to shut down the broker, just tell it to stop processing for a moment.
I am unfamiliar with a shared memory API which allow sharing memory between jobs. That seems to be a little counter to the work management schemes on IBM i. How does that work? How can you coerce a job to access memory outside it's job space. Are you using a special object like a user space or something like that?
Mark Murphy
Atlas Data Systems
mmurphy@xxxxxxxxxxxxxxx
-----Nathan Andelin <nandelin@xxxxxxxxx> wrote: -----
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
From: Nathan Andelin <nandelin@xxxxxxxxx>
Date: 05/11/2017 03:28PM
Subject: Re: Is there an API to "deactivate" an "active" service program?
If you are using *Caller to share overrides, could you not just use
ovrscope(*job). I am having trouble thinking of a situation where *New and
*Caller would work, but a named activation group would not.
The NEP and the dynamically activated service programs all "bind" to at
least one service program that exports a pointer to a data structure which
is shared between them. Actually, the value of the pointer is allocated
using a shared-memory API, so that the data is shared between multiple JOBS.
I should mention, that I do have a process in place that "ends" the NEP and
"restarts" it immediately. Ending a JOB obviously deactivates all bound
serviced programs, which works fine. When I get some time, I'll dig a
little deeper into deactivating individual service programs that were
dynamically activated during the run.
midrange.com
