CN110494849B

CN110494849B - 用于确定跨平台应用迁移的成功的系统和方法

Info

Publication number: CN110494849B
Application number: CN201780089089.5A
Authority: CN
Inventors: 张玮绚; 慎辉; 唐方智; 朱维国
Original assignee: Oracle International Corp
Current assignee: Oracle International Corp
Priority date: 2017-03-31
Filing date: 2017-03-31
Publication date: 2023-05-26
Anticipated expiration: 2037-03-31
Also published as: WO2018176356A1; CN110494849A

Abstract

根据实施例，本文描述的是用于确定应用从大型机平台到开放平台的迁移成功的系统和方法。与大型机平台相关联的第一数据库和与开放平台相关联的第二数据库可以包括相同的数据基线。可以在第一数据库和第二数据库上创建一组触发器，以捕获通过在每个平台上执行与应用相关联的作业而生成的数据库修改事件，并将数据库修改事件存储在每个数据库的表中。可以下载并比较来自大型机平台和开放平台的数据库修改事件，以确定应用迁移的成功。

Description

用于确定跨平台应用迁移的成功的系统和方法

本专利文献的公开内容的一部分包含受版权保护的素材。版权拥有者不反对任何人对专利文献或专利公开内容按照其在专利商标局的专利文件或记录中出现的那样进行传真复制，但是除此之外在任何情况下都保留所有版权权利。

技术领域

本发明的实施例一般而言涉及应用服务器和应用重新托管(rehosting)，并且特别地涉及用于确定从大型机平台(mainframe platform)到开放平台的应用迁移的成功的系统和方法。

背景技术

为了降低成本并尽可能地变得敏捷，当今的组织正在越来越多地寻求将业务关键型大型机应用转移到开放系统和云环境中。但是，这样做往往意味着复杂、昂贵且资源繁重的应用迁移项目，这阻碍了公司进行这样的迁移。因此，组织需要可扩展、可靠且高性能的应用迁移解决方案，该应用迁移解决方案可以帮助组织过渡到开放系统和云环境。

当用户将大型机应用迁移到开放系统(例如，Unix/Linux平台)时，需要用于确定迁移的成功的可靠方法。

发明内容

根据实施例，本文描述的是用于确定应用从大型机平台到开放平台的迁移的成功的系统和方法。与大型机平台相关联的第一数据库和与开放平台相关联的第二数据库可以包括相同的数据基线(baseline)。可以在第一数据库和第二数据库上创建一组触发器，以捕获由在每个平台上执行与应用相关联的作业而生成的数据库修改事件，并将数据库修改事件存储在每个数据库的表中。可以下载并比较来自大型机平台和开放平台的数据库修改事件，以确定应用迁移的成功。

附图说明

图1图示了根据实施例的示例性开放系统。

图2-3图示了根据实施例的如图1所示的事务中间件系统的示例。

图4图示了根据实施例的用于在开放平台中提供作业控制语言(JCL)执行引擎的系统。

图5图示了根据实施例的用于确定从大型机平台到开放平台的应用迁移的成功的系统。

图6进一步图示了根据实施例的用于确定从大型机平台到开放平台的应用迁移的成功的系统。

图7进一步图示了根据实施例的用于确定从大型机平台到开放平台的应用迁移的成功的系统。

图8图示了根据实施例的用于确定从大型机平台到开放平台的应用迁移的成功的流程图。

图9图示了根据实施例的用于确定从大型机平台到开放平台的应用迁移的成功的方法。

具体实施方式

随着公司面临越来越大的压力来从其IT支出中提供更多的业务价值并为新业务计划腾出资金，越来越多的公司正在将其大型机应用迁移到开放系统/重新托管平台，以降低大型机成本并实现遗留(legacy)应用的现代化。

如在文档中所使用的，可以互换地使用重新托管平台和开放平台。Oracle^TMTuxedo应用运行时(Application Runtimes,ART)是示例开放平台或重新托管平台。

重新托管平台/开放平台

图1图示了根据实施例的示例性开放平台。

如图1所示，重新托管平台101和重新托管工作台125可以提供开放系统/平台，用于在较低成本平台上重新托管大型机应用和数据129而不损失业务价值或牺牲服务质量(QoS)。

