Seuls les mouvements en erreur sont édités. Il peut y avoir de nombreux
rejets car ces entités créées en version 2.n sont soumises à un plus grand
nombre de contrôles en version 3.n. Des interventions manuelles dans la
base sont alors indispensables.
Les mouvements ne sont pas journalisés.
Le fichier mouvement &UTM2MV est déclaré en fichier permanent pour
permettre à l'utilisateur de visualiser l'ensemble des mouvements soumis à
la mise à jour.
Etape 3 : Etat des lieux
Il est recommandé de réexécuter la première étape afin de s'assurer de
l'absence d'appels de relations old dans la base.
Sinon, une intervention de l'utilisateur est à nouveau nécessaire ainsi que le
lancement des étapes suivantes.
Etape 4 : Réorganisation
Quand la migration est jugée satisfaisante, une réorganisation de la base est
nécessaire.
Condition d'exécution
Aucune pendant l'étape 1 (UTM1).
Pour l'étape 2 de mise à jour, il est nécessaire de fermer les fichiers AR, AN,
AJ et AY dans le conversationnel (sauf pour les matériels permettant la
concurrence batch/conversationnel).
Edition obtenue
A l'issue de l'étape 1, un compte-rendu édite la liste des appels de relations de
type old.
A l'issue de l'étape 2 avant la mise à jour, des messages d'erreur sont édités
sous forme de displays.
A l'issue de la mise à jour, un compte-rendu signale les anomalies rencontrées.
Résultat obtenu
Une fois la réorganisation effectuée, le résultat obtenu est un réseau exempt
de méta entités de type old et d'appels de relations de type old.
374
VisualAge Pacbase : Guide d'installation Serveur Z/OS CICS & Composants Client