Il nous faut maintenant modifier et recréer les fichiers logiques qui référençaient le fichier physique original. Les fichiers ORDERHSTTL1 et ORDERHSTTL2 ont des définitions de champs individuelles et, par conséquent, ne partagent aucun format de fichier. Donc, pour ces deux fichiers, il nous suffit de changer le nom du fichier
Recréer les fichiers logiques originaux
référencé dans le mot-clé PFILE par le nom de la nouvelle table SQL, comme dans les figures 7A et 7B.
Les fichiers ORDERHSTTX1 et ORDERHSTTX2 nécessitent deux nouveaux mots de passe en plus du changement apporté à leurs valeurs PFILE. Premièrement, nous ajoutons un mot-clé niveau de fichier DYNSLT pour changer le traitement select/ omit en dynamique, afin que les nouveaux index SQL puissent être utilisés pour l’accès indexé. Ensuite, nous ajoutons un mot-clé FORMAT qui référence le nouveau fichier logique « suppléant ». Cette technique dispense de recompiler les programmes qui accèdent à ces fichiers logiques. Les fragments de code des figures 8A et 8B montrent les changements.
Une fois les fichiers logiques recréés, examinez les descriptions de fichiers pour vérifier que les chemins d’accès sont partagés et que les IF de format n’ont pas changé. A ce stade, vous êtes prêts à faire migrer les données et à tester les programmes qui utilisent les fichiers DDS référençant la nouvelle base de données SQL.
Téléchargez cette ressource
Guide de Sécurité IA et IoT
Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.
Les articles les plus consultés
A travers cette chaîne
A travers ITPro
