Hello Rajath,

In addition to what John said, it is always advisable to check the value of SQLCODE after running an embedded SQL statement. This will tell you if the SQL statement executed successfully, or encountered an error. If it encountered an error, you can get more details from the %msg variable. See the documentation here:


You said that you are getting a JavaScript error. What is the error message? Can you send the JavaScript code you are using to call the retrieveDetail() function?

Hello Laura,

The CSP.Daemon will use the CSP Event classes (there can be more than one) associated with the session (this information is stored in the ^%cspSession global). It will default to the value of the Event Class setting in the CSP Application, but, as you know, it can also be set programmatically. 

/isc/studio/usertemplates/ is a CSP Application used by Studio to display certain dialogs. I don't believe we take a license for these sessions, but they should still time out. 

It looks like the CSP.Daemon is failing to end these sessions. This investigation might get a fairly involved. I definitely recommend contacting the WRC with the information mentioned above. 

Hello Laura,

If the user logs out with CacheLogout=end, or %session.EndSession=1, the session will end OnEndSession callback will be called and the session will be terminated immediately, and the license will be released. This will be done in the CSP server process, not the CSP.Daemon.

If the user closes the window (or just walks away from the computer), the session and the license will remain until the session timeout is reached. This is done by the the CSP.Daemon, which will periodically wake up and look for sessions that have expired, and end them. Setting EndSession=0 in the callback would prevent the session from being ended. As long as this has been removed, I agree, the CSP.Daemon should be cleaning these sessions up. 

Are you able to end any of these sessions through the Management Portal page? (I'm not recommending deleting all of them, this is just a diagnostic test). 

If you open a WRC Case, I recommend sending:

1) a Buttons report

2) an export of the Session Events class (just in case)

3) an export of the ^%cspSession global:

do $system.OBJ.Export("%cspSession.gbl","/tmp/cspSession.xml")

The CSP.Daemon should close any session with a timeout in the past. Do you have CSP Events class? In my experience, the most common cause of problems like this is a misbehaving OnTimeout or OnEndSession callback, but there could be other causes. 

If there isn't anything obviously wrong with the callback code, I suggest you open a WRC case to investigate this. 


Sean Klingensmith

Hello Laura,

Do you see any CSP Sessions active under [System Operation]->[CSP Sessions]? The CSP.Daemon will end any sessions (and release the associated license) after the session times out. The timeout for each session will be displayed on this page. You can also manually end sessions. 

If the license is remaining after the CSP Session is ended, or if the session remains after it is supposed to be timed out this would indicate a problem with the session reclamation. Otherwise, it could be an issue with an excessively long session timeout (this can be configured in the CSP Application).