Database is not shutting down after issuing an unconditional shutdown request

Database is not shutting down after issuing an unconditional shutdown request. Database is stuck in the process of shutting down.

How to shutdown the database when the process is hanging?
Is there any way to shutdown the database if the database is hung?

When there is a hung client process that does not terminate and prevents the database from shutting down, this would also cause the BI to grow. The following Articles offer troubleshooting suggestions to avoid this situation in future:

•  Suggestions for investigating and identifying the cause of unexpected bi growth 
•  Investigating why the database takes so long to shut down  

Option 1:  Force the database to shutdown

To force a database shutdown immediately, from a different shell where the DLC and PATH are correctly set, run a new PROSHUTwith the -F option:

• The use of proshut -F starts an emergency shutdown where all processes connected to the database, including the hanging 'proshut' to be destroyed.
• The proshut -F must to be executed on the machine where the server resides and is not applicable for remote shutdowns or Dataserver shutdowns.
• For further information refer to Article  "What happens during PROSHUT -by and PROSHUT -F?" 
• Since OpenEdge 10.2B, when issuing an unconditional shutdown request, add the -shutdowntimeout parameter. For further information refer to Article:   Is there a parameter that will allow a DBA to control how long it takes to PROSHUT a database down normally?  

Option 2:  Kill the hanging client process.

1. If a PROMON session can still access the database, find the process ID of the client process and kill the process.

•  Run PROMON to find the user ID

            promon dbname > R&D >Option 1 (Status Displays) > Option 4 (Processes/Clients) > Option 1 (All Processes).

•  Run PROMON to find the PID of the User 

            promon dbname > Option 1 (User Control) > Option 2 (Match a user number)

•  Kill the Process using:

            kill -9 <PID>

Once this is done, the next time the database has started it will go through normal crash recovery, provided sufficient BI file space and AI file space (if after-imaging is enabled) are available.