Skip Headers
StorageTek Virtual Library Extension Configuration du logiciel de l'hôte pour VLE

E51988-01
  Accéder à la table des matières
Sommaire

Précédent
Précédent
 
 

2 Configuration du logiciel de l'hôte MVS

Ce chapitre fournit la configuration du logiciel de l'hôte MVS pour VLE, comme le décrivent les sections suivantes :

Valeurs de configuration clés

Les sections suivantes décrivent les valeurs requises pour la configuration logicielle, lesquelles doivent correspondre aux valeurs qui sont généralement déjà définies dans la configuration matérielle et enregistrées dans la fiche d'information IP_and VMVC_Configuration.xls.

Nom du sous-système

Le nom du sous-système de la VLE, défini par les scripts d'installation VLE, est spécifié dans les éléments suivants :

  • Soit le paramètre CONFIG TAPEPLEX STORMNGR de VTCS, soit le paramètre CONFIG STORMNGR NAME

  • Le paramètre CONFIG RTD STORMNGR de VTCS

  • Le paramètre STORMNGR NAME de SMC

  • Le paramètre SERVER STORMNGR de SMC

  • Le paramètre STORCLAS STORMNGR de HSC

Adresses de port Ethernet du VTSS

Les adresses de port Ethernet du VTSS sont requises pour configurer la connexion IP du VTSS à la VLE à l'aide du paramètre CONFIG RTD IPIF . Pour les VSM5, cette valeur doit correspondre aux valeurs spécifiées dans l'écran IFF Configuration Status Screen du VSM5. Pour les VSM 6, la valeur doit être unique pour chaque VTSS mais ne correspond pas à une valeur réelle des ports TCP/IP du VSM 6.

Adresses IP des ports de la VLE pour les communications d'hôte (UUI)

Ces adresses sont requises pour le paramètre SERVER IP du SMC.

VOLSER de VMVC

Ces VOLSER sont requis afin de définir les VMVC pour le SMC/VTCS. La méthode de définition dépend de la version du logiciel. A ce sujet, reportez-vous à la section "Définition des cartouches VMVC VLE sur le logiciel de l'hôte MVS et inclusion de cartouches VMVC dans un pool MVC".

Seuil de récupération des VMVC

Pour plus d'informations, reportez-vous à la section "Spécification de la stratégie de récupération pour VMVCS".

Déduplication des VTV

Le paramètre STORCLAS DEDUP spécifie si les données des VTV migrées vers les VMVC dans le paramètre STORMNGR spécifié sont dédupliquées. Par exemple :

STORCLAS NAME(VLEDEDUP)STORMNGR(VLE1) DEDUP(YES)

Cette instruction STORCLAS spécifie de dédupliquer les données dans la classe de stockage VLEDEDUP qui sont migrées vers VLE1. Pour plus d'informations, reportez-vous au manuel ELS 7.x Command, Control Statement, and Utility Reference.

La déduplication augmente la capacité des VMVC effective et est réalisée par la VLE avant que le volume VTV soit écrit sur une cartouche VMVC. Oracle recommande, par conséquent, de commencer par activer la déduplication, de suivre les résultats dans le rapport SCRPT et d'ajuster les paramètres de déduplication si nécessaire.

Fonction Early Time to First Byte (ETTFB)

La fonction ETTFB (également connue sous le nom de fonction de rappel/montage de bande simultané), permet aux applications de l'hôte de lire des données pendant que des volumes VTV sont rappelés soit depuis des cartouches VMVC, soit depuis des lecteurs RTD. La fonction ETTFB est exécutée par chevauchement des phases de rappel et de montage des VTV, ce qui permet à l'application de lire les données des VTV plus tôt. Si l'application tente de lire une partie du VTV qui n'a pas été rappelée, la demande E/S de l'application est bloquée jusqu'à ce que les données des VTV requises soient rappelées. Avec la fonction ETTFB pour VLE, l'accès des applications au premier octet se fait en moins d'une seconde, faisant de VLE une véritable extension du VTSS. Par conséquent, la fonction ETTFB de la VLE est un bon choix pour les applications qui accèdent l'une après l'autre aux données des VTV. La fonction ETTFB de la VLE n'est généralement pas un avantage pour les applications qui empilent plusieurs fichiers sur un même volume VTV, y compris HSM et les applications de gestion des images. Dans ces types d'applications, les données désirées ne sont généralement pas au début du volume VTV, mais plutôt à un emplacement aléatoire sur le VTV.

