Because various configurations are possible with CICS®, different areas of the startup may require
attention, as follows:
- Start by defining your GCD, LCD, CSD, temporary storage data sets, or
transient data intrapartition data sets, as shown in the CICS System Definition Guide.
- When defining your terminals, pay attention to the position of group names
within the GRPLIST. If the group containing the TYPETERMs is last, all the
storage used for building the terminal definitions is held until the TYPETERMs
are known and this could cause your system to go short-on-storage.
Groups
in the GRPLIST in the SIT are processed sequentially. Place the groups containing
the model TERMINAL definitions followed by their TYPETERMs in the GRPLIST
before the user transactions and programs. This minimizes the virtual storage
tied up while processing the installation of the terminals.
Note:
All terminals are installed, even surrogate TCT entries for MRO.
You must ensure that the DFHVTAM group precedes any TERMINAL or
TYPETERM definition in your GRPLIST. It is contained in the DFHLIST GRPLIST,
so adding DFHLIST first to your GRPLIST ensures this. If you do not do this,
the programs used to build the TCT are loaded for each terminal, thus slowing
initial and cold starts.
- You should not have more than about 100 entries in any group defined in
the CSD. This may cause unnecessary overhead during processing, as well as
making maintenance of the group more difficult.
- Make sure that changing the START= parameter does not change the default
for any facilities that your users do not want to have AUTO-started. Any
facility that you may want to override may be specifically coded in the PARM=
on the EXEC statement, or all of them may be overridden by specifying START=(...,ALL).
- If you do
not intend to make use of CICS Web support or the Secure Sockets Layer,
you should make sure that TCPIP=NO is specified in the SIT. If TCPIP=YES is
specified, the Sockets domain task control block is activated.
- Tune the VSAM parameters of the local and global catalogs to suit your installation.
- CI sizes should be changed for optimum data and DASD sizes (see Size of control intervals for more information). 2KB index CI, and 8KB or 16KB data
CI can be recommended; 32KB data has been found to slow down the COLD start.
- It is recommended that you specify the BUFNI and BUFND parameters in your
JCL for the GCD via the AMP= parameter, rather than using BUFSPACE.
- Alter the number of index buffers by coding the number of strings plus
the number of index set records in the index. The number of records in the
index set can be calculated from IDCAMS LISTCAT information as follows:
- T = total number of index records (index REC-TOTAL)
- D = data control interval size (data CISIZE)
- C = data control intervals per control area (data CI/CA)
- H = data high-used relative byte address (data HURBA)
Free space has no effect, so do not spend time trying to tune
this.
The number of index levels can be obtained by using the IDCAMS
LISTCAT command against a GCD after CICS has been shut down. Because cold start
mainly uses sequential processing, it should not require any extra buffers
over those automatically allocated when CICS opens the file.
- On cold and initial starts, CICS normally has to delete all the resource
definition records from the global catalog. You can save the time taken to
do this by using the recovery manager utility program, DFHRMUTL, described
in the CICS Operations and Utilities Guide.
- Before a cold start, run DFHRMUTL with SET_AUTO_START=AUTOCOLD,COLD_COPY as input parameters. This creates a copy of the global catalog data
set that contains only those records needed for a cold start. If the return
code from this job step is normal, you can replace the original global catalog
with the new copy (taking an archive of the original catalog if you wish).
A example of the JCL to do this is in the CICS Operations and Utilities Guide.
- Before an initial start, run DFHRMUTL with SET_AUTO_START=AUTOINIT,COLD_COPY as input parameters, and follow the same procedure to use the resulting
catalog.
- Allocate your DATA and INDEX data sets on different units, if possible.
- Consider the use of autoinstalled terminals as a way of improving cold
start, even if you do not expect any storage savings. On startup, fewer terminals
are installed, thereby reducing the startup time.
- The RAPOOL system initialization parameter should be set to a value that
allows faster autoinstall rates. For a discussion of this, see Setting the size of the receive-any pool (RAPOOL).
- Specify the buffer, string, and key length parameters in the LSR pool
definition. This reduces the time taken to build the LSR pool, and also reduces
the open time for the first file to use the pool.
- If you have defined performance groups for the CICS system, ensure that all steps preceding
the CICS step are also in the same performance group or, at least, have a
high enough dispatching priority so as not to delay their execution.
- The use of DISP=(...,PASS) on any non-VSAM data set used in steps preceding CICS reduces allocation time the next time they are needed. If you do not
use PASS on the DD statement, this causes the subsequent allocation of these
data sets to go back through the catalog: a time-consuming process.
- If possible, have one VSAM user catalog with all of the CICS VSAM data sets
and use a STEPCAT DD statement to reduce the catalog search time.
- Keep the number of libraries defined by DFHRPL to a minimum. One large
library requires less time to perform the LLACOPY than many smaller libraries.
- Use of the shared modules in the link pack area (LPA) can help to reduce
the time to load the CICS nucleus modules. See the CICS Transaction Server for z/OS® Installation Guide for advice on how to install CICS modules in
the LPA.
- CICS does not load programs at startup time for resident programs. The
storage area is reserved, but the program is actually loaded on the first
access through program control for that program. This speeds startup. The
correct way to find a particular program or table in storage is to use the
program-control LOAD facility to find the address of the program or table.
The use of the LOAD facility physically loads the program into its predefined
storage location if it is the first access.
The use of a PLTPI task to
load these programs is one possible technique, but you must bear in mind that
the CICS system is not operational until the PLTPI processing is complete,
so you should not load every program. Load only what is necessary, or the
startup time will appear to increase.