根据实施例，将重新托管的大型机应用和数据129当前可以运行在大型机平台(大型机平台)127(例如IBM^@大型机平台)上；并且可以包括客户信息控制系统(CICS)131、信息管理系统(IMS)135、DB2数据库137、一个或多个数据文件(例如，顺序文件)138、以及虚拟存储访问方法(VSAM)文件管理系统139。

根据实施例，CICS和IMS可以是大型机平台上的中间件产品。CICS是繁重且严格的事务处理管理系统，该事务处理管理系统被设计为支持快速、大量的在线事务处理。IMS是基于消息的轻量级事务处理管理系统。中间件产品可以用于托管用COBOL、PL/I、C、汇编或4GL编写的业务逻辑。VSAM可以包括可以由应用程序使用以管理其数据的不同的文件组织。文件组织可以包括密钥序列化数据集密钥(KSDS)、相对记录数据集(RRDS)、条目序列化数据集(ESDS)和线性数据集(LDS)。

此外，大型机平台127可以包括批处理执行环境140，该批处理执行环境140可以支持作业控制语言(JCL)141和作业条目子系统(JES)143。JCL可以是用于在大型机平台上实现批处理的脚本语言。JES可以是大型机平台上的操作系统的主要组件、可以将作业接收到大型机平台中、调度作业以进行处理、以及控制其输出处理。

如图1中进一步所示，重新托管平台可以包括与大型机平台兼容以在很少或没有变化的情况下运行大型机应用的软件栈，以最小化迁移的风险和成本；以及用于监视重新托管平台的集成管理和监视组件113。软件栈可以提供一组与大型机兼容的功能，以保留CICS、IMS以及批处理应用逻辑和数据。

根据实施例，软件栈可以包括用于托管大型机应用的多个应用运行时(ART)109，例如，CICS应用运行时115、IMS应用运行时117和批处理应用运行时119。多个应用运行时和重新托管工作台125可以用于将大型机应用129从大型机平台127迁移142到重新托管平台101。

根据实施例，CICS应用运行时可以包括一组Tuxedo服务器以模拟大型机CICS的核心特征。Tuxedo系统服务器可以提供底层应用服务器功能，包括集群管理、请求路由、健康状况监视、重启、故障切换(failover)、负载均衡、事务管理、通信信道和网关(ATMI、CICS、IMS、SOAP/HTTP web服务、Java/JCA、.Net、ESB)和协议转换。

根据实施例，IMS应用运行时可以提供用于由从大型机平台127迁移的COBOL/C应用使用的一组DL/I调用；用于处理来自多个3270终端的并发连接的鲁棒会话环境；提供OLTP以经由调用迁移的COBOL/C应用来处理从3270终端接收到的事务代码的鲁棒执行环境；以及重新托管平台上的DB插件。

根据实施例，批处理应用运行时119可以包括一组Tuxedo服务器以模拟大型机JES核心特征。例如，批处理应用运行时可以提供批处理管理和多个JES功能(例如，作业队列、类、优先级和启动器)。

根据实施例，重新托管工作台可以用于使用重新托管工作台中的迁移工具来自动化代码和数据迁移。代码和数据可以包括COBOL程序、copybook、BMS屏幕、JCL和DB2 DDL。代码和数据可以从大型机平台127传送到重新托管工作台，该重新托管工作台可以解析源对象、计算依赖性、生成元数据，并产生报告以指示代码和数据中的任何丢失的对象或未使用的对象。

根据实施例，在解析代码和数据之后，可以运行用于文件和DB2表的数据迁移工具，然后是用于COBOL JCL的代码迁移工具。代码迁移工具可以应用复杂的语言处理来在编译器方言(dialect)之间调整COBOL代码、变换JCL、针对DB2和Oracle DB之间的差异调整SQL调用。对于数据迁移，数据迁移工具可以在重新托管平台101中生成目标模式，包括Oracle DDL，并且可以自动化数据重新加载到所生成的目标模式。

根据实施例，重新托管工作台可以在UNIX命令行模式和Eclipse IDE图形环境中使用；并且可以为重新托管平台生成系统配置文件以促进配置管理并简化部署处理。

