HciConnName…

This topic has 6 replies, 3 voices, and was last updated 14 years, 4 months ago by Tom Rioux.

Creator

Topic
December 12, 2011 at 6:39 pm #52845
Tom Rioux
Participant
I’m attempting to get a connection name from within a proc that is set as a pre-proc before an xlate. It returns “_xlate.

I’m assuming I would have to check the metadata some where, but since I’m attempting to get it at startup, there is no msgmetadata to get.

Any ideas on how to get this information?

Thanks…Tom
Creator

Topic

Viewing 5 reply threads

Author

Replies
- December 12, 2011 at 7:04 pm #75641
  Jim Kosloskey
  Participant
  Tom,
  
  global HciConnName
  
  echo $HciConnName
  
  email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 61 years IT – old fart.
- December 12, 2011 at 7:52 pm #75642
  Tom Rioux
  Participant
  I did that Jim, but I’m not getting the connection name. For instance, if my process name is “test”, then I’m getting the following as my connection name:
  
  test_xlate
  
  I’m assuming that since this is now in the xlate portion of the engine, that the HciConnName global is reset somehow. I would imagine that the original sending thread is out there somewhere, but not sure where or how to access it.
  
  Thanks….Tom
- December 12, 2011 at 9:45 pm #75643
  Charlie Bursell
  Participant
  That is because the thread you are in is the translate thread. I assume you want the thraed name of the input thread?
  
  set thdName [msgmetaget $mh SOURCECONN]
- December 12, 2011 at 10:00 pm #75644
  Tom Rioux
  Participant
  Charlie,
  
  I’ve tried that as well but am getting the error stating it can’t find the message handle. I guess I better explain what I’m trying to do.
  
  The proc that I have set as a pre-proc before the xlate that does connectivity via ODBC. There are things that are run at start up to connect to the database. The variables that are set there are passed globally to some call outs from an xlate. The run section just passes the message through. I have it all pretty much working like I want.
  
  However, there is error checking in place to shutdown the thread if it meets certain criteria, (ie. can’t reach the database or the replicated database). Since there may not be a message when I start up, it can’t find the message handle.
  
  Is there another way to get the SOURCECONN from within the translate thread? Or, is there a way to move that proc to the IB TPS and still have any global variable available to me when I attempt to access them in the translate thread? I’ve tested the second one and it appears the global variable value is lost.
  
  Thanks….Tom
- December 12, 2011 at 10:04 pm #75645
  Charlie Bursell
  Participant
  You cannot move it to IB and have the globals – different interpreter.
  
  I don’t understand why you don’t have access to the msg handle. Do you set it . I know it is passed to the route proc.
  
  I would say put in the USERDATA field but if you cannot access the message handle that would do no good.
- December 12, 2011 at 10:38 pm #75646
  Tom Rioux
  Participant
  If I bounce the process and no messages are queued up, then there isn’t a message handle….correct? The message handle is being set but the proc chokes on it because it can’t find the mh variable. I do have it set as a global as well.
  
  I would guess the best thing to do at this point is to pass the connection name in as a user argument.
  
  Thanks…Tom
Author

Replies

Viewing 5 reply threads

The forum ‘Cloverleaf’ is closed to new topics and replies.