If you are an existing CICS® user and are planning to migrate to CICS Transaction Server for z/OS®, Version 3 Release 1 in an established z/OS environment, most of the tasks described here will already have been done. In this case, review the following steps to check whether you need to make any changes. If you are setting up a new z/OS environment, perhaps on new hardware, you need to ensure that the required support for CICS is in place.
The following is a summary of the steps to follow to enable your z/OS environment to support CICS:
Schedule an IPL to install the CICS SVC routine, DFHCSVC, and other CICS-required modules in the MVS link pack area (LPA).
Defining VTAM APPL definitions for CICS application-owning regions (AORs) is optional.
Each of these tasks is discussed in more detail in the following topics.
There are also some optional tasks that you may need to perform at a later stage, but these are not essential to the initial install and operation of a basic CICS system. These tasks are connected with facilities such as VSAM record-level sharing, MVS automatic restart management, and MVS performance.
Add the CICS SDFHAUTH library to the list of APF-authorized libraries in the appropriate PROGxx (or IEAAPFxx) member in SYS1.PARMLIB. The SDFHAUTH library must be APF-authorized to enable certain CICS modules, such as DFHSIP, to run in supervisor state.
If your list(s) of APF-authorized libraries are specified in the dynamic format (in a PROGxx member), refresh the APF list dynamically using the SETPROG or SET PROG=xx command.
If your list(s) of APF-authorized libraries are specified in the static format (in IEAAPFxx members), schedule an MVS IPL for the APF-authorization to take effect.
For information about maintaining lists of APF-authorized libraries, see the z/OS MVS Initialization and Tuning Reference.
Ensure each CICS region userid (the userid under which a CICS region runs) has the required authority (READ, UPDATE, CONTROL, or ALTER) to access the various protected resources it needs to use. These include load libraries and other data sets, coupling facility structures, the VTAM ACB, and so on.
The resources for which you need to ensure access are:
When you have defined the required authorizations for CICS regions in the RACF data base, activate the various resource classes with the RACF SETROPTS command.
CICS provides a number of modules that are intended for use from the MVS LNKLST. These are supplied in the SDFHLINK library, and are in two categories:
Add the CICS SDFHLINK library to the MVS LNKLST concatenation. Note that many of the modules in SDFHLINK can only be used from an APF-authorized library, and therefore SDFHLINK also needs to be APF-authorized.
Define CICS as an MVS subsystem in an IEFSSNxx member of SYS1.PARMLIB if you plan to use any of the following CICS facilities:
Install the CICS TS Version 2 level of the CICS Type 3 SVC module, DFHCSVC, before you attempt to start a CICS region. To make the CICS Type 3 SVC ready for use:
SVCPARM 216,REPLACE,TYPE(3),EPNAME(DFHCSVC)
CICS contains a test to verify that it is using the correct release level of the CICS DFHCSVC module. If CICS calls an SVC module using the SVC number specified on the CICSSVC system initialization parameter, and the module is not at the current level, CICS issues message DFHKE0104.
The high-performance option (HPO) is provided for users who want to optimize terminal response times and maximize transaction throughput. This option requires the CICS Type 6 SVC module, DFHHPSVC, to be included in the MVS nucleus To help you decide on the use of HPO, see the CICS Performance Guide. If you decide to use this option, follow the steps described in Selecting the high-performance option.
Define each CICS terminal-owning region to VTAM as a VTAM application--that is, as a VTAM application program major node (APPL). To do this, add the required APPL definition statements to a member of SYS1.VTAMLST. For example:
* APPL definition for CICS region CICSHTH1
**********************************************************************
CICSHTH1 APPL AUTH=(ACQ,VPACE,PASS),VPACING=0,EAS=5000,PARSESS=YES X
SONSCIP=YES
********************************************************************
Also ensure that your VTAM terminals are properly defined for connection to CICS. This is particularly important if you intend using the CICS autoinstall function. For those terminals for which you want to use autoinstall, code VTAM LOGON mode table entries that correspond to the model TYPETERM/TERMINAL definitions defined to CICS. You can either code your own autoinstall models, or use the CICS-supplied model definitions that are generated for you when you initialize the CICS system definition data set (CSD).
For programming information about matching VTAM LOGMODE definitions with CICS model definitions, see the CICS Customization Guide.
For information about defining model and VTAM terminal definitions to CICS, see the CICS Resource Definition Guide.
CICS automatically connects to its system log stream, unless you define a journal model resource definition to define the log stream as TYPE(DUMMY).
Each CICS region has only one system log, which is implemented as two MVS system logger log streams. These are used by CICS as the primary and secondary system log streams and together these form a single logical log stream. Thus, as a default each CICS region requires a minimum of two log streams.
Initially, you are recommended to define to the MVS system logger some model log streams, and let CICS create the system log streams dynamically. If you plan to use a coupling facility for CICS logging, you must also define the log structures required for the log streams. To get you started, however, using DASD-only log streams is quicker and easier to define. Later, when you have more information available, you can plan to define coupling facility log structures with explicit log streams tailored to your requirements.
Define MVS model log streams using the naming convention that enables CICS to create log streams dynamically. Model names should be of the form mvs_sysid.DFHLOG.MODEL and mvs_sysid.DFHSHUNT.MODEL, where mvs_sysid is the system name of the MVS image in which the CICS region runs.
Example: If a CICS region, running in an MVS image with a sysid of MV10, issues a create log stream request for its primary log stream, the system logger requires a model log stream named MV10.DFHLOG.MODEL.
You can define a CICS JOURNALMODEL resource definition with TYPE(DUMMY) to avoid having to define log streams. If you want to run the IVPs with the minimum effort, here's what to do:
Note that your group list must follow the IBM-supplied list, DFHLIST. DFHLIST includes group DFHLGMOD (which contains DFHLOG and DFHSHUNT JOURNALMODEL definitions) but concatenating your list after DFHLIST ensures that your DUMMY definitions replace the IBM® definitions.
//CSDLGSTR JOB 1,BELL,MSGCLASS=A,MSGLEVEL=(1,1),CLASS=A
//CSDUP EXEC PGM=DFHCSDUP,REGION=1M,PARM='CSD(READWRITE)'
//STEPLIB DD DSN=CICSTS31.CICS.SDFHLOAD,DISP=SHR
//DFHCSD DD DSN=CICSTS31.CICS.CICSH###.DFHCSD,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSABOUT DD SYSOUT=*
//SYSABEND DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSIN DD *
*
* DEFINE JOURNAL MODELS FOR CICS LOG STREAMS AS DUMMY
*
DEFINE JOURNALMODEL(DFHLOG) GROUP(LOGTEST)
DESCRIPTION(DEFINE SYSTEM LOG AS DUMMY)
JOURNALNAME(DFHLOG)
TYPE(DUMMY)
*
DEFINE JOURNALMODEL(DFHSHUNT) GROUP(LOGTEST)
DESCRIPTION(DEFINE SYSTEM LOG AS DUMMY)
JOURNALNAME(DFHSHUNT)
TYPE(DUMMY)
/*
//
A CICS program may call the first failure symptoms (FFS) component. This uses the MVS SYMREC macro to write a symptom record to the MVS SYS1.LOGREC dataset.
Install an MVS ASR exit to enable CICS to use the SYMREC macro call, otherwise the FFS call fails. For more information, see the z/OS MVS Installation Exits manual.
[[ Contents Previous Page | Next Page Index ]]