Migrating the AORs

  1. Quiesce an AOR and bring it down.
  2. Update this single AOR to CICS® Transaction Server for z/OS®, Version 3 Release 1, following the standard migration procedures described in CICS Transaction Server for z/OS Migration from CICS TS Version version_number.

    If you are migrating from CICS TS 2.2, part of this will involve updating the JVM profile used by the CorbaServers. Note the changes to JVM profiles and property files that were introduced in CICS TS 2.3, as described in Migration tips.

    Important:
    1. If you upgrade a CSD from CICS TS 2.2 to CICS TS for z/OS, Version 3.1 level, if it is shared by any CICS TS 2.2 regions other than that being upgraded, include the DFHCOMPA resource group (supplied with CICS TS for z/OS, Version 3.1) in the startup group list of these regions.
    2. At this stage, don't enable any new, CICS TS for z/OS, Version 3.1-specific, options on resource definitions.
  3. Bring the AOR back up again.
  4. Ensure that all TCPIPSERVICEs are open both in this AOR and in the listener regions.
  5. Use the CEMT PERFORM DJAR PUBLISH command to re-publish the IORs of one or more enterprise beans in CICS TS for z/OS, Version 3.1 format. For each CorbaServer, select one or more deployed JAR files to re-publish. When choosing deployed JAR files to re-publish, bear the following in mind:
    • Try to pick DJARs whose entire work load can be processed by a single region.
    • Wherever possible, all the beans used by an application should be migrated at the same time. For example, if bean A is known to call bean B the two beans should be migrated together. If this is not possible, bean A should be migrated first.
      This is particularly important if you are migrating from CICS TS 2.2 and the beans are installed in the same CorbaServer but in different AORs that are at different levels of CICS. This is because a CICS TS 2.2 region cannot do a JNDI look up of an object in a CICS TS for z/OS, Version 3.1 region if both objects are in the same CorbaServer. For example, bean A in CorbaServer EJB1 in a CICS TS 2.2 AOR cannot look up bean B in CorbaServer EJB1 in a CICS TS for z/OS, Version 3.1 AOR.
      Note: If A and B are installed in different CorbaServers, or in AORs that are at the same level of CICS, they can be migrated separately.

    Re-publish the selected DJARs to the JNDI name space, in the same location as that used by the back-level AORs.

    At this point :
    • This AOR is ready to accept workload.
    • The logical server contains a pool of back-level AORs and a pool (currently containing only one region) of CICS TS for z/OS, Version 3.1 AORs.
    • Any clients that look up the IOR of a re-published bean in the name space get the new IOR in CICS TS for z/OS, Version 3.1 format. Your customized routing program or CICSPlex SM directs such requests to the CICS TS for z/OS, Version 3.1 AOR.
    • Any clients that have a stale, cached, IOR for a bean that's been re-published are still able to use the bean. Your customized routing program or CICSPlex SM directs such old-format requests to one of the back-level AORs.
      Note: Many application servers cache the results of JNDI lookups locally to increase performance, so you may find that these caches have to be purged before the new IORs are used. Over a period of time, requests for re-published enterprise beans should move gradually from the pool of back-level AORs to the pool of CICS TS for z/OS, Version 3.1 AORs.
  6. Repeat steps 1 through 5 for all of the AORs in the logical server. As each AOR is upgraded:
    • Re-publish a different set of enterprise beans, so that gradually more and more beans are supported by the pool of CICS TS for z/OS, Version 3.1 regions.
    • It becomes less important, when selecting deployed JAR files to re-publish, to choose those whose entire work load can be processed by a single region—because there are more AORs in the CICS TS for z/OS, Version 3.1 pool.
    Eventually, all the AORs will be running CICS TS for z/OS, Version 3.1 and processing 100% of the workload.