Recommandations relatives à la migration des applications d'un environnement de test vers un environnement de production

Lorsque vous faites migrer des applications activées avec l'optimisation client pureQuery d'un environnement de test vers un environnement de production, suivez ces recommandations pour obtenir les meilleurs résultats.
Il est recommandé d'exécuter la capture et le test dans un environnement aussi similaire que possible à l'environnement cible final. Toutefois, dans bien des cas, les environnement de test et de production ne correspondent pas. Parmi les exemples de différences entre un environnement de test et un environnement de production, citons :
  • Les systèmes de test peuvent utiliser une base de données DB2 for Linux, UNIX, and Windows, mais l'environnement de production utilise une base de données DB2 for z/OS.
  • Les systèmes de test peuvent utiliser une version de la base de données différente de celle qu'utilisent les systèmes de production.
Avant de faire migrer une application, vous devez vous assurer que les informations de schéma correspondent dans les deux environnements. Les deux environnements peuvent utiliser des schémas de l'une des manières suivantes :
  • Les deux systèmes utilisent les mêmes définitions de schéma.
  • Les deux systèmes utilisent des noms de table non qualifiés.
Sur le système de production, lorsque vous basculez vers l'exécution statique des instructions SQL à partir d'une exécution dynamique, vous devez tester les résultats. Exemples d'éléments à tester :
  • Assurez-vous que l'opération de liaison sur la base de données cible est efficace.
  • Assurez-vous que l'exécution statique des instructions SQL renvoie les mêmes résultats que l'exécution dynamique des instructions.
  • Assurez-vous que l'application fonctionne de la même manière lors de l'exécution des instructions en mode statique que lors de leur exécution dynamique.

Vous devrez peut-être reconfigurer le fichier pureQueryXML avec des attributs spécifiques à la production comme les noms de package et de collecte. Après avoir exécuté l'utilitaire Configure sur le fichier pureQueryXML avec des options spécifiques à la production, l'utilitaire StaticBinder peut permettre de créer les packages finaux sur le système de production.

Considérations relatives au codage z/OS

Les utilitaires pureQuery Runtime fonctionnent sur des fichiers codés au format UTF-8. Lorsque vous capturez des données SQL, le fichier pureQueryXML qui contient les données SQL est créé dans le codage UTF-8. Une commande des services système z/OS UNIX, telle que vi, utilisée pour ouvrir un fichier codé UTF-8 peut ne pas fonctionner.

Vous devrez peut-être exécuter la commande iconv pour convertir le codage de ce fichier. Par exemple, pour convertir le fichier capture.xml en codage IBM-1047, utilisez la commande suivante :
iconv -f UTF-8 -t IBM-1047 capture.xml > capture_1047.xml

Après la conversion, vous pouvez utiliser vi pour ouvrir et afficher le contenu du fichier capture_1047.xml. Toutefois, vous ne pouvez pas utiliser le fichier converti avec pureQueryRuntime. Vous devez utiliser un fichier au codage UTF-8.

Les utilitaires pureQuery Runtime fonctionnent sur des fichiers codés au format UTF-8, de sorte que le fichier capture.xml d'origine doit être fourni aux utilitaires pureQuery Runtime.

Si vous transférez un fichier en utilisant un FTP depuis un système z/OS vers un poste de travail pour affichage et traitement, vous devez transférer le fichier en mode binaire. Assurez-vous également que vous utilisez un éditeur capable de modifier les fichiers codés au format UTF-8.


Commentaires