MaxL Has an Order of Operations?! Who knew?

Just the other day I had a discussion with a U.S. based Sev 1 Essbase Guru and found our conversation very interesting as it pertained to the order of operations when issuing MaxL commands. The reason for my ticket was due to a runaway ESSSVR.exe process due to unknown reasons, which had been running for almost a week consuming 50% CPU and almost 5GB of RAM. Some items may be obvious to some, but clearly were not for me, so hopefully, this helps even one person. I honestly believe that the issues I was experiencing were a bug and addressed in future releases of 11.1.2.3 but anyhow, here goes.


Located within our MaxL process called 'Begin_Archive.mxl' we both log out users and kill active requests in preparation for a data export. Sounds simple enough so far, right? That is until I showed this person my code and she caught something right away. She mentioned the code below, which was the original code, was in the wrong order.

alter system kill request on application $ESS_APP; ​

alter system logout session on application $ESS_APP;

The changes made to the code were very straight forward as shown below. We flipped the first two statements and added the 'force' command to the end. We also issued a 'shell timeout '30' which is a sleep for 30 seconds to ensure the kill has time to properly complete.

alter system logout session on application $ESS_APP force;

alter system kill request on application $ESS_APP;

/************** As per Oracle SR Tech a timeout is required in order to give Essbase sufficient time to successfully kill all requests ***********************/

echo 'Sleep backup for 30 seconds to give kill command time to work';

shell timeout '30';​

This timeout has been somewhat of an elusive item for me in the past as online there are multiple ways of doing this, however, I can tell you works great. I always knew there had to be some sort of sleep integrated into the tool, for me this works best, even giving a countdown when viewed in an active command prompt window. One caveat to this, is attempting the shell timeout within EAS MaxL Editor will not work, it doesn't even recognize it as a suitable command. No warnings, no errors, nothing.


Lastly, she had mentioned that in MOST cases, MaxL will wait for its current line to complete processing, except Kill, for reasons unknown. Oracle has been complaining about this since version 7 Essbase internally and it has yet to be fixed. Therefore, the Shell Timeout is absolutely necessary in order to give Essbase the time it needs to successfully complete the task.


Since doing so it has eliminated long-running, runaway ESSSVR.exe processes and properly terminating them the first time. Hopefully, this helps somebody else out there!