[z/OS]

Migrating a standalone application server: 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 migration option within the Customization Dialog to generate the JCL jobs (CNTL and DATA data sets) for migrating a standalone 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.

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, select option 1: Migrate a standalone application server node.
  4. Allocate partitioned data sets that you will use to store the generated migration jobs and supporting data.
    1. On the Standalone Application Server Migration menu, select 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.

    You are taken back to the Standalone Application Server Migration menu.

  5. On the Standalone Application Server Migration menu, select option 2: Define variables.

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

  6. On the Define Variables to Migrate a Standalone Application Server Node menu, select 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.x 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.x 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).
    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 Standalone Application Server Node menu, where option 1 is marked as completed.

  9. On the Define Variables to Migrate a Standalone Application Server Node menu, select 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 that you specify here is present before running the migration utilities (BBOWMG1B, BBOWMG2B, 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 BBOMBHFS or BBOMBZFS job during the migration process after you complete this walk-through. See Migrating a standalone application server 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...:  250
        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 Standalone Application Server Node menu, where options 1 and 2 are marked as completed.

  11. On the Define Variables to Migrate a Standalone Application Server 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 (55449 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/55449. (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 your preference for the migration of applications.

      Choose one of the following options:

      Y
      Install user enterprise applications in the Application Installation Directory as part of the migration.
      S
      Prepare user enterprise applications for installation in the WebSphere Application Server Version 6.1.x installableApps directory without actually installing them during migration.
      JACL scripts that can be used to install these applications are generated and saved in the migration backup directory. For WebSphere Application Server for z/OS, the location of this backup directory is relative to the temporary directory that you specify on this same panel. The location of the backup directory is also determined by the derived migration identifier and the type of node being migrated. If you specify /tmp/migrate as the temporary directory and the derived migration identifier is 55449, for example, then the location of the generated JACL scripts is:
      /tmp/migrate/55449/nodetype_backup/
      where nodetype is dmgr, fed, or base depending on the type of node that you are migrating.
      You can then run these files at any point and in any combination after migration has completed. You can also reorganize and combine these JACL files for better application installation efficiency. Here is an example of how to use the wsadmin tool to run a generated JACL script to install an application:
      wsadmin -f install_ivtApp.ear.jacl 
      P
      Install user enterprise applications as part of the migration, and keep the same application installation directories as the previous version.
      Restrictions: If you select this option, the location is shared by the existing WebSphere Application Server Version 5.x or 6.0.x installation and the Version 6.1.x installation. If you keep the migrated applications in the same locations as those of the previous version, the following restrictions apply:
      • The WebSphere Application Server Version 6.1.x mixed-node support limitations must be followed. This means that the following support cannot be used when evoking the wsadmin command:
        • Precompile JSP
        • Use Binary Configuration
        • Deploy EJB
      • You risk losing the migrated applications unintentionally if you later delete applications from these locations when administering (uninstalling for example) your Version 5.x or 6.0.x installation.
      • Any application that is installed in a directory location relative to a WebSphere Application Server variable is migrated to a directory under the value of that variable.
        If the binariesURL in the deployment.xml file for an application being migrated has a path that is relative to WebSphere Application Server—that is, it begins with $(APP_INSTALL_ROOT), $(WAS_INSTALL_ROOT), and so on—the new WebSphere Application Server variable value is used to resolve the path when the application is installed in the new location. This leads to the following results when you select this option:
        • Any application that is installed in a directory location relative to a WebSphere Application Server variable is installed under that variable value in Version 6.1.x.
        • Any application that is installed in a directory location that is not relative to a WebSphere Application Server variable is migrated and overwritten in that same directory. If an application is installed in the /employee_records/retrieval_Apps directory, for example, the application is migrated and overwritten in the /employee_records/retrieval_Apps directory.
      N
      Do nothing with user enterprise applications.

      WebSphere Application Server system applications will migrate regardless of the value set here.

    6. Specify the directory in which to install the applications if you choose to install user enterprise applications in the Application Installation Directory as part of the migration.
    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........:  55449
     
       Application Migration Settings:  
     
         Application Migration Preference:  Y   (Y/S/P/N)
         (Y) Migrate and install applications using the Application  
             Installation Directory. 
         (S) Migrate Applications and generate scripts for later installation.
         (P) Migrate Applications and keep the same application installation 
             directories as the previous version.
         (N) Do not migrate applications. 
     
         Application Installation Directory: 
            ==> /WebSphere/V6R1/AppServer/profiles/default/installedApps

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

    You are returned to the Define Variables to Migrate a Standalone Application Server Node menu.

  14. Press PF3 to return to the Standalone Application Server Migration menu.
  15. On the Standalone Application Server Migration menu, select 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 BBOWMG1B successfully created.  
    Member BBOWMG2B successfully created.  
    Member BBOWMG3B successfully created.  
    Member BBOMBHFS successfully created.  
    Member BBOMBCR successfully created.
    Member BBOMBCRZ successfully created.  
    Member BBOMBDN successfully created.
    Member BBOMBDNZ successfully created.  
    Member BBOMBSR successfully created.
    Member BBOMBSRZ successfully created.  
    Member BBOMBCP successfully created.
    Member BBOMBINS successfully created.  
     
    Processing for data set 'hlq.DATA' ... 
    Member BBOWBMPT successfully created.  
    Member BBOWMBRF successfully created.  
    *** 
  18. On the Standalone Application Server 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. Follow the instructions in the BBOMBINS member of the CNTL data set that you generated.

    See Migrating a standalone application server for details.

  2. After you migrate the standalone application server, 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 2:56:59 AM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=pix&product=was-nd-dist&topic=tmig_z_cdwalksas
File name: tmig_z_cdwalksas.html