AIX 32bit library limitation
- This topic has 4 replies, 2 voices, and was last updated 3 days, 13 hours ago by
.
-
Topic
-
We run CIS 6.2.6.1 on AIX 7.2 TL 5 with plans to upgrade to CIS 22 hopefully this year. We ran into an issue last week where a vendor sent a 150MB pdf that caused our thread acting as a server to crash due to a memory allocation error and throw a core dump. I couldn’t even receive the message into the interface without the process crashing. Eventually we had to ask the vendor to skip the message so anything in queue could process.
I spoke with Infor customer support and they let us know the issue is related to AIX being 32 bit and IBM has no plans to release 64bit libraries for AIX. One of the main reasons we stay with AIX is that our EMR, Epic, runs on AIX as well. The solution to this problem is this process that can receive large messages is always before starting the process is to issue the export command listed below. Then the large message can be handled in the interface engine.
export LDR_CNTRL=’MAXDATA=0x3B9ACA00‘ ; hex value of 1000MB
hcienginerun -p <process name>
We’ve ran Cloverleaf on AIX since we started using this interface engine almost 20 years ago. From what I recall AIX use to be one of the top O/S’s that clients used CIS with. From what support mentioned a lot of customers have switched over to Windows/Linux (RHEL) based O/S’s due to the fact they support 64bit libraries and these types of memory allocation issues are not present and also financially less expensive than AIX.
My question to the Clovertech community has anyone started on AIX and made the transition to a different O/S due to this 32bit issue or even from a financial aspect of switching from AIX?
-
-
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.
-
One other interesting note I was able to to use the export MAXDATA command from my first post and set the process to 1GB. I was then able to use a tcl proc in the tps inbound stack to check the message size and if greater than 50mB copy OBX-5.1 to OBX-5.5 then set OBX-2 equals to “LARGEPDF”. In the xlate I added an If clause around the OBX-5.1 to OBX-5.5 to skip the copy command. The xlate does use a pathcopy on the OBX segment which when deactivating the OBX-5.1 to OBX-5.5 copy statement still allowed the message to cross. This made me realize how much memory allocation the XPM engine requires when using a copy statement. Just to reiterate support mentioned since increasing MAXDATA above 3GB still did not allow the xlate OBX-5.1 to OBX-5.5 to work they suggested to offload the pdf locally (local disc storage) before the xlate and then add it back to the message after the xlate in the Outbound tab TPS outbound data stack.
- You must be logged in to reply to this topic.
