By ‘Jump Send’ ‘Jump Receive’ do you mean you are sending messages from one site to another with the ‘Jump Receeive’ being the site which delivers to EPIC?
So you have something like:
Site 1 | ib thread –> Jump Send thread|
Site 2 | Jump Receive thread (partner to Jump Send thread above) –> ob thread (to EPIC).
If so where are you expecting an acknwledgment you are not receiving (Jump Send in Site 1 or ob thread in Site 2)?
You have a couple (maybe more) options to track the message(s):
1. turn on SMAT (Inbound AND Outbound) for ALL threads.
2. and/or turn up the EO in the processes which the threads live and look in the log.
Personally I would use SMAT.
If using SMAT then the inbound SMAT of the IB thread will show the message received from the source system (the outbound SMAT of the same IB thread will show the ack being sent back).
The outbound SMAT of the Jump Send will show the message received from the IB thread as it is sent out of the Jump Send thread and the IB SMAT of the Jump Send thread will show any Acks received from the Jump Receive thread.
The IB SMAT from the Jump Receeive thread will show the message which originated in the source (IB thread) and jumped (via the Jump Send) to the Jump Receive. The OB SMAT of the Jump Receive will show the ack sent to the Jump Send.
The OB SMAT for the OB Thread will show the source message (as transformed if it was) going to EPIC (from the Jump Receive in this site) and the IB SMAT will show the ack received from EPIC .
If these are HL/7 mesages what should tie the messages together (if everyone plays the game properly) is the MSH-10. If the MSH-10 is not used properly then you may need to use other data (like time stamps, MRN, etc.).
So you should be able to find the original message, the ack for that message, the message being sent out of site 1 (and the ack from site 2), the message received in Site 2 as well as the ack sent to Site 1, and finally the message as sent to EPIC and the ack received from EPIC.