zombie SQLERR 349

Hi, I am checking several connections with error 349 in several instances over versions 12.10.xx and 14.10.xx, the strange thing is that sessions appear in syssessions ...!!! As the error 349 is related to missing database selection. I am trying to identify the cause. Has anyone had a similar problem? How can I identify what was at the origin of this failure? Thanks for any help, SP ------------------------------ Sergio Peres AIRC Coimbra ------------------------------ #Informix

Hi, maybe "onstat -g ses <session id>" can give you a bit more information. Most likely, this is an application or user error, basically what the error description says: It is possible to connect to a server without specifying a database. For such a connection, you will see an entry in the syssessions table or in the output of "onstat -g ses". "onstat -g ses <session id>" consequently shows that no database is established. To further figure out, what such a session did to get itself into this situation, is a bit difficult on the server side. The only thing that comes to my mind is to activate SQLTRACE to be able to see, what the session did before it received the error ... But activating SQLTRACE for everybody in a production environment may not be desirable. It may be possible to create a sysdbopen procedure for a specific database user who receives the error, and then activate the SQL tracing in that sysdbopen procedure just for that user. Check the documentation for details about the sysdbopen procedure and how to use the "set environment" statement to enable SQL tracing for a a session. Regards, Martin -- Ma rtin Fuerderer Software Engineer, Software Development HCL Technologies Ltd. Frankfurter Ring 17 80807 Munich, Germany www.hcltech.com ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.

>> How can I identify what was at the origin of this failure? You can use CLIENT_LABEL parameter to track your session. Provided you are using IDS/CSDK/JDBC version which supports CLIENT_LABEL option or set CLIENT_LABEL as environment variable and make sure your IDS version supports CLIENT_LABEL. Couple of links below for more information on CLIENT_LABEL: http://www.hcl-informix-user.com/blogs/easier-client-sessions-tracking https://www.imwuc.org/HigherLogic/System/DownloadDocumentFile.ashx?DocumentFileKey=36c408f9-f54d-88e8-c247-39c6f58e67f9&forceDialog=0 Hope this helps Thanks -Shesh ------------------------------ Sheshnarayan Agrawal ------------------------------

Trapping the error should provide you with (an af file containing) an 'onstat -g ses <sid>' output which then would show things like user client host client application current + last parsed SQL statement Here's what to do: onstat -g cfg DUMPSHMEM (shmem dumping on?) onmode -wm DUMPSHMEM=0 (temporarily turn it off, shmem not needed for this purpose) onmode -I 349 (turn on the trap) onstat -g ras (to verify the trap is on/shmem dumping off)wait until error occurs (or af file(s) got created) onmode -I (disable the trap) onmode -wm DUMPSHMEM=<orig_value> (turn shmem dumping back on, if necessary)evaluate af files mentioned in message log (look for 'onstat -g ses <sid>'; also be aware that same af file could contain multiple assertions if same db server thread incurred the assertion multiple times.) ------------------------------ Andreas Legner ------------------------------

Thanks for reply Martin, My problem is that we use the same login for all applications, the validations are done internally. Since in the cases that have appeared the SQL is different, we are having trouble identifying the source. Regards, SP ------------------------------ Sergio Peres AIRC Coimbra ------------------------------

Thanks for reply Martin, My problem is that we use the same login for all applications, the validations are done internally. Since in the cases that have appeared the SQL is different, we are having trouble identifying the source. Best Regards, SP ------------------------------ Sergio Peres AIRC Coimbra ------------------------------

Thanks for reply Shes, Concerning we use older versions of CSDK and JDBC we don't have chance to use this feature. Regards, SP ------------------------------ Sergio Peres AIRC Coimbra ------------------------------

Thanks for reply and suggestion Andreas, This can help to identify the source machine, I will test it. Best Regards, SP ------------------------------ Sergio Peres AIRC Coimbra ------------------------------