Online backup is run at DB2 production server.
MirrorNightly takes over from finish of online backup. It
* Replicates Image to Mirror Server
* Drops DB at mirror
* Restores and Rollforwards the fresh DB

No problem with scripting DOS or unix. I used Quiesce DB to force application on this Server (Mirror has two DBs so I cannot use Force All option.). With last failure I realized that one application was not forced because it was using db2admin credentials.

I can redirect app_ids in a text file and read back to force apps.

But was trying to find out if I can use FORCE APPLICATION (sub-query)

I had seen one example somewhere online which actually did not work that time on my desktop.

Anyway thanks for interest.

DBFinder

I do not think you can write a force app with dynamically choosing applid. It would have to be a two step process.

However, as Andy pointed out, you should not have appls running using ids that have such an access as you have.User is a user. admin is an admin. each one has a role to play and must do so.

Sure, I understand, but the setup is as it is. The Java Application Servers take care of security. Other users in our company (company employees) are controlled via access to server (IP). Even though I had told them almost a year ago, this won't change in near future.

Even some programmers do change and/or create triggers themselves. I am not expected to force restrictions to DB2 servers myself. IMS team does that.

Still the teams work responsibly. I understand that this is not normal , thats why I explained this on this forum many times.

Thanks anyway for comment.

DBFinder

Regarding the force applications command which is what quiesce db should do:

When a force is issued for an application, db2 tries to halt it. This does not mean that db2 is able to stop the appl right away. It tries to stop the request given to the appl on the db2 side. However, from time to time, it seems that some appls can not be forced and list appl still shows that appl. It is because the force command is asynchronous and may not be effective immediately. Depending on the task the db is performing, some tasks are easily interruptable and others are not. It also may be the case that the appl was going a long time without committing, and db2 is in a state of rolling back the transaction. Please check the following technote for more info about why force appl is not always able to force the application:
IBM - Why does Force application. sometime not work ?


Issuing force appl more than once won't be of any help since db2 is already aware of this request.