MVSFORUMS.com

sarav80

Hi
The problem is CICS goes down often when number of users increases, so i want to know what are the steps to be made to make the CICS stable for more number of users.(ie. how to increase no.of users & other things)

kolusu · Posted: Thu Oct 30, 2003 2:51 pm Post subject:

sarav80,

I thought this topic answered your question

http://www.mvsforums.com/helpboards/viewtopic.php?t=1265

Kolusu

warp5 · Posted: Fri Oct 31, 2003 1:54 am Post subject:

If your CICS is now unstable it will definitely get worse the more users you have. It sounds like programs are causing storage violations that are corrupting your CICS, and that is not easy to correct or even find. You can user storage isolation to reduce the possibility of storage violations, but this will increase your CICS overhead - fair if it helps. You need to try to find out what is causing the problems and try to correct that. Give us more information why your CICS is crashing, like error codes, etc.

Mike Chantrey · Posted: Tue Nov 04, 2003 10:13 am Post subject:

Transaction isolation is quite expensive, but before considering this, have you got:
a/ reentrant program protection on (RENTPGM=PROTECT). This has very little overhead and prevents any program code with the RENT attribute being overwritten. Possible problems: programs marked RENT which modify themselves will fail - but there shouldn't be any!
b/ storage protection on (STGPROT=YES). This only has a small overhead and prevents USERKEY (application) programs overwriting CICS-related storage (CICSKEY). Possible problems: Some application programs may have a legitimate reason to update CICSKEY storage and will fail if not defined as CICSKEY. This is rare but not unknown.
c/ command protection (CMDPROT=YES). This only has a small overhead and causes CICS to check addresses passed by application code to CICS commands before writing to them.

These 3 options together only add a few% cpu to the region. Unless your machine/LPAR is having capacity problems, I would have these on in all regions. We do this and region crashes are rare. If your storage overwrites are trapped by any of these methods they will be easy to diagnose since you can get a dump at the exact point of the overwrite.

If this doesn't work, then consider transaction isolation - this does have a more significant overhead but you could switch it on only at selected times/days and on particular transactions.

taltyman · Posted: Tue Nov 04, 2003 11:06 am Post subject:

Hi Mike I tried your....

READY
DELETE 'SYS1.PARMLIB' SCRATCH
ENTRY (A) SYS1.PARMLIB DELETED
READY
LOGOFF

But our parmlib is SYS1.IPLPARM
Should I change parmlib to iplparm Mr. Green

Mike Chantrey · Posted: Wed Nov 12, 2003 11:19 am Post subject:

yes - and make sure your TSO ID has the necessary RACF access...

taltyman · Posted: Wed Nov 12, 2003 12:07 pm Post subject:

Oh, the humor of it all.....
thanks Very Happy

Mike

warp5 · Posted: Thu Nov 13, 2003 2:13 am Post subject:

What ever happened to sarav80? Question

I wonder if he ever read this thread? Rolling Eyes

Mike Chantrey · Posted: Wed Nov 19, 2003 10:56 am Post subject:

He's probably fallen into the 'bit bucket'...