Why I created a blog

Its been four years since I first created this blog. It has remained true to Essbase and related information over those years. Hopefully it has answered questions and given you insight over those years. I will continue to provide my observations and comments on the ever changing world of EPM. Don't be surprised if the scope of the blog changes and brings in other Hyperion topics.

Tuesday, May 30, 2017

New old settings (and graceful stopping applications)

I am not immune to plagiarizing sharing information I have gotten. In this case, I received a private message from one of the top support people for Essbase Carol Crider. She actually said I could/should share this to make the information more well known.  See I really do give credit where credit is due.
Thanks Carol.

"We have a OLD setting with a NEW feature and the documentation is a bit lacking in clarity. The setting is:


 This used to be ONLY UNIX, now it ALL operating systems.  It provides a lot more detail to support and development on the cause of a crash. Before you had the XCP and the stack it provided. A crash dump on Windows gives a mini dump of memory. For lack of a better term they are calling the Windows mini dump a core file.

 Also another change that was undocumented is the unload of applications. We are seeing several SR's because we get unable to unload application xyz while user GLENN is running a transaction... (editor note - Wait, How did I get in her description. I swear I didn't run anything)

 Here is a definition provided by development: ++++++ * Some operations cannot be stopped a lot of time even if user killing appropriated session or it just stuck. As workaround, you can unload the application to kill all running sessions. To avoid a situation when user cannot unload an application because of such "stuck" sessions - Essbase developed recently ( an  internal mechanism that soft kill Essbase application process (ESSSVR) when "alter system unload application" command is received, but some session on the application cannot be stopped. Essbase waits 3-5 minutes before soft kill the application. When this mechanism is activated - the following should appear in <app>.log file: 
RECEIVED SHUTDOWN COMMAND - SERVER TERMINATING ... At least one request is still active; a core file may be generated for diagnostic purposes, if core file generation is enabled ... Exception error log [<APP>/log000xx.xcp] is being created... A core file may get generated in [<APP>/ESSSVR.Fri_Oct_xx_xx_xx_xx_xxxx] Exception error log completed <APP>/log000xx.xcp please contact technical support and provide them with this file RECEIVED ABNORMAL SHUTDOWN COMMAND - APPLICATION TERMINATING  "

So there you have it. upgrade or patch to (or higher) and you get the soft kill. You also get better diagnostics. Thanks again Carol for sharing.   

No comments: