Bienvenue dans la "Liste des tâches à exécuter (parfois) du VTCS", également appelée "Liste des tâches ponctuelles". Par exemple, si vous décidez cette semaine d'exécuter DELETSCR pour remettre à zéro une liste de VTV provisoires qui immobilisent une grande partie de votre précieux espace VTSS et MVC. Parfait, bon travail ! A votre avis, dans combien de temps devrez-vous réexécuter la même opération ? En particulier si vous ne modifiez pas vos stratégies de suppression d'éléments provisoires ? Réponse : dans un jour, dans un mois ou dans une année, mais vous devrez le refaire.
Mais il n'y a pas d'inquiétudes à avoir. Des procédures utiles sont décrites dans le présent document pour vous aider à réduire la Liste des tâches à exécuter (parfois) et, comme vous l'avez déjà lu dans "Utilisation du tableau de bord VTCS", si vous surveillez de près vos rapports MVC et VTV, il est même possible que vousn'ayez pas besoin d'une liste, car ces rapports vous indiquent quand il convient d'exécuter les tâches obligatoires/ponctuelles.
Il existe également une autre classe de tâches "A exécuter (parfois)" qui sont quasiment des décisions de stratégie, mais qui sont incluses ici car (a) elles sont de nature proactive, ce qui les rend doublement utiles comme Tâches "ponctuelles" relevant des meilleures pratiques, et (b) il s'agit de techniques opérationnelles que vous pouvez utiliser, mettre de côté et réintroduire lorsque vous pouvez en tirer parti (ou non) à tout moment donné. Cela dit, nous allons commencer par trois de nos thèmes favoris dans cette catégorie, comme décrit à la section "Exécution de récupérations d'espace, de migrations et de rappels selon les besoins".
Ces tâches sont facultatives mais, en particulier dans le cas des récupérations d'espace selon les besoins, il s'agit de meilleures pratiques vivement recommandées pour des raisons qui s'imposent rapidement à l'évidence.
Comme vous le savez déjà, VSM récupère automatiquement de l'espace MVC sur chaque hôte exécutant des récupérations, le mot-clé étant automatiquement. En d'autres termes, la fonction de récupération d'espace est toujours en alerte et, bien qu'il s'agisse d'une tâche qui s'exécute en arrière-plan, si vous avez un grand nombre de MVC fragmentées, la récupération d'espace peut interférer sérieusement avec les migrations/rappels, en particulier pendant les périodes de pic de traitement.
Si votre rapport récapitulatif MVC ou la commande Display MVCPool indiquent un niveau de fragmentation élevé sur les MVC de votre système (et ce niveau est inférieur à la valeur définie dans les paramètres CONFIG RECLAIM THRESHLD ou MVCPool THRESH), vous pouvez planifier la récupération d'espace MVC selon les besoins en tant que tâche par lots à exécuter aux heures creuses.
La récupération d'espace MVC selon les besoins s'effectue à l'aide de RECLaim. Ouvrez Référence des commandes, des instructions de contrôle et des utilitaires ELS. Vous verrez alors quelques outils utiles qui vous permettront d'optimiser la récupération selon les besoins et d'exécuter cette fonctionnalité le plus efficacement possible :
Vous ne pouvez utiliser que l'un des paramètres MVCPOOL, STORCLAS, ACSid ou MVC pour filtrer la liste des MVC à traiter. Vos rapports MVC et VTV, comme décrit à la section "Utilisation du tableau de bord VTCS", vous aident à réduire la liste des candidats pouvant être inclus dans un pool MVC, une classe de stockage, un ACS spécifique, ou encore une plage ou une liste de MVC. Il vous suffit d'introduire cette liste dans RECLaim pour disposer de l'outil approprié pour réaliser la tâche.
Si vous ne spécifiez pas l'un de ces paramètres, la récupération d'espace sélectionne les MVC dans le pool de MVC nommé (si cette fonction est implémentée) ou le type de média (dans les environnements comprenant plusieurs médias MVC) nécessitant le plus de l'espace libre.
Les paramètres MAXMVC (nombre maximal de MVC traitées par une récupération d'espace unique), THRESH (pourcentage fragmenté de la MVC qui en fait un candidat à la récupération) et CONMVC (nombre maximum de MVC que le VTCS traite simultanément aussi bien pour la purge que pour la récupération) vous permettent de remplacer les paramètres globaux CONFIG RECLAIM correspondants pour la récupération selon les besoins. Cela vous donne la possibilité d'ajuster vos migrations selon les besoins de manière plus ou moins agressive par rapport à vos migrations automatiques.
NOWAIT permet d'accélérer le processus tandis que CONMVC est une autre méthode de réglage qui permet d'influencer le nombre de MVC traitées simultanément (reportez-vous au manuel Référence des commandes, des instructions de contrôle et des utilitaires ELS pour plus d'informations).
ELAPSE permet de détecter si aucune récupération selon les besoins n'a été effectuée dans l'intervalle spécifié. Si aucune récupération n'a eu lieu pendant cette période, la tâche s'interrompt.
Notez également que le VTCS applique le facteur de restriction le plus strict. Par exemple, si vous exécutez RECLAIM, réglez ELAPSE sur 5 heures et MAXMVC sur 10, et si le VTCS récupère 10 MVC en une heure, le VTCS met alors fin à la récupération avant l'expiration du délai défini par la valeur ELAPSE.
Le VTCS et le HSC doivent être actifs pour traiter une requête RECLAIM.
Comme cela a été mentionné précédemment, le VTCS/ELS est essentiellement un serveur. Par exemple, VSM gère automatiquement l'espace VTSS et migre les VTV afin de garantir un équilibre entre la disponibilité des données, l'utilisation des ressources et la protection des données optimales.
Cela est parfait pour un environnement stable, mais qu'en est-il si vous découvrez que votre système VSM est sur le point de recevoir un grand nombre de données d'application ? Réponse : il est peut-être temps d'exécuter une tâche par lots de migration selon les besoins pour libérer de l'espace VTSS avant que ne se produise l'événement de traitement de bande intensif mentionné précédemment.
Bien évidemment, vous exécutez les migrations selon les besoins à l'aide de MIGRATE, qui fournit les options suivantes :
Vous pouvez migrer les VTV :
par volser (répétitions admises) ;
classe de gestion ;
nom du jeu de données associé au VTV (méthode la plus efficace).
Une option DELETE(YES) est également disponible. Vous pouvez l'utiliser pour supprimer le VTV de l'espace VTSS après une migration réussie. Vous utilisez généralement DELete (YES) (option par défaut) pour les VTV qui ne seront probablement pas sollicités à nouveau. Vous pouvez aussi spécifier DELete (NO) pour vous assurer que les données critiques soient disponibles et rapidement migrées pour les VTV qui seront probablement sollicités à nouveau.
L'option NOWAIT vous aide à accélérer le processus. Cela revient à utiliser MIGRATE Format 1 ; reportez-vous au manuel Référence des commandes, des instructions de contrôle et des utilitaires ELS pour plus d'informations.
Vous pouvez aussi utiliser MIGRATE Format 2 pour effectuer une migration selon les besoins jusqu'au seuil pour tous les VTSS ou des VTSS spécifiques. Cet outil est particulièrement utile pour placer votre DBU là où vous voulez. Le VTCS se charge des modalités.
Notez également que, grâce à SET MIGopt, vous pouvez abaisser l'AMT élevé pour forcer efficacement une migration selon les besoins.
Le VTCS intègre un processus de rappel automatique qui démarre lorsqu'une tâche demande un jeu de données sur un VTV qui est migré sur bande, mais ne réside pas sur le VTSS. Qu'en est-il, toutefois, dans un scénario inverse ? Par exemple, vous effectuez un traitement de fin d'exercice et vous savez qu'il y a un grand nombre de tâches dont vous voulez lire les données à partir de VTV disponibles sur bande seulement. Le rappel selon les besoins est la solution idéale.
L'option RECALL vous offre toute la flexibilité dont vous avez besoin :
Pendant que vous exécutez la commande MIGRATE, vous pouvez rappeler des VTV par volser, classe de gestion ou nom de jeu de données associé.
Vous pouvez définir le VTSS sur lequel vous voulez rappeler les VTV. Sinon, la méthode par défaut consiste à utiliser le VTSS de création, et quelques aspects liés à la stratégie de rappel du VTSS doivent être pris en compte. Reportez-vous au manuel Référence des commandes, des instructions de contrôle et des utilitaires ELS pour plus d'informations.
RECALWER vous permet de spécifier si vous voulez rappeler des VTV avec la vérification des données en lecture.
Une option NOWAIT est disponible pour accélérer le processus.
De nombreuses tâches de gestion des RTD sont limitées à la "recherche et la résolution des problèmes liés au VTCS", car il s'agit presque exclusivement de scénarios de récupération d'erreurs. Les meilleures pratiques relatives aux RTD consistent à avoir suffisamment de RTD et à veiller au bon fonctionnement de ces derniers. N'oubliez pas que les RTD sont utilisés pour les migrations, les rappels et les récupérations. Il est donc essentiel de maintenir le juste équilibre de RTD pour toutes ces tâches. Pour y parvenir à l'aide des paramètres de fonctionnement, reportez-vous à la section "Vérification de l'état des bandes virtuelles (Tâche quotidienne)".
Outre le réglage des paramètres de fonctionnement des RTD, l'autre outil principal dont vous disposez avec les RTD est la commande VTCS Vary RTD, que vous utilisez pour modifier les états des RTD. Vous pouvez faire basculer les RTD en ligne, hors ligne ou en mode de maintenance si vous devez soumettre les RTD à des opérations de maintenance.
Les tâches ponctuelles majeures que vous rencontrerez probablement sont liées, et les deux premières utilisent Vary RTD :
"Modification des types de périphériques RTD", qui permet essentiellement d'effectuer une mise à niveau technologique d'une partie ou de l'ensemble des RTD de votre système.
Vous devez considérer la manière dont vous spécifier les médias MVC. Bien qu'il s'agisse réellement de considérations liées aux MVC, elles sont dues à un changement des types de périphériques RTD. Pour plus d'informations, reportez-vous à Configuration du HSC et du VTCS.
Utilisez la procédure suivante pour changer les types de périphériques RTD. Notez que la modification des types de périphériques RTD requiert que vous arrêtiez le VTCS sur tous les hôtes.
Pour modifier les types de périphériques RTD, procédez comme suit :
Passez en revue vos stratégies VSM.
Par exemple, vous pouvez examiner vos définitions de classe de gestion et de classe de stockage si ce type de périphérique RTD est utilisé pour les migrations.
Faites basculer les anciens RTD hors ligne sur le VTCS.
Si les nouveaux périphériques RTD utilisent les nouvelles adresses de périphériques MVS, procédez comme suit :
Définissez les nouvelles adresses sur MVS.
Exécutez DECOMP pour émettre vos instructions CONFIG.
Modifiez les instructions CONFIG pour remplacer les adresses des RTD par leurs nouvelles valeurs.
Exécutez CONFIG RESET.
Mise en garde :
Ne faites pas basculer les nouveaux transports en ligne sur MVS ! Sinon, ils peuvent être alloués comme des transports de proximité.Installez les nouveaux RTD.
Faites basculer les LSM sur lesquels les transports ont été remplacés à l'état hors ligne.
Faites basculer les LSM sur lesquels les transports ont été remplacés à l'état en ligne.
Faites basculer les nouveaux RTD en ligne sur VTCS.
Si nécessaire, ajoutez des MVC.
Pour plus d'informations, reportez-vous à la section "Ajout de MVC".
Comme vous le savez déjà, il est quelque peu difficile de limiter la discussion à l'une de vos entités virtuelles. Dans la mesure où les MVC contiennent des VTV, il est difficile de parler des unes sans aborder les autres inévitablement. En outre, si vous discutez des VTV, vous parlez aussi forcément des VTSS et des VTD.
Cela dit, les sections suivantes décrivent quelques procédures élémentaires à suivre pour exécuter des tâches "ponctuelles" relativement typiques avec les MVC pour diverses raisons. Par exemple, vous pouvez ajouter des MVC si vous manquez d'espace, comme décrit dans le précédent scénario, ou à titre préventif, pour éviter les problèmes.
Remarque :
Si vous supprimez des MVC dans la configuration suite au traitement de SET VOLPARM ou CONFIG MVCVOL :Vous ne pouvez pas ressaisir les volsers dans la configuration en tant que VTV.
N'utilisez pas de volsers pour les bandes HSC natives.
Le message SLS6944I indique le nombre de MVC qui ont été supprimés.
ELS 7.2 a facilité considérablement l'ajout de volumes. Vous utilisez désormais les instructions HSC VOLPARM et POOLPARM pour définir tous les volumes et leurs pools : volumes de proximité natifs, cartouches de nettoyage, MVC et VTV, ainsi que l'utilitaire HSC SET VOLPARM pour les charger. Pour plus d'informations, reportez-vous au manuel Configuration du HSC et du VTCS et Référence des commandes, des instructions de contrôle et des utilitaires ELS.
Pour ajouter des MVCS :
Créez une instruction VOLPARM pour définir les MVC.
Par exemple, pour définir une plage de volumes pleins T10000 en vue de leur chiffrement :
VOLPARM VOLSER(T10K2000-T10K2999)MEDIA(T10000T1)RECTECH(T1AE)
Créez une instruction POOLPARM pour définir le pool de MVC.
Par exemple, pour définir le pool de MVC T10000 avec des paramètres de réclamation :
POOLPARM NAME(SYS1MVCT1)TYPE(MVC)MVCFREE(40) MAXMVC(4) THRESH(60) START(70)
Créez ou mettez à jour vos instructions MGMTCLAS ou STORCLAS comme requis.
Par exemple, si vous avez ajouté un nouveau type de média MVC, suivez les recommandations décrites à la section Configuration du HSC et du VTCS.
Mettez à jour vos paramètres de sortie POLICY ou TAPEREQ comme requis.
Par exemple, si vous avez créé une nouvelle classe de gestion à l'étape 3, mettez à jour ou créez vos instructions TAPEREQ ou POLICY de sorte qu'elles pointent vers les nouvelles classes de gestion.
Avez-vous besoin de définir des VTV ?
Si la réponse est oui, allez à la section "Définition de VTV". Sinon, allez à la section "Validation et application des définitions de volume".
Pour définir des VTV :
Créez des instructions POOLPARM ou VOLPARM pour définir les VTV.
Par exemple, pour définir deux plages de VTV en vue de leur utilisation par les hôtes MVS1 et MVS2 :
POOLPARM NAME(SYS1VTV1)TYPE(SCRATCH) VOLPARM VOLSER(V5000-V5499)MEDIA(VIRTUAL) POOLPARM NAME(SYS1VTV2)TYPE(SCRATCH) VOLPARM VOLSER(V5500-V5999)MEDIA(VIRTUAL)
Allez à la section "Validation et application des définitions de volume".
Exécutez SET VOLPARM pour valider les instructions VOLPARM/POOLPARM.
SET VOLPARM APPLY(NO)
La commande APPLY(NO) valide les instructions sans les charger. Si les résultats vous conviennent, passez à l'étape 2. Sinon, révisez vos définitions de volume, puis allez à l'étape 2.
Exécutez SET VOLPARM pour charger les instructions VOLPARM/POOLPARM.
SET VOLPARM APPLY(YES)
Introduisez physiquement toutes cartouches réelles dans l'ACS.
Pour plus d'informations, reportez-vous à la section "Chargement de cartouches".
Pourquoi retirer des MVC du pool ? Un scénario typique peut être le remplacement d'anciens lecteurs par une technologie plus récente pour vos RTD et le retrait des anciens médias, auquel cas vous êtes amené à ajouter de nouvelles MVC au pool, comme décrit à la section Ajout de MVC et à retirer les anciens médias comme décrit à la section "Retrait définitif des MVC".
Notez que vous voudrez peut être, parfois, retirer provisoirement des MVC du pool. Par exemple, vous avez quelques médias défectueux, avérés ou suspectés. Vous souhaitez retirer les médias défectueux et les remplacer, essentiellement sous les mêmes volsers, comme décrit à la section "Retrait provisoire des MVC".
Pour retirer définitivement des MVC du pool, procédez comme suit :
Saisissez MVCDRain pour purger les MVC.
Par exemple, pour exécuter la commande MVCDRain en vue de purger les MVC dans la classe de stockage STORCL1, éjecter virtuellement les MVC et les remettre en place une fois la requête envoyée, saisissez les commandes suivantes :
MVCDRAIN STORCLAS(STORCL1) EJECT NOWAIT
Si les MVC ne sont plus requises dans un ACS, utilisez la commande Eject du HSC pour éjecter les MVC de l'ACS.
Eliminez les restrictions de sécurité, ainsi que les restrictions du système de gestion des bandes que vous avez définies pour la MVC.
Si vous utilisez les définitions VOLPARM et POOLPARM et le niveau du CDS virtuel est G ou supérieur, passez à l'étape 4. Sinon, allez à l'étape 5.
Si vous voulez réutiliser le volser de bande pour une utilisation de proximité (non VTCS) et utiliser les définitions VOLPARM/POOLPARM :
Mettez à jour les instructions POOLPARM/VOLPARM pour les MVC que vous souhaitez retirer.
Exécutez SET VOLPARM APPLY(YES) sur tous les hôtes pour appliquer les modifications.
Exécutez la commande SCRAtch du HSC pour supprimer les volumes de travail qui ne sont plus des MVC.
Si vous voulez réutiliser le volser de bande pour l'utilisation de proximité (non VTCS) sans utiliser les instructions VOLPARM/POOLPARM, vous devez procéder de la manière suivante :
Exécutez la commande EJECT du HSC pour retirer les MVC de l'ACS.
Changez l'étiquette de code-barres externe sur la cartouche.
Vous devez changer l'étiquette de code-barres externe, car les volsers MVC d'origine sont conservés dans le CDS, et ces volsers peuvent uniquement être utilisés en tant que MVC.
REMETTEZ les cartouches dans l'ACS.
OU
Créez de nouveaux jeux de données CDS.
Exécutez l'utilitaire MERGECDS du HSC en spécifiant l'instruction DELVirt pour retirer les plages de MVC que vous ne voulez pas.
Remarque :
Tous les HSC doivent être arrêtés lors de l'utilisation de cette option puisque de nouveaux jeux de données CDS sont créés.Pour retirer provisoirement des MVC du pool :
Saisissez la commande MVCDRain Eject pour la MVC.
Par exemple, pour exécuter la commande MVCDRain en vue de purger les MVC dans la classe de stockage STORCL1, éjecter virtuellement les MVC et les remettre en place une fois la requête envoyée, saisissez les commandes suivantes :
MVCDRAIN STORCLAS(STORCL1) EJECT NOWAIT
Cela a pour effet de :
Rappeler tous les VTV sur la MVC et les migrer vers les nouvelles MVC.
Rendre la MVC non sélectionnable pour les migrations du VTCS.
Pour remettre la MVC dans le pool de MVC, saisissez la commande MVCDRain pour la MVC.
La saisie de la commande MVCDRain sans le paramètre EJect pour la MVC rend cette dernière à nouveau disponible.
Par exemple, pour exécuter la commande MVCDRain en vue de purger les MVC dans la classe de stockage STORCL1 et les remettre en place une fois la requête envoyée, saisissez les commandes suivantes :
MVCDRAIN STORCLAS(STORCL1) NOWAIT
Remarque :
Vous pouvez aussi utiliser MVCMAINT pour marquer une MVC en lecture seule. Cela évite que le VTCS sélectionne la MVC pour les migrations, mais n'élimine pas les VTV de la MVC. Vous pouvez également utiliser MVCMAINT pour désactiver l'état en lecture seule.En cas d'utilisation de définitions VOLPARM/POOLPARM, l'option NOMIGRAT peut être spécifiée dans l'instruction POOLPARM afin d'empêcher l'utilisation des MVC pour les nouvelles migrations.
Utilisez MVCDRain pour "purger" une MVC (rappeler tous les VTV dans la MVC). Vous purgez généralement une MVC pour les raisons suivantes :
Un affichage ou un rapport MVC indique des erreurs de vérification des données pour la MVC. Le VSM ne migre pas vers la MVC et vous devez l'éliminer du pool des MVC.
Un affichage ou un rapport MVC indique des erreurs autres que les erreurs de vérification des données pour la MVC.
Une classe de stockage ou un pool de MVC nommé n'est plus utilisé et vous souhaitez retirer ou réutiliser les MVC associées.
Pour sélectionner les MVC à purger, vous pouvez spécifier l'un des paramètres suivants :
MVCid pour purger un ou plusieurs MVC par volser.
MVCPOOL pour purger les MVC dans un pool de MVC nommé. Reportez-vous au manuel Référence des commandes, des instructions de contrôle et des utilitaires ELS pour plus d'informations sur les pools de MVC nommés.
STORCLAS pour purger les MVC dans une classe de stockage. Reportez-vous au manuel Référence des commandes, des instructions de contrôle et des utilitaires ELS pour plus d'informations sur les classes de stockage.
Vous pouvez utiliser MVCDRain pour remplacer le paramètre CONFIG RECLAIM CONMVC. Vous pouvez exécuter MVCDRain à partir de chaque hôte, ce qui démarre les tâches de purge sur l'hôte en question égal à la valeur CONMVC. Ces tâches de purge peuvent s'exécuter en même temps que celles lancées par d'autres hôtes.
En outre, notez les points suivants :
Pour les VMVC, MVCDRAIN avec le paramètre EJECT supprime physiquement les VTV.
Mise en garde :
Si vous utilisez l'utilitaireDRCHKPT et/ou le paramètre CONFIG GLOBAL PROTECT pour protéger les contenus de sauvegarde CDS pour les VMVC, la saisie de MVCDR EJECT invalide le contenu VMVC de la sauvegarde CDS.Pour les VMVC et les MVC, l'utilitaire MVCDRAIN sans le paramètre EJECT ne supprime pas les VTV, mais met à jour l'enregistrement CDS de manière à n'afficher aucun VTV sur les VMVC/MVC.
Pour plus d'informations, reportez-vous au manuel Référence des commandes, des instructions de contrôle et des utilitaires ELS.
MVCMAINT est un outil tout aussi utile dans l'univers de VSM, et ses paramètres décrivent ses capacités :
Tout d'abord, le volser MVC (plage, liste, volser individuel) ou MANIFEST sont vos deux critères de sélection de MVC. On comprend pourquoi utiliser le volser MVC, mais qu'en est-il de MANIFEST ? Vous créez un fichier global (liste des MVC et VTV contenus dans ces derniers) quand vous exécutez la commande EXPORT, ce qui peut s'avérer nécessaire lorsque vous déplacez des MVC d'un système vers un autre. Lorsque vous importez les MVC dans le nouveau système, il est probablement judicieux qu'elles commencent leur nouvelle vie en mode de lecture seule, afin d'éviter qu'elles ne soient remplacées tant que vous ne les avez pas définies correctement.
READONLY (ON (Activé) ou OFF (Désactivé)). Reportez-vous à la puce précédente. Vous vous souvenez de la discussion concernant l'ajout de MVC au pool ? Vous pouvez les charger dans l'ACS à l'état provisoire, mais certains vendeurs apportent tout à l'état non provisoire, puis y remettent de l'ordre. Si les nouvelles MVC doivent être inscriptibles, MVCMAINT READONLY(OFF) est l'outil idéal à cette fin.
LOST (ON (Activé) ou OFF (Désactivé)). Comment est-il possible de perdre une MVC ? Est-il seulement possible de perdre des MVC ? Vous aurez certainement du mal à y croire, mais c'est possible. Par exemple, si le montage d'une MVC lancé par un VTCS ne s'achève pas (par opposition au fait qu'il s'achève, mais en renvoyant une erreur), le VTCS marque la MVC comme étant "perdue" dans le CDS, et l'élimine des préférences.
Les VTV multiplexés résidant sur une MVC "perdue" sont rappelés à partir d'une MVC alternative. Le VTCS n'essaie pas d'utiliser les MVC « perdues" pour la migration, à moins qu'il n'y ait pas d'autres MVC valides. Si une MVC à l'état "perdu" est monté avec succès, l'état "perdu" est supprimé de l'enregistrement MVC.
Qu'en est-il si vous savez que la MVC n'est pas réellement perdue ? Réponse : vous pouvez utiliser MVCMAINT pour désactiver l'état LOST.
Un usage intéressant de MVCMAINT mérite d'être mentionné. Qu'en est-il si un LSM est provisoirement en mode manuel ? Vous pouvez (provisoirement) éliminer la MVC des préférences dans ce LSM, ce que vous pouvez faire à l'aide de la commande LOST(ON). Vous pouvez ensuite, lorsque le LSM est rétabli en mode automatique, inverser le processus à l'aide de la commande LOST(OFF).
ERROR (ON (Activé) ou OFF (Désactivé)). Une MVC peut (par erreur) basculer à l'état d'erreur pour diverses raisons, notamment :
Le VTCS ne reconnaît pas le volume monté sur le RTD comme une MVC. Cela peut être dû au fait qu'une tâche MVS a écrasé la MVC. Déterminez ce qui est arrivé à la MVC. S'il ne contient plus de données VTV valides, réinitialisez le volume et renvoyez-le au pool des MVC.
La MVC n'est pas inscriptible, ce qui peut être dû au fait que la molette est en lecture seule ou que le progiciel de sécurité ne permet pas au VTCS d'écrire sur le volume. Réinitialisez la molette ou changez les règles dans le progiciel de sécurité afin de permettre l'accès en écriture sur la MVC.
Un ID de bloc erroné a été détecté et vous devez auditer (à l'aide du VTCS) la MVC pour essayer de corriger l'erreur.
Après avoir corrigé l'erreur comme décrit, utilisez MVCMAINT pour rétablir l'état de la MVC sur ERROR(OFF).
EJECT (ON (Activé) ou OFF (Désactivé)) définit l'état "éjection logique" de la MVC. Comment cet état est-il défini, et pourquoi le changer ? Si vous purgez explicitement une MVC à l'aide de MVCDRAIN, c'est probablement parce que vous pensez que le média est défectueux. Par conséquent, vous l'éliminez des préférences en la réglant sur l'état "éjection logique". Vous devez ensuite réellement éjecter la MVC, exécuter quelques tests, déterminer que tout est correct, puis charger à nouveau la MVC. A ce stade, utilisez MVCMAINT pour définir EJECT(OFF).
Vous avez ensuite un groupe d'attributs de MVC spécifiques aux médias T9840/T9940, tous dotés de commutateurs d'activation/de désactivation (ON/OFF) :
WARRANTY. Le VTCS détecte également l'expiration de la garantie des médias et règle l'état du paramètre WARRANTY sur ON (Activé). Vous pouvez aussi utiliser SMF, les données LOGREC ou vos rapports MVC et VTV pour détecter les MVC qui approchent de leur fin de vie, et utiliser la commande MVCMAINT pour définir manuellement WARRANTY ON. Savoir que la garantie a expiré vous permet de prévoir le remplacement des médias avant qu'ils n'atteignent leur fin de vie (reportez-vous à la puce suivante). Qu'en est-il si vous savez qu'il a été marqué par erreur que la garantie d'une MVC a expiré ? Réponse : il vous suffit d'utiliser MVCMAINT pour réinitialiser l'état expiré de la garantie.
RETIRED. Le VTCS détecte automatiquement la fin de vie des médias et règle l'état RETIRED sur ON (Activé). Comme décrit précédemment, vous pouvez utiliser SMF, les données LOGREC ou vos rapports MVC et VTV pour détecter les MVC qui approchent de leur fin de vie, et utiliser la commande MVCMAINT pour définir manuellement RETIRED ON ou rétablir l'état RETIRED OFF pour les MVC qui ont été marquées par erreur comme étant retirées.
Le VTCS détecte automatiquement une zone MIR (Media Information Region) non valide et règle l'état INVLDMIR sur ON (Activé). Vous pouvez récupérer la zone MIR à l'aide de l'utilitaire disponible dans le panneau opérateur pour le transport ou à l'aide de l'utilitaire disponible via MPST. Après avoir recréé la zone MIR, vous pouvez utiliser MVCMAINT pour définir l'état INVLDMIR OFF pour la MVC.
Remarque :
L'exécution de la commande MVCMAINT génère également un rapport MVC des volumes affectés par la tâche MVCMAINT.L'utilitaire MEDVERfy effectue la vérification des médias (MV) en vérifiant les données VTV qui peuvent être lues sur les MVC ou les VMVC (ELS 7.1, VLE 1.2 et versions supérieures uniquement). Pour la VLE, l'utilitaire MEDVERfy garantit que les cartouches VMVC dédupliquées peuvent être "réhydratées" (reconstituées).
L'utilitaire signale les MVC qui ont réussi ou échoué lors de la vérification et édite également le résultat au format XML. Pour plus d'informations sur l'utilitaire MEDVERfy, reportez-vous au manuel Référence des commandes, des instructions de contrôle et des utilitaires ELS.
Les sections suivantes présentent des exemples illustrant l'utilisation de l'utilitaire MEDVERfy pour la MV.
MEDVERFY MVC(VMC000)
Dans cet exemple :
MEDVERfy sélectionne une VMVC unique.
MAXMVC est renseigné par défaut par 99.
CONMVC est renseigné par défaut par 1, donc une seule MVC est traitée à la fois.
Aucun dépassement de délai n'est spécifié.
MEDVER MVCPOOL(MP1)
Dans cet exemple :
MEDVERfy sélectionne des MVC dans le pool de MVC MP1 en vue de leur traitement.
FREQency n'est pas spécifié et MAXMVC est renseigné par défaut par 99, donc MEDVERfy sélectionne les 99 meilleures MVC candidates sur la base de l'heure de la dernière vérification.
CONMVC est renseigné par défaut par 1, donc une seule MVC est traitée à la fois.
Aucun dépassement de délai n'est spécifié.
MEDVER MVC(MVC000-MVC049) CONMVC(2) TIMEOUT(720)
Dans cet exemple :
MEDVERfy sélectionne une plage de 50 volsers MVC en vue de leur traitement.
FREQency n'est pas spécifié et MAXMVC est renseigné par défaut par 99, donc MEDVERfy traite les 50 MVC spécifiées.
CONMVC est renseigné par 2, donc MEDVERfy traite deux MVC simultanément.
MEDVERfy s'exécute pendant 12 heures avant d'expirer.
MEDVER STORCLAS(SC1) MAXMVC(50) FREQ(365)
Dans cet exemple :
MEDVERfy sélectionne les MVC dans la classe de stockage SC1 en vue de leur traitement.
MAXMVC est renseigné par 50 et FREQency spécifie 365 jours, donc MEDVERfy sélectionne les 50 meilleures MVC candidates qui n'ont pas été vérifiées pendant 1 an au moins.
CONMVC est renseigné par défaut par 1, donc une seule MVC est traitée à la fois.
Aucun dépassement de délai n'est spécifié.
L'usage principal des VTSS, lorsque cela est nécessaire, consiste à utiliser la commande ou l'utilitaire VTCS Vary VTSS pour faire basculer un VTSS en ligne, hors ligne ou à l'état Mis au ralenti. Vous devez toujours savoir ce que vous faites, et pourquoi, lorsque vous faites basculer un VTSS hors ligne ou à l'état Mis au ralenti. Vous le faites probablement car le VTSS nécessite une maintenance ou vous prévoyez de l'éliminer de la configuration, ce qui est discuté à la section "Recherche et résolution des problèmes liés à VTCS".
Dans un premier temps, toutefois, le tableau ci-dessous vous montre ce qui se passe quand vous faites basculer un VTSS vers chacun des modes qu'il prend en charge (et pourquoi vous devez utiliser la commande QUIESCED plutôt que la commande OFFline, si cela est possible).
| Paramètre Vary VTSS spécifié | Etat initial du VTSS | Etat suivant du VTSS |
|---|---|---|
|
ONline |
En attente de la mise en ligne - A l'état en attente de la mise en ligne, le processus de mise en ligne a démarré mais ne s'est pas achevé sur tous les hôtes. |
En ligne - A l'état en ligne, le VTSS est en ligne et disponible, et il accepte aussi bien les tâches frontales que les tâches d'arrière-plan. Si le VTSS était hors ligne, quand il est mis en ligne, le VTCS affiche un message d'avertissement recommandant un audit du VTSS. |
|
QUIESCED |
Mise au ralenti - A l'état de mise au ralenti, le VTCS n'achemine aucune allocation de DD vers le VTSS, qui accepte toujours les montages en attente afin de permettre l'exécution des tâches longues comportant des chaînes unit=aff. Quand tous les VTD ne sont plus utilisés (leurs UCB ne sont plus alloués sur les MVS), le VTSS bascule à l'état mis au ralenti. Dans cet état, le VTSS continue d'accepter et de traiter les tâches d'arrière-plan ; par exemple, migrations, rappels et audits. |
Mis au ralenti - A l'état mis au ralenti, le VTSS continue d'accepter et de traiter les tâches d'arrière-plan ; par exemple, migrations, rappels et audits. En d'autres termes, vous pouvez utiliser les commandes et les utilitaires de rappel et de migration pour effectuer ces opérations à l'aide du VTSS mis au ralenti. |
|
OFFline |
En attente de la mise hors ligne - A l'état en attente de la mise hors ligne, le processus hors ligne a démarré mais ne s'est pas achevé sur tous les hôtes. Le VTCS arrête immédiatement le VTSS, puis interrompt et purge toutes les tâches actives et purge toutes les tâches dans la file d'attente. La tâche du serveur VTSS s'interrompt et plus aucune tâche frontale et d'arrière plan n'est acceptée. Le VTCS crée de nouveaux VTV et monte/démonte les VTV existants uniquement sur d'autres VTSS, si ceux-ci sont disponibles. |
Hors ligne - A l'état hors ligne, le VTSS est hors ligne sur tous les hôtes et n'accepte aucune tache frontale ou d'arrière-plan. Si une copie d'un VTV réside sur un VTSS hors ligne ainsi que sur une MVC et une tâche requiert le VTV, le VTCS rappelle automatiquement le VTV sur un autre VTSS, si celui-ci est disponible. |
Remarque :
Dans un environnement client/serveur (serveur MVS/CSC et LibraryStation ou SMC/HTTP sur hôtes clients), le VTCS ne peut pas déterminer si des tâches longues sont actives sur les hôtes clients. En conséquence, après qu'un VTSS a basculé à l'état hors ligne, vous devez toujours (a) faire basculer explicitement ses VTD hors ligne sur les MVS ou (b) veiller à ce que l'activité de bande virtuelle sur le client hôte a cessé.Dans les configurations CTR (Cross-TapePlex Replication) ou VTSS en cluster, les Clinks vers le VTSS doivent être mis hors ligne pour arrêter les opérations de réplication et d'exportation électronique.
Avant d'intervenir sur un VTSS, mettez ce dernier au ralenti en procédant comme suit :
Sur chaque hôte, faites basculer les VTD du VTSS hors ligne.
Sur chaque hôte, attendez que tous les périphériques basculent hors ligne. Notez que les VTD ne sont pas mis hors ligne tant qu'ils sont alloués. Si une tâche longue utilise un VTD, vous devez alors attendre qu'elle s'achève ou l'annuler.
Exécutez la commande VTSS QUIESCED sur tout système VTCS sur lequel est défini le VTSS nommé.
Attendez que le message SLS6742I s'affiche sur chaque système VTCS, indiquant que le VTSS est mis au ralenti.
Vous pouvez également migrer les données à partir du VTSS.
Exécutez la commande VTSS OFFLINE sur tout système VTCS sur lequel est défini le VTSS nommé.
Attendez que le message SLS6742I s'affiche sur chaque système VTCS, indiquant que le VTSS est hors ligne. Vous pouvez désormais intervenir sur le VTSS.
Le scénario suivant implique le retrait d'un VTSS : vous avez deux systèmes VSM distincts, dont la charge de travail sur l'un augmente tandis que la charge de travail sur l'autre baisse. Solution : retirez un VTSS du système A et affectez-le au système B. Dans la mesure où Installing ELS explique comment ajouter un VTSS, cette section se limitera à décrire la procédure de retrait d'un VTSS.
Pour retirer un VTSS :
Avant de retirer le VTSS, procédez comme suit :
Il n'est pas nécessaire de vider un VTSS avant sa suppression. En revanche, vous devez vous assurer que tous les VTV sont complètement migrés. Envisagez également la modification d'autres paramètres, par exemple, les instructions TAPEREQ, de sorte que les nouvelles tâches ne soient pas acheminées vers le VTSS retiré.
Si vous éliminez l'intégralité de la combinaison d'un type de périphérique/ACS d'un VTSS, assurez-vous également que tous les VTV sont complètement migrés dans un premier temps. Comme indiqué ci-dessus, envisagez la modification d'autres paramètres pour tenir compte des fonctionnalités de migration modifiées du VTSS (par exemple, les classes de gestion, qui désignent les classes de stockage spécifiant l'ACS et le média).
Faites basculer le VTSS à l'état Mis au ralenti.
Après la mise hors ligne, passez à l'étape 3.
Retirez le VTSS, puis réexécutez la commande CONFIG afin de le retirer logiquement.
Les instructions ci-dessous illustrent un exemple de JCL permettant d'exécuter CONFIG afin de mettre à jour la configuration en vue de refuser l'accès des hôtes au VTSS2 que vous avez physiquement retiré de votre configuration. Dans cet exemple, vous spécifiez à nouveau l'instruction VTSS pour le VTSS2 sans paramètres refusant l'accès des hôtes à ce VTSS.
//UPDATECFGEXEC PGM=SLUADMIN,PARM='MIXED' //STEPLIBDD DSN=hlq.SEALINK,DISP=SHR //SLSCNTLDD DSN=FEDB.VSMLMULT.DBASEPRM,DISP=SHR //SLSCNTL2DD DSN=FEDB.VSMLMULT.DBASESEC,DISP=SHR //SLSSTBYDD DSN=FEDB.VSMLMULT.DBASETBY,DISP=SHR //SLSPRINTDD SYSOUT=* //SLSINDD * CONFIG GLOBALMAXVTV=32000MVCFREE=40 RECLAIMTHRESHLD=70MAXMVC=40 START=35 VTSSNAME=VTSS1 LOW=70 HIGH=80 MAXMIG=3 RETAIN=5 RTDNAME=VTS18800 DEVNO=8800 CHANIF=0A RTDNAME=VTS18801 DEVNO=8801 CHANIF=0I RTDNAME=VTS18802 DEVNO=8802 CHANIF=1A RTDNAME=VTS18803 DEVNO=8803 CHANIF=1I RTDNAME=VTS18811 DEVNO=8811 CHANIF=0E RTDNAME=VTS18813 DEVNO=8813 CHANIF=1E VTDLOW=8900 HIGH=893F VTSSNAME=VTSS2
Cette section décrit les tâches les plus probables que vous serez amené à exécuter comme requis : suppression de VTV de travail et modification des attributs des VTV.
Remarque :
Si vous supprimez des VTV dans la configuration suite au traitement de SET VOLPARM ou CONFIG MVCVOL :Vous ne pouvez pas ressaisir les volsers dans la configuration en tant que MVC.
N'utilisez pas de volsers pour les bandes HSC natives.
Le message SLS6944I indique le nombre de VTV qui ont été supprimés.
Deux méthodes permettent de supprimer des VTV de travail :
A l'aide d'une stratégie, en spécifiant la commande DELSCR(YES) sur la classe de gestion d'un VTV et en utilisant la synchronisation des HSC ou LCM pour exécuter réellement la définition comme volume de travail.
Pour des tâches spécifiques, à l'aide de l'utilitaire DELETSCR. DELETSCR supprime les VTV de travail des VTSS et dissocie les VTV migrés des MVC. Les VTV supprimés sont marqués comme étant non initialisés, bien que les informations de version soient conservées.
Etant donné que la suppression des VTV de travail est abordée dans le document Installation d'ELS, les informations qui suivent traitent des points essentiels.
Prenez note de l'avertissement :
Mise en garde :
Si vous utilisez l'utilitaire DELETSCR pour supprimer des VTV de travail, toutes les données résidant sur ces VTV sont définitivement perdues et ne pourront pas être récupérées !La suppression de VTV n'est pas une tâche à effectuer à la légère. Si vous devez supprimer manuellement des VTV de travail, c'est parce que vous êtes confronté à un problème, comme illustré dans le scénario .
Pour éviter la suppression accidentelle de VTV par le biais d'une commande opérateur, DELETSCR est un utilitaire SLUADMIN seulement, et offre les fonctionnalités suivantes :
Vous pouvez spécifier des VTV par volser (volser individuel, liste ou plage), classe de gestion ou pool de travail HSC. Grâce à vos rapports MVC et VTV, vous devriez déjà avoir une idée du meilleur moyen d'identifier les candidats et d'appliquer l'option DELETSCR correspondante. Vous ne pouvez spécifier qu'une seule option (VTVid, MGMTclas ou SCRpool) et, si vous n'en spécifiez aucune, DELETSCR supprime tous les VTV admissibles. C'est peut-être ce que vous voulez, mais réfléchissez bien avant d'opter pour cette méthode.
Le paramètre obligatoire NOTREF indique les jours qui se sont écoulés depuis qu'un VTV a été référencé (1-999). Dans la pratique, NOTREF est un délai de grâce ; tout VTV référencé dans le délai de grâce défini n'est pas supprimé.
Un paramètre MAXVTV (facultatif) utile est disponible. Il permet de définir le nombre maximum de VTV que l'utilitaire DELETSCR supprime. Notez que cette valeur est un maximum, pas une cible. Si vous exécutez DELETSCR de manière proactive en dehors d'une période de pointe, vous n'avez pas à vous soucier de MAXVTV. En revanche, si vous êtes en difficulté, vous devez vous en soucier.
Notez que le paramètre MAXVTV peut être compris entre 0 et 999. Que se passe-t-il si vous spécifiez la valeur 0 ? Dans ce cas, l'utilitaire DELETSCR ne supprime aucun VTV, mais le rapport récapitulatif indique le nombre de VTV qui ont été supprimés au moment où vous avez exécuté DELETSCR (en d'autres termes, le rapport n'est qu'une image instantanée).
Enfin, vous pouvez voir les résultats de votre travail dans les rapports de l'utilitaire DELETSCR, qu'ils soient standard ou détaillés (en spécifiant le paramètre DETAIL).
L'exemple suivant illustre le JCL permettant d'exécuter l'utilitaire DELETSCR pour supprimer les VTV provisoires dans la classe de gestion MC1 non référencés pendant 60 jours, avec un maximum de 800 VTV, et générer un rapport détaillé.
//DELETSCR EXEC PGM=SLUADMIN,PARM='MIXED' //STEPLIBDD DSN=hlq.SEALINK,DISP=SHR //SLSPRINTDD SYSOUT=* //SLSINDD * DELETSCR MGMTCLAS(MC1) NOTREF(60) MAXVTV(800) DET
VTVMAINT est un autre outil particulièrement utile, cette fois pour la maintenance des VTV. Il permet d'effectuer ce qui suit :
Sélection des VTV par volser (plage, liste ou volser individuel, selon votre choix).
Dissociation des VTV des MVC, car il est probable que vous souhaitiez y procéder si vous modifiez la classe de gestion d'un VTV, comme décrit à la section "Modification de la classe de gestion des VTV et dissociation des VTV des MVC".
Modification de la classe de gestion du VTV, ce que vous faites lorsque vous voulez que le VTV soit géré autrement. D'autres méthodes permettent de le faire, mais l'outil idéal est clairement VTVMAINT, comme décrit à la section "Modification de la classe de gestion des VTV et dissociation des VTV des MVC".
Démontage logique des VTV spécifiés dans un VTSS hors ligne. Ce point est le mieux expliqué à la section "Démontage logique des VTV dans un VTSS hors ligne".
"Gestion des VTV répliqués via CTR (Cross-TapePlex Replication)."
Remarque :
Autre point à retenir, l'exécution de VTVMAINT génère également un rapport VTV des volumes affectés par la tâche VTVMAINT.Vous pouvez utiliser VTVMAINT pour modifier la classe de gestion d'un VTV. Si la nouvelle classe de gestion spécifie une classe de stockage différente, l'emplacement actuel du VTV sur les MVC est incorrect. La procédure ci-dessous explique comment utiliser VTVMAINT pour modifier la classe de gestion et la classe de stockage d'un VTV.
Pour modifier la classe de gestion d'un VTV et dissocier ce dernier :
Rappelez le VTV.
Le VTV doit résider sur le VTSS pour que la dissociation réussisse à l'étape 2.
Utilisez VTVMAINT ULINKMVC pour dissocier le VTV des MVC sur lesquelles il se trouve.
Utilisez VTVMAINT MGMTclas pour affecter une nouvelle classe de gestion.
Migrez à nouveau le VTV afin de le placer sur les MVC correctes ou reportez-vous à la section Modification de la classe de stockage d'un VTV avec RECONcil pour plus d'informations sur les procédures de déplacement des VTV vers les MVC comme requis.
Si un VTV est monté alors qu'un VTSS est mis hors ligne et s'il existe une copie du VTV sur une MVC, le VTCS ne rappelle pas le VTV migré sur un autre VTSS car le VTV est à l'état monté sur le VTSS hors ligne. Dans ce cas, vous pouvez utiliser VTVMAINT pour démonter logiquement les VTV dans le VTSS hors ligne (désactivez l'état "monté" dans le CDS), puis rappelez le VTV sur un autre VTSS. Le VTCS enregistre chaque démontage de VTV réussi dans le champ SMF14STA de l'enregistrement SMF sous-type 14. L'option VTVRPT (UNAVAIL) signale l'état des VTV non disponibles dans un VTSS hors ligne. Pour plus d'informations, reportez-vous au manuel Référence des commandes, des instructions de contrôle et des utilitaires ELS.
Ne démontez pas un VTV indisponible dans un VTSS hors ligne à moins que vous ne soyez absolument certain que les copies du VTV sur les MVC, si celles-ci existent, ont un contenu identique à celui du VTV indisponible ! Sinon, vous risquez de rappeler un VTV contenant des données obsolètes sur un autre VTSS ! Par exemple, il est probable qu'un VTV monté en lecture puisse être démonté en toute sécurité en vue de son rappel sur un autre VTSS. En revanche, il est probable qu'un VTV monté en écriture ne puisse pas être démonté en toute sécurité car il a probablement été mis à jour et, par conséquent, les copies MVC sont obsolètes.
La procédure ci-dessous décrit les étapes générales à suivre pour démonter logiquement un VTV et accéder à ce dernier à partir d'un autre VTSS.
Pour démonter logiquement un VTV et accéder à ce dernier à partir d'un autre VTSS :
Faites basculer le VTSS hors ligne sur un VTCS à l'aide de la commande suivante :
VT VARY VTSS(name) OFFLINE
Si l'E/S était active et le VTSS a échoué, la MVS devrait renfermer les VTD et démonter tous VTV montés du point de vue de la MVS. Toutefois, si la communication avec le VTSS échoue avant que celui-ci n'ait démonté effectivement tous VTV montés, ces derniers peuvent rester en ligne sur le VTCS. En conséquence, vous devez commencer par faire basculer le VTSS hors ligne sur le VTCS.
Si les MVS ont renfermé les VTD et démonté tous VTV montés, allez à l'étape 3. Sinon, passez à l'étape 2.
Démontez le VTV (du point de vue de la MVS).
Il n'est pas possible de remonter le VTV sur un VTD dans un autre VTSS si la MVS considère toujours qu'il est monté dans le VTSS hors ligne. Effectuez l'une des opérations suivantes :
Utilisez la commande MVS UNLOAD pour démonter le VTV.
Utilisez VARY OFFLINE pour basculer hors ligne le VTD sur lequel le VTV est monté, ce qui a aussi pour effet de démonter le VTV.
Exécutez VTVMAINT, en spécifiant le VTSS hors ligne et les VTV que vous voulez démonter logiquement.
Par exemple, pour démonter logiquement les VTV VV6823, VV6825 et VV6688 dans le VTSS01 hors ligne, codez l'instruction SLSIN DD suivante dans votre JCL :
VTVMAINT DISMOUNT VTV(VV6823,VV6825,VV6688) VTSS(VTSS01)
S'il existe des copies migrées des VTV démontés auxquelles un VTSS en ligne peut accéder, vous pouvez désormais utiliser ce VTSS pour accéder aux VTV.
Mise en garde :
Si la copie du VTV montée dans le VTSS hors ligne a été modifiée et n'a pas été migrée, la copie MVC que vous rappelez sur un autre VTSS n'est pas à jour ! En conséquence, Oracle recommande vivement que vous ne rappeliez pas ces copies MVC non actualisées !Astuce :
Quand le VTSS hors ligne est prêt à être remis en ligne, Oracle recommande vivement que vous auditiez le VTSS avant d'exécuter les tâches de production utilisant le VTSS. Assurez-vous également d'éliminer tout VTD renfermé avant d'exécuter la commande VTSS VARY ONLINE.Vous pouvez utiliser VTVMAINT pour modifier l'état des VTV répliqués via CTR en procédant comme suit :
Utilisez VTVMAINT OWNRPLEX pour modifier le TapePlex appartenant au VTV.
Utilisez VTVMAINT DELEXpot pour supprimer le nom d'un TapePlex faisant référence à un VTV.
Utilisez VTVMAINT ADDEXpot pour ajouter le nom d'un TapePlex faisant référence à un VTV.
Pour plus d'informations, reportez-vous au Guide de récupération après sinistre et de gestion des données hors site d'ELS.
Comme décrit à la section "Modification de la classe de gestion des VTV et dissociation des VTV des MVC", vous pouvez utiliser VTVMAINT pour modifier la classe de gestion d'un VTV, ce qui peut, bien évidemment, modifier sa classe de stockage. Et si vous vouliez déplacer explicitement le VTV d'une classe de stockage vers une autre ? Réponse : utilisez RECONcil.
Avant de soumettre votre première tâche RECONcil (utilitaire SLUADMIN uniquement), déterminez pourquoi vous voulez modifier la classe de stockage d'un VTV. On distingue essentiellement trois raisons :
Comme indiqué ci-dessus, vous modifiez explicitement la classe de gestion/classe de stockage du VTV.
Les VTV ne se trouvent pas sur le bon média, dans le bon ACS ou les deux.
Un ACS est indisponible pendant une longue période, puis il est remis en ligne. Dans ce cas, vous devez d'abord modifier le paramètre MIGpol dans l'instruction MGMTclas afin que les VTV concernés pointent vers un autre ACS (et média, le cas échéant). Lorsque l'ACS d'origine est remis en ligne, vous devez alors modifier le paramètre MIGpol dans l'instruction MGMTclas de manière à désigner l'ACS d'origine, puis exécuter RECONcil en spécifiant les instructions MGMTclas (ou STORclas) actualisées afin de déplacer les VTV vers l'ACS d'origine.
Notez que cette discussion traite de l'utilisation de RECONcil pour rapprocher la classe de stockage incorrecte (média MVC ou emplacement ACS incorrect, ou les deux) d'un VTV. Et si vous souhaitiez déplacer des VTV dont les données sont désormais consultées moins fréquemment depuis un média orienté accès (par exemple, cartouches T9840) vers un média orienté stockage (par exemple, cartouches T9940) et un ACS de magasin étendu ou hors site ? Dans ce cas, vous configurez généralement une stratégie d'archivage à l'aide des paramètres ARCHAge/ARCHPol de l'instruction MGMTCLAS, et le déplacement du VTV s'effectue automatiquement en fonction du paramètre ARCHPol défini lorsque la valeur ARCHAge est dépassée et que le VTV est rappelé et migré à nouveau.
Par conséquent, une stratégie d'archivage automatique est similaire à une migration automatique. Les deux se produisent au fil du temps ; or du temps, c'est ce que vous n'avez pas si un ou plusieurs VTV sont vraiment à un emplacement incorrect. Dans ce cas, utilisez RECONcil.
Pour modifier l'ACS/le média VTV avec RECONcil :
Pour sélectionner les VTV à valider (c'est-à-dire, ont-ils besoin d'un rapprochement ou non ?), vous pouvez spécifier l'un des paramètres RECONcil suivants :
STORclas - Spécifie une ou plusieurs classes de stockage. Ici, RECONcil effectue ce qui suit :
Recherche les classes de stockage spécifiées dans la définition ACS et du média.
Analyse les MVC qui se trouvent actuellement dans les classes de stockage. L'ACS et le média MVC correspondent-ils à la définition des classes de stockage ? Si la réponse est non, indiquez les MVC/VTV erronés.
MVC - Spécifie une liste ou une plage de MVC. RECONcil effectue ce qui suit :
Détermine l'ACS et le média réels des MVC spécifiées.
L'ACS/le média MVC réels correspondent-ils à la définition des classes de stockage de la MVC ? Si la réponse est non, indiquez les MVC/VTV erronés.
MGMTclas - Spécifie une ou plusieurs classes de gestion. RECONcil effectue ce qui suit :
Recherche la définition de l'ACS et du média comme spécifié dans le paramètre MGMTclas MIGpol.
Analyse les VTV qui se trouvent actuellement dans les classes de gestion spécifiées. Le VTV se trouve-t-il sur une MVC avec un ACS/média correspondant à la spécification MGMTclas MIGpol ? Si la réponse est non, indiquez les VTV erronés sur les MVC.
VTV - Liste ou plage de VTV. RECONcil effectue ce qui suit :
Détermine les classes de gestion des VTV spécifiés.
Recherche la définition de l'ACS et du média comme spécifié dans le paramètre MGMTclas MIGpol.
Analyse les VTV qui se trouvent actuellement dans les classes de gestion spécifiées. Le VTV se trouve-t-il sur une MVC avec un ACS/média correspondant à la spécification MGMTclas MIGpol ? Si la réponse est non, indiquez les VTV erronés sur les MVC.
Remarque :
Et comme vous pouvez l'imaginer, si vous ne spécifiez aucun des paramètres de sélection, le VTCS valide tous les VTV. Un complément d'informations à ce sujet est présenté à l'étape 2.Acceptez les valeurs par défaut la première fois que vous exécutez RECONcil, afin de générer un rapport uniquement car, comme vous pouvez l'imaginer, aucun mouvement de données n'a lieu. Le système se contente de signaler les VTV candidats au rapprochement.
Mise en garde :
Dans la mesure où le rapprochement des VTV peut solliciter considérablement les ressources, Oracle recommande vivement l'exécution de RECONcil sans MOVEVTV dans un premier temps, puis l'ajustement de la tâche comme requis avant de spécifier MOVEVTV.Le cas échéant, ajustez la tâche RECONcil.
Par exemple, si vous avez exécuté le rapport à l'étape 2, et il semblerait que le rapprochement prenne du temps, envisagez ce qui suit :
Exécutez RECONcil pendant les périodes de traitement creuses, comme vous effectueriez la récupération d'espace MVC selon les besoins.
Utilisez les paramètres de l'utilitaire RECONcil pour remplacer les réglages CONFIG RECLAIM THRESHLD, MAXMVC et CONMVC afin d'optimiser les performances du rapprochement.
Indiquez le temps de rapprochement maximum, en minutes, dans le paramètre ELAPSE.
Remarque :
Plusieurs facteurs restrictifs ont un impact sur les rapprochements (par exemple, MAXMVC et ELAPSE). Le VTCS applique le facteur restrictif le plus strict. Par exemple, si vous exécutez RECONcil et réglez ELAPSE sur 5 heures et MAXMVC sur 10, et que le VTCS effectue le rapprochement de 10 MVC en une heure, le VTCS interrompt alors les rapprochements avant l'expiration du délai ELAPSE.Une option RECONcil POLICYdd est également disponible dans l'utilitaire ARCHive et peut être un outil de diagnostic utile. POLICYdd, qui génère uniquement un rapport, pointe vers un fichier contenant un autre jeu d'instructions MGMTclas.
Astuce :
Il s'agit essentiellement d'un outil de "simulation de scénario" utile qui indique si vous avez modifié les classes de gestion de quelques VTV abordées à la section Modification de la classe de gestion des VTV et dissociation des VTV des MVC (y compris leurs spécifications de classes de stockage) puis exécuté RECONcil. Quel en sera le résultat ? Vous pouvez désormais le savoir avant de modifier réellement la classe de gestion d'un VTV.Remarque :
Le VTCS et le HSC doivent être actifs pour traiter une requête RECONcil, sauf lorsque vous spécifiez le paramètre POLICYdd.Vous avez effectué tous les "scénarios de simulation", ajustements et planifications aux heures creuses requis.
Il est temps à présent de passer à la phase pratique. L'exemple ci-dessous illustre un JCL pour exécuter RECONcil :
Procédez au rapprochement des VTV dans les classes de gestion LOCALPROD1 et LOCALPROD2.
Réglez MAXMVC sur 60, CONMVC sur 8 et ELAPSE sur 60 pour la tâche RECONcil.
//RECONCIL EXEC PGM=SLUADMIN //STEPLIBDD DSN=hlq.SEALINK,DISP=SHR //SLSPRINTDD SYSOUT=* //SLSINDD * RECON MGMT (LOCALPROD1,LOCALPROD2) MAXMVC(60) CONMVC(8) ELAPSE(360) MOVEVTV
Et bien sûr vous obtenez un rapport RECONcil après action qui vous indique comment se sont déroulés les événements (avec ou sans problèmes); afin que vous puissiez ajuster à nouveau et réexécuter le processus, si nécessaire.
Vous pouvez utiliser l'instruction LOGUTIL FOR_LOSTMVC pour récupérer des VTV qui résidaient sur des MVC perdues ou endommagées. Comment fonctionne l'instruction LOGUTIL FOR_LOSTMVC et comment l'utiliser de la manière la plus efficace ?
L'utilitaire FOR_LOSTMVC analyse le CDS et la structure des fichiers journaux (si nécessaire) pour identifier tous les VTV résidant sur les MVC perdues ou endommagées dont vous spécifiez les volsers et pour déterminer la méthode de récupération à partir d'une copie alternative des VTV, comme décrit à la section Tableau 5-2. LOGUTIL FOR_LOSTMVC génère un rapport indiquant tous les VTV qui existaient sur les MVC perdues ou endommagées et comment ils sont récupérés, ainsi que des informations récapitulatives concernant chaque MVC perdue ou endommagée.
Tableau 5-2 Copie alternative du VTV et processus de récupération
| Catégorie de la copie alternative du VTV | Processus de récupération |
|---|---|
|
Catégorie 1 : Résidant actuellement sur le VTSS. |
La récupération s'effectue à partir de la copie résidante. Si vous avez invoqué des commandes de récupération, les commandes |
|
Catégorie 2 : Actuellement lié à une ou plusieurs copies MVC alternatives. |
La récupération s'effectue à partir de la meilleure MVC alternative sur la base de quatre facteurs :
Si vous avez invoqué des commandes de récupération, les commandes |
|
Catégorie 3 : A été répliqué via CTR (Cross-TapePlex Replication). |
Le premier TapePlex distant rencontré contenant une copie du VTV est utilisé pour récupérer le VTV. Si vous avez invoqué des commandes de récupération, les commandes |
|
Catégorie 4 : Etait précédemment lié à une ou plusieurs copies MVC qui peuvent toujours contenir des données du VTV. |
Une des MVC précédemment liées est sélectionnée comme MVC de récupération. Ces copies MVC ont été trouvées dans les fichiers journaux et peuvent toujours contenir une copie du VTV. Vous devez auditer la MVC de récupération sélectionnée. La meilleure copie MVC précédemment liée à partir de laquelle effectuer la récupération est sélectionnée sur la base des mêmes facteurs que les MVC alternatives. Si vous avez invoqué des commandes de récupération, les commandes Les commandes |
|
Catégorie 5 : Est irrécupérable. |
Des copies irrécupérables uniquement existaient sur les MVC perdues ou endommagées. |
Remarque :
Si vous avez invoqué des commandes de récupération, les commandesMVCMAINT sont également générées pour les Catégories 1, 2, 3 et 4.. Ces instructions marquent les MVC perdues ou endommagées en lecture seule et comme étant endommagées afin qu'elles ne puissent plus être sélectionnées pour les rappels ou les migrations.Remarque :
Dans cette procédure, les exemples de JCL n'illustrent pas les instructions DD pour les copies CDS, ce qui est valable si le HSC est actif et vous voulez utiliser le CDS actif sur le système sur lequel vous exécutez LOGUTIL. Sinon, vous devez spécifier les instructions DD pour les copies CDS.Pour récupérer des VTV à l'aide de FOR_LOSTMVC :
Commencez par exécuter la commande LOGUTIL FOR_LOSTMVC uniquement avec les volsers des MVC perdues ou endommagées.
L'exemple ci-dessous indique ce qui suit :
Le jeu de données de journalisation est LOGIN.
Remarque :
Vous pouvez exécuterLOGUTIL FOR_LOSTMVC en spécifiant une instruction LOGDD fictive afin de permettre la récupération sur des systèmes sur lesquels la journalisation CDS a été activée. Bien que la récupération se limite aux données contenues dans le CDS, elle reste utile si tous les VTV sont résidants, se trouvent sur une copie MVC alternative ou ont été exportés via Cross-Tape Replication.Le volser de la MVC endommagée est DMV509.
Les commandes de récupération sont consignées dans le jeu de données RECVCMD.
//JOBLOGR job (account),programmer,REGION=1024k //S1 EXEC PGM=SLUADMIN,PARM=MIXED //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR //LOGIN DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(-2),DISP=OLD // DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(-1),DISP=OLD // DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(0),DISP=OLD //RECVCMD DD DSN=FEDB.VSMLMULT.RECVCMD,DISP=(CATLG,DELETE), // UNIT=SYSDA,SPACE=(CYL,(1,1),RLSE), // DCB=(RECFM=FB,LRECL=80,BLKSIZE=27920) //SLSPRINT DD SYSOUT=* //SLSIN DD * LOGUTIL LOGDD(LOGIN) FOR_LOSTMVC MVC(DMV509) COMMANDS(RECVCMD)
Passez en revue le rapport LOGUTIL FOR_LOSTMVC obtenu à l'étape1.
Sélectionnez les VTV à récupérer et réexécutez LOGUTIL FOR_LOSTMVC, en spécifiant les VTV que vous voulez récupérer à partir de a MVC perdue ou endommagée. Par exemple :
//JOBLOGR job (account),programmer,REGION=1024k //S1 EXEC PGM=SLUADMIN,PARM=MIXED //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR //LOGIN DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(-2),DISP=OLD // DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(-1),DISP=OLD // DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(0),DISP=OLD //RECVCMD DD DSN=FEDB.VSMLMULT.RECVCMD,DISP=(CATLG,DELETE), // UNIT=SYSDA,SPACE=(CYL,(1,1),RLSE), // DCB=(RECFM=FB,LRECL=80,BLKSIZE=27920) //SLSPRINT DD SYSOUT=* //SLSIN DD * LOGUTIL LOGDD(LOGIN) FOR_LOSTMVC MVC(DMV509) VTV(DX009) COMMANDS(RECVCMD)
Remarque :
Si vous spécifiez un VTV qui ne se trouvait pas sur la MVC perdue ou endommagée, ce VTV est ignoré.Si vous voulez récupérer tous les VTV spécifiés sur la MVC endommagée, passez à l'étape 3.
Pour récupérer les VTV spécifiés, exécutez les commandes dans le jeu de données de récupération indiqué à l'étape 2.
Remarque :
Les commandes dans le jeu de données de récupération doivent être exécutées (à l'aide du JCL SLUADMIN standard) aussitôt que possible après l'exécution de FOR_LOSTMVC afin de garantir leur précision.
Oracle vous recommande d'exécuter les commandes de récupération figurant dans le fichier COMMANDS dans l'ordre suivant :
Toutes les commandes EEXPORT ULINKMVC.
Toutes les commandes MVCMAINT READONLY(ON).
Toutes les commandes AUDIT.
S'il y avait des commandes EEXPORT ULINKMVC ou AUDIT, réexécutez FOR_LOSTMVC. Il ne devrait y avoir alors aucune commande EEXPORT ou AUDIT dans le nouveau fichier COMMANDS généré. Si ce n'est pas le cas, retournez à l'étape a.
Toutes les commandes MVCMAINT READONLY(ON) ERROR(ON).
Toutes les commandes ULINKMVC.
Toutes les commandes RECALL.
L'utilitaire RECONcil
Les commandes MVCMAINT sont générées pour toutes les MVC perdues ou endommagées spécifiées existant dans le CDS et qui comprennent au moins un VTV de qualification. Les commandes MVCMAINT définissent l'état en lecture seule et les sections erronées/endommagées sur les MVC perdues ou endommagées afin d'empêcher leur allocation pour les rappels ou les migrations. 3000 MVC environ au maximum sont incluses dans chaque commande MVCMAINT.
Exécutez l'utilitaire RECONcil pour veiller à créer le nombre correct de copies MVC pour chaque VTV.
Par exemple :
//JOBLOGR job (account),programmer,REGION=1024k //S1 EXEC PGM=SLUADMIN,PARM=MIXED //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR //LOGIN DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(-2),DISP=OLD // DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(-1),DISP=OLD // DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(0),DISP=OLD //RECVCMD DD DSN=FEDB.VSMLMULT.RECVCMD,DISP=(CATLG,DELETE), // UNIT=SYSDA,SPACE=(CYL,(1,1),RLSE), // DCB=(RECFM=FB,LRECL=80,BLKSIZE=27920) //SLSPRINT DD SYSOUT=* //SLSIN DD * RECONCIL VTV(DX009)