迁移 z/OS 联合节点
在迁移并重新启动 Deployment Manager 之后,可以通过运行生成的 作业控制语言 (JCL) 作业来实际地迁移该 Deployment Manager 的联合应用程序服务器节点。生成定制迁移作业后,还可创建定制指示信息以在用于生成作业的 CNTL 数据集的 BBOMMINS 成员中准备和运行迁移作业。请遵循这些定制指示信息来完成将您的联合节点迁移到 V9.0 的过程。
开始之前

本文是关于概要文件配置迁移。要将应用程序迁移到最新版本,请使用 WebSphere® Application Server Migration Toolkit。有关更多信息,请参阅 WASdev 上的 Migration Toolkit。
sptcfg- 请参阅迁移、共存和互操作性的概述和迁移注意事项。
- 如果您未生成 JCL 迁移作业,那么将无法继续执行操作。
- 指示信息中引用的 BBOWMG1F、BBOWMG2F 和 BBOWMG3F 作业必须由 WebSphere 管理员用户标识提交。
所有其他作业都必须由具有文件系统控制权的用户标识提交。
- 要迁移另一 MVS™ 映像中的联合节点,务必在该节点本身所在的系统上运行这些作业。
- 提示:在迁移 WebSphere Application Server V7.0 或更高版本 联合节点时,如果您希望完成迁移后能够将其回滚到先前状态,那么必须执行以下操作:
- 使用 backupConfig 命令或您自己的首选备份实用程序来备份现有配置。
- 运行 backupConfig 命令或您自己的首选实用程序,以备份 V9.0 Deployment Manager 配置。
- 运行 backupConfig 命令或者您自己的首选实用程序,以备份 V7.0 或更高版本 联合节点配置。
要点: 请务必记录此备份配置的确切名称和位置。有关更多信息,请参阅文档中的 backupConfig 命令一文。
- 迁移联合节点。
根据需要,现在可以回滚刚刚迁移的联合节点。请参阅回滚联合节点,以了解更多信息。
- 使用 backupConfig 命令或您自己的首选备份实用程序来备份现有配置。
有关帮助信息,请参阅对迁移进行故障诊断。
关于此任务

