Le SMC inclut plusieurs fonctions permettant de configurer et de gérer votre environnement TapePlex StorageTek et peut être configuré sur un hôte partagé ou sur plusieurs hôtes à l'aide de la fonction client/serveur SMC.
Le SMC sert d'interface entre le système d'exploitation z/OS d'IBM et les systèmes de contrôle de bibliothèques StorageTek, HSC et MVS/CSC. Le SMC peut opérer avec ces systèmes de contrôle de bibliothèques selon les manières suivantes.
Le SMC peut opérer directement avec un HSC sur le même hôte ou à distance avec un HSC sur un hôte différent, en utilisant TCP/IP et le composant de serveur HTTP SMC.
Le SMC peut opérer avec MVS/CSC sur le même hôte pour communiquer avec ACSLS.
Remarque :
MVS/CSC 7.1 et versions ultérieures n'est pas compatible avec StorageTek LibraryStation. Dans un environnement MVS exclusif, vous devez utiliser StorageTek SMC et son composant de serveur HTTP pour assurer la communication entre les hôtes MVS.SMC peut communiquer avec un serveur ACSLS avec support XAPI activé (sans avoir recours à MVS/CSC). Pour plus d'informations, reportez-vous à la section Interface client XAPI pour serveur ACSLS.
Un TapePlex est une configuration matérielle simple, généralement représentée par un jeu de données de contrôle (CDS) HSC unique. Un TapePlex peut contenir plusieurs ACS (Automated Cartridge System, système de cartouches automatisé) et VTSS (Virtual Tape Storage Subsystem, sous-système de stockage de bandes virtuel).
Il est recommandé d'utiliser la commande SMC TAPEPlex
pour définir explicitement tous les TapePlex auxquels un sous-système SMC doit accéder.
Pour plus d'informations sur la commande SMC TAPEPlex
, reportez-vous au document Référence des commandes, des instructions de contrôle et des utilitaires ELS.
La fonction client/serveur SMC permet au SMC de communiquer avec les systèmes HSC ne résidant pas sur le même hôte que le module SMC. Cette fonction vous permet d'effectuer les opérations suivantes :
Réduire le nombre d'emplacements auxquels HSC est démarré.
Il est recommandé de n'exécuter HSC que sur deux hôtes, le second hôte en tant que sauvegarde. L'exécution de HSC sur uniquement un ou deux hôtes réduit les conflits d'utilisation des jeux CDS et élimine le besoin de gérer plusieurs fichiers syslog MVS.
Communiquer avec plusieurs systèmes TapePlex HSC représentant des configurations matérielles physiquement différentes.
Réduire les interruptions du traitement des bandes en fournissant une seconde instance HSC en vue du basculement.
Tous les utilisateurs qui désirent que le SMC communique avec un sous-système HSC distant doivent définir un segment OMVS dans RACF pour l'ID utilisateur associé au SMC. Sans cela, un échec d'initialisation de processus UNIX z/OS se produit. Pour définir le segment OMVS, reportez-vous à la publication IBM z/OS IBM Communications Server IP Migration Guide. Si vous utilisez un produit de sécurité présentant des fonctionnalités équivalentes (par exemple, ACF2), reportez-vous à la documentation de ce produit.
Si vous le souhaitez, vous pouvez sécuriser (chiffrer) les communications complètes en utilisant AT-TLS (Application Transparent Transport Layer Security), une application distribuée dans le cadre du système d'exploitation z/OS d'IBM.
AT-TLS assure un chiffrement et un déchiffrement des données en fonction d'instructions de stratégies spécifiées dans l'agent de stratégie. Pour plus d'informations sur la mise en œuvre du protocole AT-TLS, reportez-vous à la publication z/OS Communications Server: IP Configuration Guide et consultez les informations sur l'agent de stratégie disponibles dans la publication z/OS Communications Server: IP Configuration Reference.
Pour un TapePlex HSC ne résidant pas sur le même hôte que le SMC, vous devez lancer la commande SERVer
SMC. Cette commande définit un chemin nommé vers le système de contrôle de bibliothèque, ou serveur, HSC sur un hôte MVS différent.
Le premier serveur que vous définissez est considéré comme le serveur principal. Les serveurs supplémentaires sont des serveurs secondaires. Si une erreur de communication se produit sur le serveur principal pendant le traitement des allocations ou des montages, le SMC bascule automatiquement la communication vers le premier serveur secondaire disponible. Si une erreur de communication se produit sur ce serveur secondaire, le SMC passe automatiquement au serveur secondaire disponible suivant.
Pour plus d'informations sur la commande SERVer
SMC, reportez-vous au document Référence des commandes, des instructions de contrôle et des utilitaires ELS.
Le SMC fournit des fonctions de surveillance qui assurent le fonctionnement correct du sous-système SMC et de toutes les communications client/serveur. Pour plus d'informations, reportez-vous à la section Chapitre 7, Fonctions de surveillance et procédures de récupération.
Le composant de serveur HTTP SMC permet la communication entre le SMC (client) et un HSC résidant sur un autre hôte (serveur). Il s'exécute dans l'espace d'adressage SMC sur l'hôte où HSC s'exécute en tant que serveur. Il n'est pas nécessaire sur un hôte où seul le SMC s'exécute.
Le composant de serveur HTTP SMC ne démarre pas automatiquement pendant l'initialisation du SMC.
Pour démarrer le serveur SMC HTTP, vous devez inclure la commande HTTP
STArt
dans le jeu de données SMCPARMS
ou SMCCMDS
.
Une fois le serveur HTTP SMC actif, vous pouvez lancer la commande HTTP
via la console pour arrêter ou redémarrer à tout moment le serveur HTTP.
Remarque :
Pour plus d'informations sur la commande SMCHTTP
, reportez-vous au document Référence des commandes, des instructions de contrôle et des utilitaires ELS.Lancez la commande HTTP
SMC avec le paramètre LIst
pour afficher les informations de statut et les statistiques d'intervalle du serveur HTTP SMC.
Incluez le paramètre DETail
pour afficher des informations supplémentaires, dont les nombres d'E/S, d'erreurs, d'acceptations et de rejets et le nombre d'utilisations de la CGI.
Remarque :
Reportez-vous à la publication Messages et codes ELS pour obtenir la liste des messages du serveur HTTP SMC.Lorsqu'un client SMC envoie des demandes UUI au serveur HTTP SMC, certaines de ces demandes ou toutes s'exécutent dans l'espace d'adressage SMC où s'exécute le serveur HTTP. Si vous tentez d'exécuter plusieurs demandes simultanément, des abandons de rupture de stockage SMC peuvent se produire.
Les fonctions UUI susceptibles de consommer une grosse quantité de stockage virtuel incluent VTCS EXPORT
et les rapports qui font appel à la fonction SORT
, y compris VOLRPT
, VTVRPT
et MVCRPT
.
Il est recommandé d'allouer la taille de région maximale (0M) au SMC exécutant le serveur HTTP.
SMC 7.3 introduit une nouvelle fonction de sécurité XAPI pour les communications client/serveur qui est activée par défaut sur le serveur HTTP SMC.
Le meilleur moyen de sécuriser des transactions XAPI de TapePlex qui hébergent uniquement des applications clients ELS (SMC et VM Client) est d'utiliser les fonctions AT/TLS tel que décrit dans le document StorageTek Enterprise Library Software - Guide se sécurité. AT/TLS est une fonction de couche de transport externe et transparente pour ELS.
La fonction de sécurité XAPI d'ELS 7.3 permet de sécuriser les TapePlex qui hébergent des clients non ELS (clients de systèmes ouverts) ou une combinaison de clients ELS (SMC et VM Client) et de clients non ELS. AT-TLS peut être utilisé dans ces environnements conjointement avec la fonction de sécurité XAPI d'ELS 7.3. Cependant, cela ne sécurisera pas les transactions XAPI des clients non ELS.
ELS 7.3 inclut des fonctions d'identification de l'utilisateur supplémentaires dans le cadre de son protocole XAPI interne et entièrement intégré dans ELS. ELS 7.3 implémente un protocole question-réponse pour identifier chaque transaction client/serveur XAPI. Ce protocole requiert l'utilisation de la nouvelle commande SMC XUDB
pour définir les codes d'utilisateur et les mots de passe des clients et des serveurs. Pour plus d'informations sur cette commande, reportez-vous à la Référence des commandes, des instructions de contrôle et des utilitaires ELS. Le protocole question-réponse de connexion opérationnelle est entièrement transparent et ne requiert aucune intervention supplémentaire d'un utilisateur ou opérateur. La connexion XAPI est obligatoire pour chaque opération de TapePlex (montage, démontage, consultation, définition comme volume de travail, etc.). Les codes d'utilisateur et les mots de passe ne sont jamais enregistrés ou mis en cache par le serveur au nom du client.
ELS 7.3 requiert la sécurité XAPI par défaut. Cependant, ELS offre des fonctions qui vous permettent de contrôler la sécurité de chaque client.
Vous pouvez utiliser la commande XCLIENT
SMC pour permettre à un serveur ELS 7.3 d'exempter certains clients d'utiliser le protocole de sécurité XAPI. Les clients ELS d'un niveau antérieur (par exemple, un client 7.2 qui communique avec un serveur 7.3) requièrent une définition de commande ELS 7.3 XCLIENT
pour pouvoir demander des services au serveur ELS 7.3 sans connexion XAPI.
Vous pouvez utiliser la commande HTTP
avec le paramètre XSECurity (OFF)
pour désactiver de façon globale le protocole de sécurité XAPI. Lorsque le paramètre HTTP XSECurity(OFF)
est défini, le protocole XAPI d'ELS 7.3 fonctionne de la même façon que le protocole XAPI d'ELS 7.2 (sans identification utilisateur).
Pour plus d'informations sur ces commandes, reportez-vous au document Référence des commandes, des instructions de contrôle et des utilitaires ELS.
Le protocole de sécurité XAPI requiert que la version d'IBM z/OS Cryptographic Services ICSF soit HCR7740 ou supérieure. ICSF doit être démarré sur les systèmes serveur et client. Reportez-vous au manuel IBM z/OS Cryptographic Services ICSF System Programmer's Guide (SA22-7520) pour plus d'informations sur l'initialisation d'ICSF. Lorsque ICSF est requis pour la sécurité XAPI, vous n'avez pas besoin d'un coprocesseur de chiffrement.
AVERTISSEMENT :
Si IBM z/OS Cryptographic Services ICSF n'est pas installé, la fonction de sécurité XAPI de SMC doit être désactivée. SMC ne désactive pas la fonction de sécurité XAPI comme option par défaut même lorsqu'il reconnaît que ICSF n'est pas installé. Reportez-vous au document Référence des commandes, des instructions de contrôle et des utilitaires ELS pour plus d'informations sur l'utilisation de la commande SMC HTTP
pour désactiver la fonction de sécurité XAPI.
L'interface XML API (XAPI) est l'API StorageTek d'Oracle qui permet aux clients et aux serveurs StorageTek de communiquer à l'aide d'un protocole commun sur TCP/IP.
Avec l'introduction de cette interface XAPI, les clients qui devaient préalablement utiliser un serveur basé sur MVS (StorageTek Host Software Component d'Oracle) pour le traitement des bandes réelles peuvent désormais utiliser ACSLS 8.4 ou version ultérieure (avec support XAPI activé) comme suit :
Un client SMC sur MVS peut maintenant faire des demandes de bandes réelles à partir d'un serveur ACSLS avec support XAPI activé (sans avoir recours à MVS/CSC).
Un système VM Client peut maintenant demander des services de bandes réelles à partir d'un serveur ACSLS avec support XAPI activé.
Si vous utilisez un SMC ou VM Client pour vous connecter à un serveur ACSLS avec support XAPI activé, vous devez utiliser les commandes SMC ou VM Client TAPEPlex
et SERVer
pour définir l'application ACSLS en tant que TapePlex et le chemin de contrôle TCP/IP entre le client et le serveur. Pour plus d'informations sur ces commandes, reportez-vous au document Référence des commandes, des instructions de contrôle et des utilitaires ELS.
La majorité des interactions client-serveur entre clients SMC et VM et un serveur ACSLS avec XAPI sont transparentes pour l'utilisateur final. Les demandes concernant les informations, montages et démontages de volume sont générées automatiquement par les systèmes SMC et VM Client et sont traitées sans intervention de l'opérateur. Outre ces interactions automatiques, le serveur ACSLS avec XAPI fournit des commandes d'administrateur, de configuration et d'opérateur supplémentaires qui vous permettent de gérer le composant XAPI. Reportez-vous à la publication ELS XAPI Client Interface to ACSLS Server Reference pour plus d'informations sur ces commandes.
Cette section décrit les scénarios de configuration SMC suivants :
Scenario 1 : un seul TapePlex avec le SMC et HSC sur le même hôte
Scénario 2 : un seul TapePlex utilisant la fonction SMC client/serveur
Cette liste de scénarios ne contient pas tous les scénarios client/serveur. Le SMC ne limite pas le nombre de TapePlex, ou de chemins de communications, qu'il est possible de définir.
Ces scénarios incluent en plus la communication SMC vers MVS/CSC, qui est requise lorsque le serveur est ACSLS.
Remarque :
MVS/CSC 7.1 et versions ultérieures ne sont pas compatibles avec LibraryStation. Dans un environnement MVS exclusif, vous devez utiliser la fonction SMC client/serveur pour assurer la communication entre les hôtes MVS. Pour plus d'informations, reportez-vous à la section Utilisation de la fonction client/serveur SMC.Dans une configuration comportant plusieurs TapePlex StorageTek (comme illustré dans le scénario 3), le SMC dirige l'allocation de chaque instruction DD vers le TapePlex approprié en fonction d'instructions TAPEREQ
et de commandes POLicy
, des emplacements de volumes spécifiques et des volumes de travail disponibles.
Dans ce scénario, le SMC et HSC s'exécutent sur le même hôte MVS connecté à un TapePlex unique (représenté par un CDS unique).
La figure suivante illustre ce scénario :
Cette configuration utilise trois espaces d'adressage :
L'espace d'adressage initiateur, dont les événements d'allocation et de montage proviennent
L'espace d'adressage SMC, qui intercepte ces événements
L'espace d'adressage HSC, auquel le SMC envoie des demandes de données de lecteurs et de volumes et des demandes de montage
La commande TAPEPlex
suivante définit le TapePlex HSC local :
TAPEPLEX NAME(PLEX1) LOCSUBSYS(HSC0)
PLEX1
est le nom du TapePlex local et HSC0
le nom du sous-système MVS local du HSC.
Dans ce scénario, le SMC s'exécute sur un hôte client sans HSC, avec plusieurs chemins vers un TapePlex distant (représenté par un seul CDS) et HSC s'exécutant sur plusieurs hôtes.
La figure suivante illustre ce scénario :
Les commandes TAPEPlex
et SERVer
suivantes sont requises pour le SMC sur MVSA :
TAPEPLEX NAME(PLEX1) SERVER NAME(MVSBPATH) TAPEPLEX(PLEX1) HOST(MVSB) SERVER NAME(MVSCPATH) TAPEPLEX(PLEX1) HOST(MVSC)
Les demandes provenant d'un espace d'adressage initiateur sur MVSA sont interceptées par l'espace d'adressage SMC sur MVSA. Le SMC sur MVSA envoie des demandes de données de volumes et de lecteurs et des demandes de montage au serveur sur MVSB ou MVSC.
Sur MVSB et MVSC, le SMC ne peut opérer qu'avec le HSC local ou peut utiliser l'utilitaire de communications pour fournir une sauvegarde, comme illustré :
Les commandes TAPEPlex
et SERVer
suivantes sont requises pour le SMC sur MVSB :
TAPEPLEX NAME(PLEX1) LOCSUBSYS(HSC1) SERVER NAME(MVSCPATH) TAPEPLEX(PLEX1) HOST(MVSC)
Le composant HTTP est défini pour le SMC sur MVSB :
HTTP START
Les commandes TAPEPlex
et SERVer
suivantes sont requises pour le SMC sur MVSC :
TAPEPLEX NAME(PLEX1) LOCSUBSYS(HSC2) SERVER NAME(MVSBPATH) TAPEPLEX(PLEX1) HOST(MVSB)
Le composant HTTP est défini pour le SMC sur MVSC :
HTTP START
Les commandes TAPEPlex
et SERVer
ci-dessus permettent à MVSB d'opérer en tant que serveur de bibliothèque de sauvegarde de MVSC et à MVSC d'opérer en tant que serveur de bibliothèque de sauvegarde de MVSB.
Remarque :
Pour obtenir des informations sur la manière dont le SMC obtient de HSC et MVS/CSC des informations de types de lecteurs, reportez-vous à la section Synchronisation des informations de types de lecteurs SMC.Dans ce scénario, un seul SMC communique avec deux TapePlex (représentés par deux CDS).
La figure suivante illustre ce scénario :
Dans ce scénario, supposons qu'il existe deux TapePlex (représentés par deux CDS).
Le SMC communique directement avec HSC sur le même hôte.
Le SMC utilise le serveur HTTP pour communiquer avec HSC sur différents hôtes (MVSB et MVSC).
Les demandes d'allocation et de montage provenant d'un espace d'adressage initiateur sur MVSA sont interceptées par le SMC sur MVSA. Ces demandes sont alors envoyées au HSCL local s'exécutant sur le même hôte, à HSC1 s'exécutant sur l'hôte MVSB ou à HSC2 s'exécutant sur l'hôte MVSB.
Les commandes TAPEPlex
et SERVer
suivantes sont requises pour le SMC sur MVSA :
TAPEPLEX NAME(PLEX1) LOCSUBSYS(HSC0) TAPEPLEX NAME (PLEX2) SERVER NAME(MVSBPATH) TAPEPLEX(PLEX2) HOST(MVSB) SERVER NAME(MVSCPATH) TAPEPLEX(PLEX2) HOST(MVSC)
Remarque :
Pour obtenir des informations sur la manière dont le SMC effectue un choix parmi plusieurs TapePlex afin de déterminer un "propriétaire" pour chaque demande d'allocation (chaque instruction DD au cours d'une étape de travail peut avoir un propriétaire TapePlex différent), reportez-vous à la section Sélection de TapePlex SMC.Les commandes TAPEPlex
et SERVer
suivantes sont requises pour le SMC sur MVSB :
TAPEPLEX NAME(PLEX2) LOCSUBSYS(HSC1) SERVER NAME(MVSCPATH) TAPEPLEX(PLEX2) HOST(MVSC)
Le composant HTTP est défini pour le SMC sur MVSB :
HTTP START
Les commandes TAPEPlex
et SERVer
suivantes sont requises pour le SMC sur MVSC :
TAPEPLEX NAME(PLEX2) LOCSUBSYS(HSC2) SERVER NAME(MVSBPATH) TAPEPLEX(PLEX2) HOST(MVSB)
Le composant HTTP est défini pour le SMC sur MVSC :
HTTP START
Remarque :
Il n'existe aucune limite prédéfinie au nombre de TapePlex ou de chemins de serveurs pouvant être configurés sur un seul SMC.Le SMC et HSC fournissent des utilitaires qui vous permettent de gérer un environnement dans lequel les adresses de lecteurs sont différentes entre les hôtes client et serveur. Utilisez les scénarios suivants pour vous aider à déterminer si le mappage d'adresse de lecteur client/serveur est requis et quels utilitaires et actions sont nécessaires.
Le traitement client/serveur n'est pas utilisé.
Chaque hôte MVS exécute une copie de HSC.
Action obligatoire : aucune
Le traitement client/serveur est utilisé.
Les adresses de périphériques sont identifiées de la même manière pour tous les hôtes participant à un seul réseau client/serveur.
Action obligatoire : aucune
Le traitement client/serveur est utilisé.
Les adresses de périphériques sont identifiées de la même manière pour tous les hôtes participant à un seul réseau client/serveur, mais tous les périphériques ne sont pas définis sur tous les hôtes.
Action obligatoire : Le mappage d'adresse de lecteur n'est pas requis. Toutefois, vous devez utiliser l'utilitaire HSC SET SLIDRIVS pour définir toutes les adresses de lecteurs sur les hôtes allant être utilisés comme serveurs, même si les périphériques ne sont pas définis sur l'hôte. Pour plus d'informations sur l'utilitaire SET SLIDRIVS
, reportez-vous au document Référence des commandes, des instructions de contrôle et des utilitaires ELS.
Le traitement client/serveur est utilisé.
Les adresses de périphériques sont définies de la même manière sur tous les hôtes HSC mais un ou plusieurs hôtes client uniquement SMC utilisent un jeu d'adresses différent pour le même périphérique.
Action obligatoire : Utilisez la commande SMC DRIVemap
pour mapper les adresses d'hôte client SMC sur les adresses d'hôte HSC. Le SMC effectue les traductions d'adresses nécessaires pour influencer les allocations et demander des montages au serveur. Pour plus d'informations sur la commande DRIVemap
, reportez-vous au document Référence des commandes, des instructions de contrôle et des utilitaires ELS.
Le traitement client/serveur est utilisé.
Deux hôtes MVS (MVS1 et MVS2) exécutant chacun HSC et le SMC.
Un hôte MVS (MVS3) exécutant le SMC uniquement mais défini comme communiquant à l'un des deux hôtes en tant que serveur.
Les adresses de périphériques sont définies différemment parmi les trois hôtes. Par exemple :
MVS1 (AA0-AAF)
MVS2 (BA0-BAF)
MVS3 (CA0-CAF)
Action obligatoire :
Puisque le SMC sur MVS3 peut communiquer avec l'hôte MVS1 ou MVS2 pour un événement de montage spécifique, vous devez utiliser l'utilitaire HSC SET
, SET DRVHOST
, pour désigner l'un de ces hôtes en tant que ''maître hôte de lecteur''. Par exemple, MVS1 (AA0-AAF)
.
Une fois le maître hôte de lecteur spécifié dans le CDS HSC, les adresses associées à ce maître hôte (AA0-AAF) sont utilisées par MVS1 et MVS2 lors de la communication avec le SMC.
Si vous le souhaitez, vous pouvez ajouter un ID d'hôte factice devant être le HSC DRVHOST
et utiliser des adresses de lecteurs non existantes à mapper sur les adresses client. Par exemple, utilisez l'utilitaire HSC SET NEWHOST
pour définir le nom d'hôte DRVDUMMY
et définir la plage de périphérique en tant que 000-00F
.
Pour plus d'informations sur les utilitaires HSC SET DRVHOST
et SET NEWHOST
, reportez-vous au document Référence des commandes, des instructions de contrôle et des utilitaires ELS.
Utilisez la commande DRIVemap
SMC sur les clients MVS2 et MVS3 pour mapper les adresses de lecteurs BA0-BAF
et CA0-CAF
aux adresses de serveurs AA0-AAF
. Pour plus d'informations sur la commande DRIVemap
, reportez-vous à la Référence des commandes, des instructions de contrôle et des utilitaires ELS.
Le SMC obtient des informations de types de lecteurs des systèmes de contrôle de bibliothèque ELS, HSC et MVS/CSC, à l'aide de recherches de configuration lancées depuis le SMC vers chaque TapePlex défini.
Pour les sous-systèmes HSC, les changements de la configuration de lecteur sont automatiquement reconnus par le SMC pour les systèmes locaux et distants.
Pour les sous-systèmes MVS/CSC, une commande SMC RESYNChronize
doit être lancée chaque fois que la commande MVS/CSC équivalent est lancée. Pour plus d'informations sur la commande RESYNChronize
, reportez-vous au document Référence des commandes, des instructions de contrôle et des utilitaires ELS.
La commande UNITAttr
SMC vous permet d'augmenter ou de remplacer les informations retournées par les recherches de configuration du système de contrôle de bibliothèque ELS selon les besoins de la configuration de périphérique de bande d'hôte local. La commande UNITAttr
vous permet en particulier d'effectuer les opérations suivantes :
Définir MODEL=IGNORE
pour les adresses de périphériques non disponibles pour cet hôte.
Spécifier les types de modèles pour les périphériques non bibliothèque sur cet hôte.
Spécifier NOTAPEPLEX
pour une adresse de périphérique non bibliothèque ou une plage de périphériques non bibliothèque sur cet hôte qui sont des périphériques détenus par TapePlex sur d'autres hôtes.
Spécifier la propriété TapePlex pour une adresse de périphérique ou une plage de périphériques définie sur plusieurs TapePlex, mais pour cet hôte, les périphériques rattachés appartiennent au TapePlex spécifié.
Spécifier la propriété et le modèle TapePlex pour les périphériques pouvant être référencés par un montage une fois que le SMC est démarré mais avant l'initialisation de TapePlex.
Remarque :
Les commandesUNITAttr
ne sont pas requises et ne doivent être lancées que dans les conditions décrites dans cette section.Pour définir les périphériques représentés par un UCB mais non accessibles via cet hôte, lancez une commande UNITAttr
SMC pour chaque périphérique inaccessible comme suit :
UNITATTR ADDR(ccuu) MODEL(IGNORE)
Le traitement de UNITAttr MOdel(IGNORE)
reste inchangé par rapport aux versions précédentes. Par conséquent, le SMC n'inclut le périphérique dans aucune de ses opérations de traitement.
Pour définir des types de périphériques non bibliothèque sur cet hôte, lancez une commande UNITAttr
SMC pour chaque périphérique non bibliothèque comme suit :
UNITATTR ADDR(ccuu) MODEL(model)
Un périphérique non bibliothèque est un périphérique StorageTek nécessitant la définition d'autres informations de modèles pour être différentié des autres périphériques non bibliothèque présentant des caractéristiques UCB similaires.
Si une adresse de périphérique de votre hôte chevauche une adresse de périphérique d'un périphérique détenu par TapePlex et que le périphérique détenu par TapePlex est inaccessible depuis cet hôte, lancez une commande UNITAttr
SMC en spécifiant le paramètre NOTAPEPlex
comme suit :
UNITATTR ADDR(ccuu) MODEL(model) NOTAPEPLEX
Par conséquent, si un TapePlex tel qu'HSC revendique la propriété via les données retournées d'une recherche de configuration, NOTAPEPlex
remplace le TapePlex. Les informations de configuration sont ignorées et le périphérique demeure un périphérique non bibliothèque.
Si vous ne spécifiez pas NOTAPEPlex
, les informations de configuration TapePlex remplacent la commande UNITAttr
spécifiée sans le paramètre NOTAPEPlex
et la définition de périphérique passe d'un périphérique non bibliothèque à un périphérique détenu par TapePlex.
Si votre configuration inclut plusieurs TapePlex avec des adresses ou des plages de périphériques se chevauchant et que les deux TapePlex sont définis sur le SMC, entrez une commande UNITAttr
avec le paramètre TAPEPlex
pour établir quel TapePlex détient le périphérique ou la plage spécifiée sur cet hôte. Entrez une commande UNITAttr
pour chacune des adresses de lecteurs dupliquées comme suit :
UNITATTR ADDR(ccuu) MODEL(model) TAPEPLEX(name)
Prenons l'hypothèse suivante :
L'hôte MVSA inclut deux TapePlex, HSC1 et HSC2.
HSC1 inclut une plage de périphériques 9840, 2900-2903.
HSC2 inclut une plage de périphériques 4480, 2900-2903.
Toutefois, sur MVSA, les périphériques 2900-2903 sont rattachés à HSC1. MVSA n'a aucune connexion à la plage de périphériques HSC2.
Dans ce scénario, lancez une commande UNITATTR
SMC comme suit :
UNITATTR ADDR(2900-2903) MODEL(9840) TAPEPLEX(HSC1)
Cette commande indique au SMC d'ignorer les informations de configuration pour les périphériques spécifiés d'un TapePlex autre que le TapePlex spécifié.
Remarque :
Si MVSA reconnaissait la plage d'adresses 2900-2903 définie sur HSC2 comme plage d'adresses différente (par exemple, 4900-4903), MVSA utiliserait les utilitairesSET DRVHOST
afin de définir la plage d'adresses 2900-2903 sur HSC2 comme plage d'adresses 4900-4903 pour les recherches de configuration client. Pour plus d'informations, reportez-vous à la section Mappage d'adresse de lecteur client/serveur.Pour définir des périphériques détenus par TapePlex lorsque des travaux de bandes sont exécutés après le démarrage du SMC mais avant l'initialisation du TapePlex, entrez une commande UNITAttr
SMC pour tous les périphériques détenus par TapePlex comme suit :
UNITATTR ADDR(2900-2903) MODEL(9840) TAPEPLEX(HSC1) ... UNITATTR ADDR(9000-903F) MODEL(VIRTUAL) TAPEPLEX(HSC1)
Ceci indique au SMC de conserver la trace des stratégies de bandes pour les montages en suspens, y compris VTCS MGMTCLAS
.
Lorsque le SMC intercepte une demande d'allocation spécifique ou provisoire, il sélectionne un TapePlex propriétaire pour traiter la demande. Les critères suivants sont évalués par le SMC dans l'ordre indiqué afin de déterminer quel TapePlex contrôle la demande d'allocation :
Les TapePlex sont interrogés dans l'ordre dans lequel ils sont définis. Si les commandes TAPEPlex
sont définies sur le SMC, l'ordre des commandes TAPEPlex
est utilisé. Si les commandes TAPEPlex
ne sont pas définies sur le SMC, l'ordre indiqué dans le tableau MVS SSCVT
est utilisé.
Si l'EDL (Eligible Device List, liste des périphériques éligibles) de la demande ne contient pas de lecteurs détenus par un TapePlex spécifique, ce TapePlex ne peut pas posséder la demande.
Si une commande POLicy
SMC applicable demande un TapePlex spécifique, elle est sélectionnée en tant que propriétaire de la demande.
Si le groupe ésotérique POLicy
SMC ne contient que des lecteurs dans un seul TapePlex, il est sélectionné en tant que propriétaire de la demande.
Si le numéro de série de volume spécifique demandé est spécifié dans une instruction TAPEREQ
, la commande POLicy
associée au TAPEREQ
détermine le propriétaire.
Si un volume demandé spécifique est trouvé dans un TapePlex, ce TapePlex est considéré comme propriétaire sauf s'il est demandé par une sélection de groupe ésotérique ou de TapePlex spécifique. Si le volume n'est pas trouvé dans un TapePlex mais que ce TapePlex contient une définition VOLPARM
pour ce volume, le TapePlex est considéré comme propriétaire si le volume spécifique n'est trouvé dans aucun autre TapePlex.
Si un TapePlex indique qu'il possède des volumes de travail pour la demande, il est considéré comme propriétaire sauf s'il est remplacé par une sélection de groupe ésotérique ou de TapePlex spécifique. Si le TapePlex ne possède pas de volumes de travail pour la demande mais que le nom de sous-pool spécifié est connu du TapePlex, ce dernier est considéré comme propriétaire si les volumes de travail ne sont trouvés dans aucun autre TapePlex.
Pour sélectionner un propriétaire de TapePlex dans plusieurs bibliothèques, spécifiez un nom de TapePlex à l'aide du paramètre TAPEPlex
sur la commande POLicy
SMC. Pour plus d'informations sur cette commande, reportez-vous au document Référence des commandes, des instructions de contrôle et des utilitaires ELS.