OnDemand User Group
Support Forums => z/OS Server => Topic started by: lfbeach on March 24, 2016, 10:06:37 AM
-
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 ********************************
-
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.
-
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 (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
-
...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.
-
.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
-
thank you sir. Message received.