@jeff-dawson
Forum Replies Created
-
Hi David,
We are on CIS 2022.09.03 and I had opened a ticket with Infor regarding this as well
Update from Infor unfortuantely no date of resolution for this so depending on where the tcl proc is created you would need to do the following:
- Tcl proc created from script editor, after saving proc NetConfig would have be closed and reopened.
- Tcl proc created from Text editor, after saving proc and running mktclindex entire IDE (CIS GUI) would have be closed and reopened for new tcl proc to be available.
“CISCL-10409 created for tracking fix for this to be added in a future patch. I have heard back from development. This had been reported to development already and what we call a product Jira to track correcting and will be in a future patch. To see if this specific problem is in a specific patch search for CISCL-10409. I do not have a date for when it will be patched at this time.”
Pretty frustrating the hoops you have to now jump through just to get release notes and changes for new versions. It use to be released with the new versions in the download center now it’s placed in some excel spreadsheet with a bunch of other stuff that you have to search for the version CIS version number for any hits as a KB I think. No clue why Infor would think this is a better way of handling this for their customers. If anyone has issues finding this information I would suggest opening a ticket with Infor support.
Hi Jeff,
We came across a similar issue regarding read timeout errors on a few of our inbound threads due to message size of base64 encoded pdf’s, we ended up having to adjust the timeout setting to higher value besides the default of 30. This might be something to adjust on your side and see if it helps, for some of our systems we upped this to 300. We also came across another issue where the HL7 message was just to large in general to receive but Infor support confirmed this is an AIX problem only apparently.
Hi Tim ,
We are running the same version of AIX, 7.2, talking with our AIX admins they are stating the same thing that AIX appears to be 64bit enabled yet hciengine is only 32bit. I’ve taken this back to Infor support and they are asking the developers about this. I’m hoping at some point CIS will be able to run at 64bit however it was explained to me the limitation is on the AIX which doesn’t seem to be the case with the what I’m finding out however there may be other factors involved that Infor’s developers may clarify regarding AIX. Will post what I find out and I also attached the document that Infor provided regarding this issue.
You could echo variable backupCmd out the contents of the command like the .help but if you wanted to trap an error there’s a few ways this could be accomplished with the tcl catch command.
set rc [catch {set backupCmd [exec sqlite $dbFile < $batchFileName]} error]
echo “rc $rc”
echo “error $error”I updated the spelling of the dot command so it would fail:
rc 1
error Error: unknown command or invalid arguments: “b”. Enter “.help” for helpThen updated the backup command and ran it successfully:
rc 0
errorAnother way would be to wrap the catch with an If statement and forgo the set rc (return code) command.
Hi Jim,
I’ve done something like this in the past to issue the sqlite dot commands via tcl. There may be an easier way but I know this does work.
#!/usr/bin/env tcl
global hciRoot
global hciSite
global siteDirset hciRoot $env(HCIROOT)
set hciSite $env(HCISITE)
set siteDir $env(HCISITEDIR)set dbFile “$hciRoot/sqlLiteDbs/ADT/EpicADT.db”
# create batch file of commands to backup sqlite db
set batchFileName “$hciRoot/sqlLiteDbs/ADT/EpicADTbatch.txt”
set batchFile [open $batchFileName w]
#puts $batchFile “.backup TEST.db”
#puts $batchFile “.help”
puts $batchFile “.backup TEST.db”
close $batchFile
set backupCmd [exec sqlite $dbFile < $batchFileName]Hi Jim and Levy,
I had tried this out on CIS 6.2.6.1 and had some issues testing out some of the debugging features when I came across iterating issues. We had planned on upgrading to CIS 20.1.2.0 but came across some issues and its been pushed back in our project queue. Below are some of the notes from the issue I reported and hopefully it’s been fixed with this newest version.
Hello, We are running CIS 6.2.61 on AIX 7.2 TL2. When I run a route test on this orders xlate everything works correctly nothing in the log or testing tool outputs any issues with the groupings I have for the IN1, IN2, IN3 group or the ORC, OBR, OBX grouping but when i run xlate debugger when it gets to the IN1 and OBR Groups it throws a can’t resolve address error. The address same when i output from the source side of the variant. I’m attaching a few screen shots in Test of the error and of the xlate. I also just tried this on our CIS 20.1.1.1 on AIX and the xlate debugger throws the same error.
Resolution:
Issue: Xlate debugger error Steps Taken: Test in-house the xlate box provided. No errors were fund when running route/ hl7 test, translations were correct but still shows the same errors out during debug mode on segments IN1 and ORC Resolution: Consult with r&d. They were able to reproduce it, if set breakpoint to the address that contains variable, xlate debugger throws this error. This issue is only for xlate debugger, it will not influence the route test and xlate test. The reason is that hcixlttest tcp server send cmdMsg “WAIT{ACTION BKPT} {ACNAME PATHCOPY} {INDEX 18} ” to the GUI and the GUI respond “cmdStr=LIST 1(0).1(0).1(0).0(%g3).IN1(0)”, due to cmdStr is not NULL, the xlate debugger does xpmDbgShowValue, but there is no replacement of variable %g3, so when resolve the address the error is reported. Fix will be scheduled for 20.1.2.0
Was going to add we do something similar that Robert mentioned where we have a master site and within there use a global variable to delclare Test or Prod, see attached screen shot.
If you need to call this from an xlate
Source side: =$$GLOBAL_MSH_11 Output side: 0(0).MSH(0).#11(0).[0]
If you need to call this from a tcl proc
set envrionment TEST
set server [gvgetvar GLOBAL_MSH_11]
if {$server == “P”} {
set envrionment PROD
}As mentioned above we’ve also used exec and info hostname via tcl
set srvr [string toupper [string range [exec hostname] 6 9]]
set hostName [info hostname]
Since we run AIX we have also used hostname for KSH
myhost=<code>$(hostname)</code>
