ODF/OAM - error when high volume - ARS0131E ZCMOD01P No logical place t

Previous topic - Next topic

J9CMOD

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

Ed_Arnold

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

Ed
#zOS #ODF

J9CMOD

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.

Ed_Arnold

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
#zOS #ODF

Ed_Arnold

Just to satisfy my curiosity, could you run this batch job which displays how much private area the userid has available to it?

Quote
//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:

Quote
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

#zOS #ODF

J9CMOD

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.

J9CMOD

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

Ed_Arnold

Quote from: J9CMOD on November 08, 2017, 11:42:56 PM
...

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
#zOS #ODF

J9CMOD

Thanks Ed,
We still get that error, and I don't see any upgrades in our near future.  Thanks for the info!

Ed_Arnold

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

Ed
#zOS #ODF

Ed_Arnold

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

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
#zOS #ODF