软件栈可以在分布式事务处理中间件系统121(例如Oracle Tuxedo)上执行。分布式事务处理中间件系统可以在开放系统环境(例如UNIX、Linux或Windows)上运行。分布式事务处理中间件系统可以包括本机分布式体系架构，以从应用的角度为IMS和CICS提供事务管理器特征。

根据实施例，分布式事务处理中间件系统可以表示面向事务的中间件，或者为高可用性而设计的企业应用服务器，并且提供可伸缩的应用以支持各种分布式系统上的事务。

分布式事务处理中间件系统的示例可以包括Tuxedo(分布式操作被增强的UNIX事务)，它是用于跨各种操作系统平台和数据库分发应用的基于消息的通信系统。

Tuxedo允许将消息排队到持久性或非持久性存储装置(存储器)以供以后处理或检索。Tuxedo中的应用到事务监视器接口(ATMI)可以提供允许将消息添加到队列或从队列读取消息的接口。Tuxedo可以通过操作系统(OS)进程间(inter-process)在ATMI客户端和服务器之间传递服务请求消息。在Tuxedo中，请求被发送到命名服务，并且Tuxedo使用基于存储器的进程间通信工具将请求排队到服务器。

重新托管的大型机应用可以作为Tuxedo服务运行，并且可以经由多个适配器102(例如，web服务网关适配器103、企业服务总线(ESB)适配器105和企业储存库适配器107)利用SOA集成和启用能力。

根据实施例，重新托管/迁移的应用可以被配置为经由标准WSDL暴露遗留组件中的多个服务接口，并提供鲁棒的双向web服务网关能力。例如，web服务网关适配器103(其示例可以是Oracle服务体系架构利用Tuxedo(SALT)适配器)可以使得重新托管的应用能够参与SOA环境。

此外，重新托管的应用还可以使用具有内置Tuxedo传输的ESB适配器105来进行异构消息传送。可以经由企业储存库适配器107将web服务和ESB端点导入到企业储存库中，以提供可见性、服务依赖性跟踪以及服务生命周期治理的其它益处。

如图1中进一步所示，根据实施例，分布式事务处理中间件系统可以在工程化系统和硬件100(诸如Oracle Exalogic和Oracle Exadata)上执行；并且可以包括集群数据库123，诸如Oracle REAL应用集群。集群数据库可以支持将多个单独系统用作一个集群虚拟数据库服务器；并且可以提供对由集群中所有节点共享的数据库的读写访问的透明同步、数据库工作负载的动态分配以及针对系统故障的透明保护。

根据实施例，通过组合分布式事务处理中间件系统、集群数据库、工程化系统和多个开放系统产品，上述系统可以为重新托管的大型机应用提供所需的可靠性、可用性、可伸缩性和性能。

图2-3图示了根据实施例的如图1所示的事务中间件系统121的示例。

根据实施例，Tuxedo(分布式操作被增强的UNIX事务)可以是事务中间件系统的示例。Tuxedo表示可以作为操作系统(例如，UNIX)的扩展进行操作的中间件产品或系统。作为用于执行和开发的平台，Tuxedo被设计用于创建和管理电子商务(e-commerce)在线事务处理(OLTP)系统。

根据实施例，图2-3中所示的Tuxedo系统可以包括用于数据缓冲区的通信、事务和管理中的应用到事务监视器接口(ATMI)环境。

如图2所示，ATMI环境可以包括外部接口层211、ATMI层213、系统服务层215和资源管理器层217。外部接口层可以提供用户与ATMI环境之间的多个接口。ATMI层可以表示应用与ATMI环境之间的接口。系统服务层可以为开发和管理应用提供服务和/或能力。

根据实施例，Tuxedo系统可以使用基于消息的通信系统来跨各种操作系统平台和数据库来分发应用。

如图3所示，ATMI环境内的通信可以通过传送消息来完成。Tuxedo系统可以通过操作系统(OS)进程间通信(IPC)消息队列(例如，请求队列311和应答队列313)在ATMI客户端与服务器之间传递服务请求消息。系统消息和数据可以在缓冲区中服务器和客户端的OS支持的基于存储器的队列之间传递。

根据实施例，ATMI环境中的消息可以在类型化缓冲区中打包，该类型化缓冲区可以表示既包含消息数据又包含标识正在被发送的消息数据的类型的数据的缓冲区。

