We have a process that is variable on start time. It would be great to throw a couple of records into a table to define a black out period.
And then obviously delete them upon completion.
Is it as simple as flipping the black_out_enabled_ind flag on the <database>.cr_process_black_out table?
Blackout periods are cached so direct updates to the tables may not get picked up. To ensure that the updates get picked up, one would have to make sure the cache is refreshed. Unfortunately, there is no easy way to do that for blackout periods without customization. But perhaps there may be some other alternative depending on the context in which you are trying to do this. Can you provide more details? For example, is this process supposed to run in parallel with ongoing CIM jobs or is this a process that should complete before any CIM jobs run? Is the process supposed to be sequenced with all CIM jobs or just specific CIM jobs? Depending how the process needs to be coordinated with CIM jobs, you might be able to accomplish what you need with other functionality such as externally launching the CIM jobs directly from the process using the PE client rather than using a specific recurring schedule. This would allow the process to control when certain jobs run by lauching them as the last step in the custom process.
No worries on this topic for now.
I had figured out a script to update the engines on the fly so we could attach it to other processing.
We wanted to stop anything that was processing in CIM while the database was being updated and then restart existing processing once the updates were complete.
Ok. Sounds like the best way to do that is to just shutdown the application and then bring it back up after the database updates are done. If the application should still be available to users while the database updates occur (which we generally don't recommend), then using the PE client to stop the scheduler would be the next suggestion. However, stopping the scheduler only prevents new job runs from initiating. Any actively running jobs would still run to completion. Blackout periods do not stop jobs immediately either but they have an advantage over stopping the scheduler because they stop the jobs the next available checkpoint rather than waiting for the entire job to finish. But, as mentioned, there may be a bit more complexity if one wants to update them dynamically. The PE client would be fairly trivial to implement - just use the -scheduler=[start | stop] parameter. For example:
java -jar trm-pe-client.jar -user=myuser -password=mypw -scheduler=stop
would stop the scheduler and
java -jar trm-pe-client.jar -user=myuser -password=mypw -scheduler=start
would start it back up.
Also, feel free to open an incident if you would like someone to investigate the dynamic blackout approach.