工作方式：多版本应用程序

可以将资源视为每个应用程序版本的专用资源

在应用程序中，将关键资源打包到应用程序中以进行生命周期管理。 这些关键资源包括标识为应用程序入口点和特定于应用程序版本的装入库的程序。 通过将 CICS® TS 资源定义引入到 CICS TS 应用程序中，您可以在应用程序的整个生命周期内为其提供更好的管理。 在应用程序开发期间，描述单个开发环境中的资源是有益的，并且可供应用程序开发者编辑。 当应用程序处于源代码管理中时，它可以通过应用程序部署来包含和跟踪所有相关工件。 可以通过单个控制点供应和取消供应应用程序，而所有相关 CICS TS 资源的状态由系统管理。

传统上，应用程序依赖于要在应用程序外部提供的关键 CICS TS 资源，例如，由 CICS 系统定义数据集 (CSD) 提供。 但是，如果资源由 CSD 或 CICSPlex ® SM Business Application Services (BAS) 提供，那么不同版本的应用程序的应用程序入口点无法共享资源名称。 多版本控制支持某个应用程序的多个版本使用相同名称声明特定 CICS TS 资源。 每个资源都被被视为对于应用程序版本唯一且私有。

对于受支持的资源类型，如果在打包并安装为应用程序的 CICS 束中定义了 CICS 资源 (作为应用程序束的一部分或作为应用程序绑定的一部分) ，那么该资源是专用资源。 以此方式创建 CICS 资源时，该资源不可用于平台上安装的任何其他应用程序或版本，并且不可用于 CICS 区域中的其他应用程序。 它只能由定义资源的应用程序版本使用。 这些资源称为 专用资源。 有关更多信息，请参阅 应用程序版本的专用资源。

如果您管理资源以避免应用程序的不同版本之间的资源名称冲突，那么多版本应用程序可能会涉及其他资源。 例如，当您打包并安装应用程序的新版本时，可以重命名属于应用程序的 URIMAP 资源。 或者，可以设计应用程序，以便在应用程序外部管理不支持多版本控制的资源，但声明为应用程序的依赖关系或捆绑软件导入。 对于已由或可能由不同应用程序 (例如 JVMSERVER 资源) 使用的资源，请在平台级别部署和管理资源，在该平台上部署的任何应用程序的任何版本都可以使用该资源。

与单个版本的应用程序一样，您通过声明应用程序入口点来控制用户对多版本化应用程序中的资源的访问权。

您可以使用 EXEC CICS INVOKE APPLICATION 命令来调用多版本化应用程序的特定版本。 有关调用特定版本的应用程序的更多信息，请参阅 调用多版本应用程序。

示例: 将应用程序的一个版本替换为另一个版本

想象一个场景，公司具有用户使用 CICS 事务访问的 CICS 应用程序。 系统管理员需要部署应用程序的新版本以修复应用程序中的错误，并期望所有用户同时使用新版本。

系统管理员或应用程序开发者使用 CICS Explorer® 来打包和导出应用程序的新版本。 系统管理员将应用程序的新版本部署到平台，然后启用已安装的应用程序。 当应用程序进入 "已启用" 状态时，系统管理员知道安装成功。 此时，在用户进入 CICS 事务时，仍会向其提供较旧版本的应用程序。 当系统管理员使新版本的应用程序可用时， CICS 会立即向用户提供该版本，以代替旧版本。 用户输入与之前相同的 CICS 事务，用户无需执行任何操作。

如果应用程序的新版本存在问题，那么用户可以快速回滚到应用程序的旧版本。 缺省情况下， CICS 为调用者 (例如， CICS 事务或其他链接应用程序) 提供您在平台上提供的应用程序的最高版本。 如果系统管理员使旧版本可用或保持旧版本可用，然后使新版本不可用，那么将自动向用户再次提供旧版本。 用户对应用程序的访问权由为应用程序中的资源声明的应用程序入口点控制，这些入口点可以将资源设置为可用或不可用。 系统管理员不需要禁用或废弃应用程序的备用版本，以阻止用户访问这些版本。

在此场景中，由于应用程序的较旧版本存在缺陷，因此在验证新版本后禁用或废弃该应用程序是适当的。 但是，在平台上部署的多个应用程序版本可以同时对用户可用。 编码为了解多版本控制的程序可以使用 EXEC CICS INVOKE APPLICATION 命令访问应用程序的特定主版本和次版本。

图 2 显示了 CICS Explorer 中的项目用于定义平台和打包应用程序。 示例应用程序包含一个 CICS 束，其中包含 LIBRARY 资源和两个 PROGRAM 资源 (称为 PROGA 和 PROGB) 的定义。 应用程序的 TRANSACTION 资源在 CICS 束中定义，但未随应用程序一起部署。 平台项目，应用程序项目，应用程序绑定项目和 CICS 束项目将导出到 zFS 平台主目录中的子目录。 将为平台和应用程序创建平台定义 (PLATDEF) 和应用程序定义 (APPLDEF) ，并将其存储在 CICSPlex SM 数据存储库中。 平台定义安装在 CICSplex 中，以创建具有包含目标 CICS 区域的区域类型的平台。 应用程序定义安装在平台上，以在 CICS 区域中为应用程序的 V 1.0.0 创建 CICS 束。 通过 CICS 束中的信息，将在 CICS 区域中动态生成应用程序的 LIBRARY 和 PROGRAM 资源。 LIBRARY 资源指向 z/OS® 上具有应用程序版本 1.0.0 的程序的数据集。 还会将包含 TRANSACTION 资源定义的 $TAG1 CICS $TAG2 束添加到平台，并且会在 $TAG3 CICS $TAG4 区域中动态生成 TRANSACTION 资源。

