The migration from a previous release of CICSPlex SM to CICS® TS Version 3.1 CICSPlex SM for a CMAS and all MASs (including those MASs that act as Web User Interface servers) that are connected to it, as well as for the CAS to which the CMAS is connected, should be completed before CICSPlex SM is restarted. When other CMASs at the previous release level are not migrated to this release, a separate CAS running at the previous release level must be provided to which the other CMASs can now connect. This is so that you can access the EUI at the other CMASs. The CAS running at the previous release level should only be used for administration of the CMAS-to-CMAS communications, for example using CMTCMDEF and CMTPMDEF, and not for normal operations or definition work.
Several skeleton post-installation members are distributed with CICSPlex SM. You should generate these post-installation members for use during the migration. (For information about generating the post-installation members, see the CICS Transaction Server for z/OS® Installation Guide.)
To enable you to revert to the previous release of CICSPlex SM if you encounter problems during the migration to CICS TS Version 3.1 CICSPlex SM, you should take back-up copies of the previous release components such as JCL, CLISTs, CICS tables, CMAS data repositories, and WUI repositories before you start the migration process.
In order to provide for concurrent previous release and Version 3.1 CASs you must create a separate Version 3.1 CAS environment.
To convert a CAS from Version 2.3, Version 2.2 or Release 4 to Version 3.1, complete these steps.
If you are running Version 2.3, Version 2.2 or Release 4, as well as Version 3.1, and your earlier releases currently share a single BBIPARM data set, your Version 3.1 CASs can share the same BBIPARM data set. (For information about using EYUDEFDS, see the CICS Transaction Server for z/OS Installation Guide.)
The Version 3.1 CAS is now ready for use.
You must migrate your CICSPlex SM CMAS to CICS TS Version 3.1 at the same time as you migrate the CICS system on which it runs. This is because in CICS Transaction Server for z/OS, Version 2 Release 3 a CICSPlex SM CMAS will run only in a CICS system at the same release level. During startup the CMAS checks the CICS release level and terminates with message EYUXL0142 if the release does not match.
To convert a CMAS to Version 3.1:
//BBIPARM DD DISP=SHR,DSN=CICSTS31.CPSM.EYUIPRM
(For information
about the CMAS startup JCL, see the CICS Transaction Server for z/OS Installation Guide.)The CMAS is ready to be cold started.
When you have successfully migrated all your systems to CICSPlex SM Version 3.1 you can delete the previous release groups and group lists from each CMAS’s CSD. (For information about how to do this, see Deleting the previous release definitions from CSD files.)
To convert a MAS to Version 3.1, you need to do the following:
To create a new group list in the CSD, use a statement of the following form as input to DFHCSDUP:
APPEND LIST(old_list) TO(new_list)
To remove a previous release group from a group list, use a statement of the following form as input to DFHCSDUP:
REMOVE LIST(new_list) GROUP(old_group)
where new_list is the group list used by the MAS and old_group is the previous release group to be removed. The old_group name depends on the type of MAS and whether CICSPlex SM code is used from the LPA. Table 38 lists the release group names for each environment.
Environment | Version 2.3 Group | Version 2.2 Group |
---|---|---|
Local MAS - USELPACOPY(NO) | EYU230G1 | EYU220G1 |
Remote MAS - USELPACOPY(NO) | EYU230G2 | EYU220G2 |
Local MAS - USELPACOPY(YES) | EYU230GB | EYU220GB |
Remote MAS - USELPACOPY(YES) | EYU230GC | EYU220GC |
The MAS is ready to be cold started.
When you have successfully migrated all your systems to CICSPlex SM Version 3.1 you can delete the previous release groups from each MAS’s CSD. (For information about how to do this, see Deleting the previous release definitions from CSD files.)
If you use the workload management functions of CICSPlex SM and you use your own version of the CICSPlex SM user-replaceable Workload Routing Action Module, EYU9WRAM, you must recompile and link-edit your version of EYU9WRAM using the Version 3.1 libraries. For information on how to do this, see the description of customizing the dynamic transaction routing program in the CICSPlex System Manager Managing Workloads manual.
If your application programs have
been modified to make a call to EYU9XLOP using the EYUAWTRA commarea, they
must also be recompiled and link-edited with the Version 3.1 libraries.
CICSPlex SM API programs written to run in a previous release MAS can be run in a Version 3.1 MAS. You can either continue to access the data provided by the previous release or access the new data available from Version 3.1. For a discussion of the compatibility between releases of the API, see the CICSPlex System Manager Application Programming Guide.
Both the Web User Interface server and the CMAS that it connects to must be at the highest level of CICSPlex SM and CICS within the CICSplex. This means that both must be at the same level as the maintenance point CMAS.
Before you migrate a Web User Interface server, you must migrate the CMAS that it connects to. You must migrate the Web User Interface server before you migrate any other MASs. If the CMAS that the Web User Interface server connects to is not the maintenance point CMAS, you must migrate the maintenance point CMAS at the same time.
As the CICS system that acts as your Web User Interface server is a local MAS, all the considerations that apply to a local MAS also apply to a Web User Interface server.
To convert a Web User Interface server to Version 3.1 you should:
If you have Web User Interface servers connected to CMASs other than the maintenance point CMAS, which have many other MASs connected to them, you might not want to migrate the other MASs at the same time as the CMAS. In that case you might consider using the following phased migration path:
Assuming you are running the latest CICSPlex SM 2.3 and 3.1 maintenance levels, you can convert one LPAR at a time from 2.3 to 3.1.
To migrate the MAS and update the Web User Interface CSD group you should follow the instructions for converting a MAS as described in Converting a MAS to Version 3.1.
You
must also replace the CSD group EYU230GW with EYU310GW in the group list used
by the Web User Interface server or create a new group list containing EYU310GW.
(For CICS Transaction Server for z/OS Version 3 Release 1 EYU310GW is included in the CSD when the CSD file is updated
with the Version 3.1 resource definitions, EYU964G1).
InCICS Transaction Server for z/OS Version 3 Release 1 some internal Web User Interface repository record versions have been incremented to facilitate the new features in view definitions For this reason, if your existing Web User Interface repository contains customized view sets or menus, it is essential that you migrate your view set and menu definitions.
To migrate the Web User Interface server repository to the current version:
For information about importing view set and menu definitions see the CICSPlex System Manager Web User Interface Guide and the CICSPlex System Manager Web User Interface Guide. For information about the starter set see the CICSPlex System Manager Web User Interface Guide.
You do not need to make any changes to existing customized views and menus you may have created but you can consider modifying or creating view sets to take into account the new attributes and resources.
When you have successfully migrated all your systems to CICSPlex SM Version 3.1, you can delete the Version 2.2 definitions from each CMAS’s and MAS’s CSD. This can be done by upgrading each CSD using module EYU9R220, which is supplied in CICSTS31.CPSM.SEYULOAD.
//CSDUP EXEC PGM=DFHCSDUP
//STEPLIB DD DSN=cics.index.SDFHLOAD,DISP=SHR
// DD DSN=cpsm.index.SEYULOAD,DISP=SHR
//DFHCSD DD DSN=cics.dfhcsd,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
UPGRADE USING(EYU9R220)
/*
When this JCL is run, EYU9R220 attempts to delete all Version 2.2 groups and group lists from the CSD. However, because not all of the items the job attempts to delete are actually defined in the CSD, DFHCSDUP gives a return code of 04. The DFHCSDUP SYSPRINT output lists those items that were deleted and those that were not found. For further information about updating the CSD, see the CICS Transaction Server for z/OS Installation Guide.
[[ Contents Previous Page | Next Page Index ]]