根据实施例，批处理应用运行时119可以提供允许大型机批处理应用不变地运行的实用程序和服务的组合，从而保留现有的业务逻辑和数据。

根据实施例，大型机批处理作业可以表示工作单元，该工作单元可以包括多个作业步骤并且每个作业步骤可以由JCL脚本中的一组作业控制语句指定。JCL脚本可以识别要执行的一个或多个程序、所需的输入以及输入/输出的位置。

由此，用于大型机批处理作业的工件(artifact)可以包括JCL脚本和相关程序(例如，COBOL程序)和数据。可以经由客户端应用使用JCL脚本提交批处理作业以供执行。

根据实施例，在大型机批处理作业从大型机平台迁移到重新托管平台之后，需要将大型机批处理作业的JCL脚本转换成一个或多个KSH脚本，以便在重新托管平台中执行。

一旦被转换，大型机应用就将是不同的应用，这使得维护原始应用的知识和技能无用，并且使得当需要确定转换后的应用是否已成功地在重新托管平台上执行时，难以将转换后的应用与原始应用进行比较。

如图4所示，重新托管平台101可以为JCL作业提供本机支持。本机支持可以使得重新托管平台在不转换JCL作业的情况下运行它们。

根据实施例，批处理应用运行时119可以在多个层中提供多个软件模块/组件以使得能够对JCL作业进行本机支持，其中多个层例如生命周期控制层421、执行层424和实用程序/应用层431。

根据实施例，生命周期控制层可以被配置为管理JCL作业的生命周期，并且管理JCL作业的高可用性、可伸缩性、管理和监视。执行层可以包括被配置为解析从大型机JCL作业转换的KSH作业的KSH执行引擎427；以及被配置为执行大型机JCL作业而不转换它们的JCL执行引擎429。

如图4所示，生命周期控制层可以包括可以从客户端应用409接收KSH作业437和JCL作业439的提交的逻辑作业队列411，以及分布在多个服务器上的多个作业启动器(例如，作业启动器413)。客户端应用可以是用于提交作业、保持作业、释放作业、取消作业、清除作业、显示作业信息或订阅作业状态变化的事件的命令接口。示例客户端应用可以是Oracle Tuxedo客户端。

根据实施例，逻辑作业队列可以对KSH作业和JCL作业进行排队，其中每个作业与指定作业优先级的元数据相关联。多个作业启动器可以被配置为使作业从逻辑作业队列中出列，并且基于作业的性质(例如，作业是KSH作业还是JCL作业)将每个出列的作业或者调度给作业执行引擎或者调度给KSH执行引擎。可能存在JCL执行引擎的多个运行实例，以及KSH执行引擎的多个运行实例。

根据实施例，实用程序/应用层431可以包括被配置为将由JCL执行引擎调用的一个或多个应用435和一个或多个z/OS内置实用程序433。应用可以是被识别为在JCL脚本中执行的程序。该层中的示例应用可以是COBOL程序或COBOL可执行文件(executable)。

根据实施例，当JCL执行引擎接收到JCL作业时，它可以从JCL作业生成语句序列，并且将序列中的语句排序到双链接序列中。JCL执行引擎可以执行JCL作业中的JCLLIB和INCLUDE语句以包含由JCL作业引用的代码，并解析语句序列以合成逻辑作业树或作业元素层次结构。作业元素层次结构可以包括多个步骤(例如，IF/THEN/ELSE/ENDIF、CNTL/ENDCNTL)，每个步骤包含一个或多个DD，每个DD包含一个或多个连接的DD。最后，可以执行JCL作业。

确定迁移成功

在将大型机应用从大型机平台迁移到开放平台之后，用户将需要确定迁移是否成功。

通常，大型机应用的迁移成功可以通过利用与应用相关联的程序、数据和脚本的作业的执行成功来确定。

例如，可以检查作业的返回代码以确定是否已接收到预期值。零意味着作业已成功执行，并且非零值意味着发生警告/错误。可以从作业执行进程的退出代码或从作业执行日志文件中检查此类验证。

但是，作业执行可能需要外部资源，例如，驻留在盘文件或者数据库表上的数据。由此，除了作业的返回代码之外，还需要验证对外部资源的更改来确定作业已成功执行。

