Migrating a federated node: Customization Dialog walk-through

Before you migrate a WebSphere Application Server for z/OS Version 5.x or 6.0.x node to Version 6.1.x, you must create JCL jobs (CNTL and DATA data sets) that you will run on z/OS during the actual migration. You must create these jobs before you can begin the actual migration. Walk through using the Customization Dialog to generate the JCL jobs (CNTL and DATA data sets) for migrating a federated application server node.

Before you begin

See Overview of migration, coexistence, and interoperability and Premigration considerations.

For help in troubleshooting problems when migrating, see Troubleshooting migration.

Before migrating a federated node, you must migrate its deployment manager first. If you have not migrated the deployment manager, see Migrating Network Deployment configurations then return to this article after the deployment manager is migrated.

Notes:
  • For a network-deployment cell, the applications are migrated during deployment-manager migration rather than during migration of its federated nodes.
  • You can reuse the same target data sets, file system, and JCL procedures in the Customization Dialog walk-through for your federated nodes that you used for the deployment manager if you so choose. See the system-generated instructions for BBOMMINS for complete details.
  • Default values can be accepted for all fields and settings except for those that are explicitly identified in the following steps.

Procedure

  1. Invoke the WebSphere Application Server for z/OS Version 6.1.x Customization Dialog.
    ex 'product_hlq.SBBOCLIB(BBOWSTRT)' 'options'
    • Example product_hlq: WAS610.WAS
    • Example options: appl(az)
  2. From the first menu page, select option 4: Migrate a Node.
  3. On the next panel, choose option 3: Migrate a federated node.
  4. Allocate partitioned data sets that you will use to store the generated migration jobs and supporting data.
    1. On the Federated Node Migration menu, choose option 1: Allocate target data sets.
    2. On the Allocate Target Data Sets panel, specify your high-level qualifier and then press Enter to proceed to the next panel.
    3. Accept the defaults on the next two panels that specify the parameters for the .CNTL and .DATA data sets.

    Your are taken back to the Federated Node Migration menu.

  5. On the Federated Node Migration menu, choose option 2: Define variables.

    In the following panels, the migration data collection process begins.

  6. On the Define Variables to Migrate a Federated Node menu, choose option 1: System locations (directories, HLQs, etc.).
  7. On the System Locations (1 of 2) panel, specify your Version 6.1.x installation libraries and whether you intend to put your Version 6.1 load modules in STEPLIB.

    Correctly specifying STEPLIB is essential to a successful migration. It is likely that your Version 5.x or 6.0.x modules are currently in LPA/LNKLST and that you will begin with your Version 6.1 libraries being defined in STEPLIB.

    Example:
    System Locations (1 of 2)
      
      Specify the following V6.1 information, then press ENTER to continue.
      
      For some data sets, specify "Y" if they are in STEPLIB.
      
    Full Names of Data Sets
      
      PROCLIB.:  SYS1.PROCLIB
      
      Run WebSphere Application Server from STEPLIB (Y/N)?  Y
      SBBOLPA.:  WAS610.WAS.SBBOLPA
      SBBOLOAD:  WAS610.WAS.SBBOLOAD
      SBBGLOAD:  WAS610.WAS.SBBGLOAD
      SBBOLD2.:  WAS610.WAS.SBBOLD2

    Press Enter to proceed.

  8. On the System Locations (2 of 2) panel, specify your Version 6.1.x WebSphere Application Server product directory (/usr/lpp/zWebSphere/V6R1 for example) and press Enter to proceed.
    Example:
     System Locations (2 of 2)  
     
        Specify the following, then press Enter to continue.
     
      V6.1 WebSphere Application Server product directory:  
            /usr/lpp/zWebSphere/V6R1   

    After specifying your Version 6.1.x home directory, press Enter to proceed.

    You are taken back to the Define Variables to Migrate a Federated Node menu, where option 1 is marked as completed.

  9. On the Define Variables to Migrate a Federated Node menu, choose option 2: System environment customization.
  10. On the System Environment Customization panel, specify the Version 6.1.x configuration file system.

    The configuration file system is where the configuration for the node being migrated is physically stored. You can choose to use an existing Version 6.1.x file system if you already have an appropriate file system on the node being migrated. If you choose to use an existing Version 6.1.x file system, you need to ensure that the mount point you specify here is present before running the migration utilities (BBOWMG1F, BBOWMG2F, and so on) that are created through these dialogs. If you choose to create a new Version 6.1.x file system on the node being migrated, the actual creation of the new file system will not occur until you run the BBOMMHFS or BBOMMZFS job during the migration process after you complete this walk-through. See Migrating a federated node for more information.

    Example:
     System Environment Customization
    
        Specify the following to customize your system environment, then
        press Enter to continue.
    
      WebSphere Application Server for z/OS configuration file system information
    
        Mount point....:  /WebSphere/V6R1
        Name...........:  OMVS.WAS.CONFIG.HFS
        Volume, or '*' for SMS.:  *
        Primary allocation in cylinders...:  420
        Secondary allocation in cylinders.:  100
    
        File system type (HFS or ZFS):  HFS                                         

    After specifying either an existing mount point or a new mount point and the configuration file system type, press Enter to proceed.

    You are taken back to the Define Variables to Migrate a Federated Node menu, where options 1 and 2 are marked as completed.

  11. On the Define Variables to Migrate a Federated Node menu, select option 3: Server customization.
  12. On the Server Customization (1 of 2) panel, specify or leave the defaults for all values.
    1. Specify the source node that you are migrating under From WebSphere Application Server home directory.
    2. Specify the home location of the profile that will contain your Version 6.1.x migrated node under V6.1 WebSphere Application Server home directory.
    3. Specify the procedure names used to start the Version 6.1.x servers.

      Your Version 6.1.x configuration must use different JCL procedures from those used by your Version 5.x or 6.0.x configuration. The migration process creates new Version 6.1.x JCL procedures using the procedure names specified here.

      If you want to use your existing procedure names, specify "N" in the Replace Started Procedure Command Names field.
      Caution: If you use the same names as you used in your Version 5.x or 6.0.x configuration, the migration process overlays the existing procedures. If you are using the same names, make sure that you back up the existing Version 5.x or 6.0.x procedures before running the jobs generated by the Customization Dialog in case you need to roll back later.
    Example:
    Server Customization (1 of 2)
      
       Specify the following to customize your migration, then press Enter 
       to continue. 
      
       From WebSphere Application Server home directory:
          /WebSphere/V5R1M0 
             / AppServer 
      
       V6.1 WebSphere Application Server home directory:
          /WebSphere/V6R1
             / AppServer 
      
       Replace Started Procedure Command Names:  Y  
      
         Daemon Procedure name.........:  BBO6DMN
      
         Controller Procedure name.....:  BBO6ACR
      
         Servant Procedure name........:  BBO6ASR
      
         Adjunct Procedure name........:  BBO6CRA

    After you have specified or left the defaults for all values, press Enter to proceed to the next panel.

  13. On the Server Customization (2 of 2) panel, specify the migration options and application migration settings.
    1. Specify whether or not to migrate to support script compatibility.

      This field specifies whether (Y) or not (N) migration should create the following Version 5.x or 6.0.x configuration definitions:

      • Transport
      • ProcessDef
      • Version 5.x or 6.0.x SSL
      • Version 5.x or 6.0.x ORB service threadpool

      instead of the following Version 6.1.x configuration definitions:

      • Channels
      • ProcessDefs
      • Version 6.1.x SSL
      • Version 6.1.x ORB service threadpool

      Choose to migrate to support script compatibility if you want to minimize impacts to existing administration scripts. If you have existing wsadmin scripts or programs that use third-party configuration APIs to create or modify the Version 5.x or 6.0.x configuration definitions, for example, you might want to choose this option during migration.

      Note: This is meant to provide a temporary transition until all of the nodes in the environment are at the Version 6.1.x level. When they are all at the Version 6.1.x level, you should perform the following actions:
      1. Modify your administration scripts to use all of the Version 6.1.x settings.
      2. Use the convertScriptCompatability command to convert your configurations to match all of the Version 6.1.x settings.

        See convertScriptCompatibility command.

    2. Specify whether or not to enable tracing on the migration utilities.

      If you choose to enable tracing, it will remain enabled throughout the entire migration process.

    3. Specify the location of the temporary directory for the migration configuration backup, temporary, output, and error files.

      During migration, a backup copy of the Version 5.x or 6.0.x configuration is required. The default location of this backup is already specified, though you can override if needed. You might need to specify a location other than the default if the /tmp file system does not have adequate space to store the backup configuration. If you choose to override the default location of the backup copy, the best practice is to keep the same naming convention and just replace the /tmp portion with another path, /myTemp/migrate for example.

    4. Note the migration identifier.

      The five-digit migration identifier (54700 in this example) is generated uniquely each time you create the migration jobs. The migration output messages, which you will need to monitor throughout the migration process, are stored in /tmp/migrate/54700. (After migration, the job output in this directory is NOT automatically deleted.) The migration output messages are also appended to the JCL sysout messages, which can be viewed in SDSF.

    5. Specify an administrator user ID and password.

      Because the migration jobs perform administrative functions, you need to supply a valid administrator user ID and password here.

    Example:
    Server Customization (2 of 2)
      
       Specify the following to customize your migration, then press Enter 
       to continue.   
      
       Migration Options
      
         Migrate to support script compatibility:  Y
         Enable Tracing: Script:  N  Profile:  N  PreUpgrade:  N  PostUpgrade:  N  
         Temporary Directory Location:  /tmp/migrate
         Migration Identifier........:  54700
      
         WebSphere Administrator User ID.:  XXXXXX 
         WebSphere Administrator Password:  XXXXXXXX
    

    Specify values or accept defaults, and press Enter to proceed.

    You are returned to the Define Variables to Migrate a Federated Node menu.
  14. Press PF3 to return to the Federated Node Migration menu.
  15. On the Federated Node Migration menu, choose option 3: Generate customization jobs.
  16. On the Generate Customization Jobs panel, provide a job card customized to your environment-specific requirements.

    On the Generate Customization Jobs panel, you can see the names of the .CNTL and .DATA data sets that have been customized based on your previous input.

    Example:
    Generate Customization Jobs  
      
     This portion of the Customization Dialog generates the jobs you must  
     run after you complete this dialog process. You must complete the  
     customization process before you generate the jobs with this step. 
     If you have not done this, please return to that step.  
      
     Jobs and data files will get generated into data sets:  
       'hlq.CNTL'  
       'hlq.DATA'  
     If you wish to generate customization jobs using other data sets, then
     exit from this panel and select the "Allocate target data sets" option.
      
    All the jobs that will be tailored for you will need a job card.
    Please enter a valid job card for your installation below. The 
    file tailoring process will update the job name for you in all the  
    generated jobs, so you need not be concerned with that portion of   
    the job cards below. If continuations are needed, replace the  
    comment cards with continuations. 
      
    Specify the job cards, then press Enter to continue.
      
    //jobname JOB (ACCTNO,ROOM),'IBMUSER',CLASS=A,REGION=0M  
    //*
    //*
    //*
    

    After you enter an appropriate job card, press Enter.

    The generation process runs and presents you with a list of job streams and files that have been created to perform the migration to Version 6.1.x. These jobs do not require any editing; they are to be submitted "as-is" during the migration process.

  17. When processing has completed, press Enter to proceed.
    Example:
    Processing for data set 'hlq.CNTL' ...
    Member BBOWMG1F successfully created.
    Member BBOWMG2F successfully created.
    Member BBOWMG3F successfully created.
    Member BBOMMHFS successfully created.
    Member BBOMMCR successfully created.
    Member BBOMMCRZ successfully created.
    Member BBOMMDN successfully created.
    Member BBOMMDNZ successfully created.
    Member BBOMMSR successfully created.
    Member BBOMMSRZ successfully created.
    Member BBOMMCP successfully created.
    Member BBOMMINS successfully created.
    
    Processing for data set 'hlq.DATA' ...
    Member BBOWBMPT successfully created.
    Member BBOWMMRF successfully created.
    ***   
  18. On the Federated Node Migration menu, save your configuration variables for future reference by selecting option S: Save customization variables.

    You have now completed the job generation process and are ready to begin the process of migration.

  19. See the instructions for performing the migration by selecting option 4: View instructions.

What to do next

  1. To migrate your federated node, follow the instructions in the BBOMMINS member of the CNTL data set that you generated.

    See Migrating a federated node for details.

  2. After you migrate the federated node, use the WebSphere Application Server for z/OS Version 6.1.x administrative console or scripting to administer it.



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 Task topic    

Terms and conditions for information centers | Feedback

Last updatedLast updated: Aug 31, 2013 12:02:36 AM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=pix&product=was-nd-zos&topic=tmig_z_cdwalkmn
File name: tmig_z_cdwalkmn.html