region recycle

Hi,

How often the regions should be recycled? Is it a weekly/monthly etc.  Is there a script like JCL, Powershell to automate the same.

Hi Mike,

For stop/start region, Whats the difference between using /r and /l switches in the castop command. Which is the best pratice?

casstop /rregionname /uuserid /ppassword

casstop /lregionname /uuserid /ppassword

The /r (or -r) option to casstop and similar CAS command-line options tells casstop to connect directly to CAS shared memory. It avoids network communication but requires that:

• The user executing casstop must have permission to open and write to CAS shared memory.
• The region is running on the same system where the casstop command is executed.
• On Windows, I believe the casstop command must be executed from the same session as the region is running in. (It's possible CAS uses a global object for its shared memory and this is not required.)

The /l and /s (or -l / -s) options tell casstop to make the shutdown request over the network. That means permission to access shared memory is not required, and the region may be running remotely.

With /s, you give casstop the protocol, hostname, and port of the listener to send the shutdown request to. This is the same listener as is used for ESMAC, typically the "Web Services and J2EE" listener for the region.

With /l, you tell casstop to search the MFDS directory for the region, and send the stop request to the listener associated with that region's "MF ES" service. The /l option is equivalent to /s except that you do not need to know the listener's hostname and port.

Best practice depends on your environment and needs. For interactive users on the same system as the region, /r will often work, and if it doesn't, the user can try again with /l. Scripted solutions may prefer to use /l so they are less sensitive to changes in where regions are located or how they are started.

The casstop documentation is available at:
https://www.microfocus.com/documentation/enterprise-developer/ed50/ED-VS2017/HRADRHCOMM02.html

Hi Mike,

In case the region is in not responding state then whether we need to provide casstop & then casstart or directly casstart command will work.

Because in one of our test environment online region goes to not responding state. then i provide casstart command:

casstart /r

CASCD0167I ES Daemon successfully auto-started 22:55:58
CASCD0050I ES "TST3-ONL" initiation is starting 22:55:58

If the region is running, you must stop it before starting it again, or startup will fail. In that case casstart might initially appear to work but eventually the region will report that it is already running, and it will not be restarted.

It's always safe to attempt casstop if you need to restart the region, so there's no reason to omit it. If you have reason to believe the region is in an error state, you can do a forced stop with "casstop -f" and then restart it once all region processes have exited.

The "non-responding" state is not a reliable indicator of region health. It only means that MFDS was unable to get a response from MFCS (the communications server component) before the configured timeout. Often this is because the timeout is too short; the default of 5 seconds is much too short for many reasonable configurations. The timeout can be caused by heavy load or network congestion. If you intend to leave the MFDS monitor feature enabled in production, I strongly recommend increasing the timeout to something more reasonable, perhaps 30 seconds.

Also, because the MFDS monitor feature only probes the communications server, it tells you nothing about the health of CAS (the application server component), and in particular about available SEPs, the state of CICS processing, running jobs, initiators, etc. Better mechanisms for polling region health include monitoring HSF statistics, using utilities such as casfile and casout, invoking a deployed COBOL web service or CICS Web Interface server, running a simple job, and so on - anything that tests both communications and application server.

If the region is running, you must stop it before starting it again, or startup will fail. In that case casstart might initially appear to work but eventually the region will report that it is already running, and it will not be restarted.

It's always safe to attempt casstop if you need to restart the region, so there's no reason to omit it. If you have reason to believe the region is in an error state, you can do a forced stop with "casstop -f" and then restart it once all region processes have exited.

The "non-responding" state is not a reliable indicator of region health. It only means that MFDS was unable to get a response from MFCS (the communications server component) before the configured timeout. Often this is because the timeout is too short; the default of 5 seconds is much too short for many reasonable configurations. The timeout can be caused by heavy load or network congestion. If you intend to leave the MFDS monitor feature enabled in production, I strongly recommend increasing the timeout to something more reasonable, perhaps 30 seconds.

Also, because the MFDS monitor feature only probes the communications server, it tells you nothing about the health of CAS (the application server component), and in particular about available SEPs, the state of CICS processing, running jobs, initiators, etc. Better mechanisms for polling region health include monitoring HSF statistics, using utilities such as casfile and casout, invoking a deployed COBOL web service or CICS Web Interface server, running a simple job, and so on - anything that tests both communications and application server.