La fonction ETTFB est désactivée par défaut. Vous pouvez activer de manière globale la fonction ETTFB à l'aide du paramètre CONFIG GLOBAL FASTRECL. Si vous activez la fonction ETTFB de manière globale, vous pouvez la désactiver pour des VTSS spécifiques à l'aide du paramètre CONFIG VTSS NOERLYMNT.

L'enregistrement des volumes VTV qui ont fait l'objet d'une erreur de rappel ETTFB comporte un indicateur d'erreur dans le jeu CDS. Ces volumes VTV ne sont donc pas sélectionnés pour les opérations ETTFB. Si vous souhaitez réinitialiser l'indicateur d'erreur, effectuez l'une des opérations suivantes :

  • Exécutez une commande VTVMAINT SCRATCH(ON) pour le volume VTV.

  • Migrez le volume VTV vers une nouvelle copie MVC.

  • Importez le volume VTV.

  • Créez une nouvelle version du VTV.

  • Videz le volume VTV.

Tâches de configuration du logiciel de l'hôte MVS

L'ajout d'une VLE à un système VSM requiert les opérations décrites dans les sections suivantes :

Pour plus d'informations sur les commandes et les instructions de contrôle citées dans ce chapitre, reportez-vous au manuel ELS 7.x Command, Control Statement, and Utility Reference.

Acquisition du logiciel ELS prenant en charge les correctifs PTF de la VLE 1.4

Pour ELS 7.2, la prise en charge est comprise à la base. Pour ELS 7.0 et 7.1, obtenez les dernières données HOLDDATA de la commande SMP/E receive et les derniers correctifs PTF décrits dans la Figure 1–1 et la commande SMP/E APPLY avec GROUPEXTEND.

Tableau 2-1 Correctifs PTF associés à ELS pour VLE 1.4

ELS 7.0 ELS 7.1

L1H16C1

L1H16J6

L1H1672

L1H1674


Mise à jour de l'entrée de sécurité OMVS RACF du SMC

La VLE exige que SMC possède une entrée de sécurité OMVS RACF pour établir une connexion TCP/IP avec l'hôte.

OMVS est un segment associé à l'ID utilisateur RACF. La tâche démarrée du SMC doit posséder un ID utilisateur associé à OMVS, soit dans la définition de classe RACF STARTED, soit dans le module ICHRIN03 LNKLST. Il est nécessaire qu'un segment OMVS soit défini sur l'ID utilisateur associé à la tâche SMC dans le composant RACF comme suit :

ADDUSER userid
DFLTGRP(groupname)OWNER(owner)OMVS(UID(uidnumber))

Ou encore, si l'ID utilisateur existe déjà mais n'est pas présent dans un segment OMVS :

ALTUSER userid OMVS(UID(uidnumber))

Modification du fichier SCMDS du SMC

Le composant SMC gère toutes les communications entre VTCS et VLE ; SMC doit donc savoir comment se connecter au serveur VLE. Pour ce faire, ajoutez une instruction STORMNGR du SMC pour chaque système VLE plus une ou plusieurs instructions SERVER SMC qui définissent les chemins de contrôle TCP/IP pour la VLE. Pour les versions 7.0 et supérieures, vous souhaiterez éventuellement effectuer cette opération dans le fichier CMDS de votre SMC comme décrit dans l'Exemple 2-1.

Exemple 2-1 Commandes SMC pour VLE