为了验证数据更改，需要在大型机平台和开放平台两者上启动作业，并且需要比较来自两个平台的数据库结果，以确定作业是否已经在两个平台上执行了相同的数据更新操作。

但是，假设大型机平台和开放平台的数据基线相同，由于数据的大小以及平台上不同的数据库表定义，直接比较结果可能很困难。

根据实施例，本文描述的系统和方法可以用于确定应用从大型机平台到开放平台的迁移成功。与大型机平台相关联的第一数据库和与开放平台相关联的第二数据库可以包括相同的数据基线。可以在第一数据库和第二数据库上创建一组触发器，以捕获由在每个平台上执行与应用相关联的作业而生成的数据库修改事件，并将数据库修改事件存储在每个数据库的表中。可以下载并比较来自大型机平台和开放平台的数据库修改事件，以确定应用迁移的成功。

根据实施例，第一数据库可以是DB2数据库，并且第二数据库可以是Oracle数据库。数据库触发器可以用于捕获在两个平台上执行作业所导致的所有数据更新操作。

根据实施例，测试应用可以被配置为访问两个平台以在DB2和Oracle数据库上安装数据库触发器，并在大型机平台和开放平台上启动JCL作业。

对于DB2，可以在与JCL作业相关联的多个表中的每个表上安装数据库触发器。对于Oracle数据库，可以以类似的方式安装数据库触发器。

根据实施例，当JCL作业从测试应用被启动并在每个平台上被执行时，每个平台的数据库上的数据库触发器可以被触发以生成修改事件。测试应用可以用于从每个数据库下载数据库修改事件，并调用比较逻辑来比较两组数据库修改事件。

根据实施例，大型机应用A 511(批处理应用)可以与JCL脚本、一个或多个程序和数据相关联；并且可以迁移到重新托管平台/开放平台，如应用A'513所示。

如图5所示，大型机应用A可以与大型机数据库(例如，DB2数据库)537中的用于存储与大型机应用相关联的数据的多个表(例如，表A 529和表B 530)相关联。

类似地，应用A'可以与重新托管数据库(例如，Oracle数据库)521中的用于存储与大型机应用相关联的数据的多个表(例如，表A'522和表B'524)相关联。

根据实施例，重新托管工作台可以用于在重新托管数据库中重新创建与大型机应用A相关联的多个表，并将该多个表中的数据克隆到重新托管平台，使得两个数据库可以具有相同的数据基线。

