@jeff-dawson
Forum Replies Created
-
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>
Infor released Patch CIS 20.1.2.0 last week and we went ahead and installed this patch as it looked like it had quite a few fixes in it. The first thing I tested was switching our PDF connections back from the protocol pdl to the internal protocol:tcpip with a timeout of 30 seconds (default) and from this short testing it looks like everything was working correctly once again. No messages were timing out and hanging in recovery and performance time from site to site communication and internal site communication was looking good while trying out a a few different sizes of pdf’s around 11mb.
After this bit of testing we were going to continue testing the new CIS 20.1 version with some message volume. I started the engine using the perl auto start scripts located under $HCIROOT/auto-start and about three quarters of the way through the script started getting forking and swap space errors to the point the entire system locked up having to hard boot the system. We are running brand new IBM Power 9 servers with 96GB of physical memory and 6GB of swap space. Up to this point we have been testing CIS 20.1.1.3 without running in to any memory constraints, these start/stop scripts had been ran numerous times without any issue while on CIS 20.1.1.3. I uninstalled the 20.1.2.0 patch and reran the engine start scripts without any issue just to have a base line, we never ran out of physical memory during this process.
Our AIX admins increased swap space from 6GB to 32GB, I then reinstalled CIS 20.2.1.0 and reran the engine start script which completed but noticed all physical memory was used and up to 55% of Swap was used even after the start was complete. Comparing hci process PID’s pulling a top 15 list in memory size everything appears to be consuming one quarter more of memory and it seems there is some major memory consumption issue going on with this Patch.
While typing this update I heard back from Infor
“R&D states that they are working on what may be a related issue where the intsaller problem was reported, according to the installer log, we suspected that installer might not fulfill the patch installation of Cloverleaf 21.1.2.0.
That may introduce the memory problem reported in this case. Please hold on the taste of 20.1.2.0 AIX, use 20.1.1.3 instead now”As of right now I’m not for sure what direction we are going to take, one thing I noticed with 20.1.1.3 is the GUI just seemed sluggish to me, i.e. from opening the testing tool to other various screens we use on a day to day basis. From the limited time we had on 20.1.2.0 it was feeling like some of those minimal load times were getting better.
Jeff
