Unable to allocate enough memory / cannot connect

Previous topic - Next topic

Justin Derrick

This might make you laugh...

The 'Unable to allocate enough memory' error came back to haunt me this week.

After going through the configuration and limits on the main CMOD admin ID, it was revealed to me by the support team that there was a DIFFERENT ACCOUNT that the production support team was using for loading. 

The problem?  The ulimit was set too low for the user account that the production support team used to monitor (and correct) load failures.  On AIX, user limits are set in the file /etc/security/limits.  The documentation for CMOD recommends removing all limits (ie, set the value of the various flags to -1).

You can view the limits set on your current account with "ulimit -a" (to check the 'soft' limits), or "ulimit -Ha" (to check the 'hard' limits).  Soft limits can be raised to the value of the (usually higher) hard limit at the command line, but the solution should be to have your UNIX admin change the limits file.

Good luck!

-JD.
Call:  +1-866-533-7742  or  eMail:  jd@justinderrick.com
IBM CMOD Wiki:  https://CMOD.wiki/
FREE IBM CMOD Webinars:  https://CMOD.Training/
IBM CMOD Professional Services: https://CMOD.cloud

Interests: #AIX #Linux #Multiplatforms #DB2 #TSM #SP #Performance #Security #Audits #Customizing #Availability #HA #DR

Alessandro Perucchi

Quote from: pankaj.puranik on December 13, 2012, 12:16:33 PM
We are on AIX.
I had theis issue today.
And surprisingly, I got the following error when I tried loading a zero byte file.

But when I ran the same command with a file having data, it loaded fine :)

arsload: Processing file >/cna1/cfsc/SystemLogMixed/11796736_systemLogMixedIND_132-23-2345-23-45-65<
arsload: Load Version <8.5.0.5> Operating System <AIX> <6.1>
arsload: Server Version <8.5.0.5> Operating System <AIX> <6.1> Database <DB2> <09.07.0005>
arsload: 12/13/12 07:15:59 -- Loading started, --UNKNOWN-- bytes to process
Unable to allocate enough memory.  File=arslacif.c, Line=1767
Loaded 0 rows into the database
arsload: 12/13/12 07:16:04 Loading failed
arsload: Processing failed for file >/cna1/cfsc/SystemLogMixed/11796736_systemLogMixedIND_132-23-2345-23-45-65<
arsload: Processing has stopped.  The remaining files will NOT be processed.

Cheers
Pankaj.

Hello Pankaj,

Yep :-) CMOD is unable to store a zero byte file! :-) it must be at least 1 byte! :-)

Sincerely yours,
Alessandro
Alessandro Perucchi

#Install #Migrations #Conversion #Educate #Repair #Upgrade #Migrate #Enhance #Optimize #AIX #Linux #Multiplatforms #DB2 #Windows #Oracle #TSM #Tivoli #Performance #Audits #Customizing #Availability #HA #DR #JavaApi #ContentNavigator #ICN #WEBi #ODWEK #Services #PDF #AFP #XML

Ed_Arnold

On my z/OS system, I have the following temps set up:

ARS_TMP=/ars/V850/tmp
ARS_PRINT_PATH=/ars/tfs_for_ars_print

The print tmp is actually pointing to a TFS - filesystem in memory - and it works great.

I'm tempted to change ARS_TMP to also be a TFS and have it reinitialized after every IPL.

Does anybody out there ever need to save their tmp over an IPL?

Ed

#zOS #ODF

Justin Derrick

I realize this thread is over 5 years old...  But this recently bit me again, and I felt the need to re-iterate...

When your system administrators set up the CMOD user account (the one that runs arssockd) that user account should have VERY HIGH, or preferably UNLIMITED access to memory -- 25% of your server's physical RAM at a minimum, and no less than 75% of physical if your administrators insist on a limit. 
Call:  +1-866-533-7742  or  eMail:  jd@justinderrick.com
IBM CMOD Wiki:  https://CMOD.wiki/
FREE IBM CMOD Webinars:  https://CMOD.Training/
IBM CMOD Professional Services: https://CMOD.cloud

Interests: #AIX #Linux #Multiplatforms #DB2 #TSM #SP #Performance #Security #Audits #Customizing #Availability #HA #DR