图 3 显示了对于应用程序的版本 1.0.1 ，将更新 CICS 束中的 LIBRARY 资源定义以指向具有应用程序的新程序版本的数据集。 不会更改应用程序的其他资源定义。 包含 CICS 事务资源的 CICS 束项目也不需要更新，因为它是单独部署的。

CICS Explorer 用于打包新版本的应用程序。 新应用程序版本包含用于定义应用程序资源的 CICS 束项目 V 1.0.1 。 将为应用程序和应用程序绑定的新版本创建新的子目录，但 CICS 束存储在同一束子目录中。 将为应用程序版本 1.0.1 创建应用程序定义 (APPLDEF) ，并将其存储在 CICSPlex SM 数据存储库中。 APPLDEF 资源的名称与旧版本的 APPLDEF 资源使用的名称相同，但版本号已更改为与新版本的应用程序匹配。 新应用程序定义安装在平台上，以在 CICS 区域中为应用程序的 V 1.0.1 创建 CICS 束和资源。 应用程序版本 1.0.0 的 CICS 束和资源仍安装在 CICS 区域中，但尚未更新的 TRANSACTION 资源现在自动指向应用程序版本 1.0.1 。

CICS 区域现在托管新版本的应用程序。 安装包含新版本应用程序的资源的 CICS 束时，将在 CICS 区域中动态创建新版本应用程序的专用 LIBRARY 和 PROGRAM 资源。 应用程序的新版本存储在 z/OS上的另一个分区数据集 (PDS) 或分区数据集扩展 (PDSE) 中。 新版本应用程序的已更新 LIBRARY 资源引用了新数据集。 运行应用程序的 CICS 事务不涉及更新过程，而是保持不变。 当用户运行事务时， CICS 会自动为用户提供应用程序的最高可用版本，因此应用程序版本 1.0.1 的程序现在会运行。

示例: 同时托管应用程序的两个版本

假设公司有一个 CICS 应用程序，该应用程序通过浏览器界面作为 Web 应用程序提供给用户，并在 Liberty JVM 服务器中托管演示逻辑。 该公司计划推出新版本的应用程序。 对应用程序的更改意义重大，为了避免业务中断，该公司不希望所有用户同时迁移到新版本。

系统管理员在属于平台的同一 CICS 区域中部署并提供应用程序的两个版本。 通过使用不同的 URL 将用户定向到应用程序的新版本或旧版本。

图 4 显示了对于应用程序的 V 1.0.0 ， CICS Explorer 中的项目用于定义平台和打包应用程序。 该应用程序包含一个 CICS 束项目，该项目将 Web 应用程序打包为企业束归档 (EBA) 中包含的 OSGi 应用程序项目 。 名为 INDEX 的应用程序的 URIMAP 资源是在 CICS 束中创建的，并随应用程序绑定一起部署。 Liberty JVM 服务器也是使用 CICS 束项目定义的。 这些项目将导出到 zFS 平台主目录中的子目录。 将为平台和应用程序创建平台定义 (PLATDEF) 和应用程序定义 (APPLDEF) ，并将其存储在 CICSPlex SM 数据存储库中。 平台定义安装在 CICSplex 中，以创建具有包含目标 CICS 区域的区域类型的平台。 应用程序定义安装在平台上，以在 CICS 区域中为应用程序的 V 1.0.0 创建 CICS 束。 通过 CICS 束中的信息，将在 CICS 区域中动态生成名为 INDEX 的应用程序版本 1.0.0 的 URIMAP 资源，并在 Liberty JVM 服务器中部署 Web 应用程序的资源。

图 5 显示了对于应用程序的 V 1.1.0 ， CICS Explorer 用于打包应用程序。 新应用程序版本包含用于打包 Web 应用程序的 CICS 束项目 V 1.1.0 ，并且 OSGi 应用程序项目 也将重新版本化为 V 1.1.0。 将在 CICS 束中创建新版本的应用程序的新 URIMAP 资源，并随新版本的应用程序绑定一起部署。 这些项目将导出到 zFS 平台主目录中的子目录。 将为应用程序和应用程序绑定的新版本创建新的子目录，但 CICS 束存储在同一个 bundles 子目录中。 将为应用程序的 1.1.0 版本创建应用程序定义 (APPLDEF) ，并将其存储在 CICSPlex SM 数据存储库中。 APPLDEF 资源的名称与旧版本的 APPLDEF 资源使用的名称相同，但版本号已更改为与新版本的应用程序匹配。 新应用程序定义安装在平台上，以在 CICS 区域中为应用程序的 V 1.1.0 创建 CICS 束和资源，同时为应用程序的 V 1.0.0 创建 CICS 束和资源。

CICS 区域处理新版本应用程序的工作负载以及旧版本应用程序的工作负载。 名为 INDEX11的应用程序版本 1.1.0 的 URIMAP 资源是在 CICS 区域中动态生成的，而 Web 应用程序版本 1.1.0 的资源部署在 Liberty JVM 服务器中。 原始应用程序版本的 CICS 束仍安装在 CICS 区域中，名为 INDEX 的 URIMAP 资源以及 Web 应用程序版本 1.0.0 的资源仍可用。 因此，应用程序的两个版本都在 CICS 区域中存在且可用，并且由在不同 URIMAP 资源上指定的不同 URL 访问。