CMOD OBJECT SIZE ERRORS when loading documents

[lfbeach]

Why do we get these unable to store object errors when loading CMOD using the Generic Indexer method?
Our response to these has been to 'tweek' the OBJECT SIZE in the application group until we can get the batch to load.  Is there a better way to handle these (or better yet to prevent these abends)?

SDSF OUTPUT DISPLAY CS98JABD JOB63866  DSID   167 LINE 1       COLUMNS 02- 81 
COMMAND INPUT ===>                                                  SCROLL ===>    CSR 
arsload: Using /u/arssp/tmp1 for temporary files                               
arsload: Processing file >/u/arssp/tmp1/cs98jabd<                               
arsload: Load Version <8.5.0.8> Operating System <z/OS> <04.24.00>             
arsload: Server Version <8.5.0.8> Operating System <z/OS> <04.24.00> Database <D
arsload: 03/24/16 12:59:56 -- Loading started, 560308704 bytes to process       
OnDemand Load Id = >55662-2682-0-380FAA-16885-16885<                           
An error occurred.  Contact your system administrator and/or consult the System
Unable to store the object >380FAAK<.  Object size 66199666                     
The last row successfully loaded was 913                                       
Loaded 913 rows into the database                                               
arsload: 03/24/16 13:00:34 Loading failed                                       
arsload: Processing failed for file >/u/arssp/tmp1/cs98jabd<                   
arsload: 03/24/16 13:00:34 -- Unloading started                                 
OnDemand UnLoad Successful - LoadId(55662-2682-0-380FAA-16885-16885) Rows Delete
03/24/16 13:00:37 -- Unloading of data was successful                           
arsload: Processing has stopped.  The remaining files will NOT be processed.   
******************************** BOTTOM OF DATA ********************************

[Justin Derrick]

I wrote this article for a different error on Multiplatforms, but it might be helpful for you if you're tweaking object sizes:

https://cmod.wiki/index.php/ARS0141E

But really, this seems like it might be a failure at the storage level -- it sounds like it couldn't write the file, but it doesn't say why.  Check the OS / console / storage manager (TSM/OAM/etc.) logs for related errors at the same time you were loading.

[Ed_Arnold]

Hi Lori -

> Unable to store the object >380FAAK<.  Object size 66199666

That's 66,199,666 or 66 meg.

In OAM, there's a parm called MOS - Maximum Object Size.

The default is 50 meg.

I wrote an article that talks about this in the CMOD 1Q2013 newsletter:

http://www-01.ibm.com/support/docview.wss?uid=swg27038204

To see what the current setting is for MOS in OAM issue the following operator command:

f oam,d,oam

This is down at the bottom from my system:

CBROAM:                                 
OAM1 Parms: TIME=GMT  MSG=EM  UPD=N  QB=Y
            MOS= 256  OTIS=N  LOB=N  DP=N

I'll bet yours is still at 50 meg, the default.

You change that value in the IEFSSNxx parmlib.

Lots of customers have increased that value from 50...very common.

Ed

[lfbeach]

...and just one more clarification on this....there is actually not a SINGLE DOCUMENT that exceeds the 50MB limit in our file.    So apparently when we change our APPLICATION GROUP OBJECT SIZE it changes the way the documents are batched together and loaded to OAM.
Does this change your responses at all?  I am forwarding this info to tec support, but wanted to be sure I gave you all the information.

[Ed_Arnold]

.there is actually not a SINGLE DOCUMENT that exceeds the 50MB limit in our file.    So apparently when we change our APPLICATION GROUP OBJECT SIZE it changes the way the documents are batched together and loaded to OAM.

Exactly right.  That's what my article in the quarterly newsletter that I referenced says.

Does this change your responses at all?

Not a bit.

Ed

[lfbeach]

thank you sir.  Message received.