TAPEPLEX NAME(TMVSA)LOCSUB(SLS0)
SERVER NAME(ALTSERV) TAPEPLEX(TMVSA) +
HOSTNAME(MVSX) PORT(8888)
STORMNGR NAME(VLE1)
SERVER NAME(VLE1)+ STORMNGR(VLE1)IP(192.168.1.10)PORT(60000)

L'Exemple 2-1 contient :

  • Une instruction TAPEPLEX, qui définit un TapePlex simple, TMVSA, avec un HSC/VTCS s'exécutant sur le même hôte MVS (SLS0).

  • Une instruction SERVER, qui définit un sous-système HSC/VTCS de secours (ALTSERV) s'exécutant sur un autre hôte.

  • Une commande STORMNGR qui définit une VLE (VLE1).

  • Une deuxième commande SERVER qui définit un chemin de communication UUI vers la VLE, où :

    • Le nom du serveur est VLE1

    • La valeur du paramètre STORMNGR est VLE1

    • La valeur du paramètre IP est l'adresse IP du port de VLE de 192.168.1.10 pour les communications UUI

    • La valeur du paramètre PORT est 60000 ; cette valeur est toujours utilisée pour le paramètre SERVER PORT pour les communications SMC avec une VLE

Mise à jour de la console CONFIG de VTCS pour définir la VLE

Vous devez mettre à jour la console CONFIG du VTCS pour définir la VLE et la connectivité entre les systèmes VTSS et la VLE. Le VTCS peut conduire la VLE 1.4 comme suit :

  • Pour VTCS 7.0 et versions ultérieures, l'instruction CONFIG TAPEPLEX définit le TapePlex sur lequel s'exécute le VTCS et fournit la liste des VLE définies dans le paramètre CONFIG TAPEPLEX STORMNGR comme l'illustre l'Exemple 2-2.

Exemple 2-2 VTCS 7.0 CONFIG VLE

TAPEPLEX THISPLEX=TMVSA STORMNGR=VLE1 
VTSS NAME=VTSS1 LOW=70 HIGH=80 MAXMIG=8 MINMIG=4 RETAIN=5
RTDPATH NAME=VL1RTD1 STORMNGR=VLE1 IPIF=0A:0 
RTDPATH NAME=VL1RTD2 STORMNGR=VLE1 IPIF=0A:1 
RTDPATH NAME=VL1RTD3 STORMNGR=VLE1 IPIF=0I:0 
RTDPATH NAME=VL1RTD4 STORMNGR=VLE1 IPIF=0I:1 
RTDPATH NAME=VL1RTD5 STORMNGR=VLE1 IPIF=1A:0 
RTDPATH NAME=VL1RTD6 STORMNGR=VLE1 IPIF=1A:1 
RTDPATH NAME=VL1RTD7 STORMNGR=VLE1 IPIF=1I:0 
RTDPATH NAME=VL1RTD8 STORMNGR=VLE1 IPIF=1I:1 
VTD LOW=6900 HIGH=69FF