如图5中进一步所示，用户501可以使用测试管理器应用520(例如，Oracle测试管理器)来创建脚本，以用于为重新托管数据库中的多个表创建数据库触发器523，以及用于为大型机数据库中的多个表创建数据库触发535。可以分别为大型机数据库和重新托管数据库创建修改事件表(例如，修改事件表C 531和修改事件表C'525)，用于存储由每个平台中的数据库触发器捕获的数据库修改事件。

根据实施例，可以从测试管理器应用启动或提交一个或多个批处理作业。如上所述，重新托管平台可以提供用于执行JCL作业而无需将JCL作业转换成KSH作业的JCL执行引擎。由此，在将相关程序和数据从大型机平台迁移到重新托管平台之后，批处理应用的JCL脚本可以用于从测试管理器应用向重新托管平台和大型机平台两者提交或启动批处理作业。

在示例实现中，JCL脚本可以驻留在测试管理器应用中，并且可以经由FTP提交到每个平台，以在每个平台上启动批处理作业。

根据实施例，每个数据库中的数据库触发器可以监听由每个平台中的批处理应用发出的SQL语句、捕获由SQL语句生成的数据库修改事件、并将数据库修改事件保存到对应的修改事件表525或531中。

根据实施例，当在两个平台上使用触发器记录数据库修改事件时，以下规则适用：针对插入操作记录所有新(NEW)值；针对更新(UPDATE)操作记录所有旧(OLD)和新值；并且针对删除(DELETE)操作记录所有旧值。

根据实施例，测试管理器应用可以包括修改事件比较逻辑组件545。在两个平台上完成一个或多个批处理作业的执行之后，数据库修改事件数据可以从重新托管数据库和大型机数据库被下载547、549，并且被提供给修改事件比较逻辑组件。修改事件比较逻辑组件可以比较来自两个平台的修改事件数据，以确定来自每个平台的数据是否包含相同的一组数据库修改事件。如果来自每个平台的数据包含相同的数据库修改事件，则批处理应用的迁移成功；否则，迁移不成功。

根据实施例，测试管理器应用可以在重新托管平台或另一个开放系统上运行，并且可以与重新托管数据库客户端619和大型机数据库客户端613相关联。

根据实施例，重新托管数据库可以是Oracle数据库，并且大型机数据库可以是DB2数据库。在该移植中，重新托管数据库客户端可以是被配置为连接到Oracle数据库的Oracle客户端，并且大型机客户端可以是被配置为连接到DB2数据库的DB2客户端。

根据实施例，可以生成用于大型机数据库615的触发器脚本和用于重新托管数据库617的触发器脚本，并且经由用于大型机数据库和重新托管数据库的数据库客户端来执行这些触发器脚本，以在每个数据库中创建多个触发器535和多个触发器523。

如图7所示，来自每个数据库的修改事件数据可以被下载711、713到客户端应用，并且可以被提供给修改事件比较逻辑组件。

根据实施例，来自每个数据库的数据库修改事件数据可以包含在纯文本文件中。每个纯文本文件可以包括来自每个数据库的多个数据库事件，例如插入(INSERT)、更新(UPDATE)和删除(DELETE)。

由于数据库修改事件来自不同的数据库产品，因此它们的格式可能不同。修改事件比较逻辑组件可以包括用于解析每个纯文本文件的代码，并且格式化来自每个数据库的修改事件，使得可以在两个纯文本文件之间执行有意义的比较来确定是否在每个平台上已发生相同的一组修改事件。

根据实施例，基于一个或多个批处理作业的执行在数据库修改方面是否在两个平台上显示相同的行为，测试管理器应用可以确定大型机应用是否已在开放/重新托管平台上成功地执行，以及因此大型机应用是否迁移成功。

如图8所示，在步骤811处，将应用从大型机平台迁移到重新托管平台/开放平台，并且将与应用相关联的一个或多个表从大型机平台的大型机数据库复制到重新托管平台的重新托管数据库。

根据实施例，在这个步骤处，可以将应用所需的资源从大型机平台下载到工作台。资源可以包括JCL作业脚本、SYSIN、PROC脚本、COBOL程序、COPYBOOK脚本和DB2 DDL脚本。所下载的资源可以被合并和分类，并且可以放入到工作台项目中。

另外，在这个步骤中，可以使用SQL脚本在重新托管(例如，Oracle)数据库上创建对应的表；并且可以使用重新加载脚本将大型机数据库(例如，DB2数据库)内容重新加载到重新托管数据库中，使得重新托管数据库可以包含大型机数据库数据的完整拷贝。

在步骤813处，使用客户端应用在大型机数据库和重新托管数据库中创建修改事件表和相关联的序列。

在步骤815处，为大型机数据库和重新托管数据库生成数据库触发器脚本。生成第一组触发器脚本，用于为大型机数据库中的一个或多个表创建数据库触发器，并且生成第二组触发器，用于为重新托管数据库中的一个或多个表创建数据库触发器。

在步骤817处，执行触发器脚本以在大型机数据库和重新托管数据库中创建数据库触发器。

在步骤819处，批处理作业被提交给大型机平台和重新托管平台以供执行，其中批处理作业的执行使得每个平台中的数据库触发器将由批处理作业生成的数据库修改事件存储到每个平台中的修改事件表中。

在步骤821处，检查来自重新托管/开放平台的批处理作业的返回代码，以确定返回代码是否指示在重新托管平台中执行批处理作业期间的错误。如果作业执行返回错误代码，则将确定迁移不成功，如步骤833所示。

但是，如果作业执行返回警告或成功代码，则从每个平台下载数据库修改事件数据，如步骤823所示。

在步骤827处，比较来自重新托管平台的数据库修改事件数据和来自大型机平台的数据库事件数据。

在步骤829处，客户端应用用于确定批处理作业执行是否生成相同的一组数据库操作。如果在每个平台上生成相同的一组数据库操作，则确定批处理作业的迁移是成功的，如步骤831所示；否则，确定作业迁移是失败的。

根据实施例，当将数据更新存储到修改事件表中的BLOB列的BLOG数据时，可以使用由DB2提供的hex()函数将BLOG数据转换成可读的十六进制字符。根据实施例，数据库触发器可以捕获BLOB数据更新的前16352个字节。

根据实施例，可以为下一个作业执行清理两个平台上的修改事件表，包括丢弃先前创建的触发器，以及清理修改事件数据和相关联的序列。

如图9所示，在步骤911处，在包括一个或多个微处理器的计算机上提供重新托管平台，其中重新托管平台包括用于执行从大型机平台迁移的批处理作业的应用容器。

在步骤913处，在与重新托管平台相关联的第一数据库和与大型机平台相关联的第二数据库中创建一个或多个数据库触发器和修改事件表。

在步骤915处，批处理作业从客户端应用提交到重新托管平台和大型机平台以供执行，其中每个平台上的批处理作业执行生成多个数据库修改事件。

在步骤917处，每个平台上的数据库触发器用于捕获数据库修改事件，并将它们存储到该平台上的修改事件表。

在步骤919处，将来自每个数据库的数据库修改事件下载到客户端应用，该客户端应用被配置为通过比较来自第一数据库的数据库修改事件和来自第二数据库的数据库修改事件来确定批处理作业迁移的成功。

本发明可以使用一个或多个常规的通用或专用数字计算机、计算设备、机器或微处理器(包括根据本公开的教导进行编程的一个或多个处理器、存储器和/或计算机可读存储介质)来方便地实现。如对软件领域技术人员将显而易见的，基于本公开的教导，适当的软件编码可以由熟练的程序员容易地准备。

在一些实施例中，本发明包括计算机程序产品，该计算机程序产品是其上/其中存储有指令的非瞬态存储介质或计算机可读介质，指令可以用来对计算机进行编程以执行本发明的任何处理。存储介质可以包括但不限于任何类型的盘(包括软盘、光盘、DVD、CD-ROM、微驱动器和磁光盘)、ROM、RAM、EPROM、EEPROM、DRAM、VRAM、闪存设备，磁卡或光卡、纳米系统(包括分子存储器IC)，或适于存储指令和/或数据的任何类型的介质或设备。

出于说明和描述的目的已经提供了本发明的前述描述。它不旨在是详尽的或者将本发明限于所公开的精确形式。许多修改和变化对于本领域技术人员来说将是显而易见的。修改和变化包括所公开特征的任何相关组合。实施例的选择和描述是为了最好地解释本发明的原理及其实际应用，由此使本领域的其他技术人员能够理解本发明的各种实施例以及适于预期的特定用途的各种修改。本发明的范围旨在由以下权利要求及其等同物限定。

Claims

1.一种用于确定应用的迁移成功的系统，包括：

包括一个或多个微处理器的计算机；

在所述计算机上执行的重新托管平台，所述重新托管平台包括用于执行从大型机平台迁移的应用的应用容器；

与所述重新托管平台相关联的第一数据库，以及与所述大型机平台相关联的第二数据库，每个数据库包括一个或多个数据库触发器和修改事件表；

客户端应用，被配置为将与所述应用相关联的批处理作业提交到所述重新托管平台和所述大型机平台以供执行，其中每个平台上的批处理作业执行生成多个数据库修改事件；

其中每个平台上的数据库触发器捕获数据库修改事件，并将所述数据库修改事件存储到该平台上的修改事件表；以及

其中所述客户端应用被配置为从每个数据库下载数据库修改事件，并通过比较来自第一数据库的数据库修改事件和来自第二数据库的数据库修改事件来确定迁移的成功。

2.如权利要求1所述的系统，其中所述客户端应用被配置为确定来自第一数据库的数据库修改事件和来自第二数据库的数据库修改事件是否包含相同的一组数据库操作。

3.如权利要求1或2所述的系统，其中来自第一数据库的数据库修改事件和来自第二数据库的数据库修改事件两者都被下载到纯文本文件中，并且其中所述客户端应用包括被配置为格式化每个纯文本文件以进行比较的比较逻辑。

4.如权利要求1或2所述的系统，其中每个平台上的数据库触发器由在所述客户端应用中创建的数据库触发器脚本生成。

5.如权利要求1或2所述的系统，其中第一数据库是Oracle数据库，并且第二数据库是DB2数据库，并且其中所述客户端应用被配置为与第一数据库和第二数据库通信的Oracle客户端和DB2客户端。

6.如权利要求1所述的系统，还包括：

检查批处理作业执行的返回代码。

7.如权利要求1或2所述的系统，其中所述批处理作业是作业控制语言JCL作业，并且所述JCL作业被提交给所述重新托管平台以供执行而不将所述JCL作业转换成另一种语言。

8.一种用于确定大型机批处理作业的迁移成功的方法，包括：

提供在计算机上执行的重新托管平台，所述重新托管平台包括用于执行从大型机平台迁移的应用的应用容器；

在与所述重新托管平台相关联的第一数据库和与所述大型机平台相关联的第二数据库中创建一个或多个数据库触发器和修改事件表；

从客户端应用向所述重新托管平台和所述大型机平台提交与所述应用相关联的批处理作业以供执行，其中每个平台上的批处理作业执行生成多个数据库修改事件；

使用每个平台上的数据库触发器捕获数据库修改事件，并将所述数据库修改事件存储到该平台上的修改事件表；以及

将数据库修改事件从每个数据库下载到所述客户端应用，所述客户端应用被配置为通过比较来自第一数据库的数据库修改事件和来自第二数据库的数据库修改事件来确定应用迁移的成功。

9.如权利要求8所述的方法，其中所述客户端应用被配置为确定来自第一数据库的数据库修改事件和来自第二数据库的数据库修改事件是否包含相同的一组数据库操作。

10.如权利要求8或9所述的方法，其中来自第一数据库的数据库修改事件和来自第二数据库的数据库修改事件两者都被下载到纯文本文件中，并且其中所述客户端应用包括被配置为格式化每个纯文本文件的比较逻辑。

11.如权利要求8或9所述的方法，其中每个平台上的数据库触发器由在所述客户端应用中创建的数据库触发器脚本生成。

12.如权利要求8或9所述的方法，其中第一数据库是Oracle数据库，并且第二数据库是DB2数据库，并且其中所述客户端应用被配置有与第一数据库和第二数据库通信的Oracle客户端和DB2客户端。

13.如权利要求8所述的方法，还包括：

检查批处理作业执行的返回代码。

14.如权利要求8或9所述的方法，其中所述批处理作业是作业控制语言JCL作业，并且所述JCL作业被提交给所述重新托管平台以供执行而不将所述JCL作业转换成另一种语言。

15.一种非瞬态计算机可读存储介质，存储用于确定应用的迁移成功的一组指令，所述指令在由一个或多个处理器执行时使得所述一个或多个处理器执行包括以下的步骤：

在与所述重新托管平台相关联的第一数据库和与所述大型机平台相关联的第二数据库平台中创建一个或多个数据库触发器和修改事件表；

16.如权利要求15所述的非瞬态计算机可读存储介质，其中所述客户端应用被配置为确定来自第一数据库的数据库修改事件和来自第二数据库的数据库修改事件是否包含相同的一组数据库操作。

17.如权利要求15或16所述的非瞬态计算机可读存储介质，其中来自第一数据库的数据库修改事件和来自第二数据库的数据库修改事件两者都被下载到纯文本文件中，并且其中所述客户端应用包括被配置为格式化每个纯文本文件以进行比较的比较逻辑。

18.如权利要求15或16所述的非瞬态计算机可读存储介质，其中每个平台上的数据库触发器由在所述客户端应用中创建的数据库触发器脚本生成。

19.如权利要求15或16所述的非瞬态计算机可读存储介质，其中第一数据库是Oracle数据库，并且第二数据库是DB2数据库，并且其中所述客户端应用被配置为与第一数据库和第二数据库通信的Oracle客户端和DB2客户端。

20.如权利要求15或16所述的非瞬态计算机可读存储介质，其中所述批处理作业是作业控制语言JCL作业，并且所述JCL作业被提交给所述重新托管平台以供执行而不将所述JCL作业转换成另一种语言。

21.一种用于确定大型机批处理作业的迁移成功的装置，包括执行如权利要求8-14中任一项所述的方法的部件。