- WebSphere Extended Deployment Compute Grid 或 Feature Pack for Modern Batch
- WebSphere Virtual Enterprise 或 Intelligent Management
过程
- 确保已停止所迁移的联合节点的应用程序服务器和 Node Agent。
必须先停止联合节点,然后再继续。
- 确保新迁移的 Deployment Manager 正在运行。
要正确地迁移应用程序服务器节点,Deployment Manager 必须正在运行。为了能够进行此迁移,Deployment Manager 必须已启动并且在侦听它的 SOAP 端口。
表 1. Deployment Manager 正在运行. 完成核对时勾选 核对完毕 项 访问 WebSphere Application Server V9.0 Deployment Manager 的管理控制台。这将验证 Deployment Manager 是否正在运行。 表 2. 应用程序服务器正在运行. 完成核对时勾选 核对完毕 项 请确保代码的 WebSphere Application Server V9.0 副本正在运行。版本列示在管理控制台的“欢迎”窗格上。 - 创建并安装新的 V9.0 配置文件系统。
在执行迁移之前,V9.0 要求存在用于新配置的配置文件系统。您可以运行 BBOMMHFS 或 BBOMMZFS 来创建和安装新的配置文件系统,也可以手动安装它。无论采用哪一种方法,都必须先创建并安装 V9.0 配置文件系统,然后才能继续执行操作。此配置文件系统是迁移目标;V7.0 或更高版本 配置文件系统是迁移源。
BBOMMHFS 或 BBOMMZFS 会创建安装点目录,分配该配置的文件系统,并使用您在生成迁移作业时对安装点指定的值安装文件系统。
在继续执行操作前,确保已手动或使用 BBOMMHFS 或 BBOMMZFS 分配、创建并安装了配置文件系统数据集。安装点应该由 WebSphere 管理员用户标识拥有,并且许可权至少为 755。应该将新配置文件系统结构包括在 BPXPARM 中,以便在下一次进行 IPL 时安装它们。
- 提交 BBOWMG1F 和 BBOWMG2F。 注: 如果未使用 XA 连接器,那么可以选择是否提交 BBOWMG1F 和 BBOWMG2F。但是,您应该提交这两个作业以确保清除事务日志。
BBOWMG1F 使要迁移的联合应用程序服务器节点上的所有服务器能够以对等重新启动和恢复 (PRR) 方式启动。PRR 处理方式将解决所有未完成事务、清除事务日志并停止服务器。BBOWMG2F 将禁用 PRR 方式并使所有服务器回到正常操作状态。
请执行下列步骤以清除 XA 事务日志:- 停止应用程序服务器。
- 提交作业 BBOWMG1F,并验证返回码是否为 0。
- 重新启动联合应用程序服务器,等待它执行 PRR 处理并自动停止。提示: 在事务解决且服务器停止后,正常情况下会返回预期的非零返回代码。以下是来自服务器进程的可接受结果代码的示例:
BBOO0035W 正在终止当前进程,原因=C9C218D5
- 提交作业 BBOWMG2F,并验证返回码是否为 0。
- 复制所生成的 JCL 过程。
迁移实用程序 BBOMMCP 会将生成的 JCL 过程(用于启动服务器)复制到指定的过程库。V9.0 配置使用的 JCL 过程必须与 V7.0 或更高版本 配置所使用的不相同。此实用程序将对新的 V9.0 配置进行更新,即,将原始 V7.0 或更高版本 配置中的现有名称替换为新的 JCL 名称。
注意: 此实用程序会将生成的 JCL 复制到过程库中。如果您指定的名称与生成迁移作业时在 V7.0 或更高版本 配置中所使用的名称相同,那么此实用程序将覆盖现有的过程。如果使用相同的名称,那么在运行此实用程序之前,务必备份现有 V7.0 或更高版本 过程,以便在将来需要回滚时使用。提交 BBOMMCP,并验证返回码是否为 0。
- 如果指定了新过程名称,请更新控制器和守护程序的 RACF® STARTED 概要文件。 控制器区域所使用的 STARTED 概要文件基于过程名称和 JOBNAME。您必须确保应用 STARTED 概要文件,以便对启动的任务指定正确的标识。例如,如果 V7.0 或更高版本 控制器 JCL 过程名称是 AZACR,并且您对 V9.0 指定了 AZ1ACR,那么需要为这个新过程名称创建 STARTED 概要文件:
新控制器 V5.x 或 V6.0.x 配置中 JCL 名称 V7.0 或更高版本的配置 | | RDEFINE STARTED AZ1ACR.* STDATA(USER(AZACRU) GROUP(AZCFG) TRACE(YES))
注:- 请不要使用另一用户标识来启动。还有其他内容与用户标识相关,如果更改用户标识,那么还需进行其他更改。
- 如果原始 STARTED 概要文件是通用的,例如 STARTED AZ*.* ...,那么不需要创建新的 STARTED 概要文件。
- 服务方区域 STARTED 概要文件基于 JOBNAME,而不是基于过程名称。因此,对于服务方来说,使用另一过程名称并不会引起问题。
- 守护程序和 Node Agent 是控制器;因此,对它们使用不同的过程名称即表示使用新的 STARTED 概要文件。
- 如果有必要的话,请删除日志流,然后重新定义它。 仅当先前已在 V7.0 或更高版本 服务器上配置事务 XA 伙伴日志或补偿日志以使用日志流时,才需要执行此步骤。
- 确保该节点已停止。
- 删除日志流,然后重新定义它。
如果最初已将服务器配置为使用日志流,那么可以使用 V7.0 或更高版本 定制期间创建的 BBOLOGSD 和 BBOLOGSA 作业。
以下样本提供了此类作业的一个示例://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) /*
如果要迁移综合系统中的节点,请对所迁移的每个联合节点完成此过程。
- 请执行下列其中一项操作:
- 提交 BBOWMG3F 作业。 注意: 在 z/OS 环境中运行并且配置为使用多个 TCP/IP 堆栈时,您可能需要添加环境变量 _BPXK_SETIBMOPT_TRANSPORT,以使迁移作业定向到应该使用的正确 TCP/IP 堆栈。如果您使用不正确的堆栈,那么结果将是生成 java.net.UnknownHostException,此异常将导致后续 wsadmin 登录失败。JCL 中需要 export _BPXK_SETIBMOPT_TRANSPORT=<stack.name> 语句来标识适当的堆栈。您的 JCL 可能类似于以下内容:
//*************************************************************** //* //* UPGRADE: Perform the migration to the new Profile //* //*************************************************************** //* //* //UPGRADE EXEC PGM=IKJEFT01,REGION=0M,COND=(4,LE) //SYSTSPRT DD SYSOUT=* //STDENV DD * // _CEE_RUNOPTS=TRAP(ON,NOSPIE) //* //SYSTSIN DD * BPXBATCH SH + export _BPXK_SETIBMOPT_TRANSPORT=TCP; + /tmp/migrate/bbomigrt2.sh WASPostUpgrade + /tmp/migrate/28133744/_ + 1>> /tmp/migrate/28133744/BBOWMG3F.out + 2>> /tmp/migrate/28133744/BBOWMG3F.err; /*
BBOWMG3F 作业根据您在生成迁移作业时提供的信息从 V7.0 或更高版本 节点物理迁移到 V9.0。提交 BBOWMG3F,并验证返回码是否为 0,然后查看配置文件系统上迁移临时目录中的日志文件。迁移临时目录为 temporary_directory_location/nnnnn,其中 temporary_directory_location 是指定为临时目录位置的目录(缺省情况下为 /tmp/migrate),而 nnnnn 是生成迁移作业时为迁移标识生成的数值。
- 提交以下三个作业:
- 提交 BBOWMPRO 作业。
BBOWMPRO 创建 Websphere Application Server 主概要文件和缺省概要文件。
- 提交 BBOWMPRE 作业。
BBOWMPRE 运行迁移升级前过程。
- 提交 BBOWMPOS 作业。
BBOWMPOS 运行迁移升级后和收尾(更改文件许可权)过程。
- 提交 BBOWMPRO 作业。
- 提交 BBOWMG3F 作业。
- 确保旧守护程序已停止。
确保此 LPAR 上同一单元中的所有联合节点都已停止。
- 如有必要,更新守护程序 JCL 过程。
WebSphere Application Server for z/OS® V9.0 要求守护进程处于它在同一 LPAR 中管理的所有服务器的最高代码级别。当此联合节点已启动时,该守护进程将处于 V9.0 级别。
将所有节点迁移到 V9.0 之后,并且在从系统中除去先前版本的库之前,必须更新守护程序 JCL 过程。如果不这样做,就会导致守护程序无法启动。
注:- 如果要从 V6.1 迁移到 V9.0,那么守护程序需要具有包含 V6.1 SBBOLD2 和 SBBOLPA 数据集的 STEPLIB。
- 如果 V9.0 单元有 V9.0 服务器与 V6.1 单元中的 V6.1 服务器通信,并且 V6.1 单元与该 V9.0 单元在同一系统上,那么还需要将 V6.1 SBBOLD2 和 SBBOLPA 数据集添加至 V9.0 守护程序的 STEPLIB。
- 启动新的联合应用程序服务器节点。
- 启动 Node Agent。 在控制台上将显示以下消息,BBON001 的作业日志也将包含此消息:
BBOO0019I INITIALIZATION COMPLETE FOR WEBSPHERE FOR z/OS CONTROL PROCESS BBON001
- 启动联合应用程序服务器。
使用要用于启动 V7.0 或更高版本 应用程序服务器的现有命令,但将 RACF STARTED 过程名称替换为生成迁移作业时在联合节点面板中为控制器过程名称输入的值。此命令将启动 V9.0 联合应用程序服务器。在继续执行下一步前,请等待直到服务器完成初始化为止。
以下消息将显示在控制台上和作业日志 BBOS001 中:BBOO0019I WebSphere for z/OS 控制进程 BBOS001 初始化完成
- 启动 Node Agent。
- 请验证是否已正确迁移配置和应用程序。
对于 Compute Grid 或 Feature Pack for Modern Batch,还要验证是否已正确迁移作业调度程序,以及您是否可以将作业分派给主管批处理应用程序的服务器。
要验证作业调度程序迁移,在 Deployment Manager 重新启动之后,通过 Web 浏览器访问作业管理控制台。
要验证用于主管批处理应用程序的服务器是否正确工作,请完成下列步骤:- 验证已迁移的服务器上的批处理应用程序是否已启动。请检查服务器日志中是否存在任何错误。
- 通过从已迁移的作业调度程序服务器中提交作业来验证您是否可以将批处理作业分派给已迁移的服务器。可以使用作业管理控制台、WSGrid 实用程序、EJB 接口或者 Web Service 接口来提交作业。
下一步做什么
- 源配置的文件系统中的所有内容
- 目标配置的 temporary_directory_location/nnnnn 目录中的所有内容,其中 temporary_directory_location 是指定为目标目录位置的目录(缺省情况下为 /tmp/migrate),而 nnnnn 是创建迁移作业时对迁移标识指定的数值。
- bbomigrt2.sh 文件


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-zos&topic=tmig_z_amn
文件名:tmig_z_amn.html