Forum Replies Created
-
AuthorReplies
-
I need to add OBR segments to an ORU message also. I have made the suggested changes from this post and the OBX segment now looks like an OBR segment. But don’t I need to change the segment identifier from OBX to OBR? If so, how do I do that?
Thank you in advance for any help you can give me!
Alise Blankenship
Interface Programmer/Analyst
Tricore Reference Laboratories
Hi Jim, I did try that and had some trouble with it. It would only complete one of the translates. Not all of them. Also, there is some tcl on the inbound tab of the inbound thread that I tried to move without success. I probably need to re-write the tcl proc and put it in the Xlates.
I have not had a lot of experience with this situation. I have a server that has multiple sites feeding directly into it. Our company has decided not to pay the vendor of that system to do the translations since we have Cloverleaf. So I will be doing the transactions both out of the thread for that server and back into it for the outbound results of these clients.
They all have different needs for the format of the trasactions coming out of the thread but the transactions are all going to the same destination after they are translated by Cloverleaf. I know for a fact that this inbound thread will be getting more clients feeding it and the translations are going to get more and more complicated.
I will try your suggestion again. It may be that I just didn’t spend enough time exploring that option. If I still have problems, I think I have figure out how to handle them by putting these translations in a site of their own. If I have addtional problems, I will let you know.
Thank you, Jim.
It was great hearing from you.
Alise
Hi Russ, We are running Cloverleaf v5.5 on AIX 5L v5.3. We have a dedicated IBM server set up to the recommended specs received from Quovadx in 2007.
By the way, this is happening in Cloverleaf, not on the receiving system. We have TCP iptrace logs running on the Cloverleaf engine and they are showing us the problem is on the Cloverleaf side. It does happen mainly during peak performance periods, so we do believe is has to do with volume. But we can’t tell why it is happening. What appears to be happening is that a message that has multiple packets will have a separate packet ID for each packet with a single message ID assigned to all packets associated with a message and used for acking the message. When a new message is merged with a packet from the previous message, it receives the same message ID as the previous message. So when the receiving system finally receives all the packets (from both messages), it acks the message based on the message ID assigned and Cloverleaf never recieves an ACK for the second message because it has the same message ID as the first message. I know this sounds confusing but I don’t know how else to explain what we are seeing.
Please let me know if you have any suggestions. I have a call into support but they are just as stumped as I am.
Thanks.
Alise
Hi Russ, Case 2 is what we are seeing.
Alise
Posted: Wed Jul 18, 2007 6:23 pm Post subject:
Richard,
It would be great if you could give us some pointers that might make the process go smoother. Please let me know when you might be able to talk to us. Thank you Richard.
Alise
************************
Richard wrote:
Alise.
Last year we migrated our 70 production sites from (AIX 4.3.3) CL 3.5.5 to (AIX 5.3) CL 5.4.1.
I’m happy to provide details/scripts that we used.
_________________
Richard Hart
Application Interfaces
InfoHEALTH Alliance
Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of another party.
That worked Greg. Thank you. Alise
Ok, here’s another clue. When does the vista.taf file get created in the databases directory? Because there isn’t one being created for the test environment. Hmmm… 🙄 It appears that the hcimonitord is not exactly hung. It’s just reponding so slowly that hcicmd times out before it can complete the request. The request can be as simple as a hciprocstatus. There is nothing running on the server that I have moved the test environments to. Any ideas what this might be? 😕 Thanks again.
OK, let’s try a different approach. Anyone who is running Tru64 Unix, would you please email me with whether or not you use a cluster environment and if you do, what is your cluster software? Thank you.
Alise Blankenship
Hi David, We do this for A44s changed to A35s. I am including an attachment of the tcl code we use. Try this.
Good Luck.
######################################################################
# Name: Cloverleaf Template
# Purpose:
# UPoC type: tps
# Args: tps keyedlist containing the following keys:
# MODE run mode (“start”, “run” or “time”)
# MSGID message handle
# ARGS user-supplied arguments:
#
#
# Returns: tps disposition list:
#
#
proc A44_to_A35 { args } {
keylget args MODE mode ;# Fetch mode
set dispList {} ;# Nothing to return
switch -exact — $mode {
start {
# Perform special init functions
# N.B.: there may or may not be a MSGID key in args
}
run {
# ‘run’ mode always has a MSGID; fetch and process it
keylget args MSGID mh
set msg [msgget $mh]
set addMsg [msgcreate -class engine -type data -recover]
set splitMsg [split $msg r]
set msgTest [lindex [split [lindex [split [lindex $splitMsg [lsearch
-glob $splitMsg “MSH|*”]] |] 8] ^] 1]
if {$msgTest == “A44”} {
set test [lindex [split [lindex $splitMsg [lsearch -glob $splitMsg
“PV1|*”]] |] 2]
foreach seg $splitMsg {
set splitSeg [split $seg |]
set segID [string range $seg 0 2]
switch -exact $segID {
MSH { regsub -all A44 $seg A35 newSeg
regsub -all A44 $seg $type addSeg
append mergeMsg $newSeg[format %c 13]
append adtMsg $addSeg[format %c 13]
}
EVN { regsub -all A44 $seg A35 newSeg
regsub -all A44 $seg $type addSeg
append mergeMsg $newSeg[format %c 13]
append adtMsg $addSeg[format %c 13]
}
PID { append mergeMsg $seg[format %c 13]
append adtMsg $seg[format %c 13]
}
PV1 { append mergeMsg $seg[format %c 13]
append adtMsg $seg[format %c 13]
}
DG1 { append mergeMsg $seg[format %c 13]
append adtMsg $seg[format %c 13]
}
MRG { append mergeMsg $seg[format %c 13]
}
}
}
set mergeMsg [string trimright $mergeMsg r]
set adtMsg [string trimright $adtMsg r]
# set fullMsg $adtMsgn$mergeMsgn
msgset $mh $adtMsg
msgset $addMsg $mergeMsg
lappend dispList “CONTINUE $mh”
lappend dispList “CONTINUE $addMsg”
} else { lappend dispList “CONTINUE $mh” }
}
time {
# Timer-based processing
# N.B.: there may or may not be a MSGID key in args
}
default {
error “Unknown mode ‘$mode’ in blank”
}
}
return $dispList
}
Thank you Terry! This is exactly what we need. Alise
-
AuthorReplies