OnDemand User Group
Support Forums => Other => Topic started by: J9CMOD on November 01, 2017, 08:22:34 AM
-
We randomly get the error ARS0131E ZCMOD01P No logical place to retrieve object during distributions. Normally, CMOD appears to correct itself and distribute correctly. However, we recently had over 4000 of those errors during one nightly cycle, and the output was never distributed.
We researched and it appears that an incorrect, or empty, Storage Set is being set to OAM. Since we have all of our Storage Sets correctly set up, we don't know what causes this.
Has anybody encountered and fixed this issue?
Is there a default "backup" storage set we should have set in one of our parms that we don't know about?
Any assistance would be greatly appreciated.
Thanks,
Janine
-
Perhaps the OAM threads are all busy.
Please look at the ARS_NUM_OAMSRVR= parameter in the /usr/lpp/ars/config/ars.cfg.
What do you have that value set to?
https://www.ibm.com/support/knowledgecenter/en/SSQHWE_9.5.0/com.ibm.ondemand.configuringzos.doc/dodzc276.htm (https://www.ibm.com/support/knowledgecenter/en/SSQHWE_9.5.0/com.ibm.ondemand.configuringzos.doc/dodzc276.htm)
Ed
-
It's set to 30. I can talk to our OAM Team to see if we can make it higher, if you think that will help. That number came from our Health Check, but we've grown since then in our CMOD usage.
-
Hmmm - without looking I think 30 is the max.
Also, without looking, I seem to recall that one particularly busy shop had a zap to increase that number.
When things are quite busy, what does the output of...
F arssockd,D,OAM
...look like?
Ed
-
Just to satisfy my curiosity, could you run this batch job which displays how much private area the userid has available to it?
//ULIMIT JOB blah-blah-blah
// blah-blah-blah,REGION=0M,USER=ARSSERV3
//STEP1 EXEC PGM=BPXBATCH,REGION=0M
//*
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//STDOUT DD SYSOUT=*
//STDPARM DD *
PGM /bin/ulimit -a
/*
where the USER= parm on the JOB card is the same user as the arssockd started task runs under
STDOUT will look like this:
core file unlimited
cpu time 86375
data size unlimited
file size unlimited
stack size unlimited
file descriptors 64000
address space 1865704k
memory above bar 17592186040320m
What's important is the address space value.
Don't think that my address space value is representative of the real world. It's a test system that runs multiple CMODs and not much else.
Ed
-
I set up the job to run, but it has to be run by our ETS department, I'll let you know about the results.
-
Ed,
Here's the info from my ETS resource:
The ARS address spaces have 1.54G private area
, the OMVS segment for ARSSERVR already says ASSIZEMAX= 2147483647, which can’t raise that 1.5 number but at least he can see it isn’t lowering it.
Does that answer your questions/curiosity?
Thanks,
J9
-
...
Does that answer your questions/curiosity?
Thanks,
J9
Yes and apologies for not seeing this sooner.
CMOD V10.1 exploits 64 bit addressing.
I'm hoping you'll make the jump soon?
Ed
-
Thanks Ed,
We still get that error, and I don't see any upgrades in our near future. Thanks for the info!
-
Thinking about this some more.
I'm not saying this will fix the problem but as my nephew the veterinarian says, "Couldn't hurt, might help."
How To Tune HEAP Storage for Content Manager OnDemand ODF
http://www-01.ibm.com/support/docview.wss?uid=swg21986861 (http://www-01.ibm.com/support/docview.wss?uid=swg21986861)
Ed
-
Discussed this with a colleague.
No guarantee, just a guess.
Could you do a SELECT or display of the ARSNODE table?
Within the ARSNODE table is a NAME field:
https://www.ibm.com/support/knowledgecenter/SSEPCD_10.1.0/com.ibm.ondemand.administeringmp.doc/dodsc020.htm (https://www.ibm.com/support/knowledgecenter/SSEPCD_10.1.0/com.ibm.ondemand.administeringmp.doc/dodsc020.htm)
For OAM collection names only:
If you do a HEX display of that name field, is the character immediately following the name of an OAM collection anything other than x'40' (blank)? For example some other character which doesn't display anything?
I don't care about cache only records, only OAM collection names.
Ed