Dans l'Exemple 2-2, notez les éléments suivants :

  • L'instruction CONFIG TAPEPLEX, qui définit TMVSA comme le TapePlex sur lequel le VTCS s'exécute et les noms de toutes les VLE connectées (qui dans cet exemple correspondent à une seule VLE appelée VLE1).

  • Les instructions CONFIG RTDPATH, qui définissent un seul lecteur RTD VLE pour chaque chemin du VTSS vers la VLE. Dans cet exemple, les instructions CONFIG RTDPATH pour VTSS1 spécifient :

    • Le nom du chemin RTDPATH.

    • Les connexions aux VLE définies (STORMNGR=VLE1).

    • La valeur IPIF de chaque connexion de port VTSS à VLE au format ci:p où :

      • c représente 0 ou 1.

      • i représente A ou I.

      • p représente un chiffre entre 0 et 3.


      Remarque:

      Pour les VSM5, cette valeur doit correspondre aux valeurs spécifiées dans l'écran IFF Configuration Status Screen du VSM5. Pour les VSM 6, la valeur doit être unique pour chaque VTSS mais ne correspond pas à une valeur réelle des ports TCP/IP du VSM 6.

  • Les systèmes VTCS 7.1 et versions supérieures peuvent bien sûr conduire une VLE 1.4 comme le fait VTCS 7.0, tel que décrit dans la section . Dans ce mode, toutefois, le nombre de cibles RTD VLE est limité par le nombre de chemins issus d'un VTSS. En outre, les lecteurs RTD VLE sont assignés aux chemins VTSS fixés. Le chemin d'un VTSS à la VLE est toujours réservé par le VTCS, qu'un transfert de données VTSS à VLE ait lieu ou non.

    Toutefois, avec VTCS 7.1 (doté des correctifs PTF décrits dans le Tableau 2-1) et versions supérieures, vous pouvez définir une VLE avec un nombre de cibles RTD VLE supérieur au nombre de chemins du VTSS à la VLE, ce qui signifie que :

    • Le chemin du VTSS à la VLE n'est pas réservé, excepté si un transfert de données VTSS à VLE est requis.

    • Davantage d'opérations RTD VLE peuvent avoir lieu simultanément. Par exemple, l'audit d'une cartouche VMVC ne requiert aucun transfert de données entre le VTSS et la VLE.

    Comme l'illustre l'Exemple 2-3, les VLE sont définies par le biais d'une instruction CONFIG STORMNGR, et non du paramètre CONFIG TAPEPLEX STORMNGR. L'instruction CONFIG STORMNGR spécifie les VLE auxquelles le VTCS se connecte. De plus, pour chaque VLE, le paramètre CONFIG STORMNGR VLEDEV définit le nombre et les noms des périphériques RTD que la VLE émule. Plus le nombre de périphériques définis est grand (avec un maximum de 96 périphériques par VLE), plus le niveau d'activités simultanées que le VTCS peut planifier sur les VLE est élevé.

Exemple 2-3 VTCS 7.1 CONFIG VLE

TAPEPLEX THISPLEX=TMVSC 
STORMNGR NAME=VLE1 VLEDEV(S000-S05F) 
STORMNGR NAME=VLE2 VLEDEV(S000-S05F) 
VTSS NAME=VTSS1 LOW=70 HIGH=80 MAXMIG=8 MINMIG=4 RETAIN=5
RTDPATH NAME=VL1RTD1 STORMNGR=VLE1 IPIF=0A:0 
RTDPATH NAME=VL1RTD2 STORMNGR=VLE1 IPIF=0A:1 
RTDPATH NAME=VL1RTD3 STORMNGR=VLE1 IPIF=0I:0 
RTDPATH NAME=VL1RTD4 STORMNGR=VLE1 IPIF=0I:1 
RTDPATH NAME=VL1RTD5 STORMNGR=VLE2 IPIF=1A:0 
RTDPATH NAME=VL1RTD6 STORMNGR=VLE2 IPIF=1A:1 
RTDPATH NAME=VL1RTD7 STORMNGR=VLE2 IPIF=1I:0 
RTDPATH NAME=VL1RTD8 STORMNGR=VLE2 IPIF=1I:1 
VTD LOW=6900 HIGH=69FF

