This topic applies only on the z/OS operating system.

Migrating a federated application server node

After the deployment manager is migrated and restarted, you can perform the actual migration of the federated application server node by running the JCL jobs that you generated using the Customization Dialog.

Before you begin

Make sure that you go through the steps outlined in Customization Dialog walk-through for migrating a managed application server node before you begin this migration. You will not be able to proceed if you have not created the JCL migration utilities through the Customization Dialog.

About this task

Note: At this point, ensure that the application servers and the node agent are stopped.

The BBOWMG1F, BBOWMG2F, and BBOWMG3F jobs referenced below must be submitted by a WebSphere Administrator User ID. All other jobs must be submitted by a user ID that has control over the file system.

Procedure

  1. Ensure that the newly migrated deployment manager is up and running.

    In order for the application server node to be properly migrated, the deployment manager must be running. In order for this migration to work, the deployment manager must be up and listening on its SOAP port.

    Check Off Item
      Access the administrative console of the Version 6.0.x deployment manager. This validates that the deployment manager is running.
    Check Off Item
      Ensure that the Version 6.0.x copy of the code is running. Under "About your WebSphere Application Server," the build number should begin with W601.
  2. Create and mount a new Version 6.0.x HFS.

    Before you perform the migration, Version 6.0.x requires an HFS to be present for your new configuration. You can run BBOWMMMT to create and mount a new HFS, or you can mount one manually. Either way, you must have an HFS for your Version 6.0.x configuration created and mounted before you proceed. This HFS is the target of the migration; your Version 5.x configuration HFS is the source.

    BBOWMMMT creates a mount point directory, allocates the configuration's HFS, and mounts the HFS at whatever value you specified on the field called "Mount Point" in the "System Environment Customization" panel in the Customization Dialog.

    Before you proceed, ensure that you have, either manually or using BBOWMMMT, allocated, created, and mounted your HFS data sets. The mount point should be owned by the WebSphere Admin ID, and have permissions of at least 755. The new HFS structures in should be included in BPXPARM so that they will be mounted at the next IPL.

  3. Copy your generated JCL procedures.

    The migration utility BBOMMCP copies the generated JCL procedures to start the servers to the specified procedure library. Your Version 6.0.x configuration must make use of different JCL start procedure names; this utility will update the new Version 6.0.x configuration, substituting your new JCL names in place of the names that existed in your original Version 5.x configuration. Submit BBOMMCP, and verify a return code of 0.

  4. Update your RACF STARTED profiles.
    The STARTED profile used by controller regions is based on the procedure name and JOBNAME. Because Version 6.0.x requires new start procedures, you must ensure that a STARTED profile will apply so that the proper identity will be assigned to the started task. For example, if your Version 5.x controller JCL procedure name is AZACR, and you specified AZ6ACR for Version 6.0.x, then you would need to create a STARTED profile for that new procedure name:
                  new controller      same identity used in
                     JCL name         V5.x configuration
                        |                    |
     RDEFINE STARTED AZ6ACR.* STDATA(USER(AZACRU) GROUP(AZCFG) TRACE(YES))
    Note:
    • Do not use a different user ID to start. There are other things tied to the user ID, and if you change the user ID other changes would also be required.
    • If your original STARTED profile was generic, for example, STARTED AZ*.* ... , you would not need to create a new STARTED profile.
    • Servant region STARTED profiles are based on JOBNAME, not procedure name. So there is no issue with the servant when you use a different procedure name.
    • Daemons and node agents are controllers, so using different procedure names for those implies a new STARTED profile.
  5. Submit BBOWMG1F.
    Note: If you are not using XA connectors, submitting BBOWMG1F and BBOWMG2F is optional. However, you should submit both jobs to ensure that your transaction logs are clear.

    Unlike in previous WebSphere Application Server for z/OS migrations, you no longer have to customize the migration utilities. This makes the migration process much more simple. BBOWMG1F, for example, is to be submitted as is.

    BBOWMG1F enables all servers on the federated application server node being migrated to start in PRR processing mode. PRR processing mode resolves any outstanding transactions, clears the transaction logs, and terminates the server. To enable PRR processing mode, follow these steps:
    1. Stop the federated application server.
    2. Submit the job BBOWMG1F as is, verify return code of 0.
    3. Restart the federated application server, wait for it to perform PRR processing and terminate automatically.
  6. Submit BBOWMG2F.

    BBOWMG2F disables PRR mode and returns all servers to normal operating state. Submit this job and verify a return code of 0. You do not need to start the servers again after this job completes.

  7. Stop the Version 5.x managed node.

    You must stop the Version 5.x managed node before proceeding.

  8. Delete and redefine the log stream.

    Perform this step only if you previously configured the transaction XA partner log or compensation log on the Version 5.x server to use a log stream.

    1. Make sure that the node is shut down.
    2. Delete and redefine the log stream.

      You can use the BBOLOGSD and BBOLOGSA jobs that were created during Version 5.x customization if you configured the server initially to use the log stream.

      The following sample shows an example of such a job:
      //RLSP1A  JOB 'xxxx,yyy,?','USERID',MSGCLASS=H,
      //         CLASS=J,MSGLEVEL=(1,1),REGION=4M,NOTIFY=&SYSUID
      //STEP1    EXEC PGM=IXCMIAPU
      //STEPLIB  DD   DSN=SYS1.MIGLIB,DISP=SHR
      //SYSPRINT DD SYSOUT=*
      //SYSIN    DD *
      
      DATA TYPE(LOGR) REPORT(YES) /* Default to show output of job */
       DELETE LOGSTREAM NAME(P1ACEL6A.W51ASA2.D)
       DEFINE LOGSTREAM NAME(P1ACEL6A.W51ASA2.D)
              LOWOFFLOAD(20)
              HIGHOFFLOAD(79)
              STG_DUPLEX(YES)
              DUPLEXMODE(UNCOND)
              STG_DATACLAS(OPERLOG)
              STG_SIZE(5000)
              HLQ(Q10RRS)
              LS_SIZE(5000)
              LS_DATACLAS(OPERLOG)
              STRUCTNAME(WAS_LOGRLS)
      /*
      

    If you are migrating nodes in a sysplex, follow this procedure for each federated node that you migrate.

  9. Submit BBOWMG3F.

    BBOWMG3F is the job that performs the physical migration of the Version 5.x node to Version 6.0.x, based on the information you supplied in the Customization Dialog. Submit BBOWMG3F. Verify that you are getting return codes of 0, and review the log files in the migration temp directory on the HFS (this directory is /tmp/migrate/directory, where directory is the numeric value specified in the Federated Node Customization panel in the Customization Dialog.

  10. Shut down the application servers and daemon.

    The daemon must be at the highest version level of any of the servers that it manages on the same LPAR. It will be at the Version 6.0.x level when this managed node is started. At this point, ensure that all nodes on the deployment manager's LPAR have been shut down.

  11. Start the managed application server node.

    Use the existing commands that you would use to start a Version 5.x application server, but replace the RACF STARTED procedure name with the value you entered in the Federated Node Customization Dialog (2 of 2) for Controller Procedure name. This command starts the Version 6.0.x federated application server. Wait until the server is finished initializing before proceeding.

    The following message is displayed on the console and in the job log of BBOS001:
    BBOO0019I INITIALIZATION COMPLETE FOR WEBSPHERE FOR z/OS CONTROL PROCESS BBOS001
    At this point, your migration to Version 6.0.x is complete.
  12. Perform the post-migration tasks.
    After you have verified a successful migration to Version 6.0.x, and are successfully running a migrated configuration, you should delete:
    • Everything in the source configuration's HFS
    • Everything in the target configuration's /tmp/migrate/nnnnn/ directory
    • The bbomigrt2.sh file

    WebSphere Application Server for z/OS Version 6.0.x requires that the daemon process be at the highest level of code of any of the servers that it manages. If there are any Version 5.1 nodes on the same LPAR and in the same cell as this migrated managed node, you must update the Version 5.1 daemon STARTED procedure to STEPLIB to the Version 6 libraries.

    For example, add the following to your Version 5.1 daemon procedure's "Z=BBO5DMNZ" member, using your library names:
    //*STEPLIB Setup
    //*
    //STEPLIB  DD DSN=hlq.SBBOLD2,DISP=SHR
    //         DD DSN=hlq.SBBOLOAD,DISP=SHR
    //         DD DSN=hlq.SBBOLPA,DISP=SHR
    //*                                      



In this information ...


IBM Redbooks, demos, education, and more

(Index)

Use IBM Suggests to retrieve related content from ibm.com and beyond, identified for your convenience.

This feature requires Internet access.

Task topic    

Terms of Use | Feedback

Last updated: Sep 20, 2010 10:03:57 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=vela&product=was-nd-zos&topic=rins51migASNz
File name: rins_51migASNz.html