When the Source (not destination) is in a TCP conversation with the Shadow there are many times when the Shadow must communicate which Journal data it needs to the Source. The common times are when a Shadow starts, resumes or retries to transmit Journal data. At these times a Shadow must tell the Source things like at what point it has got up to within the Journals and what it needs next from the Source. This means that the Source will be READing (listening) from the port (TCP connection between the two), waiting for the destination to give it a start point in the Journal. Any READ will have a timeout limit, because in most Operating Systems a TCP connection will have a "KeepAlive" setting (so the connection doesn't ever timeout) and we don't want the READ to wait forever and cause the Shadow to HANG. The timeout for these Source-to-Shadow TCP Reads is 10 seconds, so if there is no response from the Source "request" to the Shadow for information then the Shadow routine is directed to record a nothing read error (as you have seen) and will then retry this part of the conversation.

In your case the destination Shadow is taking too long to send the Journal position or another piece of information that the Source needs before it transmits any Journal data. It could be that one of the processes on the destination Shadow instance is hanging or being held up, so it can't actually hand over the start point or something like it.

Just to add another possible cause; if your sql code is working on a cursor, nested query or embedded piece of sql where the sql query is complicated and takes a long time to execute then it is possible to have the underlying cursor/query timeout and this of course will give the calling code that wants to reference that inner sql nothing to work on - NULL. This too could cause the error you are seeing, but just as Michael suggested, forwarding your query/code (with nothing confidential in) would be helpful.

We don't have HealthShare documentation on our central servers for public consumption, so you will have to look at your HealthShare instance documentation. From the HS symbol in your systray click and select Documentation and if that fails then it is likely that your documentation service has been disabled. If that is the case then please call our FRC or open a WRC case to have an advisor help you.

I think what you are looking at (for PIXPDQ) is any query or process that needs to check/cross-reference the MPI will use the Information Exchange Registry and the consent manager (part of the Registry) and will need to know the "User" (to get consent group info) or whether this is query/process will be using the "Consent Override" (no consent applied - "admin"?) or is an audit process, etc. I believe this is where the "Searchmode" is coming in. I think the HealthShare documentation on Information Exchange Registry will give you a better idea (obviously replace my "localhost:57774" with your own machine name and port) here is the link to the local docs...

https://www.localhost:57774/csp/docbook/DocBook.UI.Page.cls?KEY=HEOV_architecture

Hope this helps.

Hi

Check your recent changes to the instance configuration by comparing the "_LastGood_.cpf" with the "cache.cpf" - both can be found in your installation directory. If you can't see an obvious difference, but there is a difference in the date-time stamp for the files then use the "_LastGood_.cpf" file  to replace the "cache.cpf" file to get the instance to start.

If you have been making a lot of configuration changes recently then you may want to make a copy of the cache.cpf before trying the above.

Regards,

Steve