Dans l'Exemple 2-3, notez les éléments suivants :

  • L'instruction CONFIG TAPEPLEX définit désormais uniquement TMVSC comme le TapePlex sur lequel le VTCS s'exécute. Il ne définit pas les VLE connectées.

  • Les instructions CONFIG STORMNGR, qui définissent les VLE configurées dans ce système - VLE1 et VLE2 dans cet exemple. Ces instructions spécifient également le nombre des périphériques VLE via le paramètre VLEDEV. Dans cet exemple, chaque VLE possède le nombre maximal autorisé de 96 périphériques émulés, ce qui permet au VTCS de planifier jusqu'à 96 processus sur chaque VLE. Les adresses de périphérique VLE sont au format Sxxx (où xxx correspond à une valeur hexadécimale. Par exemple, S000-S05F représente 96 périphériques émulés.

  • Les instructions CONFIG RTDPATH pour VTSS1, qui spécifient :

    • Le nom du chemin RTDPATH.

    • Les connexions aux VLE définies (STORMNGR=VLE1, STORMNGR=VLE2)

    • La valeur IPIF de chaque connexion de port VTSS à VLE au format ci:p où :

      • c représente 0 ou 1

      • i représente A ou I

      • p représente un chiffre entre 0 et 3


      Remarque:

      Pour les VSM5, cette valeur doit correspondre aux valeurs spécifiées dans l'écran IFF Configuration Status Screen du VSM5. Pour les VSM 6, la valeur doit être unique pour chaque VTSS mais ne correspond pas à une valeur réelle des ports TCP/IP du VSM 6.

Spécification de la stratégie de récupération pour VMVCS

Les médias MVC VLE (cartouches VMVC) sont soumis à la fragmentation et peuvent être récupérés tout comme des MVC réels. Le processus de récupération des VMVC, cependant, utilise bien moins de ressources qu'une récupération standard. La spécification du seuil de récupération d'une cartouche VMVC s'effectue à l'aide du paramètre CONFIG RECLAIM VLTHRES. Plus la valeur sur laquelle vous définissez VLTHRES est basse, plus le VTCS exécutera des récupérations fréquentes des cartouches VMVC et plus la capacité effective du VMVS sera grande (fragmentation réduite).

Définition des cartouches VMVC VLE sur le logiciel de l'hôte MVS et inclusion de cartouches VMVC dans un pool MVC

Les VOLSER de VMVC doivent être définis à la fois dans le logiciel de l'hôte MVS et dans la VLE. Les cartouches VMVC sont définies dans la VLE dans le cadre de la configuration VLE. Les sections suivantes indiquent comment définir les cartouches VMVC sur le logiciel de l'hôte MVS.

Création de pools VMVC (7.0 et versions supérieures)

  1. Codez des instructions POOLPARM/VOLPARM HSC pour définir les pools VMVC.

    Par exemple, pour définir deux pools distincts pour VLE1 et VLE2 :

    POOLPARM NAME(LEPOOL1)TYPE(MVC)
    VOLPARM VOLSER(VL0000-VL880)
    
    POOLPARM NAME(LEPOOL2)TYPE(MVC)
    VOLPARM VOLSER(VL2000-VL2880) 
    
  2. Exécutez SET VOLPARM pour valider les instructions POOLPARM/VOLPARM.

    SET VOLPARM APPLY(NO)
    

    La commande APPLY(NO) valide les instructions sans les charger. Si les résultats vous conviennent, passez à l'étape 3. Sinon, retravaillez vos définitions de volume, réexécutez cette étape et si les définitions sont valides, passez à l'étape 3.

  3. Exécutez SET VOLPARM pour valider les instructions POOLPARM/VOLPARM.

    SET VOLPARM APPLY(YES)
    

Mise à jour des stratégies du logiciel de l'hôte MVS

Les sections suivantes indiquent comment mettre à jour les stratégies du logiciel de l'hôte MVS de sorte à diriger les données vers le système VLE.

Création de classes de stockage et de gestion pour VLE

Les classes de gestion spécifient comment le VTCS gère les VTV. L'instruction de contrôle MGMTclas de HSC définit une classe de gestion et ses attributs. Par exemple, le paramètre DELSCR de l'instruction MGMTclas spécifie si le VTCS supprime les volumes VTV vidés du VTSS. Les classes de gestion peuvent également pointer vers des classes de stockage, lesquelles spécifient les volumes VTV migrés résident. L'instruction de contrôle STORclas de HSC définit une classe de stockage et ses attributs. Vous spécifiez le système VLE en tant que cible des VTV migrés à l'aide du mot-clé STORCLAS STORMNGR. Par exemple :

