Multiple ARSOCK instances accessing the same DB2 databases and OAM

[jfunk]

Good day,
My firm has utilizes multiple z/OS ARSLOAD entry points as well as multiple ODWEK 'document retrieval' users.  During heavy load times, which may occur during prime document retrieval hours, the ARSLOAD points of entry 'takeover' the ARSOCK* z/OS DB2 threads limiting ODWEK user accessibility.  This is due to the ARSLOAD z/OS concurrency when several started task and batch jobs execute simultaneously.  Because of this, I am looking at ways to limit this ‘takeover’.

Please advise, if it is possible, by creating a separate ARSLOAD* instance, with its own ars config, utilizing the same DB2 databases, cache, and system log, to have separately identified ARSOCK* and OAM* DB2 threads.  Then ‘point the ARSLOAD z/OS processes to the new instance allowing the ARSLOAD loads to be isolated and managed via its ARSOCK instance.  Thank you.

[Ed_Arnold]

Let me see if I have this straight and let me simplify.

One CMOD instance [ARCHIVE]

Two ARSSOCKD's ... running at a different priority.  One has high priority and end users are pointed to that.  The other, lower priority ARSSOCKD, handles loads and other batch functions.

Go out to the IBM Redbook site and search on Content Manager OnDemand, look for the high availability pub. 

I'm sure there will be more questions, but that should get you started.

Note 1: whether the ARSSOCKD's run on the same LPAR or a different LPAR, it's conceptually the same problem.

Note 2: CMOD does not exploit SYSPLEX - nothing in the coupling facility.  It works in a SYSPLEX environment, but do not run two different code levels on the different ARSSOCKDs for example.

Ed

[jfunk]

Good day,

Thank you.  I just realized since the company utilizes OAM and not the cache, ars.cache is a bit superfluous to our system.  I already knew about building multiple ARSSOCKD started tasks and port access.  The cache tripped me up.  The design I was thinking about requires another step limiting one time full extracts.

Jeff

[jfunk]

Good day,

I do have one question concerning the ARSSOCKD started task start up.  Buried within OnDemand single instance documentation, a thread here, and the Content Manager OnDemand Guide are three different PARM= cards for the PGM=ARSSOCKD statement.  This identifies the instance within the ars.ini file, in the example below assume ARSINT1 is defined in ARS.INI.  Please assist in identifying which is correct.  Thank you.
1.  //STEP1  PGM=ARSSOCKD,PARM='/ARSINST1'
2.  //STEP1  PGM=ARSSOCKD,PARM='/ -I ARSINST1'
3.  //STEP1  PGM=ARSSOCKD,PARM='ARSINST1'

The rest I have pretty well understood.  It is just that this is somewhat documented within the multiplatform and not the z/OS world.  Thank you.

[Ed_Arnold]

Jeff - you absolutely, positively want to use the format in the latest append in this thread:

http://www.odusergroup.org/forums/index.php?topic=762.0

Not only is it clean and easily understandable

-S = start
-I  = instance name
-v  = verbose

But the verbose command is extremely helpful in understanding exactly what parms are in effect...and it costs nothing in performance.

Ed

[jfunk]

Good day,

Thank you.  The system was set up here without any ARSSOCKD parms whatsoever.  This assist in remediating this.