When you start up CICS®, you start a process called CICS system initialization. This process must finish before you run any
transactions.
CICS system initialization involves many activities, some of which are:
- Obtaining the required storage for CICS execution from the private area
in the CICS address space, above and below the 16MB line
- Setting up CICS system parameters for the run, as specified by the system
initialization parameters
- Loading and initializing the CICS domains according to the start option
specified by the START= system initialization parameter
- Loading the CICS nucleus with the required CICS modules
- Installing CICS resource definitions by:
- Loading, from the CSD, the groups of resources specified by the GRPLIST=
system initialization parameter
- Loading the control tables specified by system initialization parameters.
- If XRF=YES is specified, signing on to the CICS availability manager (CAVM)
to check that it is possible to continue initialization and perform the role
requested, that is, as an active or alternate CICS region
- Opening the data sets necessary for initialization, including any needed
for backout if the previous run of your CICS region was not shut down normally
(except for START=STANDBY, when most data sets are not opened until after
takeover)
- Opening BSAM sequential devices as required in the terminal control table
(TCT).
If you are operating CICS with CICS recovery options, backout procedures
may be used to restore recoverable resources to a logically consistent state.
Backout occurs if you start CICS in one of the following ways:
- With START=AUTO and CICS detects that the previous shutdown was immediate
or uncontrolled
- With START=STANDBY and XRF=YES, and a takeover occurs.
For background information about backout, and recovery and restart, see the CICS Recovery and Restart Guide.
CICS startup can be any of the following types:
- Startup type
- Effect
- Initial
- CICS starts with no reference to any system activity recorded in the
CICS global catalog and system log from a previous run of CICS. For more information,
see CICS actions on an initial start.
- Cold
- CICS starts with limited reference to any system activity recorded in
the CICS global catalog and system log from a previous run of CICS. For more
information, see CICS actions on a cold start.
- Warm
- CICS starts, after a normal shutdown, restoring CICS to the status it
was in at the last normal CICS shutdown, except for some facilities that it
initializes as for a cold start. CICS always restores the trace domain according
to the system initialization parameters, and can restore other facilities depending on the COLD option
of their associated system initialization parameters. For more information, see CICS actions on a warm start.
- Emergency
- CICS starts, after an abnormal shutdown, restoring recoverable resources
to their committed states. For more information, see CICS actions on an emergency restart.
When CICS is started, the type of startup (and therefore the actions it
takes) depends primarily on the following:
- The value of the START system initialization parameter
- Two records in the CICS global catalog:
- The recovery manager control record
- The recovery manager autostart override record.
The values of other system initialization parameters also influence the actions taken on CICS startup.
For information about the types of startup, the roles of the CICS catalogs,
and the effect of the START system initialization parameter, see the CICS System Definition Guide.
Note:
You cannot explicitly request a warm or emergency restart.
When selecting the type of start (using the START system initialization parameter), the choices are
INITIAL, COLD, or AUTO. AUTO can result in a warm or an emergency restart;
CICS itself determines which to use.
The CICS global catalog and system log are initialized, and all information
in them is lost. Because resynchronization information for
remote systems is not preserved, damage may be done to distributed units of work.
It should rarely be necessary to perform an initial start. Examples of
times when an initial start is necessary are:
- When bringing up a new CICS system for the first time
- After a serious software failure, when the global catalog or system log
has been corrupted.
In a cold start, initialization
of CICS occurs with limited reference to any system activity recorded in the
CICS catalogs. With the exception of resynchronization information for remote
systems noted below, no system log or warm keypoint information is used from
any previous run of CICS. Dump table entries from a previous run are also
deleted in a cold start.
In a cold start:
A warm start restores certain
elements of the CICS components that can be warm started to the status that
was recorded in the warm keypoint of the previous normal shutdown.
A partial warm start is
similar to a complete warm start, except that some selected CICS facilities
are cold-started, as specified in the system initialization parameters. Information
is obtained for those facilities from the warm keypoint only if they are not
specified to be cold started.
In a warm start:
- Resource definition information is obtained as follows:
- Tables specified by system initialization parameters, such as MCT=xx,
are obtained from the program library. Information contained in the warm keypoint
of the previous run is used to update the information from the program library.
- Information in the groups in the list named by the GRPLIST system initialization
parameter for this initialization is ignored.
- Information in the groups in the list named by the GRPLIST system initialization
parameter for the previous initialization is obtained
from the warm keypoint and the global catalog.
- Information in groups that have been installed since the last cold start
is obtained from the warm keypoint and the global catalog.
- Information in groups that have been defined or added to group lists is
taken from the CSD.
- Information about any autoinstalled terminal that has an automatic-initiate
descriptor (AID) outstanding is retrieved from the global catalog.
- Selected fields from the CSA are restored from the warm keypoint, including:
- Region exit time interval value
- Runaway time interval value
- Maximum number of tasks
- High-water mark number of the unit of recovery descriptor.
- The following pieces of information relating to logically recoverable,
physically recoverable and non-recoverable intrapartition transient data queues
are restored:
- All data defining the queues. This information is restored from the global
catalog, including trigger level information, ATI transaction IDs, ATI terminal
IDs and so on.
- All state-related data. This information is retrieved from the warm keypoint
which was written to the log, including:
- Record count
- Read pointer value
- Write pointer value
- Information about whether or not a trigger transaction has been attached.
All intrapartition transient data queues are installed as ENABLED.
Trigger transactions are rescheduled if required.
Extrapartition transient
data queues are opened if OPEN=INITIAL is specified in the queue definition.
- The following FCT information is restored to what it was at the time of
the warm shutdown, using information from the global catalog:
- The ENABLED/DISABLED/UNENABLED status
- The SERVREQ options (UPDATE, DELETE and so on)
- Any alterations made to the DSNAME.
- Files defined as initially OPEN are opened irrespective of their other
attributes. If the file state recovered during initialization
is ENABLED or UNENABLED, the file becomes OPEN, ENABLED after the OPEN. If
the file state recovered is DISABLED, the file becomes OPEN, DISABLED.
- Installed transaction and profile definitions are obtained from:
- The groups specified in the GRPLIST system initialization parameter at
the last cold start
- The groups that have been installed since the last cold or emergency start.
The following attributes of the installed transactions and profiles
are restored from the warm keypoint:
- ENABLED/DISABLED status
- Transaction priority.
- Installed program and mapset definitions are obtained from these sources:
- The groups specified in the GRPLIST system initialization parameters at
the last cold start
- The groups that have been installed since the last
cold start or emergency restart
- The changes (such as LPA-eligibility) made by CEMT or EXEC CICS SET PROGRAM
commands in the last run.
The ENABLED/DISABLED status
of each installed program and mapset is restored from the warm keypoint. Directory
information is obtained for each program and mapset during CICS initialization.
- The following TCT information is restored from the warm keypoint information:
- Processing status (transaction, transceive, input, or receive)
- Service status (INSERVICE or OUTSERVICE)
- Extended attributes supported (color, programmed symbols, and so on)
- Partition support
- Magnetic-stripe-reader support
- Outboard formatting support
- Coded graphic character set identifiers
- APL/TEXT keyboard.
If any outstanding work was scheduled for
an autoinstalled terminal at the last warm shutdown, the terminal entry is
recovered. (Terminal entries for autoinstalled terminals with no work outstanding
are deleted at shutdown.)
- The following auxiliary temporary storage information is restored
from the warm keypoint:
- All data in the auxiliary temporary storage queues
- The temporary storage use map.
- Interval control elements (ICEs) for outstanding START TRANSID commands
are restored from the warm keypoint.
- The BMS logical messages that were created by the functions listed below
but have not yet been viewed by the terminal operator are restored:
- Message switching transaction (CMSG).
- ROUTE command.
- SEND MAP ACCUM and SEND TEXT ACCUM commands, except for those messages
terminated by SEND PAGE without specifying RELEASE or RETAIN. In those cases,
the message might already have been viewed by the operator, but can be viewed
again following the warm start.
- All unit of recovery descriptors (APPC log name, APPC resynchronization,
and external resource manager) are restored from the warm keypoint, together
with any associated deferred work elements (DWEs).
- The STORECLOCK value is restored from the warm keypoint.
- The intervals at which statistics were collected and status and the logical
end-of-day time are restored from the global catalog.
- The monitoring status, class status and monitoring control table suffix
are restored from the global catalog.
- Transaction and system dump table options are held in the global catalog
and reapplied at a warm start.
- Journals and journal models are restored from the catalog.
- If the shared class cache was started at the time of shutdown,
it is started at initialization time. The status of autostart for the shared
class cache is restored from the global catalog. These events occur unless
the JVMCCSTART system initialization parameter is specified as an override
at startup, in which case the behaviour specified by the system initialization
parameter is used.
A CICS system that operates
on resources, such as files, that have been defined by the installation to
be recoverable, records changes to those resources
in the CICS system log. If the CICS system fails, the system log at the time
of failure should typically contain records of changes made by tasks that
have not completed (‘in-flight’ tasks) and by others that have completed.
Following an abnormal termination, Recovery Manager collects all of the
log records pertaining to in-flight tasks. It acquires locks on any records
that they updated and restores the tasks as shunted UOWs, to be backed out
after initialization is complete.
CICS-VTAM actions after an emergency restart
When LU-LU sessions are re-established
after an emergency restart (and subsequent processing), CICS participates
in a resynchronization protocol with logical units to discover if any messages,
in either direction, were lost when CICS was terminated.
The logical units for which resynchronization is required will have been
marked in the TCTTEs. Resynchronization is not attempted
in the following cases:
- If the terminal was acquired by a master terminal operation specifying
COLDACQ.
- If the terminal was acquired with the EXEC CICS SET TERMINAL ACQSTATUS(COLDACQ)
command.
- If the session is a pipeline session.
- If the TCTTE is marked to cold start the session by the TCT assembly process.
This is done for terminals such as 3270 terminals that do not support the
set and test sequence number (STSN) command.
Note:
If the previous session abended, the use of COLDACQ overrides
CICS integrity control. This could lead to data integrity problems. Also,
you should check the CSMT log for an activity keypoint after the restart of
a session following a CICS failure. If there is no activity keypoint, you
should issue COLDACQ again after the next emergency restart.
For each logical unit that does require resynchronization,
CICS issues an STSN command that notifies the logical unit of the sequence
numbers known to CICS--that is, those numbers that backout processing
placed in the TCTTE. The logical unit can compare these sequence numbers with
those that it has logged for itself, and can thus determine if any messages
were lost.
- If an input message was lost, the logical unit
should retransmit it to CICS.
- If an output message was lost, CICS retransmits
the message from the resend slot and, in so doing, deletes the resend slot.
Note:
The message remains in the resend slot if CICS does not retransmit it. This occurs if the resynchronization process shows
that the output message was not lost, or if the logical unit does not support
the STSN command; the 3270 is in this category.
In a VTAM® network, the
session between CICS and VTAM is started automatically if VTAM is started
before CICS. If VTAM is not active when you start CICS, you receive the following
messages:
F vtamname,USERVAR,ID=generic-applid,VALUE=specific-applid
+DFHSI1589D 'applid' VTAM is not currently active.
+DFHSI1572 'applid' Unable to OPEN VTAM ACB - RC=xxxxxxxx, ACB CODE=yy.
Although the MODIFY NET, USERVAR command is only significant when you are
running CICS with XRF, the USERVAR message occurs for both XRF=YES and XRF=NO
CICS systems. If you receive messages DFHSI1589D and DFHSI1572, and if the
CICS region is not initializing as an alternate CICS region, you can start
the CICS-VTAM session manually when VTAM is eventually started, by means of
the CEMT SET VTAM OPEN command from a supported MVS™ console or a non-VTAM terminal.
If VTAM is active, but CICS still cannot open the VTAM ACB because VTAM
does not recognize the CICS APPLID, you receive the following messages:
F vtamname,USERVAR,ID=generic-applid,VALUE=specific-applid
+DFHSI1592I 'applid' CICS applid not (yet) active to VTAM.
+DFHSI1572 'applid' Unable to OPEN VTAM ACB - RC=00000008, ACB CODE=5A.
This may be caused by an error in the value of APPLID operand, in which
case you must correct the error and restart CICS. For information about other
causes and actions, see the CICS Messages and Codes manual.
Concurrent initialization of VTAM and XRF alternate CICS regions
An XRF alternate CICS region cannot initialize properly until it has successfully
opened the VTAM ACB.
Because VTAM and the alternate CICS region may be initialized concurrently,
it is possible that several tries may have to be made to open the VTAM ACB.
If VTAM is not active, the following message is written to the system console
every 15 seconds:
DFHSI1589D 'applid' VTAM is not currently active.
If VTAM is active, but CICS cannot open the VTAM ACB, the following messages
are written to the system console:
+DFHSI1572 'applid' Unable to OPEN VTAM ACB - RC=xxxxxxxx, ACB CODE=yy.
DFHSI1590 'applid' XRF alternate cannot proceed without VTAM.
CICS
abends with a dump (abend code 1590).
Whichever type of startup is performed, when the message:
DFHSI1517 - 'applid': Control is being given to CICS.
is displayed on the operating system console, CICS is ready to process
terminal requests. (applid is the value of the specific APPLID system
initialization parameter.)
When the startup process is completed, users are able to enter transactions
from any terminals that are connected to CICS. For information about the CICS-supplied
transactions, see CICS Supplied Transactions.
[[ Contents Previous Page | Next Page Index ]]