STOR NAME(VLOCAL) STORMNGR(VLESERV1) DEDUP(YES)
STOR NAME(VREMOTE) STORMNGR(VLESERV2)DEDUP(YES) 

Les instructions précédentes définissent une classe de stockage "locale" (VLOCAL) sur VLE1 et une classe de stockage "distante" (VREMOTE) sur VLE2. Comme ces instructions STORCLAS l'indiquent, toutes les migrations vers la classe de stockage VLOCLAL ou VREMOTE doivent cibler les VLE spécifiées. Notez également que la déduplication est spécifiée pour les deux classes de stockage.

Vous pouvez adopter une configuration moins restrictive si vous le souhaitez. Par exemple, si vous définissez un MVCPOOL qui contient à la fois des cartouches VMVC et des cartouches MVC, vous pouvez configurer les stratégies de migration de sorte à effectuer une migration vers la VLE, mais en cas de saturation ou d'indisponibilité de la VLE, à poursuivre la migration vers des médias de bande réels (cartouches MVC). Par exemple, la récupération après sinistre du pool MVC est définie comme suit :

POOLPARM NAME(DR)TYPE(MVC)
VOLPARM VOLSER(VL0000-VL0100)
VOLPARM VOLSER(ACS000-ACS099)

La récupération après sinistre du pool contient donc à la fois des cartouches MVC et des cartouches VMVC. Une classe de stockage qui spécifie la récupération après sinistre de pool effectuera d'abord une migration vers les VMVC et utilisera les MVC seulement si les VMVC ne sont pas disponibles. Par exemple :

STOR NAME(DRCLASS) MVCPOOL(DR)DEDUP(YES)

Cette méthode est utile si, dans votre configuration, un ACS et une VLE sont connectées aux systèmes VTSS.

Ensuite, pour spécifier la migration vers la VLE, indiquez les classes de stockage VLE que vous avez définies à l'aide du paramètre MGMTCLAS MIGPOL. Par exemple :

MGMT NAME(M1) MIGPOL(VLOCAL,VREMOTE)
MGMT NAME(M2) MIGPOL(DRCLASS)

La classe de gestion M1 migre une copie VTV vers la VLE "distante" et une copie vers la VLE "locale". La classe de gestion M2 migre une seule copie VTV vers la classe de stockage qui pointe vers le pool MVC "mixte" contenant à la fois des MVC et des VMVC.


Remarque:

Outre la direction de la migration vers une VLE, prenez également en compte les possibilités suivantes :

  1. Vous pouvez utiliser les paramètres ARCHAge et ARCHPol de l'instruction MGMTclas pour définir une stratégie d'archivage pour les VTV dans une classe de gestion. Lorsque l'ancienneté des VTV est supérieure à la valeur ARCHAge, le VTV est admissible pour l'archivage par la ou les classes de stockage spécifiées sur le paramètre ARCHPol. Vous pouvez utiliser des stratégies d'archivage pour archiver (déplacer) des VTV de cartouches VMVC vers des cartouches MVC à mesure que les VTV vieillissent. Pour plus d'informations, reportez-vous au manuel Managing HSC and VTCS.

  2. Vous pouvez utiliser des instructions STORSEL pour que le VTCS donne la priorité aux rappels des médias VLE. Pour plus d'informations, reportez-vous au manuel Managing HSC and VTCS.

  3. Si vous exécutez ELS 7.0 ou versions supérieures, vous pouvez utiliser les instructions de contrôle MIGRSEL et MIGRVTV de HSC pour ajuster les paramètres de migration vers VLE. A l'aide de ces instructions, vous pouvez provoquer le démarrage de la migration de données d'une classe de gestion dans une classe de stockage précise avant une autre. Cette méthode est généralement utilisée pour assurer la création d'une copie de récupération après sinistre critique dans les meilleurs délais. Pour plus d'informations, reportez-vous au manuel Configuring HSC and VTCS.

  4. Sur un système VLE 1.1 et versions supérieures, si plusieurs VLE sont connectées entre elles et au VTSS, par défaut, le VTCS donne priorité aux connexions VLE à VLE pour réaliser plusieurs copies VTV. Vous pouvez contrôler ce comportement en suivant les indications de la section Utilisation du paramètre FROMLST.

