Ce chapitre présente la configuration du logiciel de l'hôte MVS pour VLE, comme le décrivent les sections suivantes :
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.
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
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 VSM 5, cette valeur doit correspondre aux valeurs spécifiées dans l'écran VSM5 IFF Configuration Status. 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 adresses IP de port VLE pour la communication (UUI) de l'hôte sont requises pour le paramètre SERVER IP de SMC.
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. 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".
Pour plus d'informations, reportez-vous à la section "Spécification de la stratégie de récupération pour VMVCS".
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 Référence des commandes, des instructions de contrôle et des utilitaires ELS 7.3.
La déduplication (suppression des doublons) 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.
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 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.
L'ajout d'une VLE à un système VSM requiert les opérations décrites dans les sections suivantes :
Acquisition du logiciel ELS prenant en charge les correctifs PTF de la VLE
Mise à jour de la console CONFIG de VTCS pour définir la VLE
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.
A partir de la version ELS 7.2, la prise en charge est comprise à la base. Pour ELS 7.1, obtenez les dernières données HOLDDATA de la commande SMP/E receive et les derniers correctifs PTF (L1H16J6, L1H1674) et la commande SMP/E APPLY avec GROUPEXTEND.
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))
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 SMC STORMNGR pour chaque système VLE, plus une ou plusieurs instructions SMC SERVER qui définissent les chemins de contrôle TCP/IP pour la VLE. Pour les versions 7.0 et ultérieures, vous souhaiterez éventuellement effectuer cette opération dans le fichier CMDS de votre SMC, comme indiqué 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 192.168.1.10 du port de la VLE 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.
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, comme suit :
Pour VTCS 7.0 et les versions ultérieures, l'instruction CONFIG TAPEPLEX définit le TapePlex sur lequel le VTCS s'exécute et fournit la liste des VLE définies dans le paramètre CONFIG TAPEPLEX STORMNGR comme illustré dans 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 (en l'occurrence, 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 vers 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 VSM 5, cette valeur doit correspondre aux valeurs spécifiées dans l'écran VSM5 IFF Configuration Status. 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 ultérieures peuvent évidemment piloter VLE 1.5.1 de la même manière que VTCS 7.0. 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.
Cependant, avec VTCS 7.1 ou une version ultérieure, vous pouvez définir une VLE avec davantage de cibles RTD VLE qu'il n'existe de chemins du VTSS à la VLE, ce qui signifie que :
Le chemin du VTSS à la VLE n'est pas réservé, sauf 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 le système (VLE1 et VLE2), spécifient le nombre de périphériques VLE par le biais du 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 de la forme Sxxx (où xxx est une valeur hexadécimale).
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 VSM 5, cette valeur doit correspondre aux valeurs spécifiées dans l'écran VSM5 IFF Configuration Status. 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 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, d'où une plus grande capacité effective du VMVS (fragmentation réduite).
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 expliquent comment définir les cartouches VMVC sur le logiciel de l'hôte MVS.
Utilisez des instructions HSC POOLPARM ou VOLPARM pour définir les pools de 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)
Exécutez SET VOLPARM pour valider les instructions POOLPARM ou VOLPARM.
SET VOLPARM APPLY(NO)
La commande APPLY(NO) valide les instructions sans les charger. Si les résultats vous conviennent, passez à l'étape suivante. Sinon, révisez les définitions de volume dans le cadre de cette étape et, si elles sont valides, passez à l'étape suivante.
Exécutez SET VOLPARM pour charger les instructions POOLPARM ou VOLPARM.
SET VOLPARM APPLY(YES)
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.
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 où 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. 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 VMVC et des MVC, vous pouvez configurer les stratégies de migration pour que la migration se fasse vers une VLE. Cependant, si la VLE devient saturée ou indisponible, la migration continue de se faire vers des supports de bande réels (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.
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 :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.
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 de VLE à VLE pour réaliser plusieurs copies VTV. Vous pouvez contrôler ce comportement en suivant les indications de la section Contrôle de la copie de VLE à VLE.
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. Considérons un scénario de récupération après sinistre avec une VLE locale (LOCVLE) et une VLE distante (REMVLE) connectée à un VTSSA. Vous souhaitez migrer deux copies VTV :
D'abord, une copie locale de VTSSA vers LOCVLE.
Ensuite, une copie de VLE à VLE depuis LOCVLE vers REMVLE à l'aide de la réplication de VLE à VLE (par opposition à la migration de VTSS à VLE).
Pour créer les copies VTV comme vous le souhaitez, effectuez les opérations suivantes :
Créez une instruction STORCLAS qui envoie une copie du VTV vers LOCVLE.
STORCLAS NAME(FORLOCAL) STORMNGR(LOCVLE)
Créez une instruction STORCLAS qui envoie une copie du VTV vers REMVLE.
STORCLAS NAME(FORREMOT) STORMNGR(REMVLE)
Créez des instructions MGRVTV qui spécifient que les migration vers la classe de stockage FORLOCAL ont lieu avant les migrations vers la classe de stockage FORREMOT.
MIGRVTV STOR(FORLOCAL) INITIAL MIGRVTV STOR(FORLOCAL) SUBSEQNT(360)
Enfin, créez une instruction MGMTCLAS qui indique deux copies de VTV, une pour le site locale et l'autre pour le site distant :
MGMTCLAS NAME(DRVLE) MIGPOL(FORLOCAL,FORREMOT)
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(VLEDR) MEDIA(VIRTUAL) MGMT(DRVLE)
TAPEREQ DSN(HR.**) POLICY(VLEDR)
L'exemple précédent permet d'assigner la stratégie VLEDR à tous les jeux de données de bande avec un HLQ de HR.