CICSPlex SM enablement using the CICS Explorer
One of the functions of CICSPlex SM is to implement dynamic workload management within CICS. In this chapter, we review the various factors that you must take into account when delivering such a solution. We also discuss how we can identify these solutions and address them using the CICS Explorer.
When a program or transaction in CICS uses an external resource, such as a file or temporary storage, this creates an affinity within the transaction to that resource. CICS Interdependency Analyzer gives us the ability to analyze affinity data. The affinity data is loaded into DB2 databases, on which you can perform SQL queries and from which you can produce detailed reports.
17.1 Overview of transaction affinities
CICS transactions use many different techniques to pass data from one transaction to another. Some techniques require that the transactions that are exchanging data must execute in the same CICS region and therefore impose restrictions on the dynamic routing of transactions. If transactions exchange data in ways that impose such restrictions, there is said to be an affinity between them.
There are two categories of affinity:
• Inter-transaction affinity
•Transaction-system affinity
The restrictions on dynamic routing caused by transaction affinities depend on the duration and scope of the affinities. Clearly, the ideal situation for a dynamic routing program is for there to be no transaction affinity at all, which means there is no restriction in the choice of available target regions. However, even when transaction affinities do exist, there are limits to the scope of these affinities that are determined by the:
• Affinity relations
•Affinity lifetime
CICS IA cannot detect affinities in the following types of dynamically routed requests:
•Non-terminal-related START requests
• Distributed program link (DPL) requests
• Method requests for enterprise beans or CORBA stateless objects
For these types of dynamically routed requests, review your application to determine whether it is suitable for dynamic routing.
17.1.1 Inter-transaction affinity
An inter-transaction affinity is an affinity between two or more CICS transactions. It is caused by the transactions using techniques to pass information between one another or to synchronize activity between one another in a way that requires the transactions to execute in the same CICS region.
Inter-transaction affinities that impose restrictions on the dynamic routing of transactions, can occur in the following circumstances:
• One transaction terminates, leaving “state data” in a place that a second transaction can access only by running in the same CICS region as the first transaction.
•One transaction creates data that a second transaction accesses while the first transaction is still running. For this to work safely, the first transaction usually waits on an event, which the second transaction posts when it has read the data that the first transaction created. This synchronization technique requires that both transactions are routed to the same CICS region.
17.1.2 Transaction-system affinity
A transaction-system affinity is an affinity between a transaction and a particular CICS region. It is caused by the transaction interrogating or changing the properties of the CICS region.
Transactions with an affinity to a particular CICS region, rather than to another transaction, are not eligible for dynamic transaction routing. Typically, they are transactions that use CICS SPI commands, such as EXEC CICS INQUIRE or SET or that depend on global user exit programs.
17.1.3 Affinity relations
When a transaction is associated with an affinity, the affinity relation determines how the dynamic routing program selects a target region for an instance of the transaction. An affinity relation can be classified as one of the following relations:
Global A group of transactions in which all instances of all transactions in the group that are initiated from any terminal, or are BTS or Link3270 transactions, must execute in the same target region for the lifetime of the affinity. The affinity lifetime for global relations can be “system” or “permanent.”
BAPPL All instances of all transactions in the group are associated with the same CICS Business Transaction Services (BTS) process. There might be many different user IDs and terminals that are associated with the transactions that are included in this affinity group.
LINK3270 All instances of all transactions in the group are associated with the same Link3270 bridge facility.
LUname A group of transactions in which all instances of all transactions in the group that are initiated from the same terminal must execute in the same target region for the lifetime of the affinity. The affinity lifetime for LUname relations can be “pseudoconversation,” “logon”, “pseudoconversational”, “system,” or “permanent.”
UserID A group of transactions in which all instances of the transactions that are initiated from a terminal and executed on behalf of the same user ID must execute in the same target region for the lifetime of the affinity. The affinity lifetime for userID relations can be “pseudoconversation,” “signon,” “system,” or “permanent.”
17.1.4 Affinity lifetimes
The affinity lifetime determines when the affinity is ended. An affinity lifetime can be classified as one of:
System The affinity lasts for as long as the target region exists and ends whenever the target region terminates (at a normal, immediate, or abnormal termination). The resource shared by transactions that take part in the affinity is not recoverable across CICS restarts.
Permanent The affinity extends across all CICS restarts. (The resource shared by transactions that take part in the affinity is recoverable across CICS restarts.) This is the most restrictive of all the inter-transaction affinities.
Process The affinity exists until the BTS process completes.
Activity The affinity exists until the BTS activity completes.
Facility The affinity exists until the Link3270 bridge facility is deleted.
Pseudoconversation The (LUname or userID) affinity lasts for the whole pseudoconversation and ends when the pseudoconversation ends at the terminal.
Logon The (LUname) affinity lasts for as long as the terminal remains logged on to CICS and ends when the terminal logs off.
Signon The (userID) affinity lasts for as long as the user is signed on, and ends when the user signs off. Note that this lifetime is only possible in those situations where only one userID is permitted. Signon lifetime cannot be detected if multiple users are permitted to be signed on with the same userID at the same time.
|
Note: If an affinity is both “userID” and “LUname” (that is, all instances of all transactions in the group were initiated from the same terminal and by the same user ID), “LUname” takes precedence.
|
17.2 Running CICS Interdependency Analyzer for affinities
In the first instance, we must run the collector component of CICS Interdependency Analyzer for z/OS against our candidate application. We chose a single application to analyze to prepare this for CICSplex enablment.
We need to set the correct parameters in the collector panel through the transaction CINT, as shown in Figure 17-1.
|
CIU290 CICS Interdependency Analyzer for z/OS - V3R1M0 2009/06/01
Resource Options for 09:28:10AM
CICS Sysid: EJ02 CICS Applid: IYDZEJ02
Type action code then press ENTER:
1 = General Options
2 = Time/Date Options
Interdependency Options Affinity Options
3 = CICS Options for APIs 8 = Affinity Options
4 = CICS Options for SPIs
5 = DB2/IMS/MQ Options
6 = Task Options
7 = Natural Options
CICS Sysid: EJ02 CICS Applid: IYDZEJ02 TermID: TC47
F1=Help F2= F3=Exit F4= F5= F6=
F7= F8= F9= F10= F11= F12=Exit
|
Figure 17-1 CICS IA CINT transaction
To set the collection for Affinity options, we much choose Option 8, which then displays the panel in Figure 17-2 on page 350.
Figure 17-2 Resource options panel for CICS IA
From this panel, we can set the Affinity detection options on for both Inter-Transaction and Transaction System Affinities, which enables us to scope the amount of effort that is required to resolve any affinities. It is worth noting that you can resolve an affinity by making a system-related change, as opposed to an application-related change, for example, having to amend program code. One example of this is to move any queue related activity, for example, TS or TD, to a queue-owning region.
17.3 Loading the DB2 database with the collected affinity data
CICS Interdependency Analyzer provides you with a number of supplied jobs to load your collected data into the DB2 tables. The CICS IA Affinity data is loaded by the sample job CIUAFFLD, as shown in Example 17-1.
Example 17-1 CICS IA CIUAFFLD sample JCL
//CIUAFFLD JOB USER=JAMESE,NOTIFY=JAMESE,
// CLASS=A,MSGCLASS=Y,REGION=0M
//*
//*
//*********************************************************************
//* *
//* JCL NAME = CIUAFFLD *
//* *
//* DESCRIPTIVE NAME = IBM CICS INTERDEPENDENCIES UTILITY *
//* LOAD THE AFFINITY TABLES FROM AFFINITIY VSAM *
//* FILES , CIUAFF1/2/3 *
//* AFFINITY FILES CREATED BY CICS/IA *
//* *
//* CHANGES TO BE MADE *
//* PLEASE CONSULT WITH YOUR DB2 ADMINISTRATOR *
//* *
//* 1) CHANGE THE JOB CARD TO SUIT YOUR SYSTEM CONVENTIONS *
//* 2) CHANGE THE FOLLOWING PARAMETERS:- *
//* *
//* DG2F *
//* THE DB2 ID *
//* *
//* CICSTS.CICS.IA.V31.INC38 *
//* THE HLQ FOR CIU PRODUCT *
//* *
//* SYS2.DB2.V810.SDSNLOAD *
//* THE DATASET HLQ FOR DB2 SDSNLOAD *
//* *
//* REDTOOLS.CICSIA *
//* THE HLQ FOR THE CIA AFFINITY FILES. THESE FILES ARE *
//* CREATE AS PART OF THE CICS AFFINITIES UTILITY *
//* *
//* 81 *
//* FOR THE PLAN SHOULD BE REPLACED WITH THE FIRST 2 DIGITS *
//* OF THE DB2 VERSION NUMBER *
//* *
//* DSN8102F.RUNLIB.LOAD *
//* TO THE DATASET HLQ FOR DB2 RUNLIB.LOAD *
//* *
//* YOU MAY ALSO WISH TO REVIEW THE SCIUSQL(CIUSPCDB)MEMBER. *
//* *
//* 3) EDIT THE SCIUCLIS MEMBER CIUDB2BT AND CHANGE THE FOLLOWING:- *
//* *
//* ANTZ.CICS.IA.V31.INC38 *
//* THE HLQ FOR CIA PRODUCT *
//* *
//* 4) IF YOU WISH TO UPDATE THE DATABASE WITH THE LAST USAGE *
//* COUNTS THEN CHOOSE PARM(UPDATE) *
//* *
//* 5) You can load Affinities for a region by selecting an APPLID *
//* Enter ALL for all APPLIDs or the APPLID to be loaded *
//* No entry is treated the same as ALL *
//*********************************************************************
//*********************************************************************
//* @start_copyright@ *
//* Licensed Materials - Property of IBM *
//* *
//* "Restricted Materials of IBM" *
//* *
//* 5697-J23 *
//* *
//* (c) Copyright IBM Corp. 2004, 2007 All Rights Reserved. *
//* *
//* US Government Users Restricted Rights - Use, duplication or *
//* disclosure restricted by GSA ADP Schedule Contract with *
//* IBM Corp. *
//* @end_copyright@ *
//*********************************************************************
//* *
//* CHANGE HISTORY *
//* *
//* PN= REASON REL YYMMDD HDXIII: REMARKS *
//* ---- ------ ---- ------ ------ ------------------------------- *
//* £L0= H274130 300 040601 hdej: Date Created *
//* £P1= 00050 300 040725 hdej: Load affiniy data tables *
//* £P2= 00079 300 040725 hdej: Set region to 0M *
//* £P3= PK02704 300 050505 hdej: New affinity files *
//* £P4= 00230 2100 050606 hdej: Update to CIUBTCH4 *
//* £P5= 00244 2100 050628 hdej: Change CAU to CIU all *
//* £L6= 00235 2100 050923 hdej: Add new jobcard. *
//* £P6= 00363 2100 051003 hdej: COrrect EXEC in STEP00 *
//* £P7= 00478 2100 051026 hdjah: Add DD for SCIULODE *
//* £L7= 00806 2200 070516 hd-nsm: Add step - total number of rows *
//* £P8= 00822 2200 070606 hd-mxs: Add DB2 plan customization *
//* £P7= PK72394 2200 081002 hd-ej: New update for CIU_RESOURCE *
//* £P8= 01158 2200 081216 hd-ej: Add SYSREC06 *
//* £M1= 001189 3100 090128 hdej: Remove .SDSNLOAD and.RUNLIB.LOAD*
//*********************************************************************
//******************************************************************
//JCLLIB JCLLIB ORDER=DSN8102F.PROCLIB
//JOBLIB DD DSN=ANTZ.CICS.IA.V31.INC38.SCIULOAD,
// DISP=SHR
// DD DSN=ANTZ.CICS.IA.V31.INC38.SCIULODE,
// DISP=SHR
// DD DSN=SYS2.DB2.V810.SDSNLOAD,
// DISP=SHR
// DD DSN=DSN8102F.RUNLIB.LOAD,
// DISP=SHR
//*********************************************************************
//*---------------------------------------------------------------
//* RUN THE BATCH PROGRAM CIUUREG
//*---------------------------------------------------------------
//STEP000 EXEC PGM=IKJEFT1B,
// DYNAMNBR=20,
// PARM=('%CIUDB2BT','SYS(DG2F)','PROG(CIUUREG)',
// 'PLAN(REDIADD)')
//*---------------------------------------------------------------
//* IF YOU WISH TO UPDATE THE DATABASE WITH THE LAST USED
//* TIME STAMP FOR EACH DB2 ROW THEN CHOOSE PARM(UPD)
//*---------------------------------------------------------------
//SYSPROC DD DSN=REDTOOLS.REDTST41.SCIUCLIS,
// DISP=SHR
//SYSUDUMP DD SYSOUT=*
//SYSTSIN DD DUMMY
//SYSTSPRT DD SYSOUT=*
//SYSABOUT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//CIUCNTL DD DSN=REDTOOLS.CICSIA.CIUCNTL,
// DISP=SHR
//******************************************************************
//STEP010 EXEC PGM=IKJEFT1B,
// DYNAMNBR=20,
// PARM=('%CIUDB2BT','SYS(DG2F)','PROG(CIUAFFL1)',
// 'PLAN(REDIADD)','PARM(UPDATE)')
//* 'PLAN(REDIADD)')
//*---------------------------------------------------------------
//* IF YOU WISH TO UPDATE THE DATABASE WITH THE LAST USAGE
//* COUNTS THEN CHOOSE PARM(UPDATE)
//*---------------------------------------------------------------
//SYSPROC DD DSN=REDTOOLS.REDTST41.SCIUCLIS,
// DISP=SHR
//SYSUDUMP DD SYSOUT=*
//SYSTSIN DD DUMMY
//SYSTSPRT DD SYSOUT=*
//SYSABOUT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//CIUAFF1 DD DSN=REDTOOLS.CICSIA.CIUAFF1,
// DISP=SHR
//CIUAFF2 DD DSN=REDTOOLS.CICSIA.CIUAFF2,
// DISP=SHR
//CIUAFF3 DD DSN=REDTOOLS.CICSIA.CIUAFF3,
// DISP=SHR
//CIUCNTL DD DSN=REDTOOLS.CICSIA.CIUCNTL,
// DISP=SHR
//* Enter ALL for all APPLIDs or the APPLID to be loaded
//* No entry is treated the same as ALL
//APPLID DD *
/*
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//*---------------------------------------------------------------
//* RUN SQL QUERIES FOR DB2 TABLES
//*---------------------------------------------------------------
//CIUSPACE EXEC PGM=IKJEFT01
//SYSPRINT DD SYSOUT=*
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD *
DSN SYSTEM(DG2F)
RUN PROGRAM(DSNTEP2) PLAN(DSNTEP81) PARMS('/ALIGN(LHS) MIXED') -
LIB('DSN8102F.RUNLIB.LOAD')
END
/*
//SYSIN DD DSN=REDTOOLS.REDTST41.SCIUSQL(CIUSPCAF),
// DISP=SHR
//*---------------------------------------------------------------
//* UPDATE THE CIU_RESOURCE TABLE
//*---------------------------------------------------------------
//CIUUNLD EXEC PGM=IKJEFT01
//SYSTSPRT DD SYSOUT=*
//SYSREC DD DUMMY
//SYSTSIN DD *
DSN SYSTEM(DG2F)
RUN PROGRAM(DSNTIAUL) PLAN(DSNTIB81) PARMS('SQL') -
LIB('DSN8102F.RUNLIB.LOAD')
//SYSPRINT DD SYSOUT=*
//SYSPUNCH DD DUMMY
//SYSUDUMP DD SYSOUT=*
//SYSREC00 DD DSN=&&DATA0,DISP=(,PASS),
// UNIT=SYSDA,SPACE=(CYL,(200,15),RLSE)
//SYSREC01 DD DSN=&&DATA1,DISP=(,PASS),
// UNIT=SYSDA,SPACE=(CYL,(200,15),RLSE)
//SYSREC02 DD DSN=&&DATA2,DISP=(,PASS),
// UNIT=SYSDA,SPACE=(CYL,(200,15),RLSE)
//SYSREC03 DD DSN=&&DATA3,DISP=(,PASS),
// UNIT=SYSDA,SPACE=(CYL,(200,15),RLSE)
//SYSREC04 DD DSN=&&DATA4,DISP=(,PASS),
// UNIT=SYSDA,SPACE=(CYL,(200,15),RLSE)
//SYSREC05 DD DSN=&&DATA5,DISP=(,PASS),
// UNIT=SYSDA,SPACE=(CYL,(200,15),RLSE)
//SYSREC06 DD DSN=&&DATA6,DISP=(,PASS),
// UNIT=SYSDA,SPACE=(CYL,(200,15),RLSE)
//SYSPUNCH DD SYSOUT=*
//SYSIN DD DSN=REDTOOLS.REDTST41.SCIUSQL(CIURSV8U),
// DISP=SHR
//*---------------------------------------------------------------
//CIURLD EXEC DSNUPROC,
// SYSTEM=DG2F,
// UID='CIUAFFLD',
// UTPROC=''
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(200,15),RLSE)
//SORTOUT DD UNIT=SYSDA,SPACE=(CYL,(200,15),RLSE)
//SORTWK01 DD UNIT=SYSDA,SPACE=(CYL,(200,15),RLSE)
//SORTWK02 DD UNIT=SYSDA,SPACE=(CYL,(200,15),RLSE)
//SORTWK03 DD UNIT=SYSDA,SPACE=(CYL,(200,15),RLSE)
//SORTWK04 DD UNIT=SYSDA,SPACE=(CYL,(200,15),RLSE)
//SORTWK05 DD UNIT=SYSDA,SPACE=(CYL,(200,15),RLSE)
//SYSREC00 DD DSN=&&DATA0,DISP=(OLD,DELETE)
// DD DSN=&&DATA1,DISP=(OLD,DELETE)
// DD DSN=&&DATA2,DISP=(OLD,DELETE)
// DD DSN=&&DATA3,DISP=(OLD,DELETE)
// DD DSN=&&DATA4,DISP=(OLD,DELETE)
// DD DSN=&&DATA5,DISP=(OLD,DELETE)
// DD DSN=&&DATA6,DISP=(OLD,DELETE)
//SYSIN DD DSN=REDTOOLS.REDTST41.SCIUSQL(CIURSV8L),
// DISP=SHR
//
After the data is loaded into DB2, we can then use the CICS IA plug-in to view the affinities that were collected.
17.4 Using the CICS IA plug-in to identify affinities
After we have our data loaded into DB2, we can connect using the CICS IA plug-in to review all of the data that was collected. When we use the CICS IA perspective, as a default we should be presented with a panel that is similar to Figure 17-3.
Figure 17-3 CICS IA plug-in Supplies Samples queries
The Supplied Samples that are available in the CICS IA plug-in are displayed. We are interested in the Affinities folder under the CICS samples, so we expand that to see what queries are predefined for us, as shown in Figure 17-4 on page 356.
Figure 17-4 CICS IA Supplied Sample Affinity queries
There is one particularly useful query to run, so we highlighed it. If we run that query as it stands, we should be presented with a list of programs that have affinity statements, as shown in Figure 17-5.
Figure 17-5 All programs with potential affinities
Now that we decided that we need to address the affinity issues, we must make decisions regarding the ability of the transactions to be CICSplex enabled.
First, we must understand what resource relationships our candidate programs are involved with. In Figure 17-6 on page 357, we can see that program DRIVERP has some transactions that are associated with it and another program, a TSQUEUE, and another as yet unidentified resource. If we expand that display, we can see the full list of resources.
=
Figure 17-6 Affinities by program
We must address all of the affinity issues that are identified here, so to begin with, we want to make sure that we have all of the relevant resources that are required for this program to run successfully within a CICSplex. This lists additional transactions and an additional program. We must run the same exercise on the additional program to make sure that we covered all possibilities. If we look at program WORKP, Figure 17-7 on page 358, we can see that this program uses a TSQUEUE also. Fortunately for us, it is the same TSQUEUE that our DRIVERP program uses.
Figure 17-7 Program WORKP affinities
The CICS IA collector derived this information from a running CICS region, and there might be some other commands that were not detected. In this case, it is recommended that you use the load library scanner component of CICS IA to run against the statically defined program to ensure that no commands were excluded during this exercise.
We have two affinity issues that we must address:
•ADDRESS CWA
Our DRIVERP program uses the ADDRESS CWA command, and therefore we must examine the program further to see what type of access is used. If the CWA is being addressed in read-only mode, for example, to obtain the contents of a table, then we must ensure that the table is available to all of our target regions when we implement the workload. If you want to restrict write access to the CWA, you can specify CWAKEY=CICS, which means that CICS allocates the CWA from CICS-key storage, restricting application programs that are defined with EXECKEY(USER) to read-only access to the CWA. The only programs that are allowed to write to a CWA that is allocated from CICS-key storage are those programs that you define with EXECKEY(CICS).
•TSQUEUE AUX
Again, if we write to temporary storage, we must determine if there is a requirement for that to be read by any other program that is executing as past of this workload. If that is the case, we can resolve this problem by one of two methods:
– Implementing a Queue Owning Region: To define a queue as remote you must include an entry for the queue in a temporary storage table (TST) or use an appropriate TSMODEL. TS queue names are frequently generated dynamically, but they can also be unique fixed names.
– Defining a Share Temporary Storage Server: By defining Temporary Storage pools that reside in the Coupling Facility, the queues can be shared across a sysplex.
17.5 Workload management considerations
The easiest part of workload management is setting up the definitions and installing them. However, it is much more complex than that because we must understand the current configuration and what affect our changes will have on it. The first part is to decide where our dynamic workload is going to run. There is plenty of technical material that is available to help you make those decisions, so we do not go into detail here, but we summarize the steps in Figure 17-8.
Figure 17-8 Dynamic routing exploitation
In Figure 17-8, we show (from left to right) the stages that we can go through to fully enable our transactions to be part of a dynamic workload. The stages are:
1. Existing System: This is where our transaction runs and accesses all resources that are local to the CICS region that the transaction(s) and program(s) are defined in.
2. Static Routing: The transaction is defined with a remote attribute of Dynamic=NO in our Terminal Owning Region and is defined as Local in the Application Owning Region. The program is not normally defined in the TOR and defined as Local in the AOR. There is a RemoteSystem attribute set to the SYSID of the AOR and, optionally, a RemoteName attribute set if you want to run the transaction under a different name in the AOR.
3. Dynamic Routing Single TOR. The transaction is defined with a remote attribute of Dynamic=YES in our Terminal Owning Region and is defined as Local in the Application Owning Region. At this point, our target AORs were referenced by a TRANGRP definition within the Workload Management feature of CICSPlex SM.
17.6 Creating the definitions for workload management
After we decide that we have all of the relevant resources defined for our application, we must create definitions within CICSPlex SM so that we can exploit workload management. From CICS Transaction Server V3.2, the only method of creating and managing these definitions is through the CICSPlex SM Web User Interface.
CICSPlex SM uses a routing program to process all routing requests that are made to it. This program, EYU9XLOP, is specified in the System Initialization Table parameters DSRTPGM and DTRPGM for any CICS region that wants to participate in dynamic transaction routing.
Figure 17-9 on page 361 shows the elements that are required to define the workload management criteria for balancing, separation, and affinity processing.
Figure 17-9 Workload management model
The elements are:
TRANGRPS These define the transactions that take place in dynamic routing and also their affinity relations. They are also used to define transactions for workload separation.
WLMDEFS These specify workload and separation criteria.
TrangrpName, LUname, Userid, and Process Type.
WLMGROUP These are purely for administration purposes, for example, assigning WLMGRPS to specifications.
WLMSPEC These define default routing criteria, the routing algorithm to be used, and whether abend avoidance is activated (diverts workloads from a region if it is deemed to be unstable). The workload criteria are made known to the relevant regions by association of the WLMSPEC to the region, usually through a System Group.
Figure 17-10 on page 362 shows Transactions in Transaction Groups.
Figure 17-10 Transactions in Transaction Groups
In this group, Figure 17-10TXNGRP, we defined the six transactions that are part of our application. They can now be associated with target AORs by defining the relationship to the WLMGROUP and the WLMSPEC.
17.7 Migrating the definitions using CICS Configuration Manager
Now that we selected our application for CICSplex enablement, we must migrate the selected definitions from our existing single region into their target regions. If we look at the resources, Figure 17-11 on page 363, that are being used by our candidate application, we can then prepare them to be migrated.
Figure 17-11 Resources captured
We can see that our application is going to require a number of programs, some mapsets, and then we have three datasets that must access from each region that the application runs in. Our decision on the datasets is to use a file-owning region so that our definitions must be migrated, which changes the attributes to remote.
From this information, we can prepare a package to be migrated in CICS Configuration Manager. To do this, we must select the resources that are identified by the data that we collected in CICS Interdependency Analyzer. These resources are then placed into a package, ready to be migrated between differing environments.
Figure 17-12 on page 364 shows the resource packaging.
|
File Menu Settings Help
ssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss
List - All resources Change Package TXNGRP Row 1 to 8 of 8
Command ===> Scroll ===> PAGE
To prepare Scheme views, enter a Scheme on the previous panel
Change Package resources
ssssssssssssssssssssssssssssssssssssssssssssss
Filter * * + * *
/ Name Type Group Status Config
DRIVERP PROGRAM WORKSHOP Not ready, new object REDTST41
TXNA TRANSACTION WORKSHOP Not ready, new object REDTST41
TXNB TRANSACTION WORKSHOP Not ready, new object REDTST41
TXNC TRANSACTION WORKSHOP Not ready, new object REDTST41
TXND TRANSACTION WORKSHOP Not ready, new object REDTST41
TXNE TRANSACTION WORKSHOP Not ready, new object REDTST41
TXN0 TRANSACTION WORKSHOP Not ready, new object REDTST41
WORKP PROGRAM WORKSHOP Not ready, new object REDTST41
******************************* Bottom of data ********************************
|
Figure 17-12 Resource packaging
We defined a package called NACTGRP and placed all of the required resources into it. We must now apply some transformation rules to the package before we try to migrate it. Our prime concern is that the files that we use must now be defined as REMOTE, so we can build a Transformation Rule to include in the package.
Figure 17-13 on page 365 shows a Transformation Rule.
|
File Menu Settings Help
ssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss
Edit Transform Rule
Command ===>
Name . . . . : TXNGRP
Description . .
Qualification criteria
Scheme . . . . . TXNGRP +
Source Config . . REDTST41 +
Target Config . . REDPRD41 +
Group . . . . . . WORKSHOP
Resource Type . . TSMODEL +
Resource Name . . OUTPUTP
Check Field . . . +
Check Operator +
Check Value . . . +
Choose a Processing Option
1 1. Transform and continue
2. Transform and lock field
3. Transform and lock record
4. Stop migration of this resource
Transform Field and Values
Change Field . . POOLNAME +
Change From . . . * +
Change To . . . . TSPOOL1 +
|
Figure 17-13 Transformation Rule
As we migrate our resources between environments, any TSQUEUE that we find in the Group that has the name of OUTPUTP has its POOLNAME field changed to the name of the pool that it needs to reside in, which in this case is TSPOOL1.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.