Utilisation du paramètre FROMLST

Si vous ne spécifiez pas de paramètre FROMLST, le comportement par défaut est le suivant :

  • Pour les VTSS mis en cluster, si une copie réside sur plusieurs VTSS dans le cluster, le VTV peut provenir de n'importe quel VTSS disponible, ce qui n'est pas adapté si le VTSS et l'ACS connecté sont éloignés géographiquement.

  • Pour les connexions VLE à VLE, si une copie VTV réside sur un VTSS et sur une VLE et que vous souhaitez la migrer vers une VLE connectée, le choix par défaut consiste à utiliser la connexion VLE à VLE. A nouveau, notez que ce choix n'est peut-être pas adapté si les VLE connectées sont éloignées géographiquement, par exemple dans un scénario de récupération après sinistre avec une VLE locale (LOCVLE) et une VLE distante (REMVLE) connectées au VTSSA. Vous souhaitez migrer deux copies VTV :

    • D'abord, une copie locale d'un VTSSA vers une LOCVLE

    • Ensuite, une copie à l'aide du processus de copie VLE à VLE de la LOCVLE vers la REMVLE. Réplication VLE à VLE (et non VTSS à VLE)

Pour créer les copies VTV comme vous le souhaitez, effectuez les opérations suivantes :

  1. Créez une instruction VTSSLST pour créer une liste VTSS contenant uniquement le VTSSA.

    VTSSLST NAME(VSM2VLE) VTSS(VTSSA)
    
  2. Créez une instruction STORCLAS qui envoie une copie VTV vers la REMVLE.

    STORCLAS NAME(FORREMOT) STORMNGR(REMVLE)
    
  3. Créez une instruction MIGRVTV qui retarde la migration de la copie vers la REMVLE.

    MIGRVTV STOR(FORREMOT) IMMDELAY(360)
    

    Le retard de migration est de 360 minutes pour s'assurer que la migration vers le site local ait lieu en premier. Ensuite, la migration vers le site distant est effectuée par copie VLE à VLE. Notez que la valeur de 360 minutes est donnée à titre d'exemple. Vous pouvez spécifier des valeurs allant jusqu'à 9998 (ne spécifiez pas 9999, parce que le VTV serait uniquement migré par automigration).

  4. Créez une instruction STORCLAS qui envoie une copie VTV vers la LOCVLE.

    STORCLAS NAME(FORLOCAL) STORMNGR(LOCVLE) FROMLST(VSM2VLE)
    

    Remarque:

    Notez que le paramètre FROMLST spécifie que la copie VTV locale provient du VTSSA.

  5. Pour finir, créez une instruction MGMTCLAS qui spécifie deux copies VTV, une pour le site local et une pour le site distant :

    MGMTCLAS NAME(DRVLE) MIGPOL(FORLOCAL,FORREMOT)
    

Routage des données vers la VLE

Pour acheminer les données vers la VLE, commencez par créer une commande SMC POLICY qui spécifie une classe de gestion VLE. Ensuite, créez des instructions SMC TAPEREQ qui acheminent la charge de travail désirée vers la stratégie VLE du SMC. Par exemple :

POLICY NAME(VLEWORK) MEDIA(VIRTUAL) MGMT(VLECLASS)

TAPEREQ DSN(VLETEST.**) POLICY(VLEMIGR)

L'exemple précédent permet d'assigner la stratégie VLEWORK à tous les jeux de données de bande avec un HLQ de VLETEST.