Lorsque vous apportez des modifications sur les bundles CICS pour les composants d'une application, mettez à jour les versions des bundles CICS, l'application et la liaison d'application, puis déployez les nouvelles versions sur la plateforme.
Assurez-vous tous les projets associés à l'application sont présents dans votre espace de travail local pour CICS Explorer, y compris le projet de plateforme pour la plateforme cible. CICS Explorer a besoin d'un projet de plateforme pour valider le projet d'application et le projet de liaison d'application.
Pour mettre à jour une application, vous devez modifier le projet d'application et le projet de liaison d'application. Si vous ne disposez pas d'un système de secours versionné qui vous permet de retourner vers une version antérieure des projets, au lieu de modifier directement les projets existants comme indiqué dans ces instructions, il serait mieux de les copier vers un autre projet puis modifier les nouvelles copies.
Si votre application utilise uniquement ces ressources, vous pouvez installer et rendre disponibles plusieurs versions de l'application en même temps sur la même plateforme. Si votre application utilise des ressources qui ne sont pas prises en charge pour la gestion de versions multiples, vous devez désactiver et supprimer la version existante de l'application avant d'installer une nouvelle version. Vous pouvez également renommer les ressources qui ne sont pas prises en charge pour la gestion de versions multiples, afin qu'elles n'entrent pas en conflit avec les ressources installées pour des versions précédentes de l'application.
Si vous devez désactiver une application pour installer une nouvelle version, celle-ci est indisponible pour les utilisateurs à partir du moment où vous rendez la version précédente de l'application indisponible pour désactiver et supprimer la ressource APPLCTN installée dans le CICSplex, jusqu'au moment où vous installez la nouvelle définition de ressource APPLDEF, activez la nouvelle version de l'application et rendez celle-ci disponible. Planifiez un moment opportun où cela peut se produire en toute sécurité ou planifiez une solution alternative pour les utilisateurs de l'application en ce moment.
Vous gérez les différentes versions d'applications à l'aide du contrôle des versions. Chaque bundle CICS, bundle d'application et liaison d'application a un ID des informations de version permettant de l'identifier de façon unique. La version utilise des identificateurs majeurs, mineurs et micro, donc vous pouvez indiquer la signification d'une modification et gérer les dépendances entre les bundles. Il s'agit du concept de gestion de versions sémantique qui est issu de l'initiative OSGi. Même si la gestion de versions sémantique concerne principalement les modules Java™, vous pouvez appliquer les mêmes principes aux bundles en général.
La gestion de versions sémantiques permet d'incrémenter des composants majeurs, mineurs ou micro d'une version pour indiquer la compatibilité ou l'incompatibilité avec les versions antérieures d'un bundle. Par exemple, les correctifs de bogue peuvent incrémenter le composant micro de la version, les modifications compatibles incrémentent le composants mineur de la version et les modifications incompatibles incrémentent le composant majeur de la version. Pour plus d'informations sur la gestion de versions sémantiques, voir Livre blanc technique sur la gestion des versions sémantiques.
Vous devez appliquer une politique de gestion de versions à vos bundles CICS, bundles d'application et liaisons d'application pour déployer et gérer des mises à jour dans l'environnement CICS. Vous ne pouvez pas utiliser une version existante d'un bundle d'application pour déployer de nouvelles versions des bundles CICS pour l'application. Il est également impossible d'utiliser une version existante d'une liaison d'application avec une nouvelle version d'un bundle d'application. Vous devez mettre à jour les versions du bundle d' application et de la liaison d'application chaque fois que vous mettez à jour les bundles CICS pour l'application.
Lorsque vous modifiez la version d'une application, selon les principes de la gestion de versions sémantiques, la nouvelle version doit refléter la plus grande modification dans un bundle CICS qui est inclus dans l'application. Par exemple, vous pouvez modifier un bundle CICS pour une application de la Version 1.0.1 à la Version 1.0.2, qui est une modification de version micro et modifier un autre bundle CICS pour l'application de la Version 1.2.0 à la Version 1.3.0, qui est une modification de version mineure. Le bundle d'application qui inclut ces deux bundles CICS doit cependant avoir une modification de version mineure. Par conséquent, si l'application était précédemment à la Version 2.5.1, elle doit passer à la Version 2.6.0.
La nouvelle version de l'application est déployée sur la plateforme. Les bundles CICS qui sont inclus dans la nouvelle version de l'application sont installée dans les régions CICS appropriées et les ressources qui sont définies à l'intérieur des bundles CICS sont créées de façon dynamique dans les régions CICS.
Lorsque vous rendez une nouvelle version d'une application disponible, CICS permet aux appelants d'accéder à la version d'application via les points d'entrée d'application de cette dernière, qui peuvent être des ressources PROGRAM ou URIMAP. Pour les applications qui sont prises en charge pour la gestion de versions multiples, si plusieurs versions sont disponibles, les appelants peuvent accéder à la version d'application la plus élevée disponible ou utiliser la commande EXEC CICS INVOKE APPLICATION pour spécifier une version disponible de l'application.