Remarque : Avant d'utiliser le présent document, prenez connaissance des informations générales figurant à la section Remarques.
|
Réf. US : SC14-7290-08
LE PRESENT DOCUMENT EST LIVRE EN L'ETAT SANS AUCUNE GARANTIE EXPLICITE OU IMPLICITE. IBM DECLINE NOTAMMENT TOUTE RESPONSABILITE RELATIVE A CES INFORMATIONS EN CAS DE CONTREFACON AINSI QU'EN CAS DE DEFAUT D'APTITUDE A L'EXECUTION D'UN TRAVAIL DONNE.
Ce document est mis à jour périodiquement. Chaque nouvelle édition inclut les mises à jour. Les informations qui y sont fournies sont susceptibles d'être modifiées avant que les produits décrits ne deviennent eux-mêmes disponibles. En outre, il peut contenir des informations ou des références concernant certains produits, logiciels ou services non annoncés dans ce pays. Cela ne signifie cependant pas qu'ils y seront annoncés.
Pour plus de détails, pour toute demande d'ordre technique, ou pour obtenir des exemplaires de documents IBM, référez-vous aux documents d'annonce disponibles dans votre pays, ou adressez-vous à votre partenaire commercial.
Vous pouvez également consulter les serveurs Internet suivants :
Compagnie IBM France
Direction Qualité
17, avenue de l'Europe
92275 Bois-Colombes Cedex
Cette édition concerne IBM® Rational Developer for System z Version 9.1.1 (numéro de logiciel 5724-T07) et toutes les éditions et modifications ultérieures, sauf mention contraire dans les nouvelles éditions.
Commandez les publications par téléphone ou télécopie. IBM Software Manufacturing Solutions reçoit les commandes de publication de 8h30 à 19h00, heure de la côte est. Le numéro de téléphone est (800) 879-2755. Le numéro de fax est (800) 445-9269. Les télécopies doivent être adressées à Publications, 3rd floor.
Vous pouvez également commander des publications auprès de votre interlocuteur IBM ou de l'agence IBM agence de votre localité. Les publications ne sont pas stockées à l'adresse ci-dessous.
IBM souhaite recueillir vos commentaires. Vous pouvez envoyer vos commentaires par mail à l'adresse suivante :
IBM Corporation
Attn: Information Development Department 53NA
Building 501 P.O. Box 12195
Research Triangle Park NC 27709-2195
USA
Vous pouvez télécopier vos commentaires à : 1-800-227-5088 (US et Canada)
Lorsque vous envoyez des informations à IBM, vous accordez à IBM un droit non exclusif d'utiliser ou de distribuer ces informations de toute manière qu'elle juge appropriée et sans aucune obligation envers vous.
© Copyright IBM Corporation 2000, 2014
Note to U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Le présent document a été traduit en France. Voici les principales différences et particularités dont vous devez tenir compte.
Les illustrations sont fournies à titre d'exemple. Certaines peuvent contenir des données propres à la France.
La terminologie des titres IBM peut différer d'un pays à l'autre. Reportez-vous au tableau ci-dessous, au besoin.
IBM France | IBM Canada |
---|---|
ingénieur commercial | représentant |
agence commerciale | succursale |
ingénieur technico-commercial | informaticien |
inspecteur | technicien du matériel |
Les lettres sont disposées différemment : le clavier français est de type AZERTY, et le clavier français-canadien de type QWERTY.
Au Canada, on utilise :
Les touches présentées dans le tableau d'équivalence suivant sont libellées différemment selon qu'il s'agit du clavier de la France, du clavier du Canada ou du clavier des États-Unis. Reportez-vous à ce tableau pour faire correspondre les touches françaises figurant dans le présent document aux touches de votre clavier.
Il est possible qu'IBM détienne des brevets ou qu'elle ait déposé des demandes de brevets portant sur certains sujets abordés dans ce document. Le fait qu'IBM vous fournisse le présent document ne signifie pas qu'elle vous accorde un permis d'utilisation de ces brevets. Vous pouvez envoyer, par écrit, vos demandes de renseignements relatives aux permis d'utilisation au directeur général des relations commerciales d'IBM, 3600 Steeles Avenue East, Markham, Ontario, L3R 9Z7.
Si vous avez besoin d'assistance ou si vous voulez commander du matériel, des logiciels et des publications IBM, contactez IBM direct au 1 800 465-1234.
Ce document fournit des informations de base sur les différentes tâches de configuration de IBM Rational Developer for System z, ainsi que d'autres composants et produits z/OS (tels que WLM et CICS).
Les informations contenues dans ce document s'appliquent à tous les modules IBM Rational Developer for System z version
9.1.1.
Vous trouverez les versions les plus récentes de ce document dans le Guide de référence de configuration de l'hôte IBM Rational Developer for System z (SC11-6869) à l'adresse http://www-05.ibm.com/e-business/linkweb/publications/servlet/pbi.wss?CTY=US&FNC=SRX&PBL=SC14-7290.
Les versions les plus récentes de la documentation complète, y compris les instructions d'installation, les livres blancs, les podcasts et les tutoriels, sont disponibles sur la page de la bibliothèque du site Web d'IBM Rational Developer for System z (http://www-01.ibm.com/software/sw-library/en_US/products/Z964267S85716U24/).
Ce document s'adresse aux programmeurs système chargés de configurer et d'optimiser
IBM Rational Developer for System z version 9.1.1.
Bien que les étapes de configuration soient décrites dans une autre publication, ce document décrit en détail les sujets associés, tels que l'optimisation, la configuration de la sécurité etc. Avant d'utiliser le présent manuel, vous devez maîtriser les systèmes hôtes z/OS UNIX System Services et MVS.
Cette section récapitule les modifications apportées au manuel IBM Rational Developer for System z version
9.1.1 - Guide de référence de
configuration de l'hôte, SC14-7290-08 (mis à jour en décembre 2014).
Les changements et ajouts techniques au texte et illustrations sont indiqués par un trait vertical situé à gauche du changement.
Ce document reprend des informations présentées précédemment dans le manuel IBM Rational Developer for System z version 9.1.1 - Guide de référence de configuration de l'hôte, SC14-7290-07.
Ce document reprend des informations présentées précédemment dans le document IBM Rational Developer for System z Version 9.0.1 - Guide de référence de configuration de l'hôte, SC14-7290-06.
Ce document reprend des informations présentées précédemment dans le document IBM Rational Developer for System z Version 9.0.1 - Guide de référence de configuration de l'hôte, SC11-6869-06.
Nouvelles informations :
Ce document reprend des informations présentées précédemment dans le document IBM Rational Developer for System z Version 8.5.1 - Guide de référence de configuration de l'hôte, SC11-6869-04.
Ce document reprend des informations présentées précédemment dans le document IBM Rational Developer for System z Version 8.5 - Guide de référence de configuration de l'hôte, SC11-6869-02.
Ce document reprend des informations présentées précédemment dans le document IBM Rational Developer for System z Version 8.0.3 - Guide de référence de configuration de l'hôte, SC11-6869-02.
Ce document reprend des informations présentées précédemment dans le document IBM Rational Developer for System z Version 8.0.1 - Guide de référence de configuration de l'hôte, SC11-6869-01.
Cette section récapitule les informations présentées dans ce document.
Le système hôte Developer for System z est composé de plusieurs composants qui interagissent pour permettre au client d'accéder aux services et données de l'hôte. En comprenant bien la conception de ces composants, vous pouvez prendre les bonnes décisions de configuration.
Developer for System z offre aux utilisateurs un accès grand système sur un poste de travail qui ne correspond pas à un grand système. La validation des demandes de connexion, l'établissement de communications sécurisées entre l'hôte et le poste de travail, l'autorisation et l'activité d'audit sont donc des aspects fondamentaux de la configuration d'un produit.
Developer for System z repose sur le protocole TCP/IP pour offrir l'accès au mainframe à des utilisateurs travaillant sur un poste de travail autre qu'un mainframe. TCP/IP sert également à assurer la communication entre les différents composants et les autres produits.
Contrairement aux applications z/OS traditionnelles, Developer for System z n'est pas une application monolithique qui peut être identifiée facilement au niveau du Workload Manager (WLM). Les différents composants de Developer for System z interagissent pour offrir au client un accès à des services et des données d'hôte. Certains de ces services sont actifs dans différents espaces adresse, ce qui se traduit par différentes classifications WLM.
RSE (Remote Systems Explorer) est le coeur de Developer for System z. Pour gérer les connexions et charges de travail provenant des clients, RSE est composé d'un espace adresse de démon, qui permet de contrôler les espaces adresse du groupe d'unités d'exécution. Le démon agit comme un point focal pour la connexion et la gestion, alors que les pools d'unités d'exécution traitent les charges de travail du client.
RSE devient une cible privilégiée d'optimisation de la configuration de Developer for System z. Toutefois, la gestion de centaines d'utilisateurs, chacun utilisant au moins 17 unités d'exécution, d'une certaine quantité de mémoire et éventuellement d'un ou de plusieurs espaces adresse implique de configurer correctement Developer for System z et z/OS.
z/OS est un système d'exploitation hautement personnalisable, et des modifications (parfois mineures) du système peuvent présenter un impact très important sur les performances globales. Le présent chapitre met en évidence certaines modifications qui peuvent être apportées afin d'améliorer les performances de Developer for System z.
Ce chapitre contient des informations utiles pour un administrateur CICS Transaction Server.
Ce chapitre vous guide lors du processus d'amélioration de Developer for System z en créant des routines d'exit.
Ce chapitre vous aide à simuler une procédure d'ouverture de session TSO en ajoutant des instructions de définition de données et des fichiers à l'environnement TSO dans Developer for System z.
Parfois, vous pouvez avoir besoin de plusieurs instances de Developer for System z actives sur un même système, lors du test d'une mise à niveau, par exemple. Cependant, certaines ressources (les ports TCP/IP, par exemple) ne peuvent pas être partagées. Les paramètres par défaut ne sont donc pas toujours applicables. Consultez les informations de ce chapitre afin de programmer la coexistence des différentes instances de Developer for System z, pour pouvoir ensuite les personnaliser à l'aide de ce guide de configuration.
Cette section vous aide à résoudre certains des incidents qui peuvent se produire lors de la configuration de SSL (Secure Socket Layer) ou pendant la vérification ou la modification d'une configuration existante. Elle contient également un exemple de configuration pour prendre en charge l'authentification des utilisateurs à l'aide d'un certificat X.509.
Cette section vous aide à résoudre certains des incidents qui peuvent se produire lors de la configuration de TCP/IP ou pendant la vérification ou la modification d'une configuration existante.
Les différents composants de l'hôte Developer for System z interagissent pour offrir au client un accès à des services et des données d'hôte. En comprenant bien la conception de ces composants, vous pouvez prendre les bonnes décisions de configuration.
La description du paragraphe et de la liste précédent illustre le rôle central attribué à RSE. A quelques exceptions prés, toute la communication du client passe par RSE. Cela permet de faciliter la configuration du réseau liée à la sécurité, étant donné que seul un ensemble limité de ports est utilisé pour la communication hôte-client.
Pour gérer les connexions et charges de travail provenant des clients, RSE est composé d'un espace adresse de démon, qui permet de contrôler les espaces adresse du groupe d'unités d'exécution. Le démon agit comme un point focal pour la connexion et la gestion, alors que les pools d'unités d'exécution traitent les charges de travail du client. Selon les valeurs définies dans le fichier de configuration rsed.envvars et la quantité de connexions client réelles, le démon peut démarrer plusieurs espaces adresse de pool d'unités d'exécution.
La Figure 2 présente une vue de base de l'utilisation des ressources (processus et stockage) par RSE.
RSE est une application Java™, ce qui signifie qu'il est actif dans l'environnement z/OS UNIX. Cela permet de faciliter l'accès à différentes plateformes hôte et de simplifier la communication avec le client Developer for System z, qui est également une application Java (reposant sur Eclipse). Par conséquent, il est très utile d'avoir des connaissances de base du fonctionnement de z/OS UNIX et Java pour comprendre Developer for System z.
Dans z/OS UNIX, un programme s'exécute dans un processus, qui est identifié par un PID (ID processus). Chaque programme est actif dans son propre processus. Par conséquent, l'appel d'un autre programme crée un processus. Le processus qui en a démarré un autre est référencé par un PPID (PID parent), le nouveau processus étant appelé processus enfant. Ce dernier peut s'exécuter dans le même espace adresse ou être généré (créé) dans un nouvel espace adresse. L'exécution d'un nouveau processus dans le même espace adresse est comparable à l'exécution d'une commande dans TSO, la génération d'un processus dans un nouvel espace adresse s'apparentant à la soumission d'un nouveau travail.
Notez qu'un processus peut être à unité d'exécution unique ou à unités d'exécution multiples. Dans une application à unités d'exécution multiples (RSE, par exemple), les différentes unités d'exécution rivalisent pour des ressources système comme si elles se trouvaient dans des espaces adresse séparés (avec moins de temps système).
RSE peut s'exécuter en mode d'adressage 31 ou 64 bits, ce qui provoque différentes limites de stockage. En mode 31 bits, le stockage disponible est limité à 2 Go, alors qu'en mode 64 bits il n'existe aucune limite, sauf spécification particulière dans SYS1.PARMLIB.
Les applications Java (RSE, par exemple) n'allouent pas de mémoire directement. Elles utilisent les services de gestion de mémoire Java. Ces services (l'allocation de mémoire, la libération de mémoire et la récupération de place, par exemple) fonctionnent dans les limites du segment de mémoire Java. Les tailles minimale et maximale du segment de mémoire sont définies (de manière implicite ou explicite) au démarrage de Java. En mode 64 bits, Java tente d'allouer un segment de mémoire au dessus de 2 Go, libérant ainsi l'espace en-deçà de ce seuil.
Ainsi, l'occupation de la plus grande partie de l'espace adresse disponible consiste à trouver le juste équilibre entre une taille de segment de mémoire importante et une place suffisante permettant à z/OS de stocker un nombre variable de blocs de contrôle du système (selon le nombre d'unités d'exécution actives).
La Figure 3 offre une présentation de base du propriétaire des données d'identification utilisées par différentes tâches de Developer for System z.
La propriété d'une tâche peut être divisée en deux sections. Les tâches démarrées appartiennent à l'ID utilisateur qui est attribué à la tâche démarrée dans le logiciel de sécurité. Toutes les autres tâches, avec les pools d'unités d'exécution RSE (RSEDx) comme exception, appartiennent à l'ID utilisateur du client.
La Figure 3 présente les tâches démarrées de Developer for System z (DBGMGR, JMON et RSED), ainsi que des exemples de tâches démarrées et des services système avec lesquels Developer for System z communique. Application Deployment Manager (ADM) est actif au sein d'une région CICS. La balise USS REXEC représente le service z/OS UNIX REXEC (ou SSH).
Le démon RSE (RSED) crée un ou plusieurs espaces adresse de pools d'unités d'exécution (RSEDx) dédiés aux demandes des clients. Chaque pool d'unités d'exécution RSE prend en charge plusieurs clients et appartient au même utilisateur que celui du démon RSE. Chaque client possède sa propre unité d'exécution au sein d'un pool d'unités d'exécution et ces unités d'exécution appartiennent à l'ID utilisateur client.
Selon les actions menées par le client, un ou plusieurs espaces adresse supplémentaires peuvent être démarrés, tous appartenant à l'ID utilisateur du client, pour exécuter l'action demandée. Ces espaces adresse peuvent être un travail par lots MVS, une transaction APPC ou un processus enfant z/OS UNIX. Notez qu'un processus enfant z/OS UNIX est actif dans un initiateur z/OS UNIX (BPXAS)et le processus enfant apparaît comme une tâche démarrée dans JES.
La création de ces espaces adresse est le plus souvent déclenchée par une unité d'exécution d'utilisateur dans un pool d'unités d'exécution, soit directement soit à l'aide d'un service système comme ISPF. L'espace adresse pourrait très bien être aussi créé par un tiers. Par exemple, REXEX ou SSH z/OS UNIX est impliqué lorsque un démarrage est généré dans z/OS UNIX.
Les espaces adresse spécifiques de l'utilisateur prennent fin à l'achèvement de la tâche ou à l'expiration d'un temps d'inactivité. Les tâches démarrées restent activent. Les espaces adresse répertoriés dans la Figure 3 restent dans le système suffisamment longtemps pour être visibles. Toutefois, sachez qu'en raison de la conception de z/OS UNIX, il existe aussi des espaces adresses temporaires de durée de vie courte.
La description précédente illustre la conception orientée unité d'exécution de RSE. Au lieu de démarrer un espace adresse par utilisateur, plusieurs utilisateurs sont gérés par un seul espace adresse du pool d'unités d'exécution. Dans le pool d'unités d'exécution, chaque logiciel de fouille de données (service propre à l'utilisateur) est actif dans sa propre unité d'exécution dans le contexte de sécurité de l’utilisateur qui lui est attribué, ce qui garantit la sécurité de la configuration. Cette conception permet de gérer un grand nombre d'utilisateurs avec une quantité de ressources limitée, ce qui n'implique pas que chaque client va utiliser plusieurs unités d'exécution (au moins 17, selon les tâches réalisées).
L'utilisation du mot de passe PassTickets pour tous les services z/OS impliquant une authentification permet à Developer for System z d'appeler ces services, sans stocker le mot de passe ni inviter continuellement l'utilisateur à l'indiquer. L'utilisation des mots de passe PassTickets pour tous les services z/OS permet également d'utiliser d'autres méthodes d'authentification (mots de passe à usage unique et certificats X.509, par exemple).
Developer for System z prend en charge plusieurs méthodes pour démarrer un serveur CARMA. Chaque méthode offre des avantages, mais présente également des inconvénients. Developer for System z fournit également plusieurs RAM (Repository Access Managers) qui peuvent être divisés en deux groupes : RAM de production et RAM exemples. Diverses combinaisons de RAM et de méthodes de démarrage de serveur sont disponibles dans une installation préconfigurée.
Toutes les méthodes de démarrage de serveur ont un fichier de configuration commun, CRASRV.properties, qui définit, entre autres, la méthode de démarrage utilisée.
La méthode "CRASTART" démarre le serveur CARMA sous la forme d'une sous-tâche dans RSE. Elle offre une configuration très flexible grâce à l'utilisation d'un fichier de configuration distinct qui définit les attributions de fichiers et les appels de programme nécessaires pour démarrer un serveur CARMA. Cette méthode offre les meilleures performances et utilise le moins de ressources mais requiert cependant que le module CRASTART se trouve dans LPA.
RSE appelle le module chargeable CRASTART qui utilise les définitions dans crastart*.conf pour créer un environnement valide pour exécuter des commandes TSO et ISPF par lots. Developer for System z utilise cet environnement pour exécuter le serveur CARMA, CRASERV. Developer for System z fournit plusieurs fichiers crastart*.conf, chaque fichier étant préconfiguré pour un gestionnaire donné.
Cette méthode démarre le serveur CARMA en envoyant un travail. Il s'agit de la méthode par défaut utilisée dans les fichiers de configuration fournis. L'avantage de cette méthode est que les journaux CARMA sont facilement accessibles dans la sortie de travaux. Elle permet également d'utiliser un JCL de serveur personnalisé pour chaque développeur qui sera géré par le développeur lui-même. Toutefois, cette méthode utilise un initiateur JES pour chaque développeur qui démarre un serveur CARMA.
RSE appelle CLIST CRASUB* qui envoie un document incorporé JCL pour créer un environnement valide pour exécuter des commandes TSO et ISPF par lots. Developer for System z utilise cet environnement pour exécuter le serveur CARMA, CRASERV. Developer for System z fournit plusieurs membres CRASUB*, chaque membre étant préconfiguré pour un gestionnaire donné.
Avec la configuration à un seul serveur de Developer for System z, où plusieurs utilisateurs sont attribués à un seul espace adresse de pool d'unités d'exécution, z/OS n'a plus la possibilité de savoir qui possède un verrou sur un fichier ou un membre avec la commande d'opérateur DISPLAY GRS,RES=(*,dataset*). Les commandes système s'arrêtent au niveau de l'espace adresse, qui correspond au pool d'unités d'exécution.
Pour régler ce problème, Developer for System z propose la commande d'opérateur MODIFY rsed APPL=DISPLAY OWNER,DATASET=dataset, comme indiqué dans "Commandes de l'opérateur" du manuel Guide de configuration de l'hôte (SC23-7658). La commande d'opérateur peut résoudre tous les verrous de fichier/membre placés par les utilisateurs RSE, et ceux placés par d'autres produits (ISPF, par exemple).
Dans des circonstances normales, un fichier ou un membre est verrouillé lorsque le client l'ouvre en mode édition, et libéré lorsque le client ferme la session d'édition.
Certaines conditions d'erreur peuvent gêner le fonctionnement prévu de ce mécanisme. Dans ce cas, l'utilisateur qui détient le verrou peut être annulé à l'aide de la commande d'opérateur modify cancel de RSE, tel que décrit dans "Commandes de l'opérateur" de Guide de configuration de l'hôte (SC11-6285). Les verrous du fichier actif appartenant à cet utilisateur sont libérés lors du processus.
La Figure 8 présente les répertoires z/OS UNIX utilisés par Developer for System z. La liste suivante décrit chaque répertoire en contact avec Developer for System z, le mode de changement d'emplacement et qui gère les données qu'il contient.
Les données contenues dans les répertoires /var/rdz/pushtoclient/ sont gérées par des administrateurs non système, tels que les chefs de projet, qui peuvent disposer de droits de mise à niveau limités sous z/OS UNIX. Par conséquent, il est important de bien comprendre comment z/OS UNIX définit les droits d'accès lors de la création des fichiers pour garantir une configuration à la fois gérable et sécurisée.
Les normes UNIX déterminent la définition des autorisations pour trois types d'utilisateurs : propriétaire, groupe et autres. Des droits de lecture, d'écriture et d'exécution peuvent être définis pour chaque type de façon individuelle.
Chaque site peut définir son propre masque de droits d'accès par défaut ; toutefois, un masque commun octroie des droits d'accès en lecture et en écriture au propriétaire ainsi que des droits d'accès en lecture au groupe et aux autres.
Les données contenues dans le répertoire /var/rdz/pushtoclient/ sont créées avec le masque de droits d'accès défini dans la directive file.permission de pushtoclient.properties. La valeur par défaut prévoit des droits d'accès en lecture et en écriture pour le propriétaire et le groupe ainsi que des droits d'accès en lecture pour les autres. Tous bénéficient de droits d'exécution. Les autorisations d'accès définitives doivent prévoir des droits de lecture et d'exécution pour tous et des droits d'accès en écriture pour les administrateurs de client Developer for System z chargés de la gestion des données.
Les données contenues dans le répertoire /var/rdz/pushtoclient/projects/ sont créées sans masque de droits d'accès spécifique. Les autorisations d'accès définitives doivent prévoir des droits d'accès en lecture pour tous et des droits d'accès en écriture pour les chefs de projet chargés de la gestion des données.
ADDGROUP RDZPROJ OMVS(GID(1200))
CONNECT IBMUSER GROUP(RDZPROJ)
ALTUSER IBMUSER DFLTGRP(RDZPROJ)
ls -lR /var/rdz/pushtoclient/
chown –R IBMUSER /var/rdz/pushtoclient/
chgrp -R RDZPROJ /var/rdz/pushtoclient/
chmod -R 775 /var/rdz/pushtoclient/
Dans le scénario ci-dessous, tous les chefs de projet de développement, à savoir une équipe composée de trois chefs de projet, sont chargés de jouer le rôle d'administrateur de client Developer for System z.
# chmod 775 /var/rdz/pushtoclient
# ls -ld /var/rdz/pushtoclient
drwxrwxr-x 2 IBMUSER SYS1
/var/rdz/pushtoclient
# chgrp RDZPROJ /var/rdz/pushtoclient
# ls –ld /var/rdz/pushtoclient
drwxrwxr-x 2 IBMUSER RDZPROJ
/var/rdz/pushtoclient
Cette étape met fin à la configuration permettant de limiter les droits d'accès en écriture /var/rdz/pushtoclient au programmeur-système (IBMUSER) et aux chefs de projet (RDZPROJ).
Developer for System z offre aux utilisateurs un accès grand système sur un poste de travail qui ne correspond pas à un grand système. La validation des demandes de connexion, l'établissement de communications sécurisées entre l'hôte et le poste de travail, l'autorisation et l'activité d'audit sont donc des aspects fondamentaux de la configuration d'un produit.
Pour être efficaces, les mécanismes de sécurité utilisés par les serveurs et les services Developer for System z doivent reposer sur la sécurité des fichiers et systèmes de fichiers les contenant. Cela implique que seuls les administrateurs système habilités doivent pouvoir mettre à jour les bibliothèques de programmes et les fichiers de configuration.
Les rubriques suivantes sont traitées dans le présent chapitre :
Voir Description de Developer for System z pour en savoir plus sur la conception de base de Developer for System z.
Developer for System z prend en charge plusieurs méthodes d'authentification d'un ID utilisateur fourni par un client lors de la connexion.
Le client fournit un ID utilisateur et un mot de passe lors de la connexion. L'ID utilisateur et le mot de passe sont utilisés pour authentifier l'utilisateur auprès de votre logiciel de sécurité.
Un mot de passe utilisable une seule fois peut être généré par un produit tiers à partir d'un jeton unique. Ce type de mot de passe renforce la configuration de sécurité car le sème unique ne peut pas être copié ni être utilisé sans que l'utilisateur en soit informé et un mot de passe intercepté est inutilisable car il n'est valide qu'une seule fois.
Lors de la connexion, le client indique un ID utilisateur et un mot de passe utilisable une seule fois, qui permet d'authentifier l'ID utilisateur avec l'exit de sécurité fourni par le tiers. Cet exit de sécurité doit ignorer les mots de passe PassTicket utilisés pour traiter les demandes d'authentification lors d'un traitement normal. Les mots de passe PassTicket doivent être traités par votre logiciel de sécurité.
Le client soumet un ID utilisateur et une phrase de passe correspondante à la connexion. L'ID utilisateur et la phrase de passe sont utilisés pour authentifier l'utilisateur auprès de votre produit de sécurité.
Un tiers peut fournir un ou plusieurs certificats X.509 qui permettent l'authentification d'un utilisateur. Lorsqu'ils sont stockés sur des unités sécurisées, les certificats X.509 offrent une configuration sécurisée associée à une grande facilité d'utilisation (pas d'ID utilisateur ni de mot de passe nécessaires).
Lors de la connexion, le client fournit un certificat sélectionné et éventuellement une extension, qui permet d'authentifier l'ID utilisateur auprès de votre logiciel de sécurité.
L'authentification du client est effectuée par le démon RSE (ou REXEC/SSH) dans le cadre d'une demande de connexion client. Une fois que l'utilisateur est authentifié, des mots de passe PassTicket générés automatiquement sont utilisés pour toutes les demandes d'authentification ultérieures, y compris la connexion automatique au moniteur de travaux JES.
Pour que le moniteur de travaux JES puisse valider l'ID utilisateur et le mot de passe PassTicket présenté par RSE, il doit être autorisé à évaluer le mot de passe PassTicket. Cette procédure implique les éléments suivants :
L'authentification du client est effectuée par le démon RSE (ou REXEC/SSH) dans le cadre d'une demande de connexion client. Une fois que l'utilisateur est authentifié, des mots de passe PassTicket générés automatiquement sont utilisés pour toutes les demandes d'authentification ultérieures, y compris la connexion automatique au gestionnaire de débogage.
Pour que le gestionnaire de débogage puisse valider l'ID utilisateur et le mot de passe PassTicket présenté par RSE, il doit être autorisé à évaluer le mot de passe PassTicket. Cela implique que le module de chargement AQEZPCM, situé par défaut dans la bibliothèque de chargement FEK.SFEKAUTH, doit disposer d'une autorisation APF.
Lorsqu'un moteur de débogage basé client se connecte au gestionnaire de débogage, il doit présenter un jeton de sécurité valide pour son authentification.
Developer for System z repose sur des produits tiers, tels que le serveur TN3270 pour fournir certains services. Pour plus d'informations sur les options de sécurité de connexion, reportez-vous à la documentation produit associée.
Le programmeur système peut spécifier les ports sur lesquels le serveur RSE peut communiquer avec le client. Par défaut, n'importe quel port disponible peut être utilisé. Cette gamme de ports n'a aucune connexion avec le port du démon RSE.
Tous les flux de données Developer for System z externes qui transitent par RSE peuvent être chiffrés à l'aide de SSL (Secure Socket Layer). ou Transport Layer Security (TLS). L'utilisation de communications chiffrées est contrôlée par les paramètres du fichier de configuration ssl.properties, comme décrit dans la section Communication chiffrée via SSL/TLS. La variable DSTORE_SSL_ALGORITHM de la directive _RSE_JAVAOPTS du fichier rsed.envvars vous permet de choisir entre SSL et son successeur TLS pour la méthode de chiffrement, comme indiqué à la section sur la définition de paramètres de démarrage Java supplémentaires avec _RSE_JAVAOPTS dans le document Guide de configuration de l'hôte (SC23-7658).
Le moteur de débogueur intégré sur le client se connecte au gestionnaire de débogage sur l'hôte. L'utilisation de SSL ou TLS est contrôlée par une règle AT-TLS (Application Transparent TLS).
L'émulateur de connexion à l'hôte sur le client se connecte à un serveur TN3270 sur l'hôte. L'utilisation de SSL ou TLS est contrôlée par TN3270, comme indiqué dans le document Communications Server IP Configuration Guide (SC31-8775).
Les actions à distance (basées sur l'hôte) dans les sous-projets z/OS UNIX utilisent un serveur REXEC ou SSH sur l'hôte. La communication SSH est toujours chiffrée à l'aide de SSL.
Le client du gestionnaire de déploiement d'application utilise le service Web TS CICS ou l'interface RESTful pour appeler les services hôte du gestionnaire de déploiement d'application. L'utilisation de SSL est contrôlée par CICS TS, comme indiqué dans la documentation RACF Security Guide for CICS TS.
Developer for System z prend en charge la vérification du port d'entrée, ce qui permet à l'hôte d'accéder uniquement aux adresses TCP/IP sécurisées. L'utilisation du port d'entrée est contrôlée par la définition des profils spécifiques dans votre logiciel de sécurité et la directive enable.port.of.entry dans rsed.envvars (voir section Vérification du port d'entrée (POE)).
Notez que l'activation du port d'entrée a une incidence sur d'autres applications TCP/IP prenant en charge la vérification du port d'entrée, telles que INETD.
Après la connexion, des mots de passe PassTicket sont utilisés pour établir la sécurité des unités d'exécution sur le serveur RSE. Cette fonction ne peut pas être désactivée. Les PassTickets sont des mots de passe générés par le système pour une durée d'environ 10 minutes. Les mots de passe PassTicket générés s'appuient sur l'algorithme de chiffrement DES, l'ID utilisateur, l'ID d'application, un horodatage (heure/date) et une clé confidentielle. Cette clé confidentielle est un nombre de 64 bits (16 caractères hexadécimaux) qui doit être définie pour votre logiciel de sécurité. Pour plus de sécurité, le logiciel de sécurité z/OS gère les PassTickets par défaut comme des mots de passe à usage unique.
Le mot de passe réel du client n'est plus nécessaire après l'authentification initiale car les produits de sécurité conformes à SAF peuvent évaluer à la fois les mots de passe Passticket et les mots de passe standard. Le serveur RSE génère et utilise un mot de passe PassTicket chaque fois qu'un mot de passe est requis ; un mot de passe valide (temporaire) est ainsi disponible pour le client.
L'utilisation de mots de passe PassTicket permet à RSE de configurer un environnement de sécurité propre à l'utilisateur sans avoir à stocker tous les ID et les mots de passe dans une table, qui pourrait être illégalement consultée. Ils permettent également de mettre en oeuvre des méthodes d'authentification client qui n'utilisent pas de mots de passe réutilisables, tels que des certificats X.509.
Les profils de sécurité des classes APPL et PTKTDATA sont nécessaires pour permettre l'utilisation de mots de passe PassTicket. Ce profils sont propres à l'application et n'ont pas d'incidence sur la configuration système actuelle.
Comme les mots de passe PassTicket sont propres à l'application, RSE et le moniteur de travaux JES doivent utiliser le même ID d'application (APPLID). Par défaut, les deux serveurs utilisent FEKAPPL comme APPLID mais cette valeur peut être modifiée via la directive APPLID dans rsed.envvars pour RSE et FEJJCNFG pour le moniteur de travaux JES.
Vous ne devez pas utiliser OMVSAPPL comme ID d'application, car il ouvrira la clé confidentielle de la plupart des applications z/OS UNIX. De la même manière, vous ne devez pas utiliser l'ID application par défaut MVS, lequel est MVS suivi par l'ID SMF du système, car il ouvrira la clé confidentielle de la plupart des applications MVS (y compris les travaux par lots des utilisateurs).
La plus petite unité d'un horodatage de passticket est 1 seconde. Cela signifie que tous les passtickets générés en moins d'une seconde par la même application pour le même ID utilisateur seront identiques. Ceci, combiné au fait que le logiciel de sécurité z/OS gère les passtickets comme des mots de passe à usage unique, constitue un problème pour Developer for System z lors de la connexion, car plusieurs passtickets seront requis en moins d'une seconde. Par conséquent, Developer for System z requiert l'activation d'un indicateur dans les définitions de passticket qui autorise la réutilisation des passtickets générés.
Avertissement : La demande de connexion du client n'aboutit pas si
les mots de passe PassTickets ne sont pas correctement configurés.
|
Developer for System z prend en charge la consignation dans le journal d'audit des actions gérées par le démon RSE. Les journaux d'audit sont conservés sous la forme de fichiers texte dans le répertoire de journalisation du démon, au format CSV.
La commande de l'opérateur modify switch permet de passer manuellement à un nouveau fichier journal d'audit, comme indiqué à la section "Commandes de l'opérateur" du Guide de configuration de l'hôte (SC11-6285).
Un message d'avertissement est envoyé à la console lorsque l'espace disponible dans le système de fichiers qui contient les fichiers journaux d'audit est insuffisant. Le message de console (FEK103E) s'affiche régulièrement tant que l'incident lié au manque d'espace n'a pas été résolu.
Un nouveau fichier journal d'audit est démarré après un délai défini ou lorsque la commande de l'opérateur modify switch est exécutée. L'ancien fichier journal d'audit est enregistré sous audit.log.yyyymmdd.hhmmss, où yyyymmdd.hhmmss représente la date/l'horodatage de fermeture de ce journal. La date/l'horodatage système attribué(e) au fichier indique la création du fichier journal. La combinaison des deux dates indique la période couverte par ce fichier journal d'audit.
Les directives audit.action* dans rsed.envvars vous permettent de spécifier un exit utilisateur (script de shell z/OS UNIX, programme z/OS UNIX REXX ou z/OS UNIX) qui sera appelé par RSE lors de la fermeture d'un journal d'audit. Cet exit utilisateur peut alors traiter les données du journal d'audit.
Les fichiers journaux d'audit disposent du masque de bit de droit 640 (-rw-r-----), si cela n'est pas modifié par la directive audit.log.mode dans rsed.envvars. Cela signifie que le propriétaire (ID utilisateur z/OS UNIX du démon RSE) dispose des droits d'accès en lecture et en écriture et que le groupe (par défaut) du propriétaire dispose du droit d'accès en écriture. Toutes les autres tentatives d'accès sont refusées, sauf si elles sont effectuées par un superutilisateur (UID 0) ou par un utilisateur disposant des droits d'accès suffisants sur le profil SUPERUSER.FILESYS dans la classe de sécurité UNIXPRIV.
yyyy/mm/dd hh:mm:ss.sss,userid,action,dataset_name[,returncode]
[,additional_information]]
yyyy/mm/dd hh:mm:ss.sss,userid,action,dataset_name,returncode,create%nmodify%n…
Developer for System z permet aux clients d'accéder au spoule JES via le moniteur de travaux JES. Le serveur fournit un accès de base limité qui peut être étendu à l'aide des fonctions de protection du fichier spoule standard de votre produit de sécurité. Des actions opérateur (Mettre en attente, Publier, Annuler et Purger) sont effectuées sur les fichiers spoule via la console EMCS ; elles nécessitent des autorisations conditionnelles.
Le moniteur de travaux ne fournit pas aux utilisateurs de Developer for System z un accès opérateur intégral au spoule JES. Seules les commandes Mettre en attente, Publier, Annuler et Purger sont disponibles, et par défaut, uniquement pour les fichiers spoule dont l'utilisateur est le propriétaire. Les commandes sont exécutées par la sélection de l'option appropriée dans la structure de menu du client (il n'y a pas d'invite de commande). La portée des commandes peut être réduite à l'aide des profils de sécurité afin de définir les travaux pour lesquels les commandes sont disponibles.
Comparable à l'action SDSF SJ SDSF, le moniteur de travaux JES prend en charge la commande Afficher JCL pour extraire le code JCL qui a créé la sortie de travaux sélectionnée et l'afficher dans une fenêtre d'éditeur. Le moniteur de travaux JES extrait le code JCL de JES ce qui est utile dans les situations où le membre JCL d'origine n'est pas facilement localisé.
Action | JES2 | JES3 |
---|---|---|
Mettre en attente | $Hx(jobid) avec x = {J, S ou T} |
*F,J=jobid,H |
Libérer | $Ax(jobid) avec x = {J, S ou T} |
*F,J=jobid,R |
Annuler | $Cx(jobid) avec x = {J, S ou T} |
*F,J=jobid,C |
Purger | $Cx(jobid),P avec x = {J, S ou T} |
*F,J=jobid,C |
Afficher JCL | non applicable | non applicable |
Les commandes JES disponibles répertoriées dans le Tableau 1 sont, par défaut, limitées aux travaux dont l'utilisateur est le propriétaire. Ce paramétrage peut être modifié à l'aide de la directive LIMIT_COMMANDS, comme indiqué à la section "FEJJCNFG, Fichier de configuration Moniteur de travaux JES" du Guide de configuration de l'hôte (SC11-6285).
Propriétaire du travail | ||
---|---|---|
LIMIT_COMMANDS | Utilisateur | Autre |
USERID (valeur par défaut) | Autorisé | Non autorisé |
LIMITED | Autorisé | Autorisé uniquement si permis de manière explicite par les profils de sécurité |
NOLIMIT | Autorisé | Autorisé si les profils de sécurité l'acceptent ou lorsque la classe JESSPOOL n'est pas active |
JES utilise la classe JESSPOOL pour protéger les fichiers SYSIN/SYSOUT. Comme SDSF, le moniteur de travaux JES étend l'utilisation de la classe JESSPOOL pour protéger également les ressources des travaux.
Commande | Profil JESSPOOL | Droit d'accès requis |
---|---|---|
Mettre en attente | nodeid.userid.jobname.jobid | ALTER |
Libérer | nodeid.userid.jobname.jobid | ALTER |
Annuler | nodeid.userid.jobname.jobid | ALTER |
Purger | nodeid.userid.jobname.jobid | ALTER |
Afficher JCL | nodeid.userid.jobname.jobid.JCL | READ |
nodeid | ID du noeud NJE du sous-système JES cible |
userid | ID utilisateur local du propriétaire du travail |
jobname | Nom du travail |
jobid | ID du travail JES |
Si la classe JESSPOOL n'est pas active, le comportement est différent pour les valeurs LIMITED et NOLIMIT de LIMIT_COMMANDS, comme décrit à la section "Tableau des autorisations pour la commande LIMIT_COMMANDS" dans "Fichier de configuration FEJJCNFG, moniteur de travaux JES" du Guide de configuration de l'hôte (SC11-6285). Le comportement est identique lorsque la classe JESSPOOL est active, car, par défaut, elle refuse le droit d'accès si un profil n'est pas défini.
Après la définition des cibles autorisées, la seconde phase de la sécurité des commandes du spoule JES comprend la définition des autorisations nécessaires pour exécuter la commande de l'opérateur. Ce droit d'exécution est appliqué par les contrôles de sécurité z/OS et JES.
Notez que la commande Afficher JCL n'est pas une commande de l'opérateur comme une autre (par exemple, Mettre en attente, Libérer, Annuler et Purger). En conséquence, les limitations ci-dessous ne s'appliquent pas car il n'y a pas d'autre contrôle de sécurité.
Le moniteur de travaux JES émet toutes les commandes d'opérateur JES demandées par un utilisateur via une console EMCS dont le nom est contrôlé à l'aide de la directive CONSOLE_NAME, comme indiqué à la section "FEJJCNFG, Fichier de configuration Moniteur de travaux JES" du Guide de configuration de l'hôte (SC11-6285).
Le moniteur de travaux JES permet de définir les droits accordés à la console EMCS avec la directive LIMIT_CONSOLE, comme cela est décrit dans la section "FEJJCNFG, fichier de configuration du moniteur de travaux JES" du document Guide de configuration de l'hôte (SC11-6285).
LIMIT_CONSOLE | Profil actif dans la classe OPERCMDS | Aucun profil actif dans la classe OPERCMDS |
---|---|---|
LIMITED (valeur par défaut) | Autorisé, si cela est admis par le profil de sécurité | Non autorisé |
NOLIMIT | Autorisé, si cela est admis par le profil de sécurité | Autorisé |
Supposons que l'accès à l'identité du serveur du moniteur de travaux JES lors de la création d'une console JMON à partir d'une session TSO est empêché par votre logiciel de sécurité. Même si la console peut être créée, le point d'entrée est différent (moniteur de travaux JES/TSO). Les commandes JES exécutées par cette console échouent lors du contrôle de sécurité si la sécurité est configurée comme indiqué dans cette publication et que l'utilisateur ne dispose pas de droits d'accès aux commandes JES via d'autres procédures.
Pour plus d'informations sur la protection des commandes d'opérateur, voir Security Server RACF Security Administrator's Guide (SA22-7683).
Le moniteur de travaux JES permet, par défaut, de parcourir tous les fichiers spoule. Ce paramétrage peut être modifié à l'aide de la directive LIMIT_VIEW, comme indiqué à la section "FEJJCNFG, Fichier de configuration Moniteur de travaux JES" du Guide de configuration de l'hôte (SC11-6285).
Propriétaire du travail | ||
---|---|---|
LIMIT_VIEW | Utilisateur | Autre |
USERID | Autorisé | Non autorisé |
NOLIMIT (valeur par défaut) | Autorisé | Autorisé si les profils de sécurité l'acceptent ou lorsque la classe JESSPOOL n'est pas active |
Pour limiter l'accès des utilisateurs à leurs propres travaux dans le spoule JES, définissez l'instruction "LIMIT_VIEW=USERID" dans le fichier de configuration du moniteur de travaux JES, FEJJCNFG. Si les utilisateurs souhaitent accéder à davantage de travaux, mais pas à tous, utilisez les fonctions de protection du fichier spoule standard de votre produit de sécurité (la classe JESSPOOL, par exemple).
Quand vous définissez d'autres protections, notez que le moniteur de travaux fait appel à l'interface SAPI (SYSOUT application program interface) pour accéder au spoule. En conséquence l'utilisateur a besoin, au minimum, de droits d'accès de mise à jour (UPDATE) des fichiers spoule, même pour des fonctionnalités de navigation. Cette exigence ne s'applique pas si vous utilisez z/OS version 1.7 (z/OS 1.8 pour JES3) ou une version ultérieure. Dans ce cas, les droits d'accès en lecture (READ) suffisent pour les fonctionnalités de navigation.
Pour plus d'informations sur la protection du fichier spoule JES, voir Security Server RACF Security Administrator's Guide (SA22-7683).
Les communications externes (client-hôte) utilisant RSE peuvent être chiffrées à l'aide de SSL (Secure Socket Layer) ou Transport Layer Security (TLS). Cette fonction est désactivée par défaut et est contrôlée par les paramètres du fichier ssl.properties. Reportez-vous à la section "(Facultatif) ssl.properties, chiffrement RSE SSL" du Guide de configuration de l'hôte (SC11-6285).
Le démon RSE et le serveur RSE prennent en charge des mécanismes différents pour stocker des certificats en raison leurs différences architecturales. Cela signifie que des définitions et des certificats SSL sont nécessaires pour le démon et le serveur RSE. Un certificat partagé peut être utilisé si le démon et le serveur RSE utilisent la même méthode de gestion des certificats.
Stockage des certificats | Créé et géré par | Démon RSE | Serveur RSE |
---|---|---|---|
Fichier de clés | Produit de sécurité compatible avec SAF | pris en charge | pris en charge |
Base de données de clés | gskkyman de z/OS UNIX | pris en charge | / |
Magasin de clés | Outil de clé de Java | / | pris en charge |
Les fichiers de clés conformes à SAF peuvent stocker la clé privée du certificat dans la base de données de sécurité ou en utilisant ICSF (Integrated Cryptographic Service Facility), l’interface vers le matériel de chiffrement de System z.
Il est recommandé d'utiliser ICSF pour le stockage des clés privées associées à des certificats numériques. En effet, il s'agit d'une solution plus sûre que la gestion de clé privée non ICSF. ICSF assure le chiffrement des clés privées dans la clé maîtresse ICSF, leur accès étant contrôlé par les ressources générales dans les classes de sécurité CSFKEYS et CSFSERV. De plus, les performances opérationnelles sont améliorées, car ICSF utilise un processeur cryptographique. Pour plus d'informations sur ICSF et pour savoir comment contrôler qui peut utiliser les clés et les services de chiffrement, voir Cryptographic Services ICSF Administrator's Guide (SA22-7521).
Le démon RSE utilise les fonctions SSL système pour gérer des communications chiffrées SSL. Cela signifie que SYS1.SIEALNKE doit être contrôlé par programme via le logiciel de sécurité et être à la disposition de RSE via LINKLIST ou la directive STEPLIB dans rsed.envvars.
La variable DSTORE_SSL_ALGORITHM de la directive _RSE_JAVAOPTS du fichier rsed.envvars vous permet de choisir entre SSL et son successeur TLS pour la méthode de chiffrement, comme indiqué à la section sur la définition de paramètres de démarrage Java supplémentaires avec _RSE_JAVAOPTS dans le document Guide de configuration de l'hôte (SC23-7658).
Pour plus d'informations sur l'activation de SSL pour Developer for System z, voir Configuration de l'authentification SSL et X.509.
Par défaut, le démon RSE s'appuie sur les valeurs par défaut de System SSL pour les protocoles de chiffrement et les définitions de suite de chiffrement pris en charge. Vous pouvez modifier ces valeurs par défaut en spécifiant les variables d'environnement GSK_PROTOCOL_* et GSK_V3_CIPHER_SPECS* dans rsed.envvars. Pour plus d'informations sur ces variables d'environnement, reportez-vous au document Cryptographic Services System SSL Programming (SC24-5901).
TTLSRule RDz_Debug_Manager
{
LocalPortRange 5335
Direction Inbound
TTLSGroupActionRef grp_Production
TTLSEnvironmentActionRef RDz_Debug_Manager
}
TTLSEnvironmentAction RDz_Debug_Manager
{
HandshakeRole Server
TTLSKeyRingParms
{
Keyring dbgmgr.racf # Keyring must be owned by the Debug Manager
}
}
TTLSGroupAction grp_Production
{
TTLSEnabled On
Trace 2
}
Le démon RSE prend en charge les utilisateurs qui s'authentifient eux-mêmes à l'aide d'un certificat X.509. L'utilisation de communications chiffrées SSL est indispensable pour cette fonction car il s'agit d'une extension de l'authentification hôte avec un certificat utilisé dans SSL.
Le démon RSE lance la procédure d'authentification client en validant le certificat client. Les principaux éléments vérifiés sont les dates de validité du certificat et le niveau de confiance de l'autorité de certification utilisée pour signer le certificat. Une liste de révocation de certificat (CRL) d'un tiers peut également être consultée.
Une fois que le démon RSE valide le certificat, celui-ci est traité pour l'authentification. Le certificat est transmis au produit de sécurité à des fins d'authentification, sauf si la directive enable.certificate.mapping de rsed.envvars correspond à false. Dans ce cas, le démon RSE effectue l'authentification.
Si elle aboutit, la procédure d'authentification détermine l'ID utilisateur à utiliser pour cette session et le soumet au test du démon RSE pour vérifier qu'il est utilisable sur le système hôte où le démon RSE s'exécute.
La dernière vérification (réalisée pour chaque mécanisme d'authentification, et pas simplement pour les certificats X.509) s'assure que l'ID utilisateur est autorisé à utiliser Developer for System z.
Si vous êtes familier des classifications de sécurité SSL utilisées par TCP/IP, la combinaison de ces procédures de validation correspond aux “spécification de niveau 3 du client” (la plus élevée).
Une partie de la procédure de validation du certificat consiste à vérifier que le certificat a été signé par une autorité de certification habilitée. Pour effectuer cette opération, le démon RSE doit avoir accès à un certificat qui identifie l'autorité de certification.
Si vous utilisez la base de données de clés gskkyman pour la connexion SSL, le certificat de l'autorité de certification doit être ajouté à la base de données de clés.
Pour obtenir des informations détaillées sur la commande RACDCERT, voir le document Security Server RACF Command Language Reference (SA22-7687).
Attention : Si vous faites appel au démon RSE au lieu du logiciel de sécurité pour authentifier un utilisateur, veillez à ne pas mélanger les autorités de certification avec un état TRUST et HIGHTRUST dans le fichier de clés SAF ou une base de données gskkyman. Le démon RSE n'est pas en mesure d'établir une distinction entre les deux. Les certificats signés par une autorité de certification avec l'état TRUST est valide pour une authentification de l'ID utilisateur. |
Pour plus d'informations sur ces variables d'environnement et sur d'autres variables d'environnement utilisées par z/OS System SSL, voir Cryptographic Services System Secure Sockets Layer Programming (SC24-5901).
RACF effectue plusieurs vérifications pour authentifier un certificat et renvoyer l'ID utilisateur associé. Notez toutefois que d'autres produits de sécurité peuvent effectuer cette opération différemment. Pour plus d'informations sur la fonction initACEE utilisée pour effectuer l'authentification (mode requête), reportez-vous à la documentation du produit de sécurité.
RACDCERT ID(userid) ADD(dsn) TRUST WITHLABEL('label')
id-ce-hostIdMappings OBJECT IDENTIFIER::= {1 3 18 0 2 18 1}
HostIdMappings::= SET OF HostIdMapping
HostIdMapping::= SEQUENCE{
hostName IMPLICIT[1] IA5String,
subjectId IMPLICIT[2] IA5String,
proofOfIdPossession IdProof OPTIONAL
}
IdProof::= SEQUENCE{
secret OCTET STRING,
encryptionAlgorithm OBJECT IDENTIFIER
}
Pour plus d'informations sur les certificats X.509, sur leur gestion par RACF et sur la définition de filtres de nom de certificat, voir le document Security Server RACF Security Administrator’s Guide (SA22-7683). Pour obtenir des informations détaillées sur la commande RACDCERT, voir le document Security Server RACF Command Language Reference (SA22-7687).
Developer for System z peut effectuer une authentification de base des certificats X.509 sans faire appel à votre produit de sécurité. L'authentification effectuée par le démon RSE requiert la définition d'un ID utilisateur et d'un nom d'hôte dans une extension de certificat et est activée uniquement si la directive enable.certificate.mapping définie dans le fichier rsed.envvars correspond à FALSE.
Cette fonction doit être utilisée si votre produit de sécurité ne prend pas en charge l'authentification d'un utilisateur via un certificat X.509 ou si un certificat échoue aux tests effectués par le produit de sécurité (par exemple, le certificat possède un identificateur erroné pour l'extension HostIdMappings ou il n'y a pas de filtre ou de définition de nom dans DIGTCERT).
Le client demande à l'utilisateur l'identificateur d'extension (OID) à utiliser. Par défaut, il s'agit de l'OID HostIdMappings, {1 3 18 0 2 18 1}.
Le démon RSE doit extraire l'ID utilisateur et le nom d'hôte en utilisant l'extension de format HostIdMappings. Ce format est décrit à la section Authentification par votre logiciel de sécurité.
Avertissement : Il revient à l'administrateur de sécurité de vérifier que toutes les autorités de certification connues du démon RSE sont parfaitement dignes de confiance car le démon RSE ne peut pas vérifier si l'autorité qui a signé le certificat client est parfaitement digne de confiance (highly trusted) ou simplement digne de confiance (trusted). Pour plus d'informations sur les certificats d'autorités de certification accessibles, voir Validation de l'autorité de certification (CA).
|
Pour plus d'informations sur le contrôle d'accès au réseau via la vérification du port d'entrée, voir Communications Server IP Configuration Guide (SC31-8775).
Les clients Developer for System z, version 8.5.1 et supérieure, ont la possibilité de vérifier l'autorisation d'accès aux profils de sécurité SAF, puis en fonction des résultats, peuvent activer ou désactiver la fonction correspondante de l'utilisateur.
Developer for System z vérifie les droits d'accès aux profils répertoriés dans le Tableau 7 afin de déterminer quelles options doivent être activées ou désactivées pour l'utilisateur.
Profil FACILITY | Longueur fixe | Droit d'accès requis | Résultat |
---|---|---|---|
FEK.USR.OFF.REMOTECOPY.MVS.sysname | 27 | READ | Le client désactive la fonction de copie et les fonctions connexes dans les fichiers MVS. |
La valeur sysname correspond au nom du système cible.
La colonne "Longueur fixe" indique la longueur de la partie fixe du profil de sécurité associée.
Par défaut, Developer for System z s'attend à ce que les profils FEK.* résident dans la classe de sécurité FACILITY. Notez que les profils figurant dans la classe FACILITY sont limités à 39 caractères. Si la somme de la longueur de la partie fixe du profil (FEK.USR.<key>) et de la longueur de la partie de profil spécifique au site (sysname) est supérieure à ce nombre, vous pouvez placer les profils dans une autre classe et indiquer à Developer for System z qu'il doit utiliser cette dernière à la place. Pour ce faire, mettez en commentaires _RSE_FEK_SAF_CLASS dans rsed.envvars et indiquez le nom de classe de votre choix.
RDEFINE FACILITY (FEK.USR.OFF.REMOTECOPY.MVS.CDFMVS08) -
UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z - CLIENT CONTROL')
PERMIT FEK.USR.OFF.REMOTECOPY.MVS.CDFMVS08 CLASS(FACILITY) -
ID(RESTRICT) ACCESS(READ)
SETROPTS RACLIST(FACILITY) REFRESH
Lorsque les utilisateurs disposent d'un accès en lecture READ au profil FEK.USR.OFF.REMOTECOPY.MVS.sysname, leurs clients Developer for System z version 8.5.1 et supérieure, désactivent les actions glisser, copier, enregistrer sous et travailler hors ligne sur les fichiers MVS. Cela signifie que les utilisateurs peuvent accéder aux fichiers du système, mais qu'ils ne peuvent pas créer de copie de fichier en local sur leur poste de travail. Cela permet d'éviter la fuite de données confidentielles en cas de perte ou de vol du poste de travail en local.
Les clients Developer for System z version 8.0.1 et suivante peuvent extraire les fichiers de configuration client et les informations de mise à niveau depuis l'hôte lorsqu'ils se connectent, ce qui permet de garantir que tous les clients sont paramétrés de la même façon et qu'ils sont à jour.
Depuis la version 8.0.3, l'administrateur client peut créer plusieurs jeux de configuration client et plusieurs scénarios de mise à jour client afin de répondre aux besoins des différents groupes de développeurs. Cela permet aux utilisateurs de recevoir une configuration personnalisée, basée sur des critères tels que l'appartenance d'un groupe LDAP ou les droits d'accès à un profil de sécurité.
Lorsque vous utilisez des définitions dans votre base de données de sécurité comme mécanisme de sélection (la valeur SAF est spécifiée pour les directives dans pushtoclient.properties), Developer for System z vérifie les droits d'accès aux profils répertoriés dans le Tableau 8 pour identifier les groupes de développeurs auxquels l'utilisateur appartient et déterminer si un utilisateur est autorisé à rejeter les mises à jour.
Profil FACILITY | Longueur fixe | Droit d'accès requis | Résultat |
---|---|---|---|
FEK.PTC.CONFIG.ENABLED. |
23 | READ | Le client accepte les mises à jour de configuration pour le groupe indiqué |
FEK.PTC.PRODUCT. |
24 | READ | Le client accepte les mises à jour de produit pour le groupe indiqué |
FEK.PTC.REJECT.CONFIG. |
30 | READ | L'utilisateur peut rejeter les mises à jour de configuration |
FEK.PTC.REJECT.PRODUCT. |
31 | READ | L'utilisateur peut rejeter les mises à jour de produit |
La valeur devgroup correspond au nom de groupe affecté à un groupe spécifique de développeurs. Notez que le nom de groupe est visible sur les clients Developer for System z.
La valeur sysname correspond au nom du système cible.
La colonne "Longueur fixe" indique la longueur de la partie fixe du profil de sécurité associée.
Par défaut, Developer for System z s'attend à ce que les profils FEK.* résident dans la classe de sécurité FACILITY. Notez que les profils figurant dans la classe FACILITY sont limités à 39 caractères. Si la somme de la longueur de la partie fixe du profil (FEK.PTC.<key>) et de la longueur de la partie de profil spécifique au site (sysname ou sysname.devgroup) est supérieure à ce nombre, vous pouvez placer les profils dans une autre classe et indiquer à Developer for System z qu'il doit utiliser cette dernière à la place. Pour ce faire, mettez en commentaires _RSE_FEK_SAF_CLASS dans rsed.envvars et indiquez le nom de classe de votre choix.
Notez que l'administrateur client doit figurer sur la liste d'accès des profils FEK.PTC.*.ENABLED.* pour pouvoir définir et gérer les métadonnées push-to-client associées. Cela implique que les profils soient définis avec (au moins) l'administrateur client dans la liste d'accès avant l'implémentation de la fonction push-to-client avec le support de groupe.
Pour plus d'informations sur l'activation du support de plusieurs groupes, voir la rubrique "(Facultatif) pushtoclient.properties, contrôle client résidant sur l'hôte" dans le document Guide de configuration de l'hôte (SC11-6285). Pour plus d'informations sur les concepts et l'implémentation de la fonction push-to-client, voir Remarques relatives à la fonction d'envoi au client.
Les répertoires de journaux et les fichiers journaux créés par Developer for System z ont par défaut des droits d'accès sécurisés autorisant leur accès à leur propriétaire uniquement. Pour les journaux de serveur (et d'audit), le propriétaire est l'ID utilisateur de la tâche démarrée RSED. Pour les journaux utilisateur, le propriétaire est l'ID utilisateur fourni par l'utilisateur final lors de sa connexion. La directive log.file.mode dans rsed.envvars peut être utilisée pour définir d'autres droits d'accès. Notez que les droits d'accès pour les fichiers d'audit sont contrôlés séparément et sont définis avec la directive audit.log.mode dans rsed.envvars.
Avant d'écrire dans un répertoire de journaux, Developer for System z vérifie la propriété du fichier, et l'écriture échoue si un autre utilisateur possède le fichier. Ce comportement est nouveau dans la version 9.1.0 et peut nécessiter que vous modifiiez une structure de fichier journal existante. La directive log.secure.mode dans rsed.envvars peut être utilisée pour désactiver la vérification de la propriété.
L'exemple de JCL FEKPBITS peut être utilisé pour convertir les droits d'accès et la propriété d'une infrastructure de fichier journal existante. FEKPBITS est situé dans FEK.#CUST.JCL, sauf si vous avez indiqué un autre emplacement lorsque vous avez personnalisé et soumis le travail FEK.SFEKSAMP(FEKSETUP). Pour plus de détails, reportez-vous à "Configuration personnalisée" dans le guide de configuration de l'hôte (SC11-6285).
La tâche démarrée RSED prend en charge la commande de l'opérateur MODIFY LOGS pour collecter des journaux hôte et des informations de configuration Developer for System z. Les données collectées sont placées dans le fichier z/OS UNIX, $TMPDIR/feklogs%sysname.%jobname, où $TMPDIR est la valeur de la directive TMPDIR dans rsed.envvars (/tmp par défaut), %sysname est le nom de votre système z/OS et %jobname est le nom de la tâche démarrée RSED.
Developer for System z recherche dans votre produit de sécurité les droits d'accès aux profils FEK.CMD.LOGS.** pour déterminer si le demandeur est autorisé à collecter les journaux spécifiés. Par défaut, le demandeur est l'ID utilisateur de la tâche démarrée RSED, sauf si l'option OWNER est spécifiée. Seul le demandeur a accès au fichier contenant les données collectées.
Profil FACILITY | Longueur fixe | Droit d'accès requis | Résultat |
---|---|---|---|
FEK.CMD.LOGS.AUDIT.nom_travail | 19 | READ | Le demandeur peut collecter les journaux d'audit de nom_travail |
FEK,CMD.LOGS.SERVER.nom_travail | 20 | READ | Le demandeur peut collecter les journaux serveur de nom_travail |
FEK,CMD.LOGS.USER.ID_utilisateur | 18 | READ | Le demandeur peut collecter les journaux journal utilisateur de ID_utilisateur |
FEK,CMD.LOGS.OWNER.ID_utilisateur | 19 | READ | Le demandeur est modifié depuis l'ID utilisateur de la tâche démarrée en ID_utilisateur |
La valeur nom_travail correspond au nom de la tâche démarrée RSED. La valeur ID_utilisateur correspond à un ID utilisateur valide.
La colonne "Longueur fixe" indique la longueur de la partie fixe du profil de sécurité associée.
Par défaut, Developer for System z s'attend à ce que les profils FEK.* résident dans la classe de sécurité FACILITY. Notez que les profils figurant dans la classe FACILITY sont limités à 39 caractères. Si la somme de la longueur de la partie fixe du profil (FEK.CMD.LOGS.<clé>) et de la longueur de la partie de profil spécifique au site (nom_travail ou ID_utilisateur) est supérieure à ce nombre, vous pouvez placer les profils dans une autre classe et indiquer à Developer for System z qu'il doit utiliser plutôt cette dernière. Pour ce faire, mettez en commentaires _RSE_FEK_SAF_CLASS dans rsed.envvars et indiquez le nom de classe de votre choix.
Les violations d'accès sont signalées avec le message de console FEK302E.
Les exemples de définitions de sécurité suivants permettent à tous de collecter les journaux hôte, mais seulement au groupe SYSPROG de collecter les données d'audit.
RDEFINE FACILITY (FEK.CMD.LOGS.**) UACC(READ) -
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - LOGS OPERATOR COMMAND')
RDEFINE FACILITY (FEK.CMD.LOGS.AUDIT.**) UACC(NONE) –
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - LOGS OPERATOR COMMAND')
PERMIT FEK.CMD.LOGS.AUDIT.** CLASS(FACILITY) -
ID(SYSPROG) ACCESS(READ)
SETROPTS RACLIST(FACILITY) REFRESH
La commande de l'opérateur MODIFY LOGS utilise l'ID utilisateur de tâche démarrée RSED pour collecter des journaux hôte et des informations de configuration. Par défaut, les fichiers journaux d'utilisateur sont créés avec des droits d'accès aux fichiers sécurisés (seul le propriétaire y a accès). Pour pouvoir collecter des fichiers journaux d'utilisateur sécurisés, l'ID utilisateur de tâche démarrée RSED doit être autorisé à les lire.
L'argument OWNER de la commande de l'opérateur MODIFY LOGS a pour résultat que l'ID utilisateur spécifié devienne le propriétaire des données collectés. Pour modifier la propriété, l'ID utilisateur de tâche démarrée RSED doit être autorisé à utiliser le service z/OS UNIX CHOWN.
Ce droit peut être fourni de trois manières à l'ID utilisateur de la tâche démarrée RSED. Dans l'ordre de préférence, il s'agit des méthodes suivantes :
La classe UNIXPRIV contient des profils qui permettent à un administrateur de sécurité de traiter de manière sélective les autorisations spéciales liées à z/OS UNIX, au lieu d'accorder toutes ces autorisations avec l'approche de superutilisateur.
Profil | Autorisation | Résultat |
---|---|---|
SUPERUSER.FILESYS | READ | L'utilisateur est autorisé à effectuer des opérations de lecture sur tout fichier ou répertoire. |
SUPERUSER.FILESYS.ACLOVERRIDE | READ | L'autorisation est requise uniquement si ACLOVERRIDE est déjà défini. Cette autorisation permet à l'utilisateur d'effectuer des opérations de lecture sur tout fichier ou répertoire, quelles que soient les définitions de la liste de contrôle d'accès. |
SUPERUSER.FILESYS.CHOWN | READ | L'utilisateur est autorisé à changer le propriétaire de tout fichier ou répertoire. |
Lorsque l'ID utilisateur de la tâche démarrée RSED dispose du droit de lecture droit (READ) sur le profil BPX.SUPERUSER dans la classe FACILITY, il peut faire en sorte de devenir temporairement un superutilisateur z/OS UNIX pour lequel les droits d'accès aux fichiers z/OS UNIX ne comptent pas.
Lorsque l'ID utilisateur de la tâche démarrée RSED a l'UID (ID utilisateur) 0 spécifié dans son segment OMVS, il tient lieu de superutilisateur z/OS UNIX, pour lequel les droits d'accès aux fichiers z/OS UNIX ne comptent pas. Cependant, cette approche est déconseillée car l'UID 0 est probablement un ID utilisateur partagé et il est recommandé d'affecter à l'ID utilisateur de la tâche démarrée RSED un ID utilisateur unique en raison des autres droits accordés à cet ID. (Par exemple, les administrateurs z/OS UNIX ont besoin de l'UID 0 pour certaines tâches de gestion de systèmes.)
Le débogueur intégré facultatif requiert que les utilisateurs disposent d'autorisations d'accès suffisantes aux profils de sécurité spécifiés. Si l'utilisateur ne dispose pas de l'autorisation requise, la session de débogage ne peut pas démarrer.
Developer for System z vérifie les droits d'accès aux profils répertoriés dans le Tableau 10 afin de déterminer les autorisations de débogage accordées.
Profil FACILITY | Droit d'accès requis | Résultat |
---|---|---|
AQE.AUTHDEBUG.STDPGM | READ | L'utilisateur est habilité à déboguer les applications à l'état problème |
AQE.AUTHDEBUG.AUTHPGM | READ | L'utilisateur est habilité à déboguer les applications à l'état problème et les applications autorisées |
RDEFINE FACILITY (AQE.AUTHDEBUG.STDPGM) -
UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z – DEBUG PROBLEM-STATE')
PERMIT AQE.AUTHDEBUG.STDPGM CLASS(FACILITY) -
ID(RDZDEBUG) ACCESS(READ)
SETROPTS RACLIST(FACILITY) REFRESH
Le débogueur intégré facultatif peut déboguer des transactions CICS. Pour plus d'informations, voir Débogage de transactions CICS.
Developer for System z permet, via le gestionnaire de déploiement d'application, aux administrateurs CICS de contrôler les définitions de ressource CICS qui peuvent être modifiées par le développeur, leurs valeurs par défaut ainsi que l'affichage d'une définition de ressource CICS à l'aide du serveur de définition de ressource CICS. Pour plus d'informations sur les définitions de sécurité TS CICS, voir Remarques relatives à CICSTS.
Le fichier VSAM du référentiel du serveur CRD contient toutes les définitions de ressource par défaut ; il doit par conséquent être protégé contre les mises à jour tout en autorisant les développeurs à consulter les valeurs qui y sont conservées.
Developer for System z met à disposition plusieurs transactions qui sont utilisées par le serveur CRD lors de la définition et de la consultation des ressources CICS. Quand la transaction est rattachée, la vérification de la sécurité de la ressource CICS, si elle est activée, garantit que l'ID utilisateur est autorisé à exécuter l'ID de transaction.
Le client du gestionnaire de déploiement d'application client utilise les services Web CICS ou l'interface RESTful pour appeler le serveur CRD. L'utilisation de SSL pour cette communication est contrôlée par la définition TCPIPSERVICE CICS TS, comme indiqué dans la documentation RACF Security Guide for CICS TS.
SCLM Developer Toolkit offre des fonctionnalités de sécurité facultatives pour les fonctions de génération, de promotion et de déploiement.
Si l'administrateur SCLM a activé la sécurité pour une fonction, des appels SAF sont effectués afin de vérifier l'autorité qui exécute la fonction protégée avec l'ID de l'appelant ou d'un utilisateur de substitution.
Pour de plus amples informations sur les définitions de sécurité SCLM requises, voir le document SCLM Developer Toolkit - Guide d’administration (SC11-6464).
Lorsqu'un espace adresse demande pour la première fois à RACF d'accéder à une classe de ressources ne figurant pas dans une RACLIST (non stockée en mémoire), telle que la classe DATASET, RACF extrait et stocke tous les profils génériques associés dans l'espace adresse de l'utilisateur, dans une liste appelée GATE (Generic Anchor Table Entry). Jusqu'à z/OS 1.12, RACF gère quatre ancres génériques pour chaque espace adresse et quatre pour chaque bloc de contrôle des tâches MVS disposant de son propre élément ACEE. Lorsque les quatre sont utilisés, RACF remplace celui qui est le moins récemment référencé lorsqu'il en arrive un nouveau.
Si vos utilisateurs accèdent souvent à plus de quatre qualificatifs de haut niveau de fichier, les pools d'unités d'exécution RSE (gérant plusieurs utilisateurs à l'aide d'unités d'exécution avec des éléments ACEE propres à l'utilisateur) peuvent faire l'expérience d'une mise en corbeille GATE car RACF doit faire tourner les nouvelles entrées parmi les emplacements d'ancre disponibles.
Dans z/OS 1.12, RACF a ajouté l'option GENERICANCHOR de la commande SET pour vous permettre d'augmenter la taille de la table. Cette définition peut s'effectuer au niveau du système ou pour chaque nom de travail.
Developer for System z utilise les services de noyau z/OS UNIX, tels que pthread_security_np() et __passwd(), lesquels utilisent le service de sécurité InitACEE, ce qui a pour conséquence de générer des blocs de contrôle de sécurité ACEE gérés. Un élément ACEE (Accessor Environment Element) géré est mis en cache par votre produit de sécurité, et ce dernier va ignorer certaines modifications, telles que les modifications de mot de passe en dehors de Developer for System z jusqu'au dépassement délai d'attente du cache. (Le dépassement du délai d'attente peut prendre quelques minutes.)
Actualisez le cache ACEE géré après les modifications de sécurité pour faire en sorte que nouvelles données soient utilisées par Developer for System z.
RACF peut enregistrer les éléments ACEE (Accessor Environment Elements) à l'aide de l'utilitaire VLF (Virtual Lookaside Facility) et les extraire pour les utiliser plus tard. Developer for System z demande à votre logiciel de sécurité de construire plusieurs environnements de sécurité (ACEE) pour le même utilisateur (un pour chaque unité d'exécution spécifique à l'utilisateur dans le pool d'unités d'exécution RSE), et peut donc tirer parti de la mise en cache ACEE.
Pour plus d'informations sur la mise en cache ACEE, voir "ACEEs and VLF considerations" dans le manuel Security Server RACF System Programmer's Guide (SA22-7681).
Plusieurs fichiers de configuration Developer for System z contiennent des directives qui ont une incidence sur la configuration des audits et de la sécurité. En fonction des informations de ce chapitre, l'administrateur de sécurité et le programmeur système peuvent déterminer les paramètres à définir pour les directives ci-dessous.
Définit les travaux auxquels les actions peuvent être appliquées (à l'exception de la consultation et la soumission). Pour plus d'informations, voir Actions sur les travaux - Limitations sur les cibles.
Définissez le niveau d'autorisation de la console EMCS utilisée pour les actions d'exécution. Pour plus d'informations, voir Actions sur les travaux - Limitations sur les cibles.
Définissez les fichiers de spoule qui peuvent être consultés. Pour plus d'informations, voir Accès aux fichiers spoule.
Indiquez si le moniteur de travaux JES est accessible en dehors de ce système z/OS. Pour plus d'informations, voir la section FEJJCNFG, fichier de configuration du moniteur de travaux JES du chapitre sur la personnalisation de base dans le document Guide de configuration de l'hôte (SC23-7658).
ID application utilisé pour la création et la validation de mots de passe PassTicket. Pour plus d'informations, voir Utilisation de PassTickets.
Classe de sécurité contenant les profils FEK.**. Pour plus d'informations, voir Groupes de développeurs de la fonction push-to-client et Modification des fonctions client.
Empêche les utilisateurs de sauvegarder leur mot de passe hôte sur le client. Pour plus d'informations, reportez-vous au tableau "Définition de paramètres de démarrage supplémentaires Java avec _RSE_JAVAOPTS" du Guide de configuration de l'hôte (SC11-6285).
Délai de déconnexion des clients inactifs. Pour plus d'informations, reportez-vous au tableau "Définition de paramètres de démarrage supplémentaires Java avec _RSE_JAVAOPTS" du Guide de configuration de l'hôte (SC11-6285).
ID application utilisé pour la création et la validation de mots de passe PassTicket. Pour plus d'informations, voir Utilisation de PassTickets.
Active la vérification du port d'entrée. Pour plus d'informations, voir Vérification du port d'entrée (POE).
Sélectionnez SSL ou TLS comme méthode de chiffrement des communications. Pour plus d'informations, voir Communication chiffrée via SSL/TLS.
Utilisez le produit de sécurité pour authentifier des utilisateurs avec un certificat X.509. Pour plus d'informations, voir Authentification du client à l'aide de certificats X.509.
GSK_LDAP_SERVER=*
GSK_LDAP_PORT={389 | *}
GSK_LDAP_USER=*
GSK_LDAP_PASSWORD=*
Contrôles de sécurité supplémentaires pour l'authentification X.509. Pour plus d'informations, voir (Facultatif) Interrogation d'une liste de révocation de certificat (CRL).
Masque des droits d'accès aux fichiers et aux répertoires de journaux hôte.
Contrôles de sécurité supplémentaires (comme la propriété) pour les fichiers et répertoires de journaux hôte.
Chemin d'accès aux fichier de journaux d'audit. Pour plus d'informations, voir Consignation dans le journal d'audit.
Masque des droits d'accès au fichier des journaux d'audit. Pour plus d'informations, voir Consignation dans le journal d'audit.
(_RSE_JAVAOPTS) -Daudit.action.id=<userid>
Exit utilisateur basé sur z/OS UNIX qui traite les journaux d'audit. Pour plus d'informations, voir Consignation dans le journal d'audit.
Emplacement du certificat du démon RSE. Pour plus d'informations, voir Communication chiffrée via SSL/TLS.
Nom du certificat du démon RSE. Pour plus d'informations, voir Communication chiffrée via SSL/TLS.
Emplacement du certificat du serveur RSE. Pour plus d'informations, voir Communication chiffrée via SSL/TLS.
Nom du certificat du serveur RSE. Pour plus d'informations, voir Communication chiffrée via SSL/TLS.
Type de fichier de clés utilisé (Java ou SAF). Pour plus d'informations, voir Communication chiffrée via SSL/TLS.
reject.config.updates={true | false | SAF | LDAP}
Contrôle basé sur un hôte des fichiers de configuration client de Developer for System z. Pour plus d'informations, voir Remarques relatives à la fonction d'envoi au client.
reject.product.updates={true | false | SAF | LDAP}
Contrôle basé sur un hôte des mises à jour de produit client de Developer for System z. Pour plus d'informations, voir Remarques relatives à la fonction d'envoi au client.
Personnalisez et soumettez l'exemple de membre FEKRACF, comportant les commandes RACF et z/OS UNIX permettant de créer les définitions de sécurité de base de Developer for System z.
FEKRACF se trouve dans FEK.#CUST.JCL, sauf si vous avez indiqué un autre emplacement lorsque vous avez personnalisé et soumis le travail FEK.SFEKSAMP(FEKSETUP). Pour plus d'informations, voir la section sur la configuration de la personnalisation dans le document IBM Rational Developer for System z - Guide de configuration de l'hôte.
Pour plus d'informations sur les commandes RACF, voir le document RACF Command Language Reference (SA22–7687).
Les sections suivantes décrivent les étapes nécessaires, la configuration facultative et les autres solutions possibles.
Description |
|
Valeur |
---|---|---|
Qualificatif de haut niveau du produit Developer for System z |
|
|
Qualificatif de haut niveau de personnalisation de Developer for System z |
|
|
Nom de tâche démarrée du débogueur intégré |
|
|
Nom de tâche démarrée du moniteur de travaux JES |
|
|
Nom de tâche démarrée du démon RSE |
|
|
ID application |
|
Attention : Certains produits (FTP, par exemple) doivent être contrôlés par programme si "WHEN PROGRAM" est actif. Vous devez essayer ce contrôle de programmes avant de l'activer sur un système de production. |
Un segment OMVS RACF ou équivalent indiquant un ID utilisateur z/OS UNIX différent de zéro valide, un répertoire principal et une commande shell doivent être définis pour chaque utilisateur de Developer for System z. Leur groupe par défaut requiert également un segment OMVS avec un ID de groupe.
Lors de l'utilisation du débogueur intégré facultatif, l'ID utilisateur sous laquelle l'application déboguée est active et son groupe par défaut nécessitent également un segment OMVS RACF ou équivalent.
Dans les exemples de commandes RACF ci-dessous, remplacez les marques de réservation #userid, #user-identifier, #group-name et #group-identifier par les valeurs réelles :
ALTUSER #userid
OMVS(UID(#user-identifier) HOME(/u/#userid) PROGRAM(/bin/sh) NOASSIZEMAX)
Les exemples de commande RACF ci-dessous créent les tâches démarrées DBGMGR, JMON et RSED, avec des ID utilisateur protégés (STCDBM, STCJMON et STCRSE), ainsi que le groupe STCGROUP qui leur est affecté. Remplacez les marques de réservation #group-id et #user-id-* par des ID OMVS valides.
ADDGROUP STCGROUP OMVS(AUTOGID)
DATA('GROUP WITH OMVS SEGMENT FOR STARTED TASKS')
ADDUSER STCDBM DFLTGRP(STCGROUP) NOPASSWORD NAME('RDZ – DEBUG MANAGER')
OMVS(AUTOUID HOME(/tmp) PROGRAM(/bin/sh) )
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDUSER STCJMON DFLTGRP(STCGROUP) NOPASSWORD NAME('RDZ - JES JOBMONITOR')
OMVS(AUTOUID HOME(/tmp) PROGRAM(/bin/sh) )
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDUSER STCRSE DFLTGRP(STCGROUP) NOPASSWORD NAME('RDZ - RSE DAEMON')
OMVS(AUTOUID HOME(/tmp) PROGRAM(/bin/sh) ASSIZEMAX(2147483647) )
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
RDEFINE STARTED DBGMGR.* DATA('RDZ – DEBUG MANAGER')
STDATA(USER(STCDBM) GROUP(STCGROUP) TRUSTED(NO))
RDEFINE STARTED JMON.* DATA('RDZ - JES JOBMONITOR')
STDATA(USER(STCJMON) GROUP(STCGROUP) TRUSTED(NO))
RDEFINE STARTED RSED.* DATA('RDZ - RSE DAEMON')
STDATA(USER(STCRSE) GROUP(STCGROUP) TRUSTED(NO))
ALTUSER STCRSE RESTRICTED
Pour vous assurer que les utilisateurs restreints n'ont pas accès aux ressources du système de fichiers z/OS UNIX via "d'autres" bits d'autorisation, définissez le profil RESTRICTED.FILESYS.ACCESS dans la classe UNIXPRIV avec UACC(NONE). Pour plus d'informations sur la restriction des ID utilisateurs, voir le manuel Security Server RACF Security Administrator's Guide (SA22-7683).
Avertissement : Si vous utilisez des ID utilisateur restreints,
ajoutez de manière explicite le droit d'accès à une ressource avec les commandes
TSO PERMIT ou z/OS UNIX
setfacl.
Sont incluses les ressources dans lesquelles la documentation
Developer
for System z utilise UACC,
comme le profil ** dans la classe PROGRAM,
ou qui se fondent sur les conventions z/OS
UNIX, lorsque tous les utilisateurs possèdent les droits d'accès
en lecture et en exécution aux bibliothèques Java.
Testez l'accès avant de l'activer sur un système de production.
|
RSE requiert un accès UPDATE au profil BPX.SERVER pour créer ou supprimer l'environnement de sécurité de l'unité d'exécution du client. Si ce profil n'est pas défini, UID(0) est nécessaire pour RSE. Cette étape est requise pour la connexion des clients.
Le débogueur intégré requiert un accès UPDATE au profil BPX.SERVER pour créer ou supprimer l'environnement de sécurité de l'unité d'exécution. Si ce profil n'est pas défini, un ID utilisateur UID(0) est requis pour l'ID utilisateur de la tâche démarrée STCDBM. Cette autorisation est requise uniquement lorsque la fonction de débogueur intégrée facultative est utilisée.
Avertissement : La définition du profil BPX.SERVER permet de
configurer z/OS UNIX
comme un commutateur global qui bascule de la sécurité de niveau UNIX
à la sécurité plus étendue de z/OS UNIX. Ce basculement peut avoir une incidence sur
d'autres applications et opérations z/OS UNIX. Vous devez tester la sécurité avant de l'activer sur
un système de production. Pour plus d'informations sur les différents niveaux de sécurité, voir UNIX System Services
Planning (GA22-7800).
|
Les serveurs disposant des droits BPX.SERVER doivent être exécutés dans un environnement propre, contrôlé par un programme. Cette exigence signifie que tous les programmes appelés par RSE doivent également être contrôlés par programme. Pour les bibliothèques de chargement MVS, le contrôle par programme est géré par votre logiciel de sécurité. Cette étape est requise pour la connexion des clients.
Les bibliothèques prérequises suivantes doivent être contrôlées par un programme pour la prise en charge des services facultatifs. Cette liste n'inclut pas les fichiers spécifiques d'un produit avec lequel interagit Developer for System z (IBM File Manager, par exemple).
Le mot de passe du client ou toute autre méthode d'identification, telle qu'un certificat X.509, est utilisé uniquement pour vérifier l'identité lors de la connexion. Par la suite, les mots de passe PassTicket permettent de gérer la sécurité des unités d'exécution. Cette étape est requise pour la connexion des clients.
RDEFINE PTKTDATA FEKAPPL UACC(NONE) SSIGNON(KEYMASKED(key16))
APPLDATA('NO REPLAY PROTECTION – DO NOT CHANGE')
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
RDEFINE PTKTDATA IRRPTAUTH.FEKAPPL.* UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
PERMIT IRRPTAUTH.FEKAPPL.* CLASS(PTKTDATA) ACCESS(UPDATE) ID(STCRSE)
SETROPTS RACLIST(PTKTDATA) REFRESH
RSE prend en charge l'utilisation d'un ID application autre que FEKAPPL. Supprimez la mise en commentaire et personnalisez l'option "APPLID=FEKAPPL" dans rsed.envvars pour l'activer, comme indiqué à la section "Définition de paramètres de démarrage Java supplémentaires avec _RSE_JAVAOPTS" du manuel IBM Rational Developer for System z - Guide de configuration de l'hôte. Les définitions de classe PTKTDATA doivent correspondre à l'ID application réel utilisé par RSE.
Avertissement : La demande de connexion client échoue si les passtickets ne sont pas correctement configurés.
|
La commande de l'opérateur MODIFY LOGS utilise l'ID utilisateur de tâche démarrée RSED pour collecter des journaux hôte et des informations de configuration. Par défaut, les fichiers journaux d'utilisateur sont créés avec des droits d'accès aux fichiers sécurisés (seul le propriétaire y a accès). Pour pouvoir collecter des fichiers journaux d'utilisateur sécurisés, l'ID utilisateur de tâche démarrée RSED doit être autorisé à les lire.
L'argument OWNER de la commande de l'opérateur MODIFY LOGS a pour résultat que l'ID utilisateur spécifié devienne le propriétaire des données collectés. Pour modifier la propriété, l'ID utilisateur de tâche démarrée RSED doit être autorisé à utiliser le service z/OS UNIX CHOWN.
Notez que lorsque le profil SUPERUSER.FILESYS.ACLOVERRIDE est défini, les droits d'accès configurés dans la liste de contrôle d'accès sont prioritaires sur les droits octroyés par le biais de SUPERUSER.FILESYS. L'ID utilisateur de tâche démarrée RSED aura besoin de l'autorisation d'accès en lecture (READ) au profil SUPERUSER.FILESYS.ACLOVERRIDE pour ignorer les définitions de la liste de contrôle d'accès.
Lors de la connexion du client, le démon RSE vérifie que l'utilisateur est autorisé à utiliser l'application.
RDEFINE APPL FEKAPPL UACC(READ) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
SETROPTS RACLIST(APPL) REFRESH
Les serveurs disposant des droits BPX.SERVER doivent être exécutés dans un environnement propre, contrôlé par un programme. Cette exigence signifie que tous les programmes appelés par RSE doivent également être contrôlés par programme. Pour les fichiers z/OS UNIX, le contrôle par programme est géré par la commande extattr. Pour exécuter cette commande vous devez disposer du droit d'accès en lecture (READ) sur BPX.FILEATTR.PROGCTL dans la classe FACILITY ou avoir l'ID utilisateur UID(0).
$ ls -Eog /usr/lib/libIRRRacf*.so
-rwxr-xr-x aps- 2 69632 Oct 5 2007 /usr/lib/libIRRRacf.so
-rwxr-xr-x aps- 2 69632 Oct 5 2007 /usr/lib/libIRRRacf64.so
Le moniteur de travaux JES émet toutes les commandes d'opérateur JES demandées par un utilisateur via une console EMCS dont le nom est contrôlé à l'aide de la directive CONSOLE_NAME, comme indiqué dans la section "FEJJCNFG, JES Job Monitor configuration file" du document IBM Rational Developer for System z Host Configuration Guide.
RDEFINE OPERCMDS MVS.MCSOPER.#console UACC(READ)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
RDEFINE OPERCMDS JES%.** UACC(NONE)
PERMIT JES%.** CLASS(OPERCMDS) ACCESS(UPDATE) WHEN(CONSOLE(JMON)) ID(*)
SETROPTS RACLIST(OPERCMDS) REFRESH
Avertissement : La définition des commandes JES à l'aide de l'accès universel NONE dans votre
logiciel de sécurité peut avoir une incidence sur les autres applications et opérations. Vous devez tester la sécurité avant de l'activer sur
un système de production.
|
Le Tableau 12 et le Tableau 13 présentent des commandes d'opérateur soumises pour JES2 et JES3, et les profils de sécurité discrets qui peuvent être utilisés pour les protéger.
Action | Commande | Profil OPERCMDS | Droit d'accès requis |
---|---|---|---|
Mettre en attente | $Hx(jobid) avec x = {J, S ou T} |
|
UPDATE |
Libérer | $Ax(jobid) avec x = {J, S ou T} |
|
UPDATE |
Annuler | $Cx(jobid) avec x = {J, S ou T} |
|
UPDATE |
Purger | $Cx(jobid),P avec x = {J, S ou T} |
|
UPDATE |
Action | Commande | Profil OPERCMDS | Droit d'accès requis |
---|---|---|---|
Mettre en attente | *F,J=jobid,H |
|
UPDATE |
Libérer | *F,J=jobid,R |
|
UPDATE |
Annuler | *F,J=jobid,C |
|
UPDATE |
Purger | *F,J=jobid,C |
|
UPDATE |
Supposons que l'accès à l'identité du serveur du moniteur de travaux JES lors de la création d'une console JMON à partir d'une session TSO est empêché par votre logiciel de sécurité. Même si la console peut être créée, le point d'entrée est différent ; par exemple, moniteur de travaux JES/TSO. Les commandes JES exécutées par cette console échouent lors du contrôle de sécurité si la sécurité est configurée comme indiqué dans cette publication et que l'utilisateur ne dispose pas de droits d'accès aux commandes JES via d'autres procédures.
Les utilisateurs doivent disposer du droit d'accès en lecture à l'un des profils AQE.AUTHDEBUG.* répertoriés pour pouvoir utiliser le débogueur intégré afin de déboguer les programmes à l'état problème. Les utilisateurs autorisés à accéder au profil AQE.AUTHDEBUG.AUTHPGM peuvent également déboguer des programmes autorisés par APF. Remplacez la marque de réservation #apf par des ID utilisateur ou des noms de groupes RACF pour les utilisateurs admis pour déboguer des programmes autorisés.
RDEFINE FACILITY AQE.AUTHDEBUG.STDPGM UACC(NONE)
PERMIT AQE.AUTHDEBUG.STDPGM CLASS(FACILITY) ACCESS(READ) ID(*)
RDEFINE FACILITY AQE.AUTHDEBUG.AUTHPGM UACC(NONE)
PERMIT AQE.AUTHDEBUG.AUTHPGM CLASS(FACILITY) ACCESS(READ) ID(#apf)
SETROPTS RACLIST(FACILITY) REFRESH
Un accès en lecture pour les utilisateurs et en modification pour les programmeurs système suffit pour la plupart des fichiers Developer for System z. Remplacez la marque de réservation #sysprog par des ID utilisateur ou des noms de groupes RACF. Demandez également au programmeur système qui a installé et configuré le produit de vous fournir les noms de fichier corrects. FEK est le qualificatif de haut niveau par défaut utilisé pendant l'installation, et FEK.#CUST celui relatif aux fichiers créés pendant le processus de personnalisation.
ADDGROUP (FEK) OWNER(IBMUSER) SUPGROUP(SYS1)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - HLQ STUB')
ADDSD 'FEK.*.**' UACC(READ)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
PERMIT 'FEK.*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
SETROPTS GENERIC(DATASET) REFRESH
ADDSD 'FEK.#CUST.LSTRANS.*.**' UACC(UPDATE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - SCLMDT')
PERMIT 'FEK.#CUST.LSTRANS.*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
SETROPTS GENERIC(DATASET) REFRESH
ADDSD 'FEK.#CUST.CRA*.**' UACC(READ)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - CARMA')
PERMIT 'FEK.#CUST.CRA*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.CRA*.**' CLASS(DATASET) ACCESS(UPDATE) ID(#ram-developer)
SETROPTS GENERIC(DATASET) REFRESH
ADDSD 'FEK.#CUST.ADNREP*.**' UACC(READ)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - ADN')
PERMIT 'FEK.#CUST.ADNREP*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.ADNREP*.**' CLASS(DATASET) ACCESS(UPDATE) ID(#cicsadmin)
SETROPTS GENERIC(DATASET) REFRESH
ADDSD 'FEK.#CUST.ADNMAN*.**' UACC(UPDATE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - ADN')
PERMIT 'FEK.#CUST.ADNMAN*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
SETROPTS GENERIC(DATASET) REFRESH
ADDGROUP (FEK)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - HLQ STUB')
OWNER(IBMUSER) SUPGROUP(SYS1)"
ADDSD 'FEK.*.**' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.SFEKAUTH' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.SFEKLOAD' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.SFEKLMOD' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.SFEKPROC' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.#CUST.PARMLIB' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.#CUST.CNTL' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.#CUST.SQL' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.#CUST.LSTRANS.*.**' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - SCLMDT')
ADDSD 'FEK.#CUST.CRA*.**' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - CARMA')
ADDSD 'FEK.#CUST.ADNREP*.**' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - ADN')
ADDSD 'FEK.#CUST.ADNMAN*.**' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - ADN')
PERMIT 'FEK.*.** CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.SFEKAUTH CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.SFEKLOAD CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.SFEKLMOD CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.SFEKPROC CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.PARMLIB CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.CNTL CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.SQL CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.LSTRANS.*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.CRA*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.ADNREP*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.ADNMAN*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.SFEKAUTH' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.SFEKLOAD' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.SFEKPROC' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.#CUST.CNTL' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.#CUST.SQL' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.SFEKAUTH' CLASS(DATASET) ACCESS(READ) ID(STCJMON)
PERMIT 'FEK.#CUST.PARMLIB' CLASS(DATASET) ACCESS(READ) ID(STCJMON)
PERMIT 'FEK.#CUST.LSTRANS.*.**' CLASS(DATASET) ACCESS(UPDATE) ID(*)
PERMIT 'FEK.#CUST.CRA*.**' CLASS(DATASET) ACCESS(UPDATE) ID(#ram-developer)
PERMIT 'FEK.#CUST.ADNREP*.**' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.#CUST.ADNREP*.**' CLASS(DATASET) ACCESS(UPDATE) ID(#cicsadmin)
PERMIT 'FEK.#CUST.ADNMAN*.**' CLASS(DATASET) ACCESS(UPDATE) ID(*)
PERMIT 'FEK.SFEKLOAD' CLASS(DATASET) ACCESS(READ) ID(#cicsts)
PERMIT 'FEK.SFEKLMOD' CLASS(DATASET) ACCESS(READ) ID(#cicsts)
PERMIT 'FEK.SFEKLMOD' CLASS(DATASET) ACCESS(READ) ID(#ims)
PERMIT 'FEK.SFEKLMOD' CLASS(DATASET) ACCESS(READ) ID(#batch)
SETROPTS GENERIC(DATASET) REFRESH
Utilisez les exemples de commande ci-dessous pour afficher les résultats de vos personnalisations de la sécurité.
Developer for System z repose sur le protocole TCP/IP pour offrir l'accès au mainframe à des utilisateurs travaillant sur un poste de travail autre qu'un mainframe. TCP/IP sert également à assurer la communication entre les différents composants et les autres produits.
Notez que la plupart des fonctions Developer for System z sont basées sur z/OS UNIX ; par conséquent, TCP/IP utilisera l'ordre de recherche z/OS UNIX pour trouver ses fichiers de configuration. Pour plus d'informations, voir Configuration de TCP/IP.
La Figure 10 présente les ports TCP/IP qui peuvent être utilisés par Developer for System z. Les flèches indiquent la partie qui assure la liaison (tête de flèche) et celle qui assure la connexion.
Si vous utilisez l'instruction PORT ou PORTRANGE dans PROFILE.TCPIP pour réserver les ports utilisés par Developer for System z, notez que de nombreux liens sont établis par les unités d'exécution qui sont actives dans un pool d'unités d'exécution RSE. Le nom de travail du pool d'unités d'exécution RSE est RSEDx, où RSED est le nom de la tâche démarrée RSE et x est un nombre à un chiffre aléatoire, si bien que la définition contient obligatoirement des caractères génériques.
PORT 4035 TCP RSED ; Developer for System z - RSE daemon
PORT 6715 TCP JMON ; Developer for System z - JES job monitor
PORT 5335 TCP DBGMGR ; Developer for System z – Integrated
debugger
PORT 5336 TCP DBGMGR ; Developer for System z – Integrated
debugger
PORTRange 8108 11 TCP RSED* ; Developer for System z - _RSE_PORTRANGE
;PORTRange 5227 100 TCP RSED* ; Developer for System z - CARMA
CARMA (Common Access Repository Manager) permet d'accéder à un SCM (Software Configuration Manager) basé sur un hôte, par exemple CA Endevor® SCM. Dans la plupart des cas, comme pour le démon RSE, un serveur assure la liaison à un port et écoute les demandes de connexion. Toutefois, CARMA utilise une démarche différente, étant donné que le serveur CARMA n'est pas encore actif lorsque le client lance la demande de connexion.
Lorsque le client envoie une demande de connexion, l'exploitant CARMA, qui est actif comme une unité d'exécution utilisateur d'un pool d'unités d'exécution RSE, demande un port temporaire ou trouve un port libre dans la plage indiquée dans le fichier de configuration CRASRV.properties et procède à la liaison. L'exploitant démarre le serveur CARMA et transmet le numéro de port, de sorte que le serveur sache à quel port se connecter. Une fois le serveur connecté, le client peut envoyer les demandes au serveur et recevoir les résultats.
Du point de vue de TCP/IP, RSE (via le logiciel de fouille de données CARMA) constitue le serveur qui établit la liaison au port et le serveur CARMA représente le client qui s'y connecte.
Si vous utilisez l'instruction PORT ou PORTRANGE dans PROFILE.TCPIP pour réserver la plage de ports utilisée par CARMA, notez que le logiciel de fouille de données CARMA est actif dans un pool d'unités d'exécution RSE. Le nom de travail du pool d'unités d'exécution RSE est RSEDx, où RSED correspond au nom de la tâche RSE démarrée et x à un chiffre aléatoire unique, si bien que la définition contient obligatoirement des caractères génériques.
PORTRange 5227 100 RSED* ; Developer for System z - CARMA
La fonction de retardement d'accusé de réception retarde la réception d'un accusé de réception d'un paquet TCP de 200 ms au maximum. Ce retard augmente les chances que l'accusé de réception puisse être envoyé avec la réponse au paquet reçu, ce qui réduit le trafic réseau. Toutefois, si l'émetteur attend de recevoir l'accusé de réception pour envoyer un nouveau paquet (par exemple, en raison de l'implémentation d'un algorithme de Nagle) et qu'il n'y a aucune réponse au paquet qui vient d'être envoyé (par exemple, lors d'un transfert de fichiers), la communication est retardée inutilement.
Developer for System z vous permet de désactiver la fonction de retardement d'accusé de réception. Sur l'hôte, cela s'effectue via la directive DSTORE_TCP_NO_DELAY dans rsed.envvars, comme indiqué dans le document Guide de configuration de l'hôte (SC11-6285).
z/OS Communication Server permet l'activation simultanée de plusieurs piles TCP/IP dans un seul système. Il s'agit dans ce cas d'une configuration CINET.
Si Developer for System z n'est pas actif sur la pile par défaut, les fonctions Developer for System z sélectionnées risquent d'échouer. L'utilisation de l'affinité entre piles permet de résoudre ce problème. L'affinité entre piles signale à Developer for System z d'utiliser uniquement une pile TCP/IP spécifique (et non toutes les piles TCP/IP disponibles, ce qui est la valeur par défaut pour les tâches démarrées).
L'affinité entre piles est définie pour la tâche démarrée RSED en supprimant la mise en commentaire et en personnalisant la directive _BPXK_SETIBMOPT_TRANSPORT dans le fichier de configuration rsed.envvars. Pour plus d'informations sur la personnalisation de ce fichier de configuration, voir la section connexe dans le "Chapitre 2 Personnalisation de base" du document Guide de configuration de l'hôte (SC23-7658).
CARMA (Common Access Repository Manager) permet d'accéder à un SCM (Software Configuration Manager) basé sur un hôte, par exemple CA Endevor® SCM. Pour ce faire, CARMA démarre le serveur spécifique à un utilisateur qui doit être configuré pour une application de l'affinité entre piles.
A l'instar des tâches démarrées Developer for System z, l'affinité entre piles d'un serveur CARMA est définie à l'aide de la variable _BPXK_SETIBMOPT_TRANSPORT qui doit être transmise à LE (Language Environment). Pour ce faire, réglez la commande de démarrage dans le fichier de configuration crastart*.conf ou CRASUB* actif.
... PARM(&CRAPRM1. &CRAPRM2.)
... PARM(ENVAR("_BPXK_SETIBMOPT_TRANSPORT=TCPIP") / &CRAPRM1. &CRAPRM2.)
... PARM(&PORT &TIMEOUT)
... PARM(ENVAR("_BPXK_SETIBMOPT_TRANSPORT=TCPIP") / &PORT &TIMEOUT)
L'adressage DVIPA distribué (adressage IP virtuel dynamique) permet d'exécuter simultanément des installations Developer for System z identiques sur différents systèmes du sysplex et de demander à TCP/IP, éventuellement avec l'aide de WLM, de distribuer les connexions client entre ces systèmes.
Par conséquent, Developer for System z nécessite la définition de SYSPLEXPORTS dans l'instruction VIPADISTRIBUTE pour que les ports utilisés par les unités d'exécution du serveur RSE soient uniques dans le sysplex.
Le moniteur de travaux JES, CARMA et les autres serveurs Developer for System z interagissent uniquement avec le RSE local et ils ne nécessitent donc pas de configuration DVIPA.
Le débogueur intégré interagit uniquement avec le RSE local et ne nécessite donc pas de configuration DVIPA. Pour s'assurer que les sessions de débogage communiquent avec l'hôte correct, le gestionnaire de débogage indique l'adresse TCP/IP à utiliser et ne nécessite donc pas de configuration DVIPA.
Les adresses DVIPA distribuées sont définies par les mots clés VIPADEFine et VIPABackup du bloc VIPADynamic dans votre profil TCP/IP. Le mot clé VIPADISTribute ajoute les définitions Sysplex Distributor nécessaires. L'adressage DVIPA distribué implique que toutes les piles participantes aient connaissance du sysplex, opération qui est exécuté via les mots clés SYSPLEXRouting et DYNAMICXCF du bloc IPCONFIG dans votre profil TCP/IP. Voir Communications Server: IP Configuration Reference (SC31-8776) pour plus d'informations sur ces directives.
Voir MVS Setting Up a Sysplex (SA22-7625) et Communication Server: SNA Network Implementation Guide (SC31-8777) pour plus d'informations sur la configuration de la structure EZBEPORTS dans votre fonction de couplage.
L'utilisation de SYSPLEXPORTS implique que TCP/IP sélectionne un port éphémère pour la connexion secondaire. Un port éphémère est un port disponible et non réservé. L'utilisation d'un port éphémère entre en conflit avec les meilleures pratiques de pare-feu qui consistent à limiter le nombre de ports ouverts pour les communications car le port qui sera utilisé n'est pas connu.
Vous pouvez ignorer ce problème en forçant Developer for System z à utiliser des ports connus pour la connexion secondaire en définissant un élément _RSE_PORTRANGE unique par système et en vous assurant que les plages de ports utilisées sont réservées à l'utilisation de Developer for System z sur tous les systèmes. Pour cela, vous devez disposer de l'APAR TCP/IP PM63379.
Pour garantir que TCP/IP dirige la connexion secondaire vers le système correct, Developer for System z doit utiliser une plage de ports unique sur chaque système. Cela implique que vous ne pouvez pas utiliser de configuration identique partagée pour les systèmes car _RSE_PORTRANGE dans rsed.envvars doit être unique. Pour savoir comment configurer plusieurs serveurs avec différents fichiers de configuration tout en utilisant le même code, voir Niveaux de logiciels identiques, fichiers de configuration différents dans Exécution de plusieurs instances. Vous devez utiliser un document maître de rsed.envvars et un script pour régler et copier cet élément dans une configuration spécifique au système afin de garantir que le fichier reste identique dans les différents systèmes.
$ oedit /etc/rdz/rsed.envvars
-> add the following at the END:
# -- NEEDED TO FIND THE REMAINING CONFIGURATION FILES
CFG_BASE=/etc/rdz
CLASSPATH=.:$CFG_BASE:$CLASSPATH
# --
$ oedit /etc/rdz/update.sh
$ chmod 755 /etc/rdz/update.sh
#! /bin/sh
# Licensed materials - Property of IBM
# 5724-T07 Copyright IBM Corp. 2012
# clone rsed.envvars and set PORTRANGE for use with RDz & DDVIPA
file=rsed.envvars #; echo file $file
sys=${1:-$(sysvar SYSNAME)} #; echo sys $sys
dir=$(dirname $0) #; echo dir $dir
# if sysname has a special char, precede it with \ (eg. SYS\$1)
case "$sys" in # #### CUSTOMIZE THIS SECTION ####
"SYS1") range=8108-8118;;
"SYS2") range=8119-8129;;
esac #; echo range $range
echo "setting port range $range for $sys using $dir/$file"
if test ! $range ; then
echo ERROR: no port range defined for $sys ; exit 12 ; fi
if test ! -e $dir/$file ; then
echo ERROR: file $dir/$file does not exist ; exit 12 ; fi
if test ! -d $dir/$sys ; then
echo ERROR: directory $dir/$sys does not exist ; exit 12 ; fi
mv $dir/$sys/$file $dir/$sys/prev.$file 2>/dev/null
sed="/_RSE_PORTRANGE/s/.*/_RSE_PORTRANGE=$range/"
sed "$sed" $dir/$file > $dir/$sys/$file
if test ! -s $dir/$sys/$file ; then
echo ERROR creating $dir/$sys/$file, restoring backup
mv $dir/$sys/prev.$file $dir/$sys/$file ; exit 8 ; fi
$ mkdir /etc/rdz/SYS1 /etc/rdz/SYS2
$ /etc/rdz/update.sh SYS1
setting port range 8108-8118 for SYS1 using
/etc/rdz/rsed.envvars
$ /etc/rdz/update.sh SYS2
setting port range 8119-8129 for SYS2 using
/etc/rdz/rsed.envvars
// CNFG='/etc/rdz/&SYSNAME.'
PORTRange 8108 22 RSED* ; 8108-8129 - Developer for System z
; - secondary connection
Comme cela est décrit dans Flux de connexion, la plage de ports dans _RSE_PORTRANGE peut être de petite taille. Le serveur RSE n'a pas exclusivement besoin du port pendant la durée de la connexion client. Aucun autre serveur RSE ne peut établir une liaison avec le port que dans l'intervalle de temps entre la liaison (du serveur) et la connexion (du client). Cela signifie que la plupart des connexions utiliseront le premier port de la plage, les autres valeurs de la plage servant de mémoire tampon dans le cas de plusieurs connexions simultanées.
Dans l'exemple de configuration suivant, il existe deux systèmes z/OS, SYS1 et SYS2, qui font partie d'un sysplex. Le système SYS1 est défini comme le système qui héberge normalement le Sysplex Distributor de l'adressage distribué Developer for System z.
Après avoir défini l'adressage distribué DVIPA, Developer for System z peut être démarré sur les systèmes pour équilibrer les connexions client entre les systèmes. Le moniteur de travaux JES interagit uniquement avec le RSE local et ne nécessite donc pas de configuration DVIPA. Les clients se connecteront au port 4035 à l'adresse IP 10.10.10.1.
IPCONFIG
SYSPLEXRouting
; SYSPLEXROUTING est nécessaire, car cette pile nécessite la communication sysplex
DYNAMICXCF 9.9.9.1 255.255.255.0 1
; DYNAMICXCF définit l'unité/la liaison avec l'adresse de base 9.9.9.1, le cas
échéant IGNORERedirect
VIPADYNAMIC
VIPADEFINE 255.255.255.0 10.10.10.1
; VIPADEFINE définit 10.10.10.1 comme DVIPA sur SYS1 pour RDz
VIPADISTRIBUTE DEFINE
; VIPADISTRIBUTE convertit 10.10.10.1 en adresse distribuée DVIPA : doit correspondre
à SYS2
SYSPLEXPORTS ; RDz prérequis
DISTMETHOD BASEWLM ; BASEWLM ou ROUNDROBIN
10.10.10.1 ; Adresse DVIPA utilisée par les clients RDz
PORT 4035 ; Port utilisé par les clients RDz
DESTIP 9.9.9.1 9.9.9.2 ; RDz actif sur SYS1 et SYS2
ENDVIPADYNAMIC
IPCONFIG
SYSPLEXRouting
; SYSPLEXROUTING est nécessaire, car cette pile nécessite la communication sysplex
DYNAMICXCF 9.9.9.2 255.255.255.0 1
; DYNAMICXCF définit l'unité/la liaison avec l'adresse de base 9.9.9.2, le cas échéant
IGNORERedirect
VIPADYNAMIC
VIPABACKUP 255.255.255.0 10.10.10.1
; VIPABACKUP définit 10.10.10.1 comme adresse de secours DVIPA sur SYS2 pour RDz
VIPADISTRIBUTE DEFINE
; VIPADISTRIBUTE convertit 10.10.10.1 en adresse distribuée DVIPA : doit correspondre
à SYS1
SYSPLEXPORTS ; RDz prérequis
DISTMETHOD BASEWLM ; BASEWLM ou ROUNDROBIN
10.10.10.1 ; Adresse DVIPA utilisée par les clients RDz
PORT 4035 ; Port utilisé par les clients RDz
DESTIP 9.9.9.1 9.9.9.2 ; RDz actif sur SYS1 et SYS2
ENDVIPADYNAMIC
Contrairement aux applications z/OS traditionnelles, Developer for System z n'est pas une application monolithique qui peut être identifiée facilement au niveau du Workload Manager (WLM). Les différents composants de Developer for System z interagissent pour offrir au client un accès à des services et des données d'hôte. Comme décrit au Description de Developer for System z, certains de ces services sont actifs dans différents espaces adresse; ce qui se traduit par différentes classifications WLM.
La Figure 13 montre la présentation de base des sous-systèmes par l'intermédiaire desquels les charges de travail de Developer for System z sont présentées au gestionnaire WLM.
ADM (Application Deployment Manager) est actif dans une région CICS et suivra donc les règles de classification CICS dans le gestionnaire WLM.
Le démon RSE (RSED), le gestionnaire de débogage (DBGMGR) et le moniteur de travaux JES (JMON) sont des tâches démarrées de Developer for System z (ou des travaux par lots à exécution longue), chacun avec leur espace adresse individuel.
Comme nous l'avons documenté dans RSE comme application Java, le démon RSE génère un processus enfant pour chaque serveur de pools d'unités d'exécution RSE (qui prend en charge un nombre variable de clients). Chaque pool d'unités d'exécution est actif dans un espace adresse distinct (à l'aide d'un initiateur z/OS UNIX, BPXAS). Puisqu'il s'agit de processus générés, leur classification s'effectue d'après les règles de classification WLM OMVS, mais pas selon les règles de classification des tâches démarrées.
Les clients qui sont actifs dans un pool d'unités d'exécution peuvent créer une multitude d'autres espaces adresse, selon les actions menées par les utilisateurs. Selon la configuration de Developer for System z, certaines charges de travail, comme un service de Commandes TSO (TSO cmd) ou CARMA, peuvent s'exécuter dans des sous-systèmes différents.
Les espaces adresse répertoriés dans la Figure 13 restent dans le système suffisamment longtemps pour être visibles, mais sachez qu'en raison de la conception de z/OS UNIX, il existe aussi des espaces adresses temporaires de durée de vie courte. Ces espaces adresse temporaires sont actifs dans le sous-système OMVS.
Notez que tandis que les pools d'unités d'exécution utilisent le même ID utilisateur et un nom de travail similaire au démon RSE, tous les espaces adresse démarrés par un pool d'unités d'exécution appartiennent à l'ID utilisateur du client ayant demandé l'action. L'ID utilisateur du client est aussi utilisé comme (partie du) nom de travail pour tous les espaces adresse basés sur OMVS et déclarés par le pool d'unités d'exécution.
D'autres espaces adresse sont créés par d'autres services qu'utilise Developer for System z, tels que FMNCAS (File Manager) ou z/OS UNIX REXEC (génération USS).
WLM utilise des règles de classification pour mapper un travail entrant le système en une classe de service. Cette classification repose sur des qualificateurs de travaux. Le premier qualificateur (obligatoire) est le type de sous-système qui reçoit la demande de travail. Le Tableau 14 répertorie les types de sous-systèmes qui peuvent recevoir des charges de travail de Developer for System z.
Type de sous-système | Description du travail |
---|---|
ASCH | Les demandes de travaux incluent tous les programmes de transactions APPC planifiés par le planificateur de transactions APPC/MVS fourni par IBM, ASCH. |
CICS | Les demandes de travaux incluent toutes les transactions traitées par CICS. |
JES | Les demandes de travaux incluent tous les travaux initiés par JES2 ou JES3. |
OMVS | Les demandes de travaux incluent un travail traité dans des espaces adresse enfant en parallèle à des services système z/OS UNIX. |
STC | Les demandes de travaux incluent tous les travaux initiés par les commandes START et MOUNT. STC inclut aussi des espaces adresse de composants système. |
Le Tableau 15 répertorie des qualificateurs supplémentaires que vous pouvez utiliser pour attribuer une charge de travail à une classe de service spécifique. Pour plus d'informations sur les qualificateurs répertoriés, voir MVS Planning: Workload Management (SA22-7602).
ASCH | CICS | JES | OMVS | STC | ||
---|---|---|---|---|---|---|
AI | Comptabilité des informations | x | x | x | x | |
LU | Nom de l'unité logique (*) | x | ||||
PF | Effectuer (*) | x | x | |||
PRI | Priorité | x | ||||
SE | Nom de l'environnement de planification | x | ||||
SSC | Nom de collection du sous-système | x | ||||
SI | Instance du sous-système (*) | x | x | |||
SPM | Paramètre du sous-système | x | ||||
PX | Nom Sysplex | x | x | x | x | x |
SY | Nom du système (*) | x | x | x | ||
TC | Classe Transaction/travail (*) | x | x | |||
TN | Nom Transaction/travail (*) | x | x | x | x | x |
UI | ID utilisateur (*) | x | x | x | x | x |
Comme nous l'avons documenté dans Classification des charges de travail, Developer for System z crée différents types de charges de travail sur votre système. Ces différentes tâches communiquent entre elles, ce qui implique que le temps écoulé réel devienne important pour éviter des problèmes de délai d'attente lors des connexions entre les tâches. En conséquence, une tâche Developer for System z doit être placée dans des classes de services de hautes performances avec une priorité élevée.
Une révision, et probablement une mise à jour, de vos objectifs WLM actuels est donc recommandée, notamment s'il agit de charges de travail OMVS critique en temps ou nouvelles des magasins MVS traditionnels.
Le Tableau 16 répertorie les espaces adresse utilisés par Developer for System z. z/OS UNIX remplace "x" dans la colonne "Nom de la tâche" par un nombre aléatoire comportant un seul chiffre.
Description | Nom de la tâche | Charge de travail |
---|---|---|
Gestionnaire de débogage | DBGMGR | STC |
Moniteur de travaux JES | JMON | STC |
Démon RSE | RSED | STC |
Pool d'unités d'exécution RSE | RSEDx | OMVS |
Passerelle client ISPF (service Commandes TSO et SCLMDT) | <id utilisateur>x | OMVS |
Service Commandes TSO (APPC) | FEKFRSRV | ASCH |
CARMA (lot) | CRA<port> | JES |
CARMA (crastart) | <id utilisateur>x | OMVS |
CARMA (passerelle client ISPF) | <id utilisateur> et <id utilisateur>x | OMVS |
Génération MVS (travail par lots) | * | JES |
Génération z/OS UNIX (commandes shell) | <id utilisateur>x | OMVS |
Interpréteur de commandes de z/OS UNIX | <id utilisateur> | OMVS |
Gestionnaire de déploiement d'application | CICSTS | CICS |
Toutes les tâches démarrées de Developer for System z, démon RSE et moniteur de travaux JES, répondent à des demandes client en temps réel.
Description | Nom de la tâche | Charge de travail |
---|---|---|
Moniteur de travaux JES | JMON | STC |
Gestionnaire de débogage | DBGMGR | STC |
Démon RSE | RSED | STC |
Le moniteur de travaux JES fournit tous les services liés à JES comme la soumission de travaux, la consultation de fichiers spoule et l'exécution de commandes de l'opérateur JES. Vous devez indiquer un objectif de vitesse et de hautes performances sur une période, car la tâche ne signale pas les transactions individuelles à WLM. L'usage des ressources dépend fortement des actions des utilisateurs et donc fluctuera, mais on s'attend à être de type minimal à modéré.
Le gestionnaire de débogage fournit des services pour connecter les programmes à déboguer aux clients qui les déboguent. Vous devez indiquer un objectif de vitesse et de hautes performances sur une période, car la tâche ne signale pas les transactions individuelles à WLM. L'usage des ressources dépend fortement des actions des utilisateurs et donc fluctuera, mais on s'attend à être de type minimal.
Le démon RSE gère les connexions et authentification des clients ainsi que les différents pools d'unités d'exécution RSE. Vous devez indiquer un objectif de vitesse et de hautes performances sur une période, car la tâche ne signale pas les transactions individuelles à WLM. On s'attend à une utilisation des ressources de type modéré, avec un pic au début de la journée de travail.
Les charges de travail OMVS peuvent être réparties en deux groupes, les pool d'unités d'exécution RSE et tout le reste. Ceci parce qu'à l'exception des pools d'unités d'exécution, toutes les charges de travail utilisent l'ID utilisateur du client comme base pour le nom de l'espace adresse. (z/OS UNIX remplace "x" dans la colonne "Nom de la tâche" par un nombre aléatoire comportant un seul chiffre.)
Description | Nom de la tâche | Charge de travail |
---|---|---|
Pool d'unités d'exécution RSE | RSEDx | OMVS |
Passerelle client ISPF (service Commandes TSO et SCLMDT) | <id utilisateur>x | OMVS |
CARMA (crastart) | <id utilisateur>x | OMVS |
CARMA (passerelle client ISPF) | <id utilisateur> et <id utilisateur>x | OMVS |
Génération z/OS UNIX (commandes shell) | <id utilisateur>x | OMVS |
Interpréteur de commandes de z/OS UNIX | <id utilisateur> | OMVS |
Un pool d'unités d'exécution RSE est comme le coeur et le cerveau de Developer for System z. Presque toutes les données passent par là, tandis que les logiciels de fouille de données (unités d'exécution spécifiques de l'utilisateur) à l'intérieur du pool d'unités d'exécution contrôlent les actions de la plupart des autres tâches liées à Developer for System z. Vous devez indiquer un objectif de vitesse et de hautes performances sur une période, car la tâche ne signale pas les transactions individuelles à WLM. L'usage des ressources dépend fortement des actions des utilisateurs et donc fluctuera, mais on s'attend à être de type substantiel.
Les charges de travail restantes finiront toutes par aboutir dans la même classe de service en raison d'une convention commune d'attribution de nom d'espace adresse. Vous devez indiquer un objectif à périodes multiples pour cette classe de service. Les premières périodes doivent être des objectifs de temps de réponse percentiles à hautes performances, tandis que la dernière période doit avoir un objectif de vitesse à performances modérées. Certaines charges de travail, comme une passerelle client ISPF, signaleront des transactions individuelles et d'autres non.
La passerelle client ISPF est un service ISPF appelé par Developer for System z pour exécuter des commandes TSO et ISPF non-interactives. Ceci inclut des commandes explicites émises par le client ainsi que des commandes implicites émises par Developer for System z, comme l'obtention d'une liste de membres PDS. L'usage des ressources dépend fortement des actions des utilisateurs et donc fluctuera, mais on s'attend à être de type minimal.
CARMA est un serveur Developer for System z facultatif qui permet d'interagir avec des gestionnaires de configuration logicielle (SCM) basés sur l'hôte, comme CA Endevor® SCM. Developer for System z autorise différentes méthodes de démarrage pour un serveur CARMA, dont certaines deviennent une charge de travail OMVS. L'usage des ressources dépend fortement des actions des utilisateurs et donc fluctuera, mais on s'attend à être de type minimal.
Lorsqu'un client initie une génération pour un projet z/OS UNIX, z/OS UNIX REXEC (ou SSH) démarre une tâche qui exécute plusieurs commandes shell z/OS UNIX pour effectuer la génération. L'utilisation des ressources dépend fortement des actions des utilisateurs et donc fluctuera, mais on s'attend à être de modéré à substantiel, selon la taille du projet.
Cette charge de travail traite les commande shell z/OS UNIX shell émises par le client. L'usage des ressources dépend fortement des actions des utilisateurs et donc fluctuera, mais on s'attend à être de type minimal.
Developer for System z utilise les processus de traitement par lots gérés par JES de différentes manières. L'usage le plus classique concerne les générations MVS dans lesquelles un travail est soumis et contrôlé pour déterminer quand il prend fin. Toutefois, Developer for System z pourrait aussi démarrer un serveur CARMA dans un traitement par lots et communiquer avec celui-ci via TCP/IP.
Description | Nom de la tâche | Charge de travail |
---|---|---|
CARMA (lot) | CRA<port> | JES |
Génération MVS (travail par lots) | * | JES |
CARMA est un serveur Developer for System z facultatif qui permet d'interagir avec des gestionnaires de configuration logicielle (SCM) basés sur l'hôte, comme CA Endevor® SCM. Developer for System z autorise différentes méthodes de démarrage pour un serveur CARMA, dont certaines deviennent une charge de travail JES. Vous devez indiquer un objectif de vitesse et de hautes performances sur une période, car la tâche ne signale pas les transactions individuelles à WLM. L'usage des ressources dépend fortement des actions des utilisateurs et donc fluctuera, mais on s'attend à être de type minimal.
Dans les versions actuelles de Developer for System z, la passerelle client ISPF permet l'exécution de commandes TSO et ISPF non-interactive. Pour des raisons historiques, Developer for System z prend également en charge l'exécution de ces commandes via une transaction APPC. Notez que la méthode APPC est obsolète.
Description | Nom de la tâche | Charge de travail |
---|---|---|
Service Commandes TSO (APPC) | FEKFRSRV | ASCH |
Developer for System z peut démarrer le service Commandes TSO peut être démarré comme une transaction APPC pour exécuter des commandes TSO et ISPF non-interactive. Ceci inclut des commandes explicites émises par le client ainsi que des commandes implicites émises par Developer for System z, comme l'obtention d'une liste de membres PDS. Vous devez indiquer un objectif à périodes multiples pour cette classe de service. Pour les premières périodes, vous devez indiquer des objectifs de temps de réponse percentiles de hautes performances. Pour la dernière période, vous devez indiquer un objectif de vitesse à performances modérées. L'usage des ressources dépend fortement des actions des utilisateurs et donc fluctuera, mais on s'attend à être de type minimal.
Le gestionnaire de déploiement d'application est un serveur Developer for System z facultatif qui est actif au sein d'une région CICS Transaction Server.
Description | Nom de la tâche | Charge de travail |
---|---|---|
Gestionnaire de déploiement d'application | CICSTS | CICS |
Le serveur facultatif du gestionnaire de déploiement d'application qui est actif au sein d'une région CICSTS, vous permet de décharger en toute sécurité des tâches de gestion CICSTS pour les développeurs de logiciel. L'usage des ressources dépend fortement des actions des utilisateurs et donc fluctuera, mais on s'attend à être de type minimal. Le type de classe de service que vous devez utiliser dépend des autres transactions actives dans cette région CICS et il n'est donc pas abordé en détail.
L'objectif est défini sur une classe de service qui gère des espaces adresse CICS. Vous ne pouvez utiliser qu'un objectif de vitesse d'exécution pour cette classe de service. Le gestionnaire WLM utilise les règles de classification JES ou STC pour les espaces adresse, mais pas les règles de classification de sous-système CICS pour les transactions.
Vous pouvez définir un objectif de temps de réponse dans une classe de service attribuée à une transaction unique ou à un groupe de transactions. Le gestionnaire WLM utilise les règles de classification JES ou STC pour les espaces adresse et les règles de classification de sous-système CICS pour les transactions.
Comme indiqué dans Description de Developer for System z, RSE (Remote Systems Explorer, Explorateur de systèmes distants) est le coeur de Developer for System z. Pour gérer les connexions et charges de travail provenant des clients, RSE est composé d'un espace adresse de démon, qui permet de contrôler les espaces adresse du groupe d'unités d'exécution. Le démon agit comme un point focal pour la connexion et la gestion, alors que les pools d'unités d'exécution traitent les charges de travail du client.
RSE devient une cible privilégiée d'optimisation de la configuration de Developer for System z. Toutefois, la gestion de centaines d'utilisateurs, chacun utilisant au moins 17 unités d'exécution, d'une certaine quantité de mémoire et éventuellement d'un ou de plusieurs espaces adresse implique de configurer correctement Developer for System z et z/OS.
Utilisez les informations présentées dans cette section pour estimer l'utilisation normale et optimale des ressources par Developer for System z, de manière à pouvoir planifier la configuration du système en conséquence.
Lors de l'utilisation des nombres et formules présentés dans cette section pour définir les valeurs des limites du système, n'oubliez pas que vous utilisez des estimations assez précises. Lors de la définition des limites du système, prévoyez une marge suffisante afin de permettre aux tâches temporaires, aux autres tâches ou aux utilisateurs se connectant plusieurs fois à l'hôte simultanément d'utiliser les ressources (au moyen, par exemple, de RSE et TN3270).
Tâche démarrée | Espaces adresses | Processus | Unités d'exécution |
---|---|---|---|
JMON | 1 | 1 | 3 |
DBGMGR | 1 | 1 | 4 |
RSED | 1 | 3 | 16 |
RSEDx | (a) 1 + 2 | 1 + 3 | 1 + 14 |
Logiciels requis | Espaces adresses | Processus | Unités d'exécution |
---|---|---|---|
Passerelle client ISPF | 1 | 2 | 4 |
APPC | 1 | 1 | 2 |
Action de l'utilisateur | Espaces adresses ID utilisateur |
Processus ID utilisateur |
Unités d'exécution |
||
---|---|---|---|---|---|
Connexion | - | - | - | 17 | 1 |
Temporisateur pour le délai d'inactivité | - | - | - | 1 | - |
Rechercher | - | - | - | 1 | - |
Développement de PDS(E) | ISPF | ISPF | ISPF | - | - |
Ouverture du fichier | ISPF | ISPF | ISPF | 1 | - |
Commande TSO | ISPF | ISPF | ISPF | - | - |
Interpréteur de commandes de z/OS UNIX | 1 | 1 | 1 | 6 | - |
Génération MVS | 1 | - | - | - | - |
Génération z/OS UNIX | 3 | 3 | 3 | - | - |
CARMA (lot) | 1 | 1 | 2 | 1 | - |
CARMA (crastart) | 1 | 1 | 2 | 1 | - |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
CARMA (ispf) | 4 | 4 | 7 | 5 | - |
SCLMDT | ISPF | ISPF | ISPF | - | - |
Nombre | Description | Nom de la tâche | Partagé | Se termine après |
---|---|---|---|---|
1 | Moniteur de travaux JES | JMON | Oui | Jamais |
1 | Gestionnaire de débogage | DBGMGR | Oui | Jamais |
1 | Démon RSE | RSED | Oui | Jamais |
1 | Démon RSE avec des droits APF | RSEDx | Oui | Jamais |
(a) | Pool d'unités d'exécution RSE | RSEDx | Oui | Jamais |
(a) | Pool d'unités d'exécution RSE avec des droits APF | RSEDx | Oui | Jamais |
lu | Passerelle client ISPF (service Commandes TSO et SCLMDT) | <id utilisateur>x | Non | 15 minutes ou déconnexion de l'utilisateur |
lu | Service Commandes TSO (APPC) | FEKFRSRV | Non | 60 minutes ou déconnexion de l'utilisateur |
lu | CARMA (lot) | CRA<port> | Non | 7 minutes ou déconnexion de l'utilisateur |
lu | CARMA (crastart) | <id utilisateur>x | Non | 7 minutes ou déconnexion de l'utilisateur |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
4u | CARMA (ispf, obsolète) | (1)<id utilisateur> ou (3)<id utilisateur>x | Non | 7 minutes ou déconnexion de l'utilisateur |
(b) | Utilisation de la passerelle client ISPF simultanée par 1 utilisateur | <id utilisateur>x | Non | Fin de la tâche |
1u | Génération MVS (travail par lots) | * | Non | Fin de la tâche |
3u | Génération z/OS UNIX (commandes shell) | <id utilisateur>x | Non | Fin de la tâche |
1u | Interpréteur de commandes de z/OS UNIX | <id utilisateur> | Non | Déconnexion de l'utilisateur |
X | SCLMDT | TSO au moyen de la passerelle client | TSO au moyen d'APPC |
---|---|---|---|
1 | Non | Non | Oui |
1 | Non | Oui | Non |
1 | Oui | Oui | Non |
Y | |
---|---|
0 | Pas de CARMA |
1 | CARMA (lot) |
1 | CARMA (crastart) |
![]() ![]() |
![]() ![]() |
4 | CARMA (ispf, obsolète) |
Adresse | Limite | Ressources affectées |
---|---|---|
rsed.envvars | maximum.threadpool.process | Limite le nombre de pools d'unités d'exécution RSE |
IEASYMxx | MAXUSER | Limite le nombre d'espaces adresse |
ASCHPMxx | MAX | Limite le nombre de demandeurs APPC pour le service Commandes TSO (APPC) |
Processus | Espaces adresses | Description | ID utilisateur |
---|---|---|---|
1 | 1 | Moniteur de travaux JES | STCJMON |
1 | 1 | Gestionnaire de débogage | STCDBM |
3 | 1 | Démon RSE | STCRSE |
1 | 1 | Démon RSE avec des droits APF | STCRSE |
2 | (a) | Pool d'unités d'exécution RSE | STCRSE |
1 | (a) | Pool d'unités d'exécution RSE avec des droits APF | STCRSE |
2 | (b) | Passerelle client ISPF (service Commandes TSO et SCLMDT) | <id utilisateur> |
2 | (a) | Pool d'unités d'exécution RSE | STCRSE |
1 | 1u | Service Commandes TSO (APPC) | <id utilisateur> |
1 | 1u | CARMA (lot) | <id utilisateur> |
1 | 1u | CARMA (crastart) | <id utilisateur> |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
1 | 1u | CARMA (ispf, obsolète) | <id utilisateur> |
1 | 3u | Génération z/OS UNIX (commandes shell) | <id utilisateur> |
1 | 1u | Interpréteur de commandes de z/OS UNIX | <id utilisateur> |
(5) | (u) | SCLM Developer Toolkit | <id utilisateur> |
X | SCLMDT | TSO au moyen de la passerelle client | TSO au moyen d'APPC |
---|---|---|---|
1 | Non | Non | Oui |
2 | Non | Oui | Non |
7 | Oui | Oui | Non |
Y | |
---|---|
0 | Pas de CARMA |
1 | CARMA (lot) |
1 | CARMA (crastart) |
![]() ![]() |
![]() ![]() |
4 | CARMA (ispf, obsolète) |
Adresse | Limite | Ressources affectées |
---|---|---|
BPXPRMxx | MAXPROCSYS | Limite le nombre de processus |
BPXPRMxx | MAXPROCUSER | limite le nombre de processus par UID z/OS UNIX |
Segment OMVS | PROCUSERMAX | Limite le nombre de processus pour un ID utilisateur |
Unités d'exécution |
ID utilisateur | Description | ||
---|---|---|---|---|
RSEDx | Actif | Amorce | ||
- | (f) 3 + 1u | - | STCJMON | Moniteur de travaux JES |
- | 4 | - | STCDBM | Gestionnaire de débogage |
- | 14 | 2 | STCRSE | Démon RSE |
- | 1 | - | STCRSE | Démon RSE avec des droits APF |
(a,g) 12 + 8u | - | (a) 1 | STCRSE | Pool d'unités d'exécution RSE avec des logiciels de fouille de données à unité d'exécution unique |
(a,g) 12 + 19u | - | (a) 1 | STCRSE | Pool d'unités d'exécution RSE avec des logiciels de fouille de données à unités d'exécutions multiples |
- | (a) 1 | - | STCRSE | Pool d'unités d'exécution RSE avec des droits APF |
- | (b) 4u | (b) 1u | <id utilisateur> | Passerelle client ISPF (service Commandes TSO et SCLMDT) |
- | 2u | - | <id utilisateur> | Service Commandes TSO (APPC) |
1u | 2u | - | STCRSE et <id utilisateur> | CARMA (lot) |
![]() ![]() |
2u | - | STCRSE et <id utilisateur> | CARMA (crastart) |
![]() ![]() ![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
5u | 4u | 3u | STCRSE et <id utilisateur> | CARMA (ispf, obsolète) |
- | (c) 1u | 2u | <id utilisateur> | Génération z/OS UNIX (commandes shell) |
6u | 1u | - | STCRSE et <id utilisateur> | Interpréteur de commandes de z/OS UNIX |
(d) 1 | - | - | STCRSE | Télécharger |
(e) 1 | - | - | STCRSE | Rechercher |
- | (5) | - | <id utilisateur> | SCLM Developer Toolkit |
1u | - | - | STCRSE | Temporisateur pour le délai d'inactivité |
X | SCLMDT | TSO au moyen de la passerelle client | TSO au moyen d'APPC | Délai d'attente |
---|---|---|---|---|
0 | Non | Non | Oui | Non |
0 | Non | Oui | Non | Non |
0 | Oui | Oui | Non | Non |
1 | Non | Non | Oui | Oui |
1 | Non | Oui | Non | Oui |
1 | Oui | Oui | Non | Oui |
Y | |
---|---|
0 | Pas de CARMA |
1 | CARMA (lot) |
![]() ![]() |
CARMA (crastart) |
![]() ![]() ![]() ![]() |
![]() ![]() |
5 | CARMA (ispf, obsolète) |
Adresse | Limite | Ressources affectées |
---|---|---|
Segment OMVS | THREADSMAX | Limite le nombre d'unités d'exécution pour un ID utilisateur |
BPXPRMxx | MAXTHREADS | Limite le nombre d'unités d'exécution d'un processus. |
BPXPRMxx | MAXTHREADTASKS | Limite le nombre de tâches MVS d'un processus. |
BPXPRMxx | MAXASSIZE | Limite la taille d'espace adresse, et donc la mémoire disponible pour les blocs de contrôle liés à l'unité d'exécution. |
rsed.envvars | Xmx | Définit la taille maximale de segment de mémoire Java. Cette mémoire est réservée. Elle n'est donc plus disponible pour les blocs de contrôle liés à l'unité d'exécution. |
rsed.envvars | maximum.clients | Limite le nombre de clients (et donc leurs unités d'exécution) dans un pool d'unités d'exécution RSE. |
rsed.envvars | maximum.threads | Limite le nombre d'unités d'exécution client dans un pool d'unités d'exécution RSE. |
FEJJCNFG | MAX_THREADS | Limite le nombre d'unités d'exécution dans le moniteur de travaux JES. |
L'utilisation des ressources documentée dans les sections précédentes est permanente pour le cycle de vie de Developer for System z ou semi-permanente pour certaines tâches spécifiques des utilisateurs.
Unités d'exécution |
ID utilisateur | Description | ||
---|---|---|---|---|
RSEDx | Actif | Amorce | ||
- | (f) 3 + 1u | - | STCJMON | Moniteur de travaux JES |
- | 4 | - | STCDBM | Gestionnaire de débogage |
- | 14 | 2 | STCRSE | Démon RSE |
- | 1 | - | STCRSE | Démon RSE avec des droits APF |
(a,g) 12 + 8u | - | (a) 1 | STCRSE | Pool d'unités d'exécution RSE avec des logiciels de fouille de données à unité d'exécution unique |
(a,g) 12 + 19u | - | (a) 1 | STCRSE | Pool d'unités d'exécution RSE avec des logiciels de fouille de données à unités d'exécutions multiples |
- | (a) 1 | - | STCRSE | Pool d'unités d'exécution RSE avec des droits APF |
- | (b) 4u | (b) 1u | <id utilisateur> | Passerelle client ISPF (service Commandes TSO et SCLMDT) |
- | 2u | - | <id utilisateur> | Service Commandes TSO (APPC) |
1u | 2u | - | STCRSE et <id utilisateur> | CARMA (lot) |
![]() ![]() |
2u | - | STCRSE et <id utilisateur> | CARMA (crastart) |
![]() ![]() ![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
5u | 4u | 3u | STCRSE et <id utilisateur> | CARMA (ispf, obsolète) |
- | (c) 1u | 2u | <id utilisateur> | Génération z/OS UNIX (commandes shell) |
6u | 1u | - | STCRSE et <id utilisateur> | Interpréteur de commandes de z/OS UNIX |
(d) 1 | - | - | STCRSE | Télécharger |
(e) 1 | - | - | STCRSE | Rechercher |
- | (5) | - | <id utilisateur> | SCLM Developer Toolkit |
1u | - | - | STCRSE | Temporisateur pour le délai d'inactivité |
X | SCLMDT | TSO au moyen de la passerelle client | TSO au moyen d'APPC | Délai d'attente |
---|---|---|---|---|
0 | Non | Non | Oui | Non |
0 | Non | Oui | Non | Non |
0 | Oui | Oui | Non | Non |
1 | Non | Non | Oui | Oui |
1 | Non | Oui | Non | Oui |
1 | Oui | Oui | Non | Oui |
Y | |
---|---|
0 | Pas de CARMA |
1 | CARMA (lot) |
![]() ![]() |
CARMA (crastart) |
![]() ![]() ![]() ![]() |
![]() ![]() |
5 | CARMA (ispf, obsolète) |
Adresse | Limite | Ressources affectées |
---|---|---|
Segment OMVS | THREADSMAX | Limite le nombre d'unités d'exécution pour un ID utilisateur |
BPXPRMxx | MAXTHREADS | Limite le nombre d'unités d'exécution d'un processus. |
BPXPRMxx | MAXTHREADTASKS | Limite le nombre de tâches MVS d'un processus. |
BPXPRMxx | MAXASSIZE | Limite la taille d'espace adresse, et donc la mémoire disponible pour les blocs de contrôle liés à l'unité d'exécution. |
rsed.envvars | Xmx | Définit la taille maximale de segment de mémoire Java. Cette mémoire est réservée. Elle n'est donc plus disponible pour les blocs de contrôle liés à l'unité d'exécution. |
rsed.envvars | maximum.clients | Limite le nombre de clients (et donc leurs unités d'exécution) dans un pool d'unités d'exécution RSE. |
rsed.envvars | maximum.threads | Limite le nombre d'unités d'exécution client dans un pool d'unités d'exécution RSE. |
FEJJCNFG | MAX_THREADS | Limite le nombre d'unités d'exécution dans le moniteur de travaux JES. |
RSE est une application Java, ce qui signifie que l'utilisation de l'espace de stockage (mémoire) de Developer for System z doit s'appuyer sur deux limites d'allocation de mémoire : la taille de pile Java et la taille de l'espace adresse.
Java offre de nombreux services visant à faciliter le codage des applications Java. L'un de ces services est la gestion de l'espace de stockage.
La gestion de l’espace de stockage Java alloue des blocs d'espace de stockage volumineux et les utilise pour satisfaire les demandes d'espace de stockage de l'application. Cet espace de stockage géré par Java est appelé pile Java. La récupération régulière de place (défragmentation) permet de récupérer l'espace inutilisé dans la pile et de réduire sa taille. Notez que pour économiser des cycles d'unité centrale, l'opération de récupération de place attend généralement que la mémoire occupée soit réellement nécessaire pour s'exécuter, laissant ainsi allouée la mémoire qui n'est plus utilisée (et rejetée) pour une durée plus longue que celle requise.
La taille de pile Java maximale est définie dans rsed.envvars avec la directive Xmx. Si cette directive n'est pas spécifiée, Java utilise une taille par défaut de 512 Mo. Indiquez une valeur de 256 Mo ou supérieure. En mode 64 bits, Java tente d'allouer un segment de mémoire au dessus de 2 Go, libérant ainsi l'espace en-deçà de ce seuil.
Chaque pool d'unités d'exécution RSE (qui gère les actions du client) est une application Java distincte et possède donc une pile Java personnelle. Notez que tous les pools d'unités d'exécution utilisent le même fichier de configuration rsed.envvars et donc la même limite de taille de pile Java.
L’utilisation du pool d'unités d'exécution de la pile Java dépend fortement des actions des clients connectés. Il est nécessaire de surveiller régulièrement l'utilisation de la pile pour définir la limite de taille de pile optimale. Utilisez la commande de l'opérateur modify display process pour surveiller l'utilisation de la pile Java par les pools d'unités d'exécution RSE.
Toutes les applications z/OS, y compris les applications Java, sont actives dans un espace adresse et sont donc liées par les limites de taille de l'espace adresse.
Les pools d'unités d'exécution RSE héritent des limites de taille d'espace adresse provenant du démon RSE. La taille d'espace adresse doit être suffisante pour héberger la pile Java, Java lui-même, les zones de mémoire communes et tous les blocs de contrôle que le système crée pour prendre en charge l'activité du pool d'unités d'exécution (un bloc de contrôle des tâches par unité d'exécution, par exemple). Notez que certaines de ces utilisations de l'espace de stockage usage est inférieure à la ligne 16 Mo. En mode 64 bits, Java tente d'allouer un segment de mémoire au dessus de 2 Go, libérant ainsi l'espace en-deçà de ce seuil.
Il est recommandé de surveiller la taille réelle de l'espace adresse avant de modifier les paramètres qui l'influencent (la modification de la taille de la pile Java ou le nombre d'utilisateurs pris en charge par un seul pool d'unités d'exécution, par exemple). Utilisez les logiciels de surveillance du système pour suivre l'utilisation réelle de l'espace de stockage par Developer for system z. Si vous ne disposez pas de ce type d'outil, vous pouvez utiliser des outils comme la vue SDSF DA ou TASID (un outil d'informations système en l'état disponible sur la page Web ISPF "Support and downloads") afin de rassembler des informations de base.
Notez que le message de console FEK004I de RSE affiche la limite en cours de la taille de la pile Java et de l'espace adresse lors du démarrage.
Le Tableau 33 présente les valeurs utilisées par les clients réels de Developer for System z pour les paramètres clés rsed.envvars ayant une incidence sur l'utilisation de la mémoire.
xmx (segment de mémoire java max) | Nombre maximum de clients | Type principal de développement |
---|---|---|
512 M | 30 | PL/I |
512 M | 10 | COBOL |
384 M | 12 | COBOL |
800 M (64 bits) | 20 | Non spécifié |
Max Heap Size=10MB and private AS Size=1,959MB
startup
BPXM023I (STCRSE)
ProcessId(268 ) Memory Usage(7%) Clients(0)
Jobname Cpu time Storage EXCP
-------- ----------- ------- ----------
JMON 0.01 2740 72
RSED 4.47 32.8M 15910
RSED8 1.15 27.4M 12612
logon 1
BPXM023I (STCRSE)
ProcessId(268 ) Memory Usage(13%) Clients(1)
Jobname Cpu time Storage EXCP
-------- ----------- ------- ----------
JMON 0.01 2864 81
RSED 4.55 32.8M 15980
RSED8 3.72 55.9M 24128
logon 2
BPXM023I (STCRSE)
ProcessId(268 ) Memory Usage(23%) Clients(2)
Jobname Cpu time Storage EXCP
-------- ----------- ------- ----------
JMON 0.02 2944 86
RSED 4.58 32.9M 16027
RSED8 4.20 57.8M 25205
logon 3
BPXM023I (STCRSE)
ProcessId(268 ) Memory Usage(37%) Clients(3)
Jobname Cpu time Storage EXCP
-------- ----------- ------- ----------
JMON 0.02 3020 91
RSED 4.60 32.9M 16076
RSED8 4.51 59.6M 26327
logon 4
BPXM023I (STCRSE)
ProcessId(268 ) Memory Usage(41%) Clients(4)
Jobname Cpu time Storage EXCP
-------- ----------- ------- ----------
JMON 0.02 3108 96
RSED 4.61 32.9M 16125
RSED8 4.77 62.3M 27404
logon 5
BPXM023I (STCRSE)
ProcessId(268 ) Memory Usage(41%) Clients(4)
ProcessId(33554706) Memory Usage(13%) Clients(1)
Jobname Cpu time Storage EXCP
-------- ----------- ------- ----------
JMON 0.03 3184 101
RSED 4.64 32.9M 16229
RSED8 4.78 62.4M 27413
RSED9 4.60 56.6M 24065
Max Heap Size=10MB and private AS Size=1,959MB
startup
BPXM023I (STCRSE)
ProcessId(212 ) Memory Usage(7%) Clients(0)
Jobname Cpu time Storage EXCP
-------- ----------- ------- ----------
JMON 0.01 2736 71
RSED 4.35 32.9M 15117
RSED8 1.43 27.4M 12609
logon
BPXM023I (STCRSE)
ProcessId(212 ) Memory Usage(13%) Clients(1)
Jobname Cpu time Storage EXCP
-------- ----------- ------- ----------
JMON 0.01 2864 80
RSED 4.48 33.0M 15187
RSED8 3.53 53.9M 24125
expand large MVS tree (195 data sets)
BPXM023I (STCRSE)
ProcessId(212 ) Memory Usage(13%) Clients(1)
Jobname Cpu time Storage EXCP
-------- ----------- ------- ----------
JMON 0.01 2864 80
RSED 4.58 33.1M 16094
RSED8 4.28 56.1M 24740
expand small PDS (21 members)
BPXM023I (STCRSE)
ProcessId(212 ) Memory Usage(13%) Clients(1)
Jobname Cpu time Storage EXCP
-------- ----------- ------- ----------
IBMUSER2 0.22 2644 870
JMON 0.01 2864 80
RSED 4.61 33.1M 16108
RSED8 4.40 56.2M 24937
open medium sized member (86 lines)
BPXM023I (STCRSE)
ProcessId(212 ) Memory Usage(13%) Clients(1)
Jobname Cpu time Storage EXCP
-------- ----------- ------- ----------
IBMUSER2 0.22 2644 870
JMON 0.01 2864 80
RSED 4.61 33.1M 16108
RSED8 8.12 62.7M 27044
La plupart des données liées à Developer for System z qui ne sont pas écrites dans une instruction de définition de données sont placées dans un fichier z/OS UNIX. Le programmeur système peut décider des données écrites et de leur destination. Toutefois, il ne contrôle pas la quantité de données écrites.
Par défaut, seuls les erreurs et messages d'avertissement sont consignés dans les fichiers journaux. Ainsi, si tout ce passe comme prévu, ces répertoires ne contiennent que des fichiers vides ou presque vides (sans compter les journaux d'audit).
Vous pouvez activer la consignation des messages d'information (de préférence avec l'aide du point de service IBM), ce qui augmente sensiblement la taille des fichiers journaux.
startup
$ ls -l /var/rdz/logs/server
total 144
-rw-rw-rw- 1 STCRSE STCGRP 33642 Jul 10 12:10 rsedaemon.log
-rw-rw-rw- 1 STCRSE STCGRP 1442 Jul 10 12:10 rseserver.log
logon
$ ls -l /var/rdz/logs/server
total 144
-rw------- 1 STCRSE STCGRP 36655 Jul 10 12:11 rsedaemon.log
-rw------- 1 STCRSE STCGRP 1893 Jul 10 12:11 rseserver.log
$ ls -l /var/rdz/logs/IBMUSER
total 160
-rw------- 1 IBMUSER SYS1 3459 Jul 10 12:11 ffs.log
-rw------- 1 IBMUSER SYS1 0 Jul 10 12:11 ffsget.log
-rw------- 1 IBMUSER SYS1 0 Jul 10 12:11 ffsput.log
-rw------- 1 IBMUSER SYS1 303 Jul 10 12:11 ffslock.log
-rw------- 1 IBMUSER SYS1 7266 Jul 10 12:11 rsecomm.log
logoff
$ ls -l /var/rdz/logs/server
total 80
-rw------- 1 STCRSE STCGRP 36655 Jul 10 12:11 rsedaemon.log
-rw------- 1 STCRSE STCGRP 2208 Jul 10 12:11 rseserver.log
$ ls -l /var/rdz/logs/IBMUSER
total 296
-rw------- 1 IBMUSER SYS1 6393 Jul 10 12:11 ffs.log
-rw------- 1 IBMUSER SYS1 0 Jul 10 12:11 ffsget.log
-rw------- 1 IBMUSER SYS1 0 Jul 10 12:11 ffsput.log
-rw------- 1 IBMUSER SYS1 609 Jul 10 12:11 ffslock.log
-rw------- 1 IBMUSER SYS1 45157 Jul 10 12:11 rsecomm.log
stop
$ ls -l /var/rdz/logs/server
total 80
-rw------- 1 STCRSE STCGRP 36655 Jul 10 12:11 rsedaemon.log
-rw------- 1 STCRSE STCGRP 2490 Jul 10 12:12 rseserver.log
A l'exception de journaux d'audit, les fichiers journaux sont écrasés à chaque redémarrage (pour la tâche démarrée RSE) ou connexion (pour un client), ce qui permet de contrôler la taille totale. Les journaux d'audit sont supprimés lorsque l'intervalle spécifié dans audit.retention.period expire. La directive keep.last.log de rsed.envvars peut changer cela, étant donné qu'elle peut demander à RSE de conserver un exemplaire des fichiers journaux précédents. Les exemplaires plus anciens sont toujours supprimés. Si la directive keep.all.logs dans rsed.envvars est activée, un horodatage est ajouté au nom de tous les journaux et les fichiers sont supprimés lorsque l'intervalle spécifié dans log.retention.period expire.
Un message d'avertissement est envoyé à la console lorsque l'espace disponible dans le système de fichiers qui contient les fichiers journaux commence à manquer. Le message de console (FEK103E) s'affiche régulièrement tant que l'incident lié au manque d'espace n'a pas été résolu. Lorsque le système de fichiers commence à manquer d'espace, RSE tente de supprimer les fichiers journaux existants pour en libérer. Les journaux d'audit ne sont pas concernés par ce processus.
Adresse | Directive | Fonction |
---|---|---|
resecomm.properties | debug_level | Définition du niveau de détails du journal par défaut. |
rsecomm.properties | USER | Activation du niveau de débogage 2 pour des utilisateurs spécifiés. |
rsed.envvars | keep.all.logs | Conservation d'un exemplaire des fichiers journaux précédents avant démarrage/connexion. |
rsed.envvars | keep.last.log | Conservation d'un exemplaire des fichiers journaux précédents avant démarrage/connexion. |
rsed.envvars | enable.audit.log | Conservation d'un trace d'audit des actions du client. |
rsed.envvars | enable.standard.log | Ecriture des flux stdout et stderr du/des pool(s) d'unités d'exécution dans un fichier journal. |
rsed.envvars | DSTORE_TRACING_ON | Activation du journal des actions du magasin de données. |
rsed.envvars | DSTORE_MEMLOGGING_ON | Activation du journal relatif à l'utilisation de la mémoire par le magasin de données. |
Commande d'opérateur | modify rsecommlog <niveau> | Modification dynamique du niveau de détail du journal de rsecomm.log |
Commande d'opérateur | modify rsedaemonlog <niveau> | Modification dynamique du niveau de détail du journal de rsedaemon.log |
Commande d'opérateur | modify rseserverlog <niveau> | Modification dynamique du niveau de détail du journal de rseserver.log |
Commande d'opérateur | modify rsestandardlog {on|off} | Modification dynamique de la mise à jour de std*.*.log |
Commande d'opérateur | modify trace {on|off} USER=userid | Activation du niveau de débogage 2 pour des utilisateurs spécifiés. |
Commande d'opérateur | modify trace {on|off} SERVER=pid | Activation du niveau de débogage 2 pour des utilisateurs spécifiés. |
Commande d'opérateur | modify trace clear | Désactivation de la configuration de trace. |
Commande d'opérateur | modify logs | Collecte les journaux hôte et les informations de configuration |
rsed.envvars | daemon.log | Chemin d'accès au répertoire de base de la tâche démarrée RSE et des journaux d'audit. |
rsed.envvars | user.log | Chemin d'accès au répertoire de base des journaux utilisateur. |
rsed.envvars | CGI_ISPWORK | Chemin d'accès au répertoire de base des journaux d'ISPF Client Gateway |
rsed.envvars | TMPDIR | Répertoire pour les journaux IVP (procédure de vérification d'installation) et la commande de l'opérateur modify logs |
rsed.envvars | _CEE_DMPTARG | Répertoire pour les vidages Java |
Developer for System z, et les logiciels requis (ISPF Client Gateway, par exemple) écrivent également les données temporaires dans /tmp et /var/rdz/WORKAREA. La quantité de données écrites suite aux actions de l'utilisateur n'est pas prévisible. Il est donc recommandé de prévoir un espace disponible suffisant dans les systèmes de fichiers contenant ces répertoires.
Developer for System z tente toujours de nettoyer ces fichiers temporaires, mais le nettoyage manuel, indiqué dans "(Facultatif) Nettoyage de WORKAREA et /tmp" dans Guide de configuration de l'hôte (SC11-6285), peut être réalisé pratiquement à tout moment.
Adresse | Directive | Fonction |
---|---|---|
rsed.envvars | CGI_ISPWORK | Chemin d'accès au répertoire de base des données temporaires. |
rsed.envvars | TMPDIR | Répertoire des données temporaires. |
Les variables d'environnement définies dans rsed.envvars sont utilisées par RSE, Java et z/OS UNIX. Le fichier exemple qui accompagne Developer for System z vise les petites et moyennes installations qui n'ont pas besoin des composants facultatifs de Developer for System z. "rsed.envvars, fichier de configuration RSE" du Guide de configuration de l'hôte (SC11-6285) décrit toutes les variables définies dans l'exemple de fichier, dont certaines qui méritent une attention particulière :
RSE est une application Java, ce qui signifie qu'il est actif dans l'environnement z/OS UNIX. BPXPRMxx peut donc aisément devenir un membre parmlib essentiel, étant donné qu'il contient les paramètres permettant de contrôler l'environnement et les systèmes de fichiers z/OS UNIX. BPXPRMxx est décrit dans le document MVS Initialization and Tuning Reference (SA22-7592). Les directives suivantes sont réputées avoir un impact sur Developer for System z :
Gamme de valeurs : nnnnn est une valeur décimale comprise
entre 5 et 32767.
Valeur par défaut : 900
Gamme de valeurs : nnnnn est une valeur décimale comprise
entre 3 et 32767.
Valeur par défaut : 25
Gamme de valeurs : nnnnnn est une valeur décimale comprise
entre 0 et 100000.
Valeur par défaut : 200
Gamme de valeurs : nnnnn est une valeur décimale comprise
entre 0 et 32768.
Valeur par défaut : 1000
Gamme de valeurs : nnnnn est une valeur décimale comprise
entre 1 et 32767.
Valeur par défaut : 200
Gamme de valeurs : nnnnn est une valeur décimale comprise
entre 10485760 (10 mégaoctets) et 2147483647 (2 gigaoctets).
Valeur par défaut : 209715200 (200 mégaoctets)
Gamme de valeurs : nnnnnn est une valeur décimale comprise
entre 3 et 524287.
Valeur par défaut : 64000
Gamme de valeurs : nnnnn est une valeur décimale comprise
entre 1 et 16777216.
Valeur par défaut : 40960
Utilisez la commande de l'opérateur SETOMVS ou SET OMVS pour augmenter ou diminuer de manière dynamique (jusqu'à l'IPL suivant) la valeur de l'une des variables BPXPRMxx précédentes. Pour apporter une modification permanente, éditez le membre BPXPRMxx qui va être utilisé pour les IPL. Voir le document MVS System Commands (SA22-7627) pour plus d'informations relatives à ces commandes de l'opérateur.
Les définitions suivantes sont des sous-paramètres de l'instruction NETWORK.
Gamme de valeurs : nnnnnnnn est une valeur décimale comprise
entre 0 et 16777215.
Valeur par défaut : 100
Gamme de valeurs : nnnn est une valeur décimale
comprise entre 1 et 4000.
Valeur par défaut : si INADDRANYPORT et INADDRANYCOUNT
ne sont pas spécifiés, la valeur par défaut d'INADDRANYCOUNT est 1000.
Sinon, aucun port n'est réservé (0).
Il est recommandé d'ajouter les définitions suivantes à la carte EXEC dans le JCL des serveurs Developer for System z.
Les variables d'environnement définies dans FEJJCNFG sont utilisées par le moniteur de travaux JES. Le fichier exemple qui accompagne Developer for System z vise les petites et moyennes installations. "FEJJCNFG, Fichier de configuration Moniteur de travaux JES" du Guide de configuration de l'hôte (SC11-6285) décrit toutes les variables définies dans l'exemple de fichier, dont certaines qui méritent une attention particulière :
IEASYSxx contient les paramètres système et est décrit dans le document MVS Initialization and Tuning Reference (SA22-7592). Les directives suivantes sont réputées avoir un impact sur Developer for System z :
Gamme de valeurs : nnnnn est une valeur décimale comprise
entre 0 et 32767. Notez que la somme des valeurs spécifiées
pour les paramètres système MAXUSER, RSVSTRT, et RSVNONR
ne peut pas dépasser 32767.
Valeur par défaut : 255
IVTPRMxx permet d'attribuer une valeur aux paramètres du gestionnaire de stockage des communications (CSM) et est décrit dans le document MVS Initialization and Tuning Reference (SA22-7592). Les directives suivantes sont réputées avoir un impact sur Developer for System z :
Gamme de valeurs : maxfix est une valeur comprise
entre 1024 Ko et 2048 Mo.
Valeur par défaut : 100 Mo
Gamme de valeurs : maxecsa est une valeur comprise
entre 1024 Ko et 2048 Mo.
Valeur par défaut : 100 Mo
Le membre parmlib ASCHPMxx contient des informations de planification pour le programme de transactions ASCH et est décrit dans le document MVS Initialization and Tuning Reference (SA22-7592). Les directives suivantes sont réputées avoir un impact sur Developer for System z :
Gamme de valeurs : nnnnn est une valeur décimale comprise
entre 1 et 64000.
Valeur par défaut : 1
Etant donné que les charges de travail de l'utilisateur peuvent modifier les besoins en ressources système, il est recommandé de contrôler le système régulièrement pour mesurer l'utilisation des ressources, de manière à pouvoir ajuster Rational Developer for System z et les configurations système en fonction des exigences de l'utilisateur. Les commandes suivantes peuvent être utilisées pour faciliter ce processus de contrôle.
FEK004I RseDaemon: Max Heap Size=65MB and private AS Size=1,959MB
f rsed,appl=d p
BPXM023I (STCRSE)
ProcessId(16777456) Memory Usage(33%) Clients(4) Order(1)
f rsed,appl=d p,detail
BPXM023I (STCRSE)
ProcessId(33555087) ASId(002E) JobName(RSED8) Order(1)
PROCESS LIMITS: CURRENT HIGHWATER LIMIT
JAVA HEAP USAGE(%) 10 56 100
CLIENTS 0 25 30
MAXFILEPROC 83 103 64000
MAXPROCUSER 97 99 200
MAXTHREADS 9 14 1500
MAXTHREADTASKS 9 14 1500
f rsed,appl=d p,cpu
BPXM023I (STCRSE)
ProcessId(33555087) ASId(002E) JobName(RSED8) Order(1)
USERID THREAD-ID TCB@ ACC_TIME TAG
STCRSE 0EDE540000000000 005E6B60 822 1/ThreadPoolProcess
STCRSE 0EDE870000000001 005E69C8 001
STCRSE 0EDE980000000002 005E6518 1814
STCRSE 0EDEBA0000000003 005E66B0 2305
STCRSE 0EDECB0000000004 005E62F8 001
STCRSE 0EDEDC0000000005 005E60D8 001
STCRSE 0EDF860000000006 005C2BF8 628 6/ThreadPoolMonitor$Memory
UsageMonitor
STCRSE 0EDF970000000007 005C2D90 003 7/ThreadPoolMonitor
IBMUSER 0EE2C70000000024 005C08B0 050 38/JESMiner
IBMUSER 0EE2B60000000026 005C0690 004 40/FAMiner
IBMUSER 0EE30B0000000027 005C0250 002 41/LuceneMiner
IBMUSER 0EE31C0000000028 005C0030 002 42/CDTParserMiner
IBMUSER 0EE32D0000000029 005BDE00 002 43/MVSLuceneMiner
IBMUSER 0EE33E000000002A 005BDBE0 002 44/CDTMVSParserMiner
La plupart des limites z/OS UNIX qui présentent un intérêt pour Developer for System z peuvent être affichées à l'aide des commandes de l'opérateur. Certaines commandes affichent même l'utilisation réelle et la cote d'alerte haute associées à une limite particulière. Voir le document MVS System Commands (SA22-7627) pour plus d'informations relatives à ces commandes.
d omvs,o
BPXO043I 13.10.16 DISPLAY OMVS 066
OMVS 000D ETC/INIT WAIT OMVS=(M7)
CURRENT UNIX CONFIGURATION SETTINGS:
MAXPROCSYS = 256 MAXPROCUSER = 16
MAXFILEPROC = 256 MAXFILESIZE = NOLIMIT
MAXCPUTIME = 1000 MAXUIDS = 200
MAXPTYS = 256
MAXMMAPAREA = 256 MAXASSIZE = 209715200
MAXTHREADS = 200 MAXTHREADTASKS = 1000
MAXCORESIZE = 4194304 MAXSHAREPAGES = 4096
IPCMSGQBYTES = 2147483647 IPCMSGQMNUM = 10000
IPCMSGNIDS = 500 IPCSEMNIDS = 500
IPCSEMNOPS = 25 IPCSEMNSEMS = 1000
IPCSHMMPAGES = 25600 IPCSHMNIDS = 500
IPCSHMNSEGS = 500 IPCSHMSPAGES = 262144
SUPERUSER = BPXROOT FORKCOPY = COW
STEPLIBLIST =
USERIDALIASTABLE=
SERV_LINKLIB = POSIX.DYNSERV.LOADLIB BPXLK1
SERV_LPALIB = POSIX.DYNSERV.LOADLIB BPXLK1
PRIORITYPG VALUES: NONE
PRIORITYGOAL VALUES: NONE
MAXQUEUEDSIGS = 1000 SHRLIBRGNSIZE = 67108864
SHRLIBMAXPAGES = 4096 VERSION = /
SYSCALL COUNTS = NO TTYGROUP = TTY
SYSPLEX = NO BRLM SERVER = N/A
LIMMSG = NONE AUTOCVT = OFF
RESOLVER PROC = DEFAULT
AUTHPGMLIST = NONE
SWA = BELOW
d omvs,l
BPXO051I 14.05.52 DISPLAY OMVS 904
OMVS 0042 ACTIVE OMVS=(69)
SYSTEM WIDE LIMITS: LIMMSG=SYSTEM
CURRENT HIGHWATER SYSTEM
USAGE USAGE LIMIT
MAXPROCSYS 1 4 256
MAXUIDS 0 0 200
MAXPTYS 0 0 256
MAXMMAPAREA 0 0 256
MAXSHAREPAGES 0 10 4096
IPCMSGNIDS 0 0 500
IPCSEMNIDS 0 0 500
IPCSHMNIDS 0 0 500
IPCSHMSPAGES 0 0 262144 *
IPCMSGQBYTES --- 0 262144
IPCMSGQMNUM --- 0 10000
IPCSHMMPAGES --- 0 256
SHRLIBRGNSIZE 0 0 67108864
SHRLIBMAXPAGES 0 0 4096
La commande affiche les cotes d'alerte hautes et l'utilisation en cours d'un processus individuel lorsque le mot clé PID=processid est également spécifié.
d,omvs,l,pid=16777456
BPXO051I 14.06.28 DISPLAY OMVS 645
OMVS 000E ACTIVE OMVS=(76)
USER JOBNAME ASID PID PPID STATE START CT_SECS
STCRSE RSED8 007E 16777456 67109106 HF---- 20.00.56 113.914
LATCHWAITPID= 0 CMD=java -Ddaemon.log=/var/rdz/logs -
PROCESS LIMITS: LIMMSG=NONE
CURRENT HIGHWATER PROCESS
USAGE USAGE LIMIT
MAXFILEPROC 83 103 256
MAXFILESIZE --- --- NOLIMIT
MAXPROCUSER 97 99 200
MAXQUEUEDSIGS 0 1 1000
MAXTHREADS 9 14 200
MAXTHREADTASKS 9 14 1000
IPCSHMNSEGS 0 0 500
MAXCORESIZE --- --- 4194304
MAXMEMLIMIT 0 0 16383P
d omvs,p
BPXO046I 14.35.38 DISPLAY OMVS 092
OMVS 000E ACTIVE OMVS=(33)
PFS CONFIGURATION INFORMATION
PFS TYPE DESCRIPTION ENTRY MAXSOCK OPNSOCK HIGHUSED
TCP SOCKETS AF_INET EZBPFINI 50000 244 8146
UDS SOCKETS AF_UNIX BPXTUINT 64 6 10
ZFS LOCAL FILE SYSTEM IOEFSCM
14:32.00 RECYCLING
HFS LOCAL FILE SYSTEM GFUAINIT
BPXFTCLN CLEANUP DAEMON BPXFTCLN
BPXFTSYN SYNC DAEMON BPXFTSYN
BPXFPINT PIPE BPXFPINT
BPXFCSIN CHAR SPECIAL BPXFCSIN
NFS REMOTE FILE SYSTEM GFSCINIT
PFS NAME DESCRIPTION ENTRY STATUS FLAGS
TCP41 SOCKETS EZBPFINI ACT CD
TCP42 SOCKETS EZBPFINI ACT
TCP43 SOCKETS EZBPFINI INACT SD
TCP44 SOCKETS EZBPFINI INACT
PFS PARM INFORMATION
HFS SYNCDEFAULT(60) FIXED(50) VIRTUAL(100)
CURRENT VALUES: FIXED(55) VIRTUAL(100)
NFS biod(6)
d omvs,pid=16777456
BPXO040I 15.30.01 DISPLAY OMVS 637
OMVS 000E ACTIVE OMVS=(76)
USER JOBNAME ASID PID PPID STATE START CT_SECS
STCRSE RSED8 007E 16777456 67109106 HF---- 20.00.56 113.914
LATCHWAITPID= 0 CMD=java -Ddaemon.log=/var/rdz/logs -
THREAD_ID TCB@ PRI_JOB USERNAME ACC_TIME SC STATE
0E08A00000000000 005E6DF0 OMVS .927 RCV FU
0E08F00000000001 005E6C58 .001 PTX JYNV
0E09300000000002 005E6AC0 7.368 PTX JYNV
0E0CB00000000008 005C2CF0 OMVS 1.872 SEL JFNV
0E192000000003CE 005A0B70 OMVS IBMUSER 14.088 POL JFNV
0E18D000000003CF 005A1938 IBMUSER .581 SND JYNV
Developer for System z utilise les systèmes de fichiers z/OS UNIX pour stocker les différents types de données (les journaux et fichiers temporaires, par exemple). Utilisez la commande z/OS UNIX df pour connaître le nombre de descripteurs de fichier encore disponibles et la quantité d'espace libre avant la création de la prochaine étendue du fichier HFS ou zFS sous-jacent.
$ df
Mounted on Filesystem Avail/Total Files Status
/tmp (OMVS.TMP) 1393432/1396800 4294967248 Available
/u/ibmuser (OMVS.U.IBMUSER) 1248/1728 4294967281 Available
/usr/lpp/rdz (OMVS.LPP.FEK) 3062/43200 4294967147 Available
/var (OMVS.VAR) 27264/31680 4294967054 Available
Par défaut, Developer for System z tente d'ajouter 30 utilisateurs à un seul pool d'unités d'exécution. Toutefois, nos exigences stipulent que le délai d'attente d'inactivité soit actif. Le Tableau 31 indique qu'une unité d'exécution va être ajoutée par client connecté. Il s'agit d'une unité d'exécution de temporisation qui doit donc être active en permanence. Cela empêche RSE de placer 30 utilisateurs dans un seul pool d'unités d'exécution, étant donné que 10+30*(17+1)=550, et que le paramètre maximum.threads est défini par défaut sur 520.
La valeur de maximum.threads pourrait être augmentée, mais compte tenu de l'obligation de prévoir un segment de mémoire Java moyen de 20 Mo par utilisateur, la valeur de maximum.clients a été abaissée à 25 (10+25*18 = 460). La taille maximale du segment de mémoire Java de 512 Mo (20*25 = 500) est respectée.
Avec 25 clients par pool d'unités d'exécution et la nécessité de prendre en charge 500 connexions, nous savons désormais que nous allons avoir besoin de 20 espaces adresse de pool d'unités d'exécution.
3 + 2*A + N*(x + y + z) + (2 + N*0.01)
3 + 2*20 + 500*1 + 200*1 + 300*1 + (2 + 500*0.01) = 1050
x + y + z
1 + 1 + 1 = 3
6 + 3*A + N*(x + y + z) + (10 + N*0.05)
6 + 3*20 + 500*2 + 200*1 + 300*0 + (10 + 500*0.05) = 1591
4 + 3*A
4 + 3*20 = 64
(x + y + z) + 5*s
(2 + 1 + 0) + 5*0 = 3
12 + N*(19 + x + y + z) + (20 + N*0.1)
12 + 25*(19 + 1 + 4 + 0) + (20 + 25*0.1) = 635
3 + N+ (20 + N*0.1)
3 + 500+ (20 + 500*0.1) = 573
4
4
500 + 3 = 503
Les 3 ID utilisateur supplémentaires sont pour STCJMON, STCDBM, et STCRSE, les ID utilisateur de la tâche démarrée Developer for System z.
non modifié
non modifié
Ce changement est facultatif ; RSE démarrera des nouveaux pools d'unités d'exécution, si nécessaire
1591 au moins, mémoire tampon supplémentaire ajoutée pour les tâches
autres que Developer
for System z
64 au moins, mémoire tampon supplémentaire ajoutée lorsque les pools
d'unités d'exécution RSE prennent en charge moins de 25 clients projetés.
doit être de 573 au moins (pour le moniteur de travaux JES) si
THREADSMAX du segment OMVS de l'ID utilisateur STCRSE est utilisé
pour définir la limite de RSE (635 au moins)
doit être de 573 au moins (pour le moniteur de travaux JES) si
THREADSMAX du segment OMVS de l'ID utilisateur STCRSE est utilisé pour
définir la limite de RSE (635 au moins)
503 au moins, mémoire tampon supplémentaire ajoutée pour les
tâches autres que Developer
for System z
non modifié (valeur par défaut du système de 200 Mo),
nous utilisons ASSIZEMAX dans le segment OMVS
de l'ID utilisateur STCRSE
1050 au moins, mémoire tampon supplémentaire ajoutée pour les tâches
autres que Developer
for System z
2 Go
Après l'activation des limites du système comme documenté dans Définition des limites, nous pouvons démarrer le contrôle de l'utilisation des ressources par Developer for System z pour voir si un ajustement de certaines variables est nécessaire. Figure 31 affiche l'utilisation des ressources après la connexion de 499 utilisateurs. (L'exemple présenté sur la figure montre seulement la connexion. Aucune action utilisateur n'est indiquée dans l'exemple.)
F RSED,APPL=D P
BPXM023I (STCRSE)
ProcessId(83886168) Memory Usage(17%) Clients(25) Order(1)
ProcessId(91 ) Memory Usage(17%) Clients(25) Order(2)
ProcessId(122 ) Memory Usage(17%) Clients(25) Order(3)
ProcessId(16777348) Memory Usage(17%) Clients(25) Order(4)
ProcessId(16777358) Memory Usage(17%) Clients(25) Order(5)
ProcessId(16777368) Memory Usage(17%) Clients(25) Order(6)
ProcessId(16777378) Memory Usage(17%) Clients(25) Order(7)
ProcessId(16777388) Memory Usage(17%) Clients(25) Order(8)
ProcessId(16777398) Memory Usage(17%) Clients(25) Order(9)
ProcessId(33554622) Memory Usage(17%) Clients(25) Order(10)
ProcessId(16777416) Memory Usage(17%) Clients(25) Order(11)
ProcessId(16777426) Memory Usage(17%) Clients(25) Order(12)
ProcessId(16777436) Memory Usage(9%) Clients(25) Order(13)
ProcessId(16777446) Memory Usage(17%) Clients(25) Order(14)
ProcessId(16777456) Memory Usage(17%) Clients(25) Order(15)
ProcessId(16777466) Memory Usage(17%) Clients(25) Order(16)
ProcessId(16777476) Memory Usage(17%) Clients(25) Order(17)
ProcessId(16777487) Memory Usage(17%) Clients(25) Order(18)
ProcessId(16777497) Memory Usage(17%) Clients(25) Order(19)
ProcessId(16777507) Memory Usage(16%) Clients(24) Order(20)
F RSED,APPL=D P,D
BPXM023I (STCRSE)
ProcessId(83886168) ASId(0022) JobName(RSED857 ) Order(1)
PROCESS LIMITS: CURRENT HIGHWATER LIMIT
JAVA HEAP USAGE(%) 17 17 100
CLIENTS 25 25 25
MAXFILEPROC 365 366 64000
MAXPROCUSER 64 64 100
MAXTHREADS 362 363 1500
MAXTHREADTASKS 363 363 1500
TASID
Jobname Cpu time Storage EXCP
-------- ----------- ------- ----------
JMON 0.00 1780 73
RSED 5.88 95.2M 41958
RSED1 8.26 190.1M 58669
RSED1 8.17 187.0M 58605
RSED2 8.06 185.3M 58653
RSED2 8.19 183.1M 60209
RSED3 8.12 189.1M 58650
RSED3 8.03 186.7M 58590
RSED4 8.15 188.2M 58646
RSED4 5.50 182.5M 58585
RSED5 7.72 184.4M 58631
RSED5 7.82 184.1M 58576
RSED6 7.14 184.1M 58622
RSED6 6.27 186.9M 58583
RSED7 5.17 185.1M 58804
RSED7 6.57 185.2M 58621
RSED7 5.86 182.8M 58565
RSED8 0.36 1560 2459
RSED8 7.94 184.1M 58615
RSED8 7.45 181.8M 58548
RSED9 8.16 190.6M 58802
RSED9 7.62 183.8M 58610
RSED9 7.36 177.7M 57478
z/OS est un système d'exploitation hautement personnalisable, et des modifications (parfois mineures) du système peuvent présenter un impact très important sur les performances globales. Le présent chapitre met en évidence certaines modifications qui peuvent être apportées afin d'améliorer les performances de Developer for System z.
Pour plus d'informations sur l'optimisation du système, voir le document MVS Initialization and Tuning Guide (SA22-7591) and UNIX System Services Planning (GA22-7800).
Pour plus d'informations sur zFS, voir le document UNIX System Services Planning (GA22-7800).
Chaque processus z/OS UNIX qui présente un STEPLIB propagé de parent à enfant ou à travers une commande exec utilise environ 200 octets de zone de mémoire commune étendue ECSA. Si aucune variable d'environnement STEPLIB n'est définie ou qu'elle est définie comme STEPLIB=CURRENT, z/OS UNIX propage toutes les allocations TASKLIB, STEPLIB et JOBLIB actuellement actives lors d'une fonction fork(), spawn(), ou exec().
Developer for System z présente une valeur par défaut STEPLIB=NONE codée dans rsed.envvars, comme décrit dans le fichier de configuration rsed.envvars. Pour les raisons mentionnées précédemment, il est conseillé de ne pas modifier cette directive et de placer les fichiers ciblés dans LINKLIST ou dans la zone permanente de programme LPA à la place.
Certaines bibliothèques du système ainsi que certains modules de chargement sont fortement utilisés par z/OS UNIX et par les activités de développement d'applications. En améliorant leur accès (en les ajoutant à la zone permanente de programme (LPA), par exemple), il est possible d'améliorer les performance du système. Pour plus d'informations sur la modification des membres SYS1.PARMLIB décrits ci-après, voir le document MVS Initialization and Tuning Reference (SA22-7592).
Lorsque des programmes C (y compris le shell z/OS UNIX) sont exécutés, ils utilisent fréquemment des routines issues de la bibliothèque d'exécution Language Environment (LE). En moyenne, environ 4 mégaoctets de bibliothèque d'exécution sont chargés dans la mémoire pour chaque espace adresse qui exécute un programme LE activé, et sont copiés à chaque fourche.
CEE.SCEELPA
Le fichier CEE.SCEELPA contient un sous-ensemble de routines d'exécution LE, qui sont fortement utilisées par z/OS UNIX. Il est conseillé, pour gagner le maximum de performances, d'ajouter ce fichier à SYS1.PARMLIB(LPALSTxx). De cette manière, les modules sont lus une seule fois sur le disque, et sont stockés dans un emplacement partagé.
LPA ADD MASK(*) DSNAME(CEE.SCEELPA)
Il est également conseillé de placer les bibliothèque d'exécution LE CEE.SCEERUN et CEE.SCEERUN2 dans LINKLIST, en ajoutant les fichiers à SYS1.PARMLIB(LNKLSTxx) ou à SYS1.PARMLIB(PROGxx). Cela élimine le temps système de z/OS UNIX STEPLIB, et il y a moins d'entrées/sorties en raison de la gestion par LLA et VLF ou par des produits similaires.
Si vous décidez de ne pas mettre ces bibliothèques dans LINKLIST, vous devez alors configurer l'instruction STEPLIB appropriée dans rsed.envvars, comme décrit dans le fichier de configuration rsed.envvars. Même si cette méthode utilise toujours de la mémoire virtuelle supplémentaire, vous pouvez améliorer les performances en définissant les bibliothèques d'exécution LE pour LLA ou un produit similaire. Cela réduit les entrées/sorties nécessaires au chargement des modules.
Les performances des systèmes sur lesquels le développement d'applications est l'activité principale peuvent également être améliorées si vous placez l'éditeur de liens dans la LPA dynamique, en ajoutant les lignes suivantes à SYS1.PARMLIB(PROGxx) :
LPA ADD MODNAME(CEEBINIT,CEEBLIBM,CEEEV003,EDCZV) DSNAME(CEE.SCEERUN)
LPA ADD MODNAME(IEFIB600,IEFXB603) DSNAME(SYS1.LINKLIB)
Pour le développement C/C++, vous pouvez également ajouter le fichier du compilateur CBC.SCCNCMP à SYS1.PARMLIB(LPALSTxx).
Les instructions précédentes sont des exemples de candidats LPA possibles, mais les besoins de votre site peuvent être différents. Voir Language Environment Customization (SA22-7564) pour plus d'informations sur le placement d'autres modules de chargement LE dans la LPA dynamique. Pour plus d'informations sur l'insertion de modules de chargement de compilateur C/C++ dans la LPA dynamique, voir le document UNIX System Services Planning (GA22-7800).
Chaque site a des besoins spécifiques, et il est possible de personnaliser le système d'exploitation z/OS pour tirer le meilleur parti des ressources disponibles pour répondre à ces besoins. Avec la gestion de charge de travail, vous pouvez définir des objectifs de performances et leur attribuer une importance. Vous définissez les buts en terme d'activités, et le système décide quelles ressources, comme le stockage ou l'unité centrale, doivent être allouées à la tâche pour qu'elle atteigne son but.
Les performances de Developer for System z peuvent être équilibrées en paramétrant les but adéquats pour ses processus. Vous trouverez des instructions générales ci-dessous :
Pour plus d'informations sur ce sujet, voir MVS Planning Workload Management (SA22-7602).
Avec une pile à taille fixe, aucune expansion ou contraction de pile ne peut se produire, ce qui peut permettre des gains de performances significatifs dans certaines situations. Toutefois, l'emploi d'une pile de taille fixe n'est généralement pas un bonne idée, dans la mesure où elle retarde le démarrage de la récupération de place jusqu'au moment où la pile est pleine, ce qui et une tâche très importante. Elle augmente également le risque de fragmentation, qui nécessite une compression de la pile. Aussi, n'utilisez les piles à taille fixe qu'après avoir effectué des essais appropriés, ou sur instructions du point service IBM. Pour plus d'informations sur les tailles de pile et la récupération de place, voir le document Java Diagnostics Guide (SC34-6650).
La taille de pile initiale et maximale d'une machine virtuelle Java z/OS peut être définie avec les options de ligne de commande Java -Xms (initiale) et -Xmx (maximale).
Dans Developer for System z, les options de ligne de commande Java sont définies dans la directive _RSE_JAVAOPTS de rsed.envvars, comme indiqué dans "Définition de paramètres de démarrage supplémentaires Java avec _RSE_JAVAOPTS" dans Guide de configuration de l'hôte (SC11-6285).
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Xms128m -Xmx128m"
L'option -Xquickstart peut être utilisée pour améliorer le délai de démarrage de certaines applications Java. L'option -Xquickstart entraîne l'exécution du compilateur JIT (Just In Time) avec un sous-ensemble d'optimisations (il s'agit d'une compilation rapide). Cette compilation rapide permet d'améliorer le délai de démarrage.
L'option -Xquickstart convient aux applications avec un temps d'exécution plus court, notamment les applications pour lesquelles le délai d'exécution n'est pas concentré dans un petit nombre de méthodes. L'option -Xquickstart peut affecter les performances si elle est utilisée avec des applications connaissant un délai d'exécution plus long qui contiennent des méthodes à chaud.
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Xquickstart"
IBM Java Virtual Machine (JVM) versions 5 et suivantes vous permet de partager entre JVM les amorces et les classes d'application par leur stockage dans un cache de la mémoire partagée. Le partage de classes réduit la consommation globale de mémoire virtuelle quand plusieurs JVM partagent un cache. Le partage de classes réduit également le temps de démarrage d'une JVM une fois que le cache a été créé.
Le cache de classes partagées est indépendant de toute JVM active et se conserve au-delà de la durée de vie de la JVM qui l'a créé. Dans la mesure où le cache de classes partagées se conserve au-delà de la durée de vie de toute JVM, le cache est mis à jour de façon dynamique afin de refléter toute modification qui peut avoir été apportée aux JAR ou aux classes sur le système de fichiers.
Le temps système pour créer et remplir un nouveau cache est minimal. Le coût de démarrage en temps d'une JVM unique est généralement entre 0 et 5 % plus lent que celui d'un système qui n'utilise pas le partage de classes, en fonction du nombre de classes qui est chargé. L'amélioration du temps de démarrage de JVM avec un cache rempli est généralement entre 10 % et 40 % plus rapide par rapport à celui d'un système n'utilisant pas le partage de classe, en fonction du système d'exploitation et du nombre de classes chargées. Plusieurs JVM exécutées en même temps présenteront des bénéfices plus importants en terme de temps de démarrage.
Pour plus d'informations sur le partage des classes, voir le document Java SDK and Runtime Environment User Guide.
_RSE_CLASS_OPTS=-Xshareclasses:name=RSE,groupAccess,nonFatal
#_RSE_CLASS_OPTS="$_RSE_CLASS_OPTS -Xscmx6m
_RSE_JAVAOPTS="$_RSE_JAVAOPTS $_RSE_CLASS_OPTS"
Le maximum théorique de la taille de la mémoire cache est de 2 gigaoctets. La taille de la mémoire cache que vous pouvez indiquer est limitée par la quantité de mémoire physique et par le fichier d'échange disponible pour le système. Dans la mesure où l'espace d'adresse virtuelle d'un processus est partagée entre la mémoire cache de classe partagée et la pile Java, l'augmentation de la taille maximale de la pile Java réduit la taille de la mémoire cache de classes partagées que vous pouvez créer.
L'accès au cache de classes partagées est limité par les autorisation du système d'exploitation et par les autorisations de sécurité de Java.
Par défaut, les caches de classes sont créés avec une sécurité au niveau utilisateur, de sorte que seul l'utilisateur qui a créé le cache peut y avoir accès. Dans z/OS UNIX, l'option groupAccess donne accès à tous les utilisateurs du groupe primaire de l'utilisateur qui a créé le cache. Toutefois, quel que soit le niveau d'accès utilisé, un cache peut uniquement être détruit par l'utilisateur qui l'a créé, ou par le superutilisateur (UID 0).
Pour plus d'informations sur les options de sécurité supplémentaires à l'aide d'un gestionnaire de sécurité Java, voir le document Java SDK and Runtime Environment User Guide.
Ces paramètres affectent la quantité de pages de mémoire partagée disponible pour la machine virtuelle Java. La taille de page partagée pour un service de système z/OS UNIX 31-bit est fixée à 4 kilooctets. Les classes partagées essaient de créer par défaut une mémoire cache de 16 mégaoctets. Définissez donc IPCSHMMPAGES à une valeur supérieure à 4096.
Si vous définissez un taille de cache en utilisant -Xscmx, la machine virtuelle Java arrondira la valeur au mégaoctet le plus proche. Vous devez en tenir compte lors de la définition de IPCSHMMPAGES sur le système.
Ces paramètres affectent la quantité de sémaphores disponibles pour les processus UNIX. Les classes partagées utilisent les sémaphores de communication interprocessus pour dialoguer entre les machines virtuelles Java.
Le cache de classes partagées nécessite de l'espace disque pour stocker les informations d'identification concernant les caches qui existent sur le système. Ces informations sont stockées dans /tmp/javasharedresources. Si le répertoire des informations d'identification est effacé, la machine virtuelle Java ne peut plus identifier les classes partagées sur le système, et doit recréer le cache.
$ java -Xshareclasses:listAllCaches
Shared Cache OS shmid in use Last detach time
RSE 401412 0 Mon Jun 18 17:23:16 2007
Could not create the Java virtual machine.
$ java -Xshareclasses:name=RSE,printStats
Current statistics for cache "RSE":
base address = 0x0F300058
end address = 0x0F8FFFF8
allocation pointer = 0x0F4D2E28
cache size = 6291368
free bytes = 4355696
ROMClass bytes = 1912272
Metadata bytes = 23400
Metadata % used = 1%
# ROMClasses = 475
# Classpaths = 4
# URLs = 0
# Tokens = 0
# Stale classes = 0
% Stale classes = 0%
Cache is 30% full
Could not create the Java virtual machine.
$ java -Xshareclasses:name=RSE,destroy
JVMSHRC010I Shared Cache "RSE" is destroyed
Could not create the Java virtual machine.
Les clients Developer for System z version 8.0.1 et suivante peuvent extraire les fichiers de configuration client et les informations de mise à jour de produit depuis l'hôte lorsqu'ils se connectent, ce qui permet de garantir que tous les clients sont paramétrés de la même façon et qu'ils sont à jour.
Depuis la version 8.0.3, l'administrateur client peut créer plusieurs jeux de configuration client et plusieurs scénarios de mise à jour client afin de répondre aux besoins des différents groupes de développeurs. Cela permet aux utilisateurs de recevoir une configuration personnalisée, basée sur des critères tels que l'appartenance d'un groupe LDAP ou les droits d'accès à un profil de sécurité.
Les projets z/OS peuvent être définis de façon individuelle via la perspective Projets z/OS sur le client, ou de façon centralisée sur l'hôte, puis propagés individuellement sur le client pour chaque utilisateur. Ces projets résidant sur l'hôte ressemblent et fonctionnent exactement comme des projets définis sur le client, sauf que leur structure, leurs membres et leurs propriétés ne peuvent pas être modifiés par le client et qu'ils sont accessibles uniquement lorsque vous êtes connecté à l'hôte.
pushtoclient.properties indique au client si ces fonctions sont activées et précise l'emplacement des données associées. Pour plus d'informations, voir la rubrique "(Facultatif) pushtoclient.properties, contrôle du client basé sur un hôte" dans le document Guide de configuration de l'hôte (SC11-6285).
Pour plus d'informations sur la façon dont l'administrateur client et le responsable de projet de développement effectuent les tâches qui leur ont été affectées, voir le centre de documentation Developer for System z (http://www-01.ibm.com/support/knowledgecenter/SSQ2R2_9.1.0/com.ibm.etools.getstart.wsentdev.doc/kc_version_welcome_rdz.html).
La fonction d'envoi au client est conçue pour stocker des données spécifiques à un système sur chaque système tout en conservant les données communes (globales) sur un seul système (système principal) afin de réduire l'effort de gestion. Le système principal est identifié par la directive primary.system dans pushtoclient.properties. La valeur par défaut est faux.
Vérifiez qu'un seul et unique système est défini comme système principal. Les administrateurs client Developer for System z ne peuvent exporter les données de configuration globales que si le système cible est un système principal. Les clients Developer for System z peuvent avoir un comportement incohérent lors de la connexion à plusieurs systèmes principaux avec des configurations désynchronisées.
La règle d'un seul système ne s'applique pas lorsque plusieurs systèmes partagent la configuration Developer for System z (/etc/rdz) et les métadonnées d'envoi au client (/var/rdz/pushtoclient). Etant donné que la configuration est partagée, tous les systèmes concernés sont identifiés comme étant le système principal. Toutefois, tant que tous les systèmes partagent également les métadonnées, cette duplication ne constitue pas un problème.
La directive pushtoclient.folder dans pushtoclient.properties identifie le répertoire de base dans lequel les métadonnées d'envoi au client sont stockées. La valeur par défaut est /var/rdz/pushtoclient.
Le répertoire de base contient le fichier de configuration de la fonction d'envoi au client racine, keymapping.xml. Toutes les autres métadonnées résident dans des sous-répertoires.
La plupart des sous-répertoires sont créés dynamiquement lorsque l'administrateur client exporte la configuration d'espace de travail de la fonction d'envoir au client. Ces sous-répertoires regroupent les métadonnées par objet, comme les mappages et les préférences. Comme davantage de composants client Developer for System z peuvent être gérés par la fonction d'envoi au client, un plus grand nombre de sous-répertoires est créé dynamiquement. Voir l'assistant d'exportation dans le client Developer for System z (Fichier > Exporter > Rational Developer for System z > Fichiers de configuration) pour savoir ce que contiennent ces sous-répertoires.
Pour plus d'informations sur la création de ces sous-répertoires, voir la section sur la configuration de la personnalisation dans le chapitre sur la personnalisation de base dans le document Guide de configuration de l'hôte (SC11-6285).
Par défaut (voir la directive file.permission dans pushtoclient.properties), tous les fichiers et répertoires créés dans le répertoire de base reçoivent le masque de contrôle des données de droits 775 (rwxrwxr-x), lequel octroie au propriétaire et au groupe par défaut du propriétaire un accès en lecture et en écriture à la structure de répertoire et aux fichiers qu'elle contient. Les autres utilisateurs ont uniquement un accès en lecture à la structure de répertoire et aux fichiers qu'elle contient.
Il est essentiel que l'ID utilisateur propriétaire et l'ID groupe appropriés soient définis pour ces répertoires avant de commencer à configurer la fonction d'envoi au client.
ADDGROUP RDZADMIN OWNER(IBMUSER) SUPGROUP(SYS1) –
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - CLIENT ADMIN')
ALTGROUP RDZADMIN OMVS(GID(2))
CONNECT RDZADM1 GROUP(RDZADMIN) AUTH(USE)
ALTUSER RDZADM1 DFLTGRP(RDZADMIN) OMVS(UID(6))
chown –R rdzadm1:rdzadmin /var/rdz/pushtoclient
chmod –R 775 /var/rdz/pushtoclient
Pour plus d'informations sur les exemples de commande RACF, voir Security Server RACF Command Language Reference (SA22-7687). Pour plus d'informations sur les exemples de commande z/OS UNIX, voir UNIX System Services Command Reference (SA22-7802). Pour toute information complémentaire, voir Structure de répertoires z/OS UNIX.
Les métadonnées d'envoi au client utilisent un volume d'espace disque assez réduit dans z/OS UNIX, car elles correspondent à des fichiers XML codés en UTF-8. Notez que le code produit utilisé pour les scénarios de mise à jour de client peut être stocké n'importe où sur le réseau ; il n'a pas besoin d'être stocké dans z/OS UNIX car les métadonnées d'envoi au client associées (appelées fichiers de réponses) pointent vers l'emplacement approprié pour le client.
Lorsqu'un client Developer for System z (version 8.0.1 et suivante) se connecte à l'hôte, il lit les définitions dans pushtoclient.properties. Si la directive config.enabled est activée, le client compare sa configuration en cours aux définitions dans les métadonnées d'envoi au client. Si des différences sont détectées, le client démarre un assistant qui extrait les données requises et active la configuration comme indiqué par la fonction d'envoi au client.
La directive reject.config.updates dans pushtoclient.properties contrôle si un utilisateur est autorisé à rejeter les mises à jour de configuration que la fonction d'envoi au client est sur le point de distribuer.
Un client Developer for System z (version 8.0.1 et suivante) dispose d'un assistant (à l'intention de l'administrateur client) qui peut exporter la configuration en cours, laquelle est ensuite importée par tous les clients Developer for System z via la fonction d'envoi au client. Notez que cette fonction est disponible dans tous les clients. Par conséquent, vous devez vous assurer que seuls les administrateurs client disposent d'un droit d'accès en écriture sur les répertoires z/OS UNIX qui contiennent les métadonnées d'envoi au client (/var/rdz/pushtoclient).
La version 8.0.3 ou suivante est requise à la fois pour le client et pour l'hôte, de manière à permettre l'activation du support de groupe, comme indiqué dans le Plusieurs groupes de développeurs.
Lorsqu'un client Developer for System z (version 8.0.1 et suivante) se connecte à l'hôte, il lit les définitions dans pushtoclient.properties. Si la directive product.enabled est activée, le client compare sa version de produit en cours aux définitions dans les métadonnées d'envoi au client. Si des différences sont détectées, le client démarre un assistant qui extrait les données requises et active la configuration comme indiqué par la fonction d'envoi au client.
La directive reject.product.updates dans pushtoclient.properties contrôle si un utilisateur est autorisé à rejeter les mises à jour de produit que la fonction d'envoi au client est sur le point de distribuer.
La version 8.0.3 ou suivante est requise à la fois pour le client et pour l'hôte, de manière à permettre l'activation du support de groupe, comme indiqué dans Plusieurs groupes de développeurs.
Depuis la version 8.0.3, l'administrateur client peut créer plusieurs jeux de configuration client et plusieurs scénarios de mise à jour client afin de répondre aux besoins des différents groupes de développeurs. Cela permet aux utilisateurs de recevoir une configuration personnalisée, basée sur des critères tels que l'appartenance d'un groupe LDAP ou les droits d'accès à un profil de sécurité.
La prise en charge de plusieurs groupes de développeurs, chacun ayant sa propre configuration client et ses propres exigences de mise à jour de produit client, est activée en affectant la valeur souhaitée aux directives connexes (config.enabled et product.enabled) dans pushtoclient.properties, comme indiqué dans le Tableau 36.
Valeur *.enabled | Fonction activée | Plusieurs groupes pris en charge |
---|---|---|
Faux | Non | Non |
Vrai | Oui | Non |
LDAP | Oui | Yes, en fonction de l'appartenance des groupes LDAP FEK.PTC.*.ENABLED.sysname.devgroup |
SAF | Oui | Oui, en fonction des droits d'accès aux profils de sécurité FEK.PTC.*.ENABLED.sysname.devgroup |
Notez que lorsque la fonction est activée (valeur VRAI), les développeurs font toujours partie d'un groupe par défaut. Un développeur peut appartenir à aucun groupe, à un groupe ou à plusieurs groupes supplémentaires.
Le rejet des mises à jour peut également être conditionnel, comme indiqué dans le Tableau 37.
Valeur reject.*.updates | Fonction activée |
---|---|
Faux | Non |
Vrai | Oui |
LDAP | Dépend de l'appartenance de groupe LDAP FEK.PTC.REJECT.*.UPDATES.sysname.** |
SAF | Dépend des droits d'accès au profil de sécurité FEK.PTC.REJECT.*.UPDATES.sysname.** |
Notez que les directives dans pushtoclient.properties fonctionnent indépendamment les unes des autres. Vous pouvez attribuer n'importe quelle valeur prise en charge aux directives. Il n'est pas nécessaire que les paramètres soient identiques.
Pour plus d'informations sur la configuration requise pour une fonction donnée, voir respectivement Sélection de groupe basé sur LDAP et Sélection de groupe basé sur SAF. Pour plus d'informations sur l'activation du support de plusieurs groupes, voir la rubrique "(Facultatif) pushtoclient.properties, contrôle client résidant sur l'hôte" dans le document Guide de configuration de l'hôte (SC11-6285).
Lorsque la fonction *.enabled est activée (valeur VRAI) dans pushtoclient.properties, les développeurs font toujours partie d'un groupe par défaut pour la fonction associée. Un développeur peut appartenir à aucun groupe, à un groupe ou à plusieurs groupes supplémentaires.
Pour rendre moins complexe l'application des modifications définies dans plusieurs groupes, Developer for System z limite les définitions qui seront utilisées, sur la base d'une sélection effectuée par l'utilisateur.
Groupes supplémentaires | Définitions utilisées |
---|---|
Aucun | Valeur par défaut |
Un | Valeur par défaut ou (valeur par défaut + groupe) |
Plusieurs | Valeur par défaut ou (valeur par défaut + 1 groupe) |
Même si un développeur peut faire partie de plusieurs groupes simultanément, son espace de travail actif ne peut pas. L'espace de travail actif doit être lié à un groupe de configuration et un groupe de produits spécifiques (lesquels peuvent être le groupe par défaut) pour recevoir les mises à jour de configuration ou de produit. Une fois la liaison effectuée, elle ne peut plus être annulée. Un nouvel espace de travail doit être créé si une nouvelle liaison de groupe est requise.
Lorsqu'un espace de travail sans liaison de groupe de configuration se connecte à l'hôte et que config.enabled indique que la fonction d'envoi au client (push-to-client) est active, Developer for System z interroge tous les groupes de configuration pour identifier ceux auxquels l'utilisateur appartient et il invite ce dernier à sélectionner un groupe. Lors des connexions successives, seul le groupe sélectionné est interrogé pour vérifier si l'appartenance au groupe est toujours valide.
config.enabled | Espace de travail lié à ce groupe de mises à jour de configuration |
---|---|
False | Aucune |
True | Valeur par défaut |
LDAP | Valeur par défaut ou Groupe (après invite) |
SAF | Valeur par défaut ou Groupe (après invite) |
Lorsqu'un espace de travail sans liaison de groupe de produits se connecte à l'hôte et que product.enabled indique que la fonction d'envoi au client est active, Developer for System z interroge tous les groupes de produits pour identifier ceux auxquels l'utilisateur appartient et il invite ce dernier à sélectionner un groupe. Lors des connexions successives, seul le groupe sélectionné est interrogé pour vérifier si l'appartenance au groupe est toujours valide.
product.enabled | Espace de travail lié à ce groupe de mises à jour de produit |
---|---|
False | Aucune |
True | Valeur par défaut |
LDAP | Valeur par défaut ou Groupe (après invite) |
SAF | Valeur par défaut ou Groupe (après invite) |
Les directives reject.*.updates peuvent fonctionner avec et sans définition de groupe. Si des groupes sont utilisés pour reject.*.updates, la liaison de groupe de la directive *.enabled associée est utilisée. Lorsqu'une mise à jour existe, Developer for System z détermine si l'utilisateur est autorisé ou non à la rejeter il et agit en conséquence.
La prise en charge de groupe pour les directives reject.*.updates est une nouveauté de la version 9.1.0, et nécessite que l'hôte et le client Developer for System z aient la version 9.1.0 ou suivante. Cette prise en charge modifie la manière dont les mots-clés LDAP et SAF sont traités.
Avant la version 9.1.0, il suffisait d'être dans la liste d'accès FEK.PTC.REJECT.*.UPDATES.sysname pour rejeter une mise à jour, quelle que soit la liaison de groupe de l'espace de travail. A partir de la version 9.1.0, FEK.PTC.REJECT.*.UPDATES.sysname est utilisé uniquement pour rejeter les mises à jour par les espaces de travail liés au groupe par défaut. Les espaces de travail liés à un groupe nécessitent que vous soyez dans la liste d'accès pour FEK.PTC.REJECT.*.UPDATES.sysname.groupname pour rejeter les mises à jour.
La personnalisation de produit initiale crée le répertoire grouping/ dans var/rdz/pushtoclient/. L'administrateur client est chargé d'ajouter les répertoires <devgroup>/ dans /var/rdz/pushtoclient/grouping/.
Notez que lors de la personnalisation de produit initiale, les répertoires projects/, install/, et install/responsefiles/ sont créés dans /var/rdz/pushtoclient/. L'administrateur client doit répéter ces actions de création de répertoire dans /var/rdz/pushtoclient/grouping/<devgroup>/ si des scénarios de mise à niveau de produit spécifiques à un groupe ou des projets basés sur l'hôte spécifiques à un groupe sont requis.
L'exemple de séquence de commande z/OS UNIX suivant crée les sous-répertoires avec le masque de contrôle des données de droits approprié. Les commandes doivent être exécutées par l'administrateur client pour éviter tout problème de propriété.
saved_umask=$(umask)
umask 0000
cd /var/rdz/pushtoclient/grouping/
mkdir –m775 <devgroup>
cd <devgroup>
mkdir –m775 install
mkdir –m775 install/responsefiles
mkdir –m775 projects
umask $saved_umask
Pour plus d'informations sur les exemples de commande z/OS UNIX, voir UNIX System Services Command Reference (SA22-7802).
/var/rdz/pushtoclient/grouping/<devgroup>
pour chaque groupe de fonction d'envoi au client.Même si LDAP (Lightweight Directory Access Protocol) est le nom d'un protocole basé sur TCP/IP, il est généralement utilisé pour décrire un ensemble de services d'annuaire distribué. Comme une base de données, un annuaire est un ensemble structuré d'enregistrements. Developer for System z peut utiliser un serveur LDAP comme une base de données hiérarchique simple, dans laquelle des groupes contiennent un ou plusieurs membres.
Lorsque vous utilisez des définitions dans votre serveur LDAP comme mécanisme de sélection (la valeur LDAP est spécifiée pour les directives dans pushtoclient.properties), Developer for System z vérifie l'appartenance aux groupes répertoriés dans le Tableau 41 pour identifier les groupes de développeurs auxquels l'utilisateur appartient et déterminer si un utilisateur est autorisé à rejeter les mises à jour.
Nom de groupe (cn=) | Résultat |
---|---|
FEK.PTC.CONFIG.ENABLED.sysname.devgroup | Le client accepte les mises à jour de configuration pour le groupe indiqué |
FEK.PTC.PRODUCT.ENABLED.sysname.devgroup | Le client accepte les mises à jour de produit pour le groupe indiqué |
FEK.PTC.REJECT.CONFIG.UPDATES.sysname | L'utilisateur peut rejeter les mises à jour de configuration lorsque l'espace de travail est lié au groupe par défaut. |
FEK.PTC.REJECT.CONFIG.UPDATES.sysname.devgroup | L'utilisateur peut rejeter les mises à jour de configuration lorsque l'espace de travail est lié au groupe spécifié. |
FEK.PTC.REJECT.PRODUCT.UPDATES.sysname | L'utilisateur peut rejeter les mises à jour de produit lorsque l'espace de travail est lié au groupe par défaut. |
FEK.PTC.REJECT.PRODUCT.UPDATES.sysname.devgroup | L'utilisateur peut rejeter les mises à jour de produit lorsque l'espace de travail est lié au groupe spécifié. |
La valeur devgroup correspond au nom de groupe affecté à un groupe spécifique de développeurs. Notez que le nom de groupe est visible sur les clients Developer for System z.
La valeur sysname correspond au nom du système cible.
Un utilisateur peut choisir de lier un espace de travail au groupe par défaut pour les mises à jour de configuration si config.enabled dans pushtoclient.properties est défini sur SAF ou LDAP. Si config.enabled est défini sur TRUE, l'espace de travail est lié automatiquement au groupe par défaut.
Un utilisateur peut choisir de lier un espace de travail au groupe par défaut pour les mises à jour de produit si product.enabled dans pushtoclient.properties est défini sur SAF ou LDAP. Si product.enabled est défini sur TRUE, l'espace de travail est lié automatiquement au groupe par défaut.
La prise en charge de groupe pour les directives reject.*.updates est une nouveauté de la version 9.1.0 et modifie la manière dont les mots-clés LDAP et SAF sont traités.
La Figure 32 est un exemple de définition LDAP pour un groupe et un utilisateur, exprimé au format LDIF.
# Group Definition
dn: cn=FEK.PTC.CONFIG.ENABLED.CDFMVS08.GROUPA,o=PTC,c=DeveloperForZ
objectClass: groupOfUniqueNames
objectClass: top
cn: FEK.PTC.CONFIG.ENABLED.CDFMVS08.GROUPA
description: Project A
uniqueMember: uid=mborn,ou=Users,dc=example,dc=com
# User Definition
dn: uid=mborn,ou=Users,dc=example,dc=com
objectClass: organizationalPerson
objectClass: person
objectClass: inetOrgPerson
objectClass: uidObject
objectClass: top
cn: May Born
sn: Born
uid: mborn
facsimiletelephonenumber: +1 800 982 6883
givenname: May
mail: mborn@example.com
ou: Users
Il existe un large choix de serveurs LDAP commerciaux et gratuits. Par exemple, IBM Tivoli Directory Server (http://www-01.ibm.com/software/tivoli/products/directory-server/). Il existe également un large choix d'outils de type interface graphique et ligne de commande qui permettent de gérer un serveur LDAP.
Comme indiqué dans Schéma LDAP, chaque utilisateur doit être défini sur le serveur LDAP. Pour réduire l'effort de gestion, il est préférable de placer le schéma d'envoi au client sur un serveur LDAP qui a déjà accès à toutes les définitions d'utilisateur. Par exemple, vous pouvez utiliser un serveur IBM Tivoli Directory Server actif sous z/OS à l'aide d'une base de données SDBM (laquelle sert d'encapsuleur pour votre base de données de sécurité).
Selon les règles appliquées sur le site, le schéma d'envoi au client sur le serveur LDAP peut être géré par l'administrateur client. Cet arrangement permet de réduire les besoins en termes de collaboration, ainsi que les retards et erreurs de communication éventuels.
L'un des arguments en faveur de la gestion LDAP par l'administrateur client est que le schéma d'envoi au client ne contient aucune donnée confidentielle ni aucune information liée à la sécurité. Lorsque des définitions utilisateur sont disponibles sur le serveur LDAP via d'autres schémas, les objets LDAP Developer for System z identifient simplement les choix dont dispose un développeur pour la sélection d'une présentation d'espace de travail et des mises à niveau de produit client Developer for System z automatiques.
Tout serveur de base de données qui prend en charge le protocole LDAP peut être utilisé pour héberger le schéma d'envoi au client Developer for System z. Par conséquent, Developer for System z vous permet de spécifier les informations nécessaires à la connexion au serveur LDAP. Vous pouvez également spécifier le suffixe qui rend la base de données unique dans le serveur LDAP.
Directive rsed.envvars | Valeur par défaut |
---|---|
_RSE_LDAP_SERVER | Système hôte local |
_RSE_LDAP_PORT | 389 |
_RSE_LDAP_PTC_GROUP_SUFFIX | "O=PTC,C=DeveloperForZ" |
Supposons que Developer for System z soit actif sur le système CDFMVS08. IBM Tivoli Directory Server, également actif sur CDFMVS08, est utilisé en tant que serveur LDAP. Le serveur LDAP est configuré comme indiqué dans Ajout à LDAP d'une section dorsale pour la fonction d'envoi au client.
Chaque groupe de développeurs nécessite des fichiers de configuration client spécifiques, et tous les développeurs sont soumis au même contrôle de version client. Contrairement aux administrateurs client, les développeurs ne sont pas autorisés à rejeter les modifications présentées par la fonction d'envoi au client.
L'administrateur client et l'administrateur LDAP s'entendent pour utiliser les noms de groupe BANKING et INSURANCE pour les mises à jour de configuration.
# filename ds.conf
# restart GLDSRV started task to pick up changes
# global section
adminDN "cn=LDAP admin"
adminPW password
listen ldap://:389
schemaPath /etc/ldap
# SDBM back-end section (RACF)
database SDBM GLDBSD31/GLDBSD64
suffix "cn=RACF,o=IBM,c=US"
# LDBM back-end section (z/OS UNIX files)
database LDBM GLDBLD31/GLDBLD64 LDBM-RDZ
suffix "o=PTC,c=DeveloperForZ"
databaseDirectory /var/ldap/ldbm/rdz
mkdir -p /var/ldap/ldbm/rdz
ldapmodify -D "cn=LDAP admin" -w password -f
/usr/lpp/ldap/etc/schema.user.ldif
ldapmodify -D "cn=LDAP admin" -w password -f
/usr/lpp/ldap/etc/schema.IBM.ldif
ldapadd -D "cn=LDAP admin" -w password -f
/u/ibmuser/ptc_root.ldif
où /u/ibmuser/ptc_root.ldif contient les éléments suivants :dn: o=PTC,c=DeveloperForZ
objectclass: top
objectclass: organization
o: PTC
Ajoutez les différents objets groupe LDAP au schéma, puis associez l'administrateur client à chacun d'eux. La définition d'utilisateur de l'ID utilisateur RDZADM1 est extraite du schéma RACF.
ldapadd -D "cn=LDAP admin" -w password -f /u/ibmuser/ptc_setup.ldif
# banking workspace configuration
dn: cn=FEK.PTC.CONFIG.ENABLED.CDFMVS08.BANKING,o=PTC,c=DeveloperForZ
objectclass: groupOfUniqueNames
cn: FEK.PTC.CONFIG.ENABLED.CDFMVS08.BANKING
description: Developer for System z push-to-client
# give client administrator access
uniqueMember: racfID=RDZADM1,profileType=user,cn=RACF,o=IBM,c=US
# insurance workspace configuration
dn: cn=FEK.PTC.CONFIG.ENABLED.CDFMVS08.INSURANCE,o=PTC,c=DeveloperForZ
objectclass: groupOfUniqueNames
cn: FEK.PTC.CONFIG.ENABLED.CDFMVS08.INSURANCE
description: Developer for System z push-to-client
# give client administrator access
uniqueMember: racfID=RDZADM1,profileType=user,cn=RACF,o=IBM,c=US
# reject configuration updates
dn: cn=FEK.PTC.REJECT.CONFIG.UPDATES.CDFMVS08,o=PTC,c=DeveloperForZ
objectclass: groupOfUniqueNames
cn: FEK.PTC.REJECT.CONFIG.UPDATES.CDFMVS08
description: Developer for System z push-to-client
# give client administrator access
uniqueMember: racfID=RDZADM1,profileType=user,cn=RACF,o=IBM,c=US
# reject product updates
dn: cn=FEK.PTC.REJECT.PRODUCT.UPDATES.CDFMVS08,o=PTC,c=DeveloperForZ
objectclass: groupOfUniqueNames
cn: FEK.PTC.REJECT.PRODUCT.UPDATES.CDFMVS08
description: Developer for System z push-to-client
# give client administrator access
uniqueMember: racfID=RDZADM1,profileType=user,cn=RACF,o=IBM,c=US
Ajoutez les développeurs aux objets groupe LDAP. Les définitions d'utilisateur des ID utilisateur sont extraites du schéma RACF.
ldapmodify -D "cn=LDAP admin" -w password -f /u/ibmuser/ptc_add.ldif
où /u/ibmuser/ptc_add.ldif contient les éléments suivants :# banking workspace configuration
dn: cn=FEK.PTC.CONFIG.ENABLED.CDFMVS08.BANKING,o=PTC,c=DeveloperForZ
changeType: modify
add: uniqueMember
uniqueMember: racfID=BNK010,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=BNK011,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=BNK012,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=BNK013,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=BNK014,profileType=user,cn=RACF,o=IBM,c=US
# insurance workspace configuration
dn: cn=FEK.PTC.CONFIG.ENABLED.CDFMVS08.INSURANCE,o=PTC,c=DeveloperForZ
changeType: modify
add: uniqueMember
uniqueMember: racfID=INS010,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=INS011,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=INS012,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=INS013,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=INS014,profileType=user,cn=RACF,o=IBM,c=US
# BANKING and INSURANCE have different configuration needs
config.enabled=LDAP
# everyone receives product updates
product.enabled=TRUE
# only RDZADMIN can reject configuration updates
reject.config.updates=LDAP
# only RDZADMIN can reject product updates
reject.product.updates=LDAP
Etant donné qu'il n'existe pas de scénarios de mise à niveau de produit individualisés, l'administrateur client n'a pas besoin de créer ou mettre à jour les sous-répertoires install/ et install/responsefiles/ de /var/rdz/pushtoclient/grouping/<devgroup>.
L'administrateur client doit créer les fichiers de réponses nécessaires aux mises à jour de produit dans le répertoire de groupe par défaut, /var/rdz/pushtoclient/install/responsefiles/.
SAF (Security Access Facility) est une interface qui permet d'accéder à n'importe quel produit de sécurité z/OS. Developer for System z peut utiliser cette interface pour interroger votre produit de sécurité et extraire les informations liées à la fonction d'envoi au client.
Lorsque vous utilisez des définitions dans votre base de données de sécurité comme mécanisme de sélection (la valeur SAF est spécifiée pour les directives dans pushtoclient.properties), Developer for System z vérifie les droits d'accès aux profils répertoriés dans le Tableau 42 pour identifier les groupes de développeurs auxquels l'utilisateur appartient et déterminer si un utilisateur est autorisé à rejeter les mises à jour.
Profil FACILITY | Longueur fixe | Droit d'accès requis | Résultat |
---|---|---|---|
FEK.PTC.CONFIG.ENABLED. |
23 | READ | Le client accepte les mises à jour de configuration pour le groupe indiqué |
FEK.PTC.PRODUCT.ENABLED. |
24 | READ | Le client accepte les mises à jour de produit pour le groupe indiqué |
FEK.PTC.REJECT.CONFIG. |
30 | READ | L'utilisateur peut rejeter les mises à jour de configuration lorsque l'espace de travail est lié au groupe par défaut. |
FEK.PTC.REJECT.CONFIG. UPDATES.sysname.devgroup | 30 | READ | L'utilisateur peut rejeter les mises à jour de configuration lorsque l'espace de travail est lié au groupe spécifié. |
FEK.PTC.REJECT.PRODUCT. |
31 | READ | L'utilisateur peut rejeter les mises à jour de produit lorsque l'espace de travail est lié au groupe par défaut. |
FEK.PTC.REJECT.PRODUCT. UPDATES.sysname.devgroup | 31 | READ | L'utilisateur peut rejeter les mises à jour de produit lorsque l'espace de travail est lié au groupe spécifié. |
La valeur devgroup correspond au nom de groupe affecté à un groupe spécifique de développeurs. Notez que le nom de groupe est visible sur les clients Developer for System z.
La valeur sysname correspond au nom du système cible.
Un utilisateur peut choisir de lier un espace de travail au groupe par défaut pour les mises à jour de configuration si config.enabled dans pushtoclient.properties est défini sur SAF ou LDAP. Si config.enabled est défini sur TRUE, l'espace de travail est lié automatiquement au groupe par défaut.
Un utilisateur peut choisir de lier un espace de travail au groupe par défaut pour les mises à jour de produit si product.enabled dans pushtoclient.properties est défini sur SAF ou LDAP. Si product.enabled est défini sur TRUE, l'espace de travail est lié automatiquement au groupe par défaut.
La colonne "Longueur fixe" indique la longueur de la partie fixe du profil de sécurité associée.
Par défaut, Developer for System z s'attend à ce que les profils FEK.* résident dans la classe de sécurité FACILITY. Notez que les profils figurant dans la classe FACILITY sont limités à 39 caractères. Si la somme de la longueur de la partie fixe de profil (FEK.PTC.<key>.) et de la longueur de la partie de profil spécifique au site (sysname ou sysname.devgroup) est supérieure à ce nombre, vous pouvez placer les profils dans une autre classe et indiquer à Developer for System z que cette dernière doit être utilisée. Pour ce faire, mettez en commentaires _RSE_FEK_SAF_CLASS dans rsed.envvars et indiquez le nom de classe de votre choix.
Chaque groupe de développeurs nécessite des fichiers de configuration client spécifiques, et tous les développeurs sont soumis au même contrôle de version client. Contrairement aux administrateurs client, les développeurs ne sont pas autorisés à rejeter les modifications présentées par la fonction d'envoi au client. La règle de rejet est valide pour tous les systèmes en vue d'une expansion ultérieure.
L'administrateur de la sécurité et l'administrateur client s'entendent pour utiliser les noms de groupe d'envoi au client BANKING et INSURANCE pour les mises à jour de configuration.
# allow RDZADMIN and DEVBANK to select push-to-client group BANKING
RDEFINE XFACILIT (FEK.PTC.CONFIG.ENABLED.CDFMVS08.BANKING) –
UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEN Z - PUSH-TO-CLIENT')
PERMIT FEK.PTC.CONFIG.ENABLED.CDFMVS08.BANKING CLASS(XFACILIT) –
ID(RDZADMIN DEVBANK) ACCESS(READ)
# allow RDZADMIN and DEVINSUR to select push-to-client group INSURANCE
RDEFINE XFACILIT (FEK.PTC.CONFIG.ENABLED.CDFMVS08.INSURANCE) –
UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEN Z - PUSH-TO-CLIENT')
PERMIT FEK.PTC.CONFIG.ENABLED.CDFMVS08.INSURANCE CLASS(XFACILIT) –
ID(RDZADMIN DEVINSUR) ACCESS(READ)
# RDZADMIN can reject configuration updates on any system and for any group
RDEFINE XFACILIT (FEK.PTC.REJECT.CONFIG.UPDATES.**) –
UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEN Z - PUSH-TO-CLIENT')
PERMIT FEK.PTC.REJECT.CONFIG.UPDATES.** CLASS(XFACILIT) –
ID(RDZADMIN) ACCESS(READ)
# RDZADMIN can reject product updates on any system system and for any group
RDEFINE XFACILIT (FEK.PTC.REJECT.PRODUCT.UPDATES.**) –
UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEN Z - PUSH-TO-CLIENT')
PERMIT FEK.PTC.REJECT.PRODUCT.UPDATES.** CLASS(XFACILIT) –
ID(RDZADMIN) ACCESS(READ)
# activate changes
SETROPTS RACLIST(XFACILIT) REFRESH
# BANKING and INSURANCE have different configuration needs
config.enabled=SAF
# everyone receives product updates
product.enabled=TRUE
# only RDZADMIN can reject configuration updates
reject.config.updates=SAF
# only RDZADMIN can reject product updates
reject.product.updates=SAF
_RSE_FEK_SAF_CLASS=XFACILIT
Etant donné qu'il n'existe pas de scénarios de mise à niveau de produit individualisés, l'administrateur client n'a pas besoin de créer ou mettre à jour les sous-répertoires install/ et install/responsefiles/ de /var/rdz/pushtoclient/grouping/<devgroup>/.
L'administrateur client doit créer les fichiers de réponses nécessaires aux mises à jour de produit dans le répertoire de groupe par défaut, /var/rdz/pushtoclient/install/responsefiles/.
Supposons que pendant que l'exemple de configuration est en vigueur, un groupe de correctifs Developer for System z comportant des correctifs majeurs devienne disponible. Toutefois, le calendrier d'un projet bancaire est tel qu'il est possible que plusieurs développeurs soient lassés de devoir apporter des modifications sur leur poste de travail pour le moment.
Pour résoudre ce problème, l'administrateur de la sécurité peut accorder à tous les développeurs DEVBANK un délai de grâce pendant lequel ils peuvent différer (rejeter) la mise à jour.
# start of grace period
PERMIT FEK.PTC.REJECT.PRODUCT.UPDATES.** CLASS(XFACILIT) –
ID(DEVBANK) ACCESS(READ)
# activate changes
SETROPTS RACLIST(FACILITY) REFRESH
# end of grace period
PERMIT FEK.PTC.REJECT.PRODUCT.UPDATES.** CLASS(XFACILIT) –
ID(DEVBANK) DELETE
# activate changes
SETROPTS RACLIST(FACILITY) REFRESH
Les projets z/OS peuvent être définis de façon individuelle via la perspective Projets z/OS sur le client, ou de façon centralisée sur l'hôte, puis propagés individuellement sur le client pour chaque utilisateur. Ces projets résidant sur l'hôte ressemblent et fonctionnent exactement comme des projets définis sur le client, sauf que leur structure, leurs membres et leurs propriétés ne peuvent pas être modifiés par le client et qu'ils sont accessibles uniquement lorsque vous êtes connecté à l'hôte.
Le répertoire de base pour les projets résidant sur l'hôte est défini (par l'administrateur client) dans /var/rdz/pushtoclient/keymapping.xml. Il s'agit du répertoire par défaut /var/rdz/pushtoclient/projects.
Les projets résidant sur l'hôte peuvent également être sélectionnés pour faire partie de la configuration de plusieurs groupes (présentée dans Plusieurs groupes de développeurs). Cela signifie que les projets résidant sur l'hôte peuvent également être définis dans /var/rdz/pushtoclient/grouping/<devgroup>/projects/.
Lorsqu'un espace de travail est lié à un groupe spécifique et qu'il existe des définitions de projet pour un utilisateur dans ce groupe et dans le groupe par défaut, l'utilisateur reçoit les définitions de projet depuis ces deux groupes.
Developer for System z traite ces problèmes en permettant aux administrateurs CICS de contrôler les paramètres par défaut de définition de ressource CICS ainsi que les propriétés d'affichage d'un paramètre de définition de ressource CICS à l'aide du serveur de définition de ressource CICS, qui fait partie du gestionnaire de déploiement d'application.
Par exemple, l'administrateur CICS peut fournir certains paramètres de définition de ressource CICS qui risquent de ne pas avoir été mis à jour par le développeur d'applications. D'autres paramètres de définition de ressource CICS sont réactualisables, avec ou sans les valeurs fournies par défaut, ou le paramètre de définition de ressource CICS peut être masqué pour éviter toute complexité inutile.
Une fois que le développeur d'applications est satisfait des définitions de ressource CICS, il peut les installer immédiatement dans l'environnement de test CICS en cours d'exécution ou les exporter dans un manifeste pour qu'un administrateur CICS puisse les éditer et les valider. L'administrateur CICS peut utiliser l'utilitaire d'administration (utilitaire de traitement par lots) ou l'outil de traitement de manifestes pour mettre en oeuvre les modifications de définition de ressource.
Voir "(Facultatif) Gestionnaire de déploiement d'application" dans Guide de configuration de l'hôte (SC11-6285) pour plus d'informations sur les tâches nécessaires pour configurer le gestionnaire de déploiement d'application sur votre système hôte.
Le serveur CRD (CICS Resource Definition) du gestionnaire de déploiement d'application est constitué du serveur CRD, d'un référentiel CRD, des définitions de ressource CICS associées et, lorsque vous utilisez l'interface Web Service, des fichiers de liaison Web Service et un exemple de gestionnaire de messages de pipeline. Le serveur CRD doit être exécuté dans une région gérant le Web (WOR, Web Owning Region) référencée dans la documentation Developer for System z comme région de connexion principale CICS.
Pour en savoir plus sur les services du gestionnaire de déploiement d'application disponibles dans l'édition en cours de Developer for System z, reportez-vous au centre de documentation Developer for System z (http://www-01.ibm.com/support/knowledgecenter/SSQ2R2_9.1.0/com.ibm.etools.getstart.wsentdev.doc/kc_version_welcome_rdz.html).
CICS Transaction Server fournit dans la version 4.1 et les versions suivantes le support d'une interface HTTP conçue en utilisant les principes RESTful (Representational State Transfer). Cette interface RESTful est désormais l'interface CICSTS stratégique utilisée par les applications client. L'ancienne interface Web Service a été stabilisée, les améliorations concernant uniquement l'interface RESTful.
Le gestionnaire de déploiement d'application suit cette logique et demande au serveur CRD RESTful tous les nouveaux services de Developer for System version 7.6 ou ultérieures.
Les interfaces RESTful et Web Service peuvent être activées simultanément dans une seule région CICS, si nécessaire. Dans ce cas, la région contient deux serveurs CRD actifs. Les deux serveurs partagent le même référentiel de CRD. Notez que CICS émet des avertissement su les définitions dupliquées lorsque la seconde interface est définie dans la région.
Un environnement de test CICS peut se composer de plusieurs régions connectées par MRO (exploitation multirégionale). Au cours du temps, des désignations non officielles ont été utilisées pour catégoriser ces régions. Les désignations standard sont : région TOR (région gérant les terminaux), région WOR (région gérant le Web), région AOR (région gérant les applications) et région DOR (région gérant les données).
Une région gérant le Web est utilisée pour mettre en oeuvre la prise en charge des services Web CICS et le serveur de définition de ressource CICS du gestionnaire de déploiement d'application doit être exécuté dans cette région. Cette région est connue dans le Gestionnaire de déploiement d'application en tant que région de connexion CICS primaire. Le client CRD ADM implémente une connexion de service Web à la région primaire de connexion CICS.
Les régions de connexion non primaires CICS constituent toutes les autres régions que le serveur CRD peut gérer. Ce service englobe l'affichage des ressources à l'aide d'IBM CICS Explorer et des ressources de définition à l'aide de l'éditeur de définition de ressource CICS.
Si les services d'application métier (BAS) SM CICSPlex sont utilisés pour gérer les définitions de ressource CICS de la région de connexion primaire CICS, toutes les autres régions CICS gérées par BAS peuvent être gérées par le serveur CRD.
Les régions CICS non gérées par BAS requièrent des modifications supplémentaires afin de pouvoir être gérées par le serveur CRD.
Les actions effectuées par le serveur CRD sur les ressources CICS sont consignées dans la file d'attente TD CSDL CICS qui indique généralement la définition de données MSGUSR de votre régionCICS.
Si CICSPlex SM Business Application Services (BAS) est utilisé pour gérer les définitions de ressource CICS, la directive CICSPlex SM EYUPARM BASLOGMSG doit avoir pour valeur (YES) pour que la consignation soit activée.
Le fichier VSAM du référentiel du serveur CRD contient toutes les définitions de ressource par défaut ; il doit par conséquent être protégé contre les mises à jour tout en autorisant les développeurs à consulter les valeurs qui y sont conservées. Pour protéger le référentiel CRD, reportez-vous à Définition des profils de fichier afin d'obtenir des exemples de commande RACF.
Quand le message SOAP est reçu par CICS par l'intermédiaire de l'interface Web Service, il est traité par un pipeline. Un pipeline désigne un ensemble de gestionnaires des messages qui sont exécutés dans l'ordre. CICS lit le fichier de configuration du pipeline pour déterminer les gestionnaires de messages à appeler dans le pipeline. Un gestionnaire des messages est un programme qui permet d'exécuter un traitement spécial des demandes et réponses de service Web.
Application Deployment Manager procure un exemple de fichier de configuration de pipeline qui spécifie l'appel d'un gestionnaire des messages et d'un programme de traitement de l'en-tête SOAP.
Le gestionnaire de message de pipeline (ADNTMSGH) est utilisé par sécurité dans le traitement de l'ID utilisateur et des mots de passe dans l'en-tête du protocole SOAP. ADNTMSGH est référencé par le fichier de configuration de pipeline et doit donc être placé dans la concaténation RPL CICS.
CPIH correspond à l'ID de transaction par défaut sous lequel une application appelée par un pipeline sera exécutée. En règle générale, CPIH est défini pour un niveau minimal d'autorisation.
Developer for System z met à disposition plusieurs transactions qui sont utilisées par le serveur CRD lors de la définition et de la consultation des ressources CICS. Ces ID de transaction sont définis par le serveur CRD en fonction de l'opération demandée. Reportez-vous à la section "(Facultatif) Gestionnaire de déploiement d'application" du Guide de configuration de l'hôte (SC11-6285) pour obtenir plus d'informations sur la personnalisation des ID de transaction.
Transaction | Description |
---|---|
ADMS | Pour les demandes, par l'outil de traitement des manifestes, de modification des ressources CICS. Généralement destiné aux administrateurs CICS. Cette transaction requiert des droits d'accès de haut niveau. |
ADMI | Pour les demandes qui définissent, installent ou désinstallent les ressources CICS. Cette transaction peut requérir des droits d'accès de niveau intermédiaire en fonction des règles d'administration de votre site. |
ADMR | Pour toutes les autres demandes qui récupèrent des informations sur les ressources ou l'environnement CICS. Cette transaction peut requérir des droits d'accès de niveau minimum en fonction des règles d'administration de votre site. |
Certaines ou toutes les demandes de définition de ressource effectuées par les transactions du serveur CRD doivent être sécurisées. Au minimum, les commandes de mise à jour (mise à jour des paramètres de service Web par défaut, des paramètres de descripteur par défaut et de liaison de noms de fichiers) doivent être sécurisées pour éviter que les administrateurs CICS émettent ces commandes permettant de définir les paramètres par défaut de la ressource globale.
Quand la transaction est rattachée, la vérification de la sécurité de la ressource CICS, si elle est activée, garantit que l'ID utilisateur est autorisé à exécuter l'ID de transaction.
La vérification de la ressource est contrôlée par l'option RESSEC dans la transaction qui est en cours de fonctionnement, c'est-à-dire le paramètre d'initialisation système RESSEC, et pour le serveur CRD, le paramètre d'initialisation système XPCT.
La vérification de la ressource a lieu uniquement si la valeur du paramètre d'initialisation système XPCT est différente de NO et que l'option RESSEC de la définition TRANSACTION est définie sur YES ou que le paramètre d'initialisation système RESSEC est défini sur ALWAYS.
RALTER GCICSTRN SYSADM UACC(NONE) ADDMEM(ADMS)
PERMIT SYSADM CLASS(GCICSTRN) ID(#cicsadmin)
RALTER GCICSTRN DEVELOPER UACC(NONE) ADDMEM(ADMI)
PERMIT DEVELOPER CLASS(GCICSTRN) ID(#cicsdeveloper)
RALTER GCICSTRN ALLUSER UACC(READ) ADDMEM(ADMR)
SETROPTS RACLIST(TCICSTRN) REFRESH
Le chiffrement SSL du flux de données est pris en charge lorsque le client Application Deployment Manager utilise l'interface Web Services pour appeler le serveur CRD. L'utilisation de SSL pour ces communications est contrôlée par le mot clé SSL(YES) dans la définition CICSTS TCPIPSERVICE (voir le document RACF Security Guide for CICSTS).
CICSTS offre la possibilité de protéger les ressources et les commandes permettant de les manipuler. Certaines actions du gestionnaire de déploiement d'application risquent de ne pas aboutir si la sécurité est active mais pas intégralement configurée (autorisation de manipuler les nouveaux types de ressources, par exemple)
En cas de problème de fonctionnement dans le gestionnaire de déploiement d'application, examinez le journal CICS des messages, tel que celui indiqué ci-dessous, et effectuez l'action corrective indiquée dans le document RACF Security Guide for CICSTS.
DFHXS1111 %date %time %applid %tranid Security violation by user
%userid at netname %portname for resource %resource in class
%classname. SAF codes are (X'safresp',X'safreas'). ESM codes are
(X'esmresp',X'esmreas').
Developer for System z offre l'utilitaire d'administration qui permet aux administrateurs CICS de fournir des valeurs par défaut pour les définitions de ressource CICS. Ces valeurs par défaut peuvent être accessibles en lecture seulement ou peuvent être éditées par le développeur d'application.
L'utilitaire d'administration est appelé par un modèle de travail ADNJSPAU dans le fichier FEK.#CUST.JCL. L'utilisation de cet utilitaire requiert les droits d'accès UPDATE au référentiel CRD.
ADNJSPAU se trouve dans FEK.#CUST.JCL, sauf si le programmeur système z/OS a indiqué un autre emplacement lorsqu'il a personnalisé et soumis le travail FEK.SFEKSAMP(FEKSETUP). Reportez-vous à la section "Configuration personnalisée" du Guide de configuration de l'hôte (SC11-6285) pour obtenir plus de détails.
UPDATE | Les attributs qui suivent ce mot clé peuvent être mis à jour par un développeur d'applications à l'aide de Developer for System z. Il s'agit également de la valeur par défaut pour les attributs omis. |
PROTECT | Les attributs qui suivent ce mot clé sont affichés, mais ils sont protégés contre toute mise à jour par un développeur d'applications qui utilise Developer for System z. |
HIDDEN | Les attributs qui suivent ce mot clé ne sont pas affichés et sont protégés contre toute mise à jour par un développeur d'applications qui utilise Developer for System z. |
Voir l'exemple de code ADNJSPAU.
//ADNJSPAU JOB <JOB PARAMETERS>
//*
//ADNSPAU EXEC PGM=ADNSPAU,REGION=1M
//STEPLIB DD DISP=SHR,DSN=FEK.SFEKLOAD
//ADMREP DD DISP=OLD,DSN=FEK.#CUST.ADNREPF0
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
*
* CICSPlex SM parameters
*
DEFINE CPSMNAME( )
*DEFINE STAGINGGROUPNAME(ADMSTAGE)
*
* Manifest export rule
*
DEFINE MANIFESTEXPORTRULE(installOnly)
*
* CICS resource definition defaults
* Omitted attributes default to UPDATE.
*
* DB2TRAN default attributes
*
DEFINE DB2TRAN()
UPDATE DESCRIPTION()
ENTRY()
TRANSID()
*
* DOCTEMPLATE default attributes
*
DEFINE DOCTEMPLATE()
UPDATE DESCRIPTION()
TEMPLATENAME()
FILE() TSQUEUE() TDQUEUE() PROGRAM() EXITPGM()
DDNAME(DFHHTML) MEMBERNAME()
HFSFILE()
APPENDCRLF(YES) TYPE(EBCDIC)
*
* File default attributes
*
DEFINE FILE()
UPDATE DESCRIPTION()
RECORDSIZE() KEYLENGTH()
RECORDFORMAT(V) ADD(NO)
BROWSE(NO) DELETE(NO) READ(YES) UPDATE(NO)
REMOTESYSTEM() REMOTENAME()
PROTECT DSNAME() RLSACCESS(NO) LSRPOOLID(1) STRINGS(1)
STATUS(ENABLED) OPENTIME(FIRSTREF)
DISPOSITION(SHARE) DATABUFFERS(2) INDEXBUFFERS(1)
TABLE(NO) MAXNUMRECS(NOLIMIT)
READINTEG(UNCOMMITTED) DSNSHARING(ALLREQS)
UPDATEMODEL(LOCKING) LOAD(NO)
JNLREAD(NONE) JOURNAL(NO)
JNLSYNCREAD(NO) JNLUPDATE(NO)
JNLADD(NONE) JNLSYNCWRITE(YES)
RECOVERY(NONE) FWDRECOVLOG(NO)
BACKUPTYPE(STATIC)
PASSWORD() NSRGROUP()
CFDTPOOL() TABLENAME()
*
* Mapset default attributes
*
DEFINE MAPSET()
UPDATE DESCRIPTION()
PROTECT RESIDENT(NO) STATUS(ENABLED)
USAGE(NORMAL) USELPACOPY(NO)
** Processtype default attributes
*
DEFINE PROCESSTYPE()
UPDATE DESCRIPTION()
FILE(BTS)
PROTECT STATUS(ENABLED)
AUDITLOG() AUDITLEVEL(OFF)
*
* Program default attributes
*
DEFINE PROGRAM()
UPDATE DESCRIPTION()
CEDF(YES) LANGUAGE(LE370)
REMOTESYSTEM() REMOTENAME() TRANSID()
PROTECT API(CICSAPI) CONCURRENCY(QUASIRENT)
DATALOCATION(ANY) DYNAMIC(NO)
EXECKEY(USER) EXECUTIONSET(FULLAPI)
RELOAD(NO) RESIDENT(NO)
STATUS(ENABLED) USAGE(NORMAL) USELPACOPY(NO)
HIDDEN JVM(NO) JVMCLASS() JVMPROFILE(DFHJVMPR)
*
* TDQueue default attributes
*
DEFINE TDQUEUE()
UPDATE DESCRIPTION()
TYPE(INTRA)
* Extra partition parameters
DDNAME() DSNAME()
REMOTENAME() REMOTESYSTEM() REMOTELENGTH(1)
RECORDSIZE() BLOCKSIZE(0) RECORDFORMAT(UNDEFINED)
BLOCKFORMAT() PRINTCONTROL() DISPOSITION(SHR)
* Intra partition parameters
FACILITYID() TRANSID() TRIGERRLEVEL(1)
USERID()
* Indirect parameters
INDIRECTNAME()
PROTECT WAIT(YES) WAITACTION(REJECT)
* Extra partition parameters
DATABUFFERS(1)
SYSOUTCLASS() ERROROPTION(IGNORE)
OPENTIME(INITIAL) REWIND(LEAVE) TYPEFILE(INPUT)
* Intra partition parameters
ATIFACILITY(TERMINAL) RECOVSTATUS(NO)
*
* Transaction default attributes
*
DEFINE TRANSACTION()
UPDATE DESCRIPTION()
PROGRAM()
TWASIZE(0)
REMOTESYSTEM() REMOTENAME() LOCALQ(NO)
PROTECT PARTITIONSET() PROFILE(DFHCICST)
DYNAMIC(NO) ROUTABLE(NO)
ISOLATE(YES) STATUS(ENABLED)
RUNAWAY(SYSTEM) STORAGECLEAR(NO)
SHUTDOWN(DISABLED)
TASKDATAKEY(USER) TASKDATALOC(ANY)
BREXIT() PRIORITY(1) TRANCLASS(DFHTCL00)
DTIMOUT(NO) RESTART(NO) SPURGE(NO) TPURGE(NO)
DUMP(YES) TRACE(YES) CONFDATA(NO)
OTSTIMEOUT(NO) WAIT(YES) WAITTIME(00,00,00)
ACTION(BACKOUT) INDOUBT(BACKOUT)
RESSEC(NO) CMDSEC(NO)
TRPROF()
ALIAS() TASKREQ()
XTRANID() TPNAME() XTPNAME()
*
* URDIMAP attributes
*
DEFINE URIMAP()
UPDATE USAGE(CLIENT)
DESCRIPTION()
PATH(/required/path)
TCPIPSERVICE()
TRANSACTION()
PROGRAM()
PROTECT ANALYZER(NOANALYZER)
ATOMSERVICE()
CERTIFICATE()
CHARACTERSET()
CIPHERS()
CONVERTER()
HFSFILE()
HOST(host.mycompany.com)
HOSTCODEPAGE()
LOCATION()
MEDIATYPE()
PIPELINE()
PORT(NO)
REDIRECTTYPE(NONE)
SCHEME(HTTP)
STATUS(ENABLED)
TEMPLATENAME()
USERID()
WEBSERVICE()
*
* Optional file name to VSAM data set name binding
*
*DEFINE DSBINDING() DSNAME()
/*
Developer for System z version 7.6.1 bénéficie désormais de la prise en charge d'URIMAP pour l'utilitaire d'administration. Pour pouvoir utiliser la prise en charge d'URIMAP, vous devez allouer au fichier VSAM du référentiel CRD la taille d'enregistrement maximale de 3000. Jusqu'à Developer for System z version 7.6.1, le modèle du travail d'allocation du référentiel CRD utilise une taille d'enregistrement maximale de 2000.
Les messages ci-après sont générés par l'utilitaire d'administration dans SYSPRINT DD. Les messages CRAZ1803E, CRAZ1891E, CRAZ1892E, et CRAZ1893E contiennent les codes de statut de fichier ainsi que les codes de retour, de fonction et de commentaire VSAM. Les codes de retour, de fonction et de commentaire de VSAM sont expliqués dans le document DFSMS Macro Instructions for Data Sets (SC26-7408). Les codes de statut de fichier sont expliqués dans le document Enterprise COBOL for z/OS Language Reference (SC27-1408).
Explication : L'utilitaire d'administration du programmeur système a été correctement exécuté.
Réponse de l'utilisateur : Aucune.
Explication : L'utilitaire d'administration du programmeur système a fini de traiter un ou plusieurs avertissements détectés lors du traitement des instructions de contrôle.
Réponse de l'utilisateur : Vérifiez les autres messages d'avertissement.
Explication : L'utilitaire d'administration du programmeur système a rencontré une erreur grave.
Réponse de l'utilisateur : Vérifiez les autres messages d'avertissement.
Explication : L'utilitaire d'administration du programmeur système a rencontré une erreur grave lors de l'ouverture du référentiel CRD.
Réponse de l'utilitaire : Vérifiez les codes de statut, de retour, de fonction et de commentaire VSAM.
Explication : L'utilitaire d'administration du programmeur système a rencontré une instruction de contrôle d'entrée non reconnue.
Réponse de l'utilisateur : Vérifiez qu'une commande DEFINE est bien suivie d'un seul espace, puis du mot clé CPSMNAME, STAGINGGROUPNAME, MANIFESTEXPORTRULE, DSBINDING, DB2TRAN, DOCTEMPLATE, FILE, MAPSET, PROCESSTYPE, PROGRAM, TDQUEUE ou TRANSACTION.
Explication : L'utilitaire d'administration du programmeur système traite l'instruction de contrôle d'entrée du mot clé DEFINE.
Réponse de l'utilisateur : Aucune.
Explication : L'utilitaire d'administration du programmeur système a rencontré une règle d'exportation de manifeste non valide.
Réponse de l'utilisateur : Vérifiez que la valeur du mot clé MANIFESTEXPORTRULE est "installOnly", "exportOnly" ou "both".
Explication : L'utilitaire d'administration du programmeur système traitait une instruction de contrôle DEFINE DSBINDING dans laquelle il manque le mot clé DSNAME.
Réponse de l'utilisateur : Vérifiez que l'instruction de contrôle DEFINE DSBINDING contient le mot clé DSNAME.
Explication : L'utilitaire d'administration du programmeur système traitait une instruction de contrôle DEFINE lorsqu'il a rencontré une valeur non valide pour le mot clé spécifié.
Réponse de l'utilisateur : Vérifiez que la longueur et la valeur du mot clé spécifié sont correctes.
Explication : L'utilitaire d'administration du programmeur système traitait une instruction de contrôle DEFINE lorsqu'il a rencontré une erreur de syntaxe pour un mot clé ou sa valeur.
Réponse de l'utilisateur : Vérifiez que la valeur du mot clé est placée entre parenthèses et qu'elle est immédiatement suivie du mot clé. Le mot clé et sa valeur doivent se trouver sur la même ligne.
Explication : L'utilitaire d'administration du programmeur système a rencontré une erreur de clé en double lors de l'enregistrement dans le référentiel CRD.
Réponse de l'utilitaire : Vérifiez les codes de statut, de retour, de fonction et de commentaire VSAM.
Explication : L'utilitaire d'administration du programmeur système a rencontré une grave erreur lors de l'écriture dans le référentiel CRD.
Réponse de l'utilitaire : Vérifiez les codes de statut, de retour, de fonction et de commentaire VSAM.
Explication : L'utilitaire d'administration du programmeur système a rencontré une erreur grave lors de lecture dans le référentiel CRD.
Réponse de l'utilitaire : Vérifiez les codes de statut, de retour, de fonction et de commentaire VSAM.
Définissez le débogueur sur une région CICS, comme indiqué dans l'exemple de travail de mise à jour de CDS AQECSD. AQECSD se trouve dans FEK.#CUST.JCL, sauf si le programmeur système z/OS a indiqué un autre emplacement lorsqu'il a personnalisé et soumis le travail FEK.SFEKSAMP(FEKSETUP). Pour plus de détails, reportez-vous à "Configuration personnalisée" dans le guide de configuration de l'hôte (SC23-7658).
Ce chapitre vous guide lors du processus d'amélioration de Developer for System z en créant des routines d'exit.
Developer for System z fournit des points d'exit pour la sélection d'événements Developer for System z. Un point d'exit est un point spécifique dans le traitement d'une fonction où la fonction appelle une routine d'appel s'il en existe une. Vous pouvez créer une routine d'exit pour effectuer un traitement supplémentaire.
Contrairement aux points d'exit standard, les points d'exit Developer for System z ne vous permettent pas de changer le comportement de la fonction. La routine d'exit, s'il en existe une, est appelée de manière asynchrone une fois la fonction terminée. Le traitement Developer for System z n'attend pas la fin de la routine. Il ne vérifie pas non plus l'état d'achèvement.
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -D<point_exit>.action=<exit_utilisateur>"
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -D<point_exit>.action.id=<idutilisateur>"
Par défaut, l'ID utilisateur attribué au démon RSE permet d'exécuter la routine utilisateur fournie. Supprimez la mise en commentaire et spécifiez un ID utilisateur afin d'utiliser l'ID spécifié pour l'exécution de l'ID utilisateur. Il n'est pas nécessaire d'indiquer de mot de passe car RSE génère un PassTicket à utiliser comme mot de passe lorsqu'il passe à l'ID utilisateur indiqué.
Les routines d'exit utilisateur sont appelées en tant que commande shell z/OS UNIX à laquelle il est possible d'ajouter un ou plusieurs arguments. La routine d'exit que vous développez doit donc être exécutable à partir de la ligne de commande z/OS UNIX. Les techniques communes de codage incluent le script shell z/OS UNIX et la commande exec REXX z/OS UNIX mais il est également possible d'utiliser un code compilé, tel C/C++.
Voir UNIX System Services User's Guide (SA22-7801) pour plus d'informations sur les scripts de shell z/OS UNIX. Voir le document Using REXX and z/OS UNIX System Services (SA22-7806) pour en savoir plus sur les extensions du langage REXX spécifiques à z/OS.
$ chmod 755 process_logon.sh
$ ls -l process_logon.sh
-rwxr-xr-x 1 IBMUSER SYS1 2228 Feb 28 23:44 process_logon.sh
Les définitions dans rsed.envvars sont disponibles dans la routine d'exit utilisateur en tant que variables d'environnement.
RSE appelle la routine d'exit utilisateur avec une seule chaîne d'arguments. La chaîne d'arguments peut être une seule valeur ou une seule chaîne qui contient plusieurs mots clés et valeurs délimités par des espaces. Pour plus d'informations, voir Points d'exit disponibles.
Developer for System z utilise l'ID de message de console FEK910I pour afficher les données relatives aux exits utilisateur.
FEK910I <POINT_EXIT> EXIT: invoking <point_exit> processing exit
in thread <id_unité_exécution>
FEK910I <POINT_EXIT> EXIT: <message>
FEK910I <POINT_EXIT> EXIT: completed <point_exit> processing exit
in thread <id_unité_exécution>
Developer for System z permet d'exécuter une routine d'utilisateur avec l'ID utilisateur de la tâche démarrée ou avec un ID utilisateur indiqué. Toutefois, vous pouvez souhaiter exécuter certaines actions dans la routine utilisateur en utilisant un autre ID utilisateur, tel l'ID utilisateur client se trouvant dans la routine d'exit de connexion. Pour cela, utilisez les services z/OS UNIX standard, comme cela est présenté dans les exemples suivants.
#! /bin/sh
myID=ibmuser
echo a $(id)
echo 'echo b $(id)' | su -s $myID
echo "echo c \$(id)" | su -s $myID
cat /u/ibmuser/iefbr14
echo "submit /u/ibmuser/iefbr14" | su -s $myID
Cet exit de connexion exemple, exécuté par l'ID utilisateur de la tâche démarrée, génère les messages de console suivants :
+FEK910I LOGON EXIT: invoking logon processing exit in thread 411
+FEK910I LOGON EXIT: a uid=8(STCRSE) gid=1(STCGROUP)
+FEK910I LOGON EXIT: b uid=1(IBMUSER) gid=0(SYS1)
+FEK910I LOGON EXIT: c uid=1(IBMUSER) gid=0(SYS1)
+FEK910I LOGON EXIT: //IEFBR14 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1)
+FEK910I LOGON EXIT: //IEFBR14 EXEC PGM=IEFBR14
$HASP100 IEFBR14 ON INTRDR FROM STC03919
IBMUSER
IRR010I USERID IBMUSER IS ASSIGNED TO THIS JOB.
+FEK910I LOGON EXIT: JOB JOB03926 submitted from path '/u/ibmuser/iefbr14'
ICH70001I IBMUSER LAST ACCESS AT 00:46:13 ON MONDAY, MARCH 19, 2012
$HASP373 IEFBR14 STARTED - INIT 2 - CLASS A - SYS CD08
IEF403I IEFBR14 - STARTED - TIME=00.46.14
+FEK910I LOGON EXIT: completed logon processing exit in thread 411
IEFBR14 IEFBR14 IEFBR14 0000
IEF404I IEFBR14 - ENDED - TIME=00.46.14
$HASP395 IEFBR14 ENDED
$HASP309 INIT 2 INACTIVE ******** C=BA
/* rexx */
myID='ibmuser'
say userid()
address SYSCALL 'getpwnam' myID 'pw.'
say pw.1 pw.2 pw.3 pw.4 pw.5
address SYSCALL 'seteuid' pw.2 /* PW_UID = 2 */
say retval errno errnojr
say userid()
Cet exit de connexion exemple, exécuté par l'ID utilisateur de la tâche démarré, génère les messages de console suivants :
+FEK910I LOGON EXIT: invoking logon processing exit in thread 515
+FEK910I LOGON EXIT: STCRSE
+FEK910I LOGON EXIT: IBMUSER 1 0 / /bin/sh
+FEK910I LOGON EXIT: 0 0 0
+FEK910I LOGON EXIT: IBMUSER
+FEK910I LOGON EXIT: completed logon processing exit in thread 515
L'exit utilisateur d'audit est appelé à la fermeture du fichier journal d'audit actif. (L'audit se poursuit car RSE est passé à un nouveau fichier d'audit.)
/usr/lpp/rdz/samples/process_audit.rex
Cette commande exec REXX z/OS UNIX génère un travail par lots qui traitera le journal d'audit fermé.
L'exit utilisateur de connexion est appelé lorsqu'un utilisateur a terminé le processus de connexion.
/usr/lpp/rdz/samples/process_logon.sh
Ce script de shell z/OS UNIX exemple crée un message de connexion dans la console.
Ce chapitre vous aide à simuler une procédure d'ouverture de session TSO en ajoutant des instructions de définition de données et des fichiers à l'environnement TSO dans Developer for System z.
Le service Commandes TSO est le composant Developer for System z qui exécute les commandes TSO et ISPF (par lots) et renvoie le résultat au client demandeur. Ces commandes peuvent être demandées implicitement par le produit, ou explicitement par l'utilisateur.
Les exemples de membres fournis avec Developer for System z créent un environnement TSO/ISPF minimal. Si les développeurs doivent accéder à des bibliothèques personnalisées ou tierces, le programmeur système z/OS doit ajouter les instructions de définition de données et les bibliothèques nécessaires à l'environnement du service Commandes TSO. Bien que l'implémentation soit différente dans Developer for System z, la logique sous-jacente est identique à la procédure d'ouverture de session TSO.
Le fichier de configuration ISPF.conf (situé par défaut dans le répertoire /etc/rdz/) définit l'environnement TSO/ISPF utilisé par Developer for System z. Il existe un seul fichier de configuration ISPF.conf actif, lequel est utilisé par tous les utilisateurs Developer for System z.
sysproc=ISP.SISPCLIB,FEK.SFEKPROC
ispmlib=ISP.SISPMENU
isptlib=ISP.SISPTENU
ispplib=ISP.SISPPENU
ispslib=ISP.SISPSLIB
ispllib=ISP.SISPLOAD
myDD=HLQ1.LLQ1,HLQ2.LLQ2
#_RSE_ISPF_OPTS="$_RSE_ISPF_OPTS&ISPPROF=&SYSUID..ISPPROF"
Supprimez la mise en commentaire de l'instruction (en retirant le signe dièse (#) initial) et fournissez le nom qualifié complet de fichier de données du profil ISPF existant pour utiliser cette fonction.
*allocjob = ISP.SISPSAMP(ISPZISP2)
Bien que ISPF.conf prenne uniquement en charge l'appel d'une seule commande exec, cette dernière peut en revanche appeler une autre commande exec sans limite. L'ID utilisateur du client transmis comme paramètre donne la possibilité d'appeler des commandes exec d'allocation personnalisées. Vous pouvez, par exemple, vérifier si le membre USERID’.EXEC(ALLOC)’ existe et l'exécuter.
Si les scénarios exec d'allocation décrits dans les sections précédentes ne répondent pas à vos besoins spécifiques, vous pouvez créer des instances de serveur de communication RSE Developer for System z différentes, chacune d'elle utilisant son propre fichier ISPF.conf. L'inconvénient majeur de la méthode décrite ci-dessous est que les utilisateurs de Developer for System z doivent se connecter à différents serveurs sur le même système hôte pour obtenir l'environnement TSO voulu.
$ cd /etc/rdz
$ mkdir /etc/rdz/tso2
$ cp rsed.envvars /etc/rdz/tso2
$ cp ISPF.conf /etc/rdz/tso2
$ ls /etc/rdz/tso2
ISPF.conf rsed.envvars
$ oedit /etc/rdz/tso2/rsed.envvars
-> change: _RSE_RSED_PORT=4037
-> change: CGI_ISPCONF=/etc/rdz/tso2
-> change: -Ddaemon.log=/var/rdz/logs/tso2
-> change: -Duser.log=/var/rdz/logs/tso2
-> add at the END:
# -- NEEDED TO FIND THE REMAINING CONFIGURATION FILES
CFG_BASE=/etc/rdz
CLASSPATH=.:$CFG_BASE:$CLASSPATH
# --
$ oedit /etc/rdz/tso2/ISPF.conf
-> change: change as needed
Les commandes de l'exemple ci-dessus copient les fichiers de configuration Developer for System z à modifier dans le répertoire qui vient d'être créé, tso2. La variable CGI_ISPCONF dans rsed.envvars doit être mise à jour pour définir le nouveau répertoire de base ISPF.conf . De plus, daemon.log et user.log doivent être mis à jour pour définir un nouvel emplacement de journal (lequel est créé automatiquement s'il n'existe pas). La mise à jour de _RSE_RSED_PORT permet de garantir que le démon RSE existant et le nouveau démon RSE utiliseront des numéros de port uniques. La mise à jour de la variable CLASSPATH permet de s'assurer que RSE peut localiser les fichiers de configuration qui n'ont pas été copiés dans tso2. Le fichier ISPF.conf peut lui-même être mis à jour pour que vous puissiez l'adapter à vos besoins. Notez que la zone de travail ISPF (variable CGI_ISPWORK dans rsed.envvars) peut être partagée entre les deux instances.
Les éléments restants créent une nouvelle tâche démarrée pour RSE qui utilise un nouveau numéro de port et les nouveaux fichiers de configuration /etc/rdz/tso2. Notez que si la variable _RSE_RSED_PORT n'est pas modifiée dans rsed.envvars, la nouvelle tâche démarrée doit spécifier un nouveau port comme argument de démarrage.
Pour plus d'informations sur les actions présentées précédemment dans cette section, voir IBM Rational Developer for System z - Guide de configuration de l'hôte (SC23-7658).
Parfois, vous pouvez avoir besoin de plusieurs instances de Developer for System z actives sur un même système, lors du test d'une mise à niveau, par exemple. Cependant, certaines ressources (les ports TCP/IP, par exemple) ne peuvent pas être partagées. Les paramètres par défaut ne sont donc pas toujours applicables. Consultez les informations de cette section afin de programmer la coexistence des différentes instances de Developer for System z, pour pouvoir ensuite les personnaliser à l'aide de ce guide de configuration.
Bien qu'il soit possible de partager certaines parties de Developer for System z entre deux instances (ou plus), il est recommandé de NE PAS le faire, sauf si leurs niveaux de logiciel sont identiques et que les seules modifications sont effectuées dans les membres de configuration. Developer for System z offre suffisamment de possibilités de personnalisation pour que plusieurs instances ne se chevauchent pas et nous vous recommandons vivement d'utiliser ces fonctions.
Dans un nombre limité de circonstances, vous pouvez partager tout sauf (certains) des composants personnalisables. La mise à disposition d'un accès non-SSL pour un utilisation sur site, et d'une communication encodée SSL pour une utilisation hors site est un exemple.
Avertissement : La configuration partagée NE peut PAS être utilisée de manière sûre pour tester la maintenance, ou effectuer une prévisualisation technique ou une nouvelle édition.
|
Pour configurer une autre instance d'une installation active de Developer for System z, suivez de nouveau la procédure de personnalisation pour les composants qui sont différents, en utilisant d'autres fichiers, répertoires et ports afin d'éviter un chevauchement avec la configuration en cours.
Dans l'exemple SSL mentionné précédemment, la configuration du démon RSE en cours peut être clonée, après quoi la configuration clonée peut être mise à jour. Le JCL de démarrage du démon RSE peut ensuite être cloné et personnalisé avec un nouveau port TCP/IP et l'emplacement des fichiers de configuration mis à jour. Les personnalisations du système MVS (moniteur de travaux JES etc.) peuvent être partagées entre les instances SSL et les instances non-SSL. Il en résulte les actions suivantes :
$ cd /etc/rdz
$ mkdir /etc/rdz/ssl
$ cp rsed.envvars /etc/rdz/ssl
$ cp ssl.properties /etc/rdz/ssl
$ ls /etc/rdz/ssl/
rsed.envvars ssl.properties
$ oedit /etc/rdz/ssl/rsed.envvars
-> change: _RSE_RSED_PORT=4047
-> change: -Ddaemon.log=/var/rdz/logs/ssl
-> change: -Duser.log=/var/rdz/logs/ssl
-> add at the END:
# -- NEEDED TO FIND THE REMAINING CONFIGURATION FILES
CFG_BASE=/etc/rdz
CLASSPATH=.:$CFG_BASE:$CLASSPATH
# --
$ oedit /etc/rdz/ssl/ssl.properties
-> change: change as needed
Les commandes de l'exemple précédent copient les fichiers de configuration Developer for System z à modifier dans le répertoire qui vient d'être créé, ssl. Les variables daemon.log et user.log dans rsed.envvars doivent être mises à jour pour définir un nouvel emplacement de journal (qui est créé automatiquement, s'il n'existe pas). La mise à jour de la variable CLASSPATH permet de s'assurer que RSE peut localiser les fichiers de configuration qui n'ont pas été copiés dans ssl. Le fichier ssl.properties peut lui-même être mis à jour en fonction de vos besoins.
Les éléments restants créent une nouvelle tâche démarrée pour RSE qui utilise un nouveau numéro de port et les nouveaux fichiers de configuration /etc/rdz/ssl.
Pour plus d'informations sur les actions présentées précédemment dans cette section, voir les sections connexes du document IBM Rational Developer for System z - Guide de configuration de l'hôte (SC23-7658).
Dans l'exemple SSL mentionné précédemment, les modifications entre le démon RSE non-SSL et le démon RSE compatible SSL sont minimales, ce qui permet d'automatiser le processus de maintien de la synchronisation de leurs fichiers rsed.envvars. Cela simplifie le déploiement de service car un seul fichier rsed.envvars doit être géré.
L'exemple suivant ajoute le numéro de port RSED aux noms de répertoire de journaux et met à jour le CLASSPATH de sorte que les clones trouvent les fichiers de configuration restants. L'exemple étend ensuite le JCL de la tâche démarrée du démon RSE compatible SSL pour cloner le fichier rsed.envvars du démon RSE non-SSL au démarrage, en mettant à jour le numéro de port pendant le processus. Le numéro de port étant intégré dans le nom de répertoire de journaux, il est automatiquement différent pour chacun des deux démons.
$ oedit /etc/rdz/rsed.envvars
-> change: -Ddaemon.log=/var/rdz/logs/$RSE_RSED_PORT
-> change: -Duser.log=/var/rdz/logs/$RSE_RSED_PORT
-> add at the END:
# -- NEEDED BY CLONES TO FIND THE REMAINING CONFIGURATION FILES
CFG_BASE=/etc/rdz
CLASSPATH=.:$CFG_BASE:$CLASSPATH
# --
$ mkdir /etc/rdz/ssl
$ cp /etc/rdz/ssl.properties /etc/rdz/etc/rdz/ssl
$ oedit /etc/rdz/ssl/ssl.properties
-> change: change as needed
//*
//* RSE DAEMON - SSL
//*
//RSED PROC IVP=, * 'IVP' to do an IVP test
// HOME='/usr/lpp/rdz',
// CNFG='/etc/rdz/ssl'
//*
// SET SED='"/RSED_PORT/s/4035/4034/"'
// SET FILE='rsed.envvars'
//*
//* copy /etc/rdz/rsed.envvars to /etc/rdz/ssl/rsed.envvars
//* and alter RSED_PORT
//*
//CLONE EXEC PGM=BPXBATCH,REGION=0M,COND=(4,LT),
// PARM='SH cd &CNFG;sed &SED ../&FILE>&FILE'
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//*
//* start RSED with the newly created rsed.envvars
//*
//RSED EXEC PGM=BPXBATSL,REGION=0M,TIME=NOLIMIT,COND=(4,LT),
// PARM='PGM &HOME./bin/rsed.sh &IVP -C&CNFG'
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
// PEND
//*
Lorsque des modifications de code sont effectuées (maintenance, prévisualisation technique, nouvelle édition) ou que les modifications que vous effectuez sont complexes, il est recommandé de procéder à une autre installation de Developer for System z. La présente section décrit les points possibles de conflit entre différentes installations.
La liste ci-dessous décrit brièvement les éléments qui doivent être différents entre les instances de Developer for System z (fortement recommandé) :
Vous trouverez ci-dessous une présentation plus détaillée :
Le guide Developer for System z Messages et codes (SC11-7014) présente les messages et les codes retour générés par les composants Developer for System z. Le document Developer for System z - Answers to common host configuration and maintenance issues (SC14-7373) décrit différents problèmes pouvant survenir ainsi que la résolution de ces derniers.
Pour plus d'informations, reportez-vous à la section Support du site Web de Developer for System z (http://www-03.ibm.com/software/products/us/en/developerforsystemz/) pour consulter les notes techniques et disposer des dernières informations produites par notre équipe de support technique.
Dans la section Library du site Web (http://www-01.ibm.com/support/docview.wss?uid=swg27038517), vous pouvez également consulter la dernière version de la documentation de Developer for System z, notamment les livres blancs.
Le centre de documentation de Developer for System z (http://www-01.ibm.com/support/knowledgecenter/SSQ2R2_9.1.0/com.ibm.etools.getstart.wsentdev.doc/kc_version_welcome_rdz.html) fournit des informations sur le client Developer for System z et son interaction avec l'hôte (du point de vue du client).
La bibliothèque z/OS en ligne contient également des informations importantes, que vous pouvez consulter à l'adresse suivante : http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/.
https://www.ibm.com/developerworks/support/rational/rfe/
La tâche démarrée RSED prend en charge la commande de l'opérateur MODIFY LOGS pour collecter des journaux hôte et des informations de configuration Developer for System z. Les données collectées sont placées dans le fichier z/OS UNIX, $TMPDIR/feklogs.%sysname.%jobname, où $TMPDIR est la valeur de la directive TMPDIR dans rsed.envvars (/tmp par défaut), %sysname est le nom de votre système z/OS et %jobname est le nom de la tâche démarrée RSED.
Par défaut, seuls les journaux serveur sont collectés. Les options de la commande vous permettent de collecter différents journaux :
USER | Collecter les fichiers journaux pour l'ID utilisateur spécifié |
AUDIT | Collecter les journaux d'audit |
NOSERVER | Ne pas collecter les journaux serveur |
Developer for System z recherche dans votre produit de sécurité les droits d'accès aux profils FEK.CMD.LOGS.** pour déterminer si le demandeur est autorisé à collecter les journaux spécifiés. Par défaut, le demandeur est l'ID utilisateur de la tâche démarrée RSED, sauf si l'option OWNER est spécifiée. Seul le demandeur a accès au fichier contenant les données collectées.
Pour collecter les données avant que la tâche démarrée RSED puisse être lancée, Developer for System z fournit un modèle de travail (FEKLOGS), qui rassemble tous les fichiers journaux z/OS UNIX, ainsi que les informations d'installation et de configuration relatives à Developer for System z.
Le modèle de travail FEKLOGS se trouve dans FEK.#CUST.JCL, sauf si vous avez indiqué un autre emplacement lorsque vous avez personnalisé et soumis le travail FEK.SFEKSAMP(FEKSETUP). Reportez-vous à la section "Configuration personnalisée" du Guide de configuration de l'hôte (SC11-6285) pour obtenir plus de détails.
La personnalisation de FEKLOGS est présentée dans JCL. La personnalisation porte sur la mise à disposition de quelques variables clés.
Developer for System z crée des fichiers journaux utiles pour vous et pour le point service IBM dans l'identification et la résolution des incidents. La liste ci-après présente les fichiers journaux que vous pouvez créer sur le système hôte z/OS. Situé en regard des journaux spécifiques au produit, vérifiez bien le SYSLOG de tous les messages associés.
Les fichiers journaux basés sur le système MVS peuvent être localisés par l'intermédiaire de l'instruction de définition de données appropriée. Les fichiers journaux basés sur z/OS UNIX sont situés dans les répertoires suivants :
Les fichiers journaux propres à l'utilisateur sont placés dans userlog/$LOGNAME/, où userlog est la valeur combinée des directives user.log et DSTORE_LOG_DIRECTORY dans rsed.envvars, et $LOGNAME l'ID utilisateur de connexion (en majuscules). Si la directive user.log est mise en commentaire ou omise, le chemin du répertoire de base est utilisé. Ce chemin est défini dans le segment de sécurité OMVS de l'ID utilisateur. Si a directive DSTORE_LOG_DIRECTORY est mise en commentaire ou omise, .eclipse/RSE/ est ajouté à la valeur user.log.
Les fichiers journaux propres au démon RSE et au pool d'unités d'exécution RSE se trouvent dans le répertoire rép_base_démon/server, où rép_base_démon est la valeur de la directive daemon.log dans rsed.envvars. Si la directive daemon.log est mise en commentaire ou omise, le répertoire de base de l'ID utilisateur affecté à la tâche démarrée RSED est utilisé. Le répertoire de base est défini dans le segment de sécurité OMVS de l'ID utilisateur.
Les fichiers journaux du programme de vérification d'installation se situent dans le répertoire référencé par TMPDIR, si cette variable est définie dans rsed.envvars. Si ce n'est pas le cas, les fichiers sont créés dans le répertoire /tmp. La commande de l'opérateur MODIFY LOGS pour la tâche démarrée RSED crée également sa sortie dans ce répertoire.
Journalisation de trace et des opérations classiques. La valeur par défaut du modèle JCL FEK.#CUST.PROCLIB(DBGMGR) est SYSOUT=*.
Journalisation des opérations classiques. La valeur par défaut du modèle JCL FEK.#CUST.PROCLIB(JMON) est SYSOUT=*.
Journalisation de trace. La valeur par défaut du modèle JCL FEK.#CUST.PROCLIB(JMON) est SYSOUT=*. La fonction de trace est activée à l'aide du paramètre –TV, voir Fonction de trace du moniteur de travaux JES pour des informations détaillées.
Données réacheminées de stdout, la sortie Java standard du démon RSE. La valeur par défaut du modèle JCL FEK.#CUST.PROCLIB(RSED) est SYSOUT=*.
Données réacheminées de stderr, la sortie d'erreur standard Javadu démon RSE. La valeur par défaut du modèle JCL FEK.#CUST.PROCLIB(RSED) est SYSOUT=*.
Les fichiers journaux propres au démon RSE et au pool d'unités d'exécution RSE se trouvent dans le répertoire rép_base_utilisateur, où rép_base_utilisateur est la valeur de la directive daemon.log dans rsed.envvars. Si la directive daemon.log est mise en commentaire ou omise, le répertoire de base de l'ID utilisateur affecté à la tâche démarrée RSED est utilisé. Le répertoire de base est défini dans le segment de sécurité OMVS de l'ID utilisateur.
Plusieurs fichiers journaux sont créés par les composants associés à RSE. Ils sont tous placés dans userlog/$LOGNAME/, où userlog est la valeur combinée des directives user.log et DSTORE_LOG_DIRECTORY dans rsed.envvars, et $LOGNAME l'ID utilisateur de connexion (en majuscules). Si la directive user.log est mise en commentaire ou omise, le chemin du répertoire de base est utilisé. Ce chemin est défini dans le segment de sécurité OMVS de l'ID utilisateur. Si a directive DSTORE_LOG_DIRECTORY est mise en commentaire ou omise, .eclipse/RSE/ est ajouté à la valeur user.log.
Journalisation de la communication de SCLM Developer Toolkit, où userlog est la valeur combinée des directives user.log et DSTORE_LOG_DIRECTORY dans rsed.envvars, et $LOGNAME l'ID utilisateur de connexion (en majuscules). Si la directive user.log est mise en commentaire ou omise, le chemin du répertoire de base est utilisé. Ce chemin est défini dans le segment de sécurité OMVS de l'ID utilisateur. Si a directive DSTORE_LOG_DIRECTORY est mise en commentaire ou omise, .eclipse/RSE/ est ajouté à la valeur user.log.
Quand vous ouvrez une connexion avec CARMA à l'aide de l'interface de traitement par lots, FEK.#CUST.SYSPROC(CRASUBMT) démarre un travail de serveur (avec l'ID utilisateur de l'utilisateur en tant que propriétaires) appelé CRAport, où port est le port TCP/IP utilisé.
Si l'instruction de définition de données CARMALOG est indiquée dans la méthode de démarrage CARMA sélectionnée, le journal de CARMA est réacheminé vers cette instruction de définition de données dans le travail de serveur. Dans le cas contraire, elle est dirigée vers SYSPRINT.
L'instruction de définition de données SYSPRINT du travail de serveur contient le journal de CARMA, si l'instruction de définition de données CARMALOG n'est pas définie.
L'instruction de définition de données SYSTSPRT du travail de serveur contient les messages système (TSO) pour le démarrage du serveur CARMA.
Journalisation de la communication de CARMA, où userlog est la valeur combinée des directives user.log et DSTORE_LOG_DIRECTORY dans rsed.envvars, et $LOGNAME l'ID utilisateur de connexion (en majuscules). Si la directive user.log est mise en commentaire ou omise, le chemin du répertoire de base est utilisé. Ce chemin est défini dans le segment de sécurité OMVS de l'ID utilisateur. Si a directive DSTORE_LOG_DIRECTORY est mise en commentaire ou omise, .eclipse/RSE/ est ajouté à la valeur user.log.
La commande fekfivpc (test du programme de vérification de l'installation lié à CARMA) crée le fichier fekfivpc.log pour documenter la communication entre RSE et CARMA. Le journal est créé dans le répertoire référencé par TMPDIR, si cette variable est définie dans rsed.envvars. Si ce n'est pas le cas, le fichier est créé dans le répertoire /tmp.
Sortie de la commande fekfivpi -file (test du programme de vérification de l'installation lié à la passerelle client TSO/ISPF). Le journal est créé dans le répertoire référencé par TMPDIR, si cette variable est définie dans rsed.envvars. Si ce n'est pas le cas, le fichier est créé dans le répertoire /tmp.
Sortie de la commande fekfivps -file (test du programme de vérification de l'installation lié à SCLMDT). Le journal est créé dans le répertoire référencé par TMPDIR, si cette variable est définie dans rsed.envvars. Si ce n'est pas le cas, le fichier est créé dans le répertoire /tmp.
La définition de données SYSTSPRT de l'étape appelant la procédure de révision du code contient les messages du système frontal qui pilote le processus d'analyse de code.
La définition de données WORKSPCE de l'étape appelant la procédure de révision du code contient les messages de journal de l'espace de travail Eclipse du processus d'analyse de code.
La définition de données ERRMSGS de l'étape appelant la procédure de révision du code contient la sortie stderr du processus d'analyse de code.
La définition de données SYSTSPRT de l'étape appelant la procédure de révision du code contient les messages du système frontal qui pilote le processus d'analyse de code.
La définition de données WORKSPCE de l'étape appelant la procédure de révision du code contient les messages de journal de l'espace de travail Eclipse du processus d'analyse de code.
La définition de données ERRMSGS de l'étape appelant la procédure de révision du code contient la sortie stderr du processus d'analyse de code.
Quand un produit subit une fin anormale, un vidage mémoire est créé pour aider à l'identification de l'incident. La disponibilité et l'emplacement de ces fichiers de vidage dépendent pour une grande part des paramètres spécifiques du site. Les vidages ne peuvent pas être créés, ou les vidages peuvent être créés dans des emplacements différents de ceux mentionnés dans les sections suivantes.
Quand le programme fonctionne sous MVS, vérifiez les fichiers de vidage système ainsi que votre JCL pour les instructions de définition de données suivantes (selon le produit) :
Pour plus d'informations sur ces instructions de définition de données, voir MVS JCL Reference (SA22-7597) et Language Environment Debugging Guide (GA22-7560).
Dans z/OS UNIX, la plupart des fichiers de vidage de Developer for System z sont commandés par la machine virtuelle Java (JVM).
La JVM crée un ensemble d'agents de vidage par défaut lors de son initialisation (SYSTDUMP et JAVADUMP). Vous pouvez changer cet ensemble d'agents de vidage à l'aide de la variable d'environnement JAVA_DUMP_OPTS et même changer l'ensemble à l'aide de -Xdump sur la ligne de commande. Les options de ligne de commande de la JVM sont définies dans la directive _RSE_JAVAOPTS de rsed.envvars. Ne modifiez pas les paramètres de vidage sans instruction du point service IBM.
Le vidage est consigné dans un fichier séquentiel MVS avec un nom par défaut au format %uid.JVM.TDUMP.%job.D%y%m%d.T%H%M%S, ou selon la configuration de la variable d'environnement JAVA_DUMP_TDUMP_PATTERN.
Variable | Utilisation |
---|---|
%uid | ID utilisateur |
%job | Nom du travail |
%y | Année (2 chiffres) |
%m | Mois (2 chiffres) |
%d | Jour (2 chiffres) |
%H | Heure (2 chiffres) |
%M | Minute (2 chiffres) |
%S | Seconde (2 chiffres) |
Le vidage est inscrit dans un fichier z/OS UNIX nommé CEEDUMP.yyyymmdd.hhmmss.pid, où yyyymmdd est la date du jour, hhmmss est l'heure et pid est l'ID processus en cours. Les emplacements possibles de ce fichier sont décrits dans Emplacements des fichiers de vidage z/OS UNIX.
Le vidage est inscrit dans un fichier z/OS UNIX nommé HEAPDUMP.yyyymmdd.hhmmss.pid.TXT, où yyyymmdd est la date du jour, hhmmss est l'heure et pid est l'ID processus en cours. Les emplacements possibles de ce fichier sont décrits dans Emplacements des fichiers de vidage z/OS UNIX.
Notez que Developer for System z fournit une commande de l'opérateur pour déclencher ce vidage. Pour plus d'informations, reportez-vous au chapitre "Commandes de l'opérateur" du manuel Guide de configuration de l'hôte (SC23-7658).
Le vidage est inscrit dans un fichier z/OS UNIX nommé JAVADUMP.yyyymmdd.hhmmss.pid.TXT, où yyyymmdd est la date du jour, hhmmss est l'heure et pid est l'ID processus en cours. Les emplacements possibles de ce fichier sont décrits dans Emplacements des fichiers de vidage z/OS UNIX.
Notez que Developer for System z fournit une commande de l'opérateur pour déclencher ce vidage. Pour plus d'informations, reportez-vous au chapitre "Commandes de l'opérateur" du manuel Guide de configuration de l'hôte (SC23-7658).
Pour plus d'informations sur les fichiers de vidages JVM, voir Java Diagnostic Guide (SC34-6358) et pour des informations spécifiques de l'environnement de langage, voir Language Environment Debugging Guide (GA22-7560).
La machine virtuelle Java vérifie l'existence et les droits d'accès en écriture pour chacun des emplacements suivants, et stocke les fichiers CEEDUMP, HEAPDUMP et JAVADUMP dans le premier emplacement disponible. Notez que vous devez disposer d'un espace disque suffisant pour que le fichier de vidage soit écrit correctement.
La fonction de trace du gestionnaire de débogage est contrôlée par l'opérateur système, comme l'indique la section "Commandes de l'opérateur" du Guide de configuration de l'hôte (SC11-6285).
La fonction de trace du moniteur de travaux JES est contrôlée par l'opérateur système, comme l'indique la section "Commandes de l'opérateur" du Guide de configuration de l'hôte (SC11-6285).
Plusieurs fichiers journaux sont créés par les composants associés à RSE. La plupart se trouve dans userlog/$LOGNAME/, où userlog est la valeur combinée des directives user.log et DSTORE_LOG_DIRECTORY dans rsed.envvars, et $LOGNAME l'ID utilisateur de connexion (en majuscules). Si la directive user.log est mise en commentaire ou omise, le chemin du répertoire de base est utilisé. Ce chemin est défini dans le segment de sécurité OMVS de l'ID utilisateur. Si a directive DSTORE_LOG_DIRECTORY est mise en commentaire ou omise, .eclipse/RSE/ est ajouté à la valeur user.log.
La quantité de données consignées dans ffs*.log et rsecomm.log est déterminée par la commande d'opérateur modify rsecommlog ou par le paramètre debug_level dans rsecomm.properties. Reportez-vous à la section "Commandes de l'opérateur" du Guide de configuration de l'hôte (SC11-6285) et à la section "(Facultatif) Fonction de trace RSE" du Guide de configuration de l'hôte (SC11-6285) pour obtenir plus de détails.
La création des fichiers journaux .dstore* est contrôlée par les options de démarrage –-DDSTORE_* Java, comme indiqué dans "Définition de paramètres de démarrage supplémentaires Java avec _RSE_JAVAOPTS" dans Guide de configuration de l'hôte (SC11-6285).
Les fichiers journaux propres au démon RSE et au pool d'unités d'exécution RSE se trouvent dans le répertoire rép_base_utilisateur, où rép_base_utilisateur est la valeur de la directive daemon.log dans rsed.envvars. Si la directive daemon.log est mise en commentaire ou omise, le répertoire de base de l'ID utilisateur affecté à la tâche démarrée RSED est utilisé. Le répertoire de base est défini dans le segment de sécurité OMVS de l'ID utilisateur.
La quantité de données consignées dans rsedaemon.log et rseserver.log est commandée par les commandes de l'opérateur modify rsedaemonlog et modify rseserverlog ou par le paramètre debug_level de rsecomm.properties. Reportez-vous à la section "Commandes de l'opérateur" du Guide de configuration de l'hôte (SC11-6285) et à la section "(Facultatif) Fonction de trace RSE" du Guide de configuration de l'hôte (SC11-6285) pour obtenir plus de détails.
serverlogs.count, stderr.*.log et stdout.*.log sont uniquement créés si la directive enable.standard.log de rsed.envvars est active ou si la fonction est activée dynamiquement avec la commande de l'opérateur modify rsestandardlog on.
L'utilisateur peut contrôler la quantité d'informations de trace
générées par CARMA en définissant le niveau de trace dans l'onglet des propriétés
de la connexion CARMA du client. Les différents Niveaux de trace sont les suivants :
Journalisation des erreurs
Pour plus d'informations sur l'emplacement des fichiers journaux, voir Fichiers journaux.
Le programmeur système z/OS peut contrôler la quantité des informations de
trace générées par la méthode de démarrage CRASTART de CARMA en définissant
crastart.syslog dans CRASRV.properties,
et en définissant le niveau de débogage pour rsecomm.log dans rsecomm.properties
ou avec une commande d'opérateur.
//COBOL EXEC PGM=IGYCRCTL,REGION=2048K,
//* PARM=('EXIT(ADEXIT(ELAXMGUX))',
// PARM=('EXIT(ADEXIT(''MAXTRACE'',ELAXMGUX))',
// 'ADATA',
// 'LIB',
// 'TEST(NONE,SYM,SEP)',
// 'LIST',
// 'FLAG(I,I)'&CICS &DB2 &COMP)
ABOUT TOO OPEN SIDEFILE1 - NAME = 'uid.DT021207.TT110823.M0000045.C0000000'
SUCCESSFUL OPEN SIDEFILE1 - NAME = 'uid.DT021207.TT110823.M0000045.C0000000'
ABOUT TOO OPEN SIDEFILE2 - NAME = 'uid.DT021207.TT110823.M0000111.C0000001'
SUCCESSFUL OPEN SIDEFILE2 - NAME = 'uid.DT021207.TT110823.M0000111.C0000001'
ABOUT TOO OPEN SIDEFILE3 - NAME = 'uid.DT021207.TT110823.M0000174.C0000002'
SUCCESSFUL OPEN SIDEFILE3 - NAME = 'uid.DT021207.TT110823.M0000174.C0000002'
ABOUT TOO OPEN SIDEFILE4 - NAME = 'uid.DT021207.TT110823.M0000236.C0000003'
SUCCESSFUL OPEN SIDEFILE4 - NAME = 'uid.DT021207.TT110823.M0000236.C0000003'
22 //COBOL.WSEDSF1 DD DISP=MOD,
// DSN=uid.ERRCOB.member.SF.Z682746.XML
23 //COBOL.WSEDSF2 DD DISP=MOD,
// DSN=uid.ERRCOB.member.SF.Z682747.XML
Developer for System z requiert que le système de fichiers z/OS UNIX et certains fichiers z/OS UNIX comportent des données de droits spécifiques définies.
L'Explorateur de systèmes distants (RSE) est le composant Developer for System z qui fournit des services de base, comme la connexion du client à l'hôte. Il doit pouvoir effectuer des tâches telles que la création de l'environnement de sécurité de l’utilisateur.
Plusieurs erreurs (messages BPXP014I et BPXP015I, par exemple) peuvent survenir si les systèmes de fichiers hébergeant les binaires Java ou z/OS UNIX sont montés à l'aide du paramètre NOSETUID.
Utilisez la commande TSO ISHELL afin de répertorier l'état actuel des données SETUID. Dans le panneau ISHELL, sélectionnez Systèmes_de_fichiers > 1. Table de montage... pour répertorier les systèmes de fichiers montés. La commande-ligne a affichera les attributs du système de fichiers sélectionné où le champ “Ignorer SETUID” sera 0.
L'Explorateur de systèmes distants (RSE) est le composant Developer for System z qui fournit des services de base, comme la connexion du client à l'hôte. L'exécution doit être contrôlée par le programme afin d'effectuer des tâches telles que la commutation sur l'ID utilisateur du client.
Les données de contrôle de programmes z/OS UNIX sont définies au cours de l'installation SMP/E si nécessaire, sauf pour l'interface Java à votre produit de sécurité (voir le Remarques relatives à la sécurité). Cette donnée de droits pourrait être perdues si vous ne la conservez pas lors de la copie manuelle des répertoires Developer for System z.
Utilisez la commande z/OS UNIX ls –E pour répertorier les attributs étendus, dans lesquels le bit de contrôle de programme est marqué avec la lettre p, comme indiqué dans l'exemple suivant ($ est l'invite z/OS UNIX) :
$ cd /usr/lpp/rdz
$ ls -E lib/fekf*
-rwxr-xr-x -ps- 2 user group 94208 Jul 8 12:31 lib/fekfdir.dll
$ cd /usr/lpp/rdz
$ su
# extattr +p lib/fekf*
# exit
$ ls -E lib/fekf*
-rwxr-xr-x -ps- 2 user group 94208 Jul 8 12:31 lib/fekfdir.dll
L'Explorateur de systèmes distants (RSE) est le composant Developer for System z qui fournit des services de base, comme la connexion du client à l'hôte. Il doit être exécuté avec des droits APF pour effectuer des tâches comme l'affichage de l'usage détaillé des ressources du processus.
Le bit APF z/OS UNIX est défini au cours de l'installation SMP/E lorsque cela est nécessaire. Cette donnée de droits pourrait être perdues si vous ne la conservez pas lors de la copie manuelle des répertoires Developer for System z.
Utilisez la commande z/OS UNIX, ls -E, pour lister les attributs d'extension, dans lesquels le bit APF est marqué avec la lettre a, comme indiqué dans l'exemple suivant ($ est l'invite z/OS UNIX) :
$ cd /usr/lpp/rdz
$ ls -E bin/fekfrivp
-rwxr-xr-x aps- 2 user group 114688 Sep 17 06:41 bin/fekfrivp
Utilisez la commande z/OS UNIX, extattr +a, pour définir le bit APF manuellement, comme indiqué dans l'exemple suivant ($ et # sont les invites z/OS UNIX) :
$ cd /usr/lpp/rdz
$ su
# extattr +a bin/fekfrivp
# exit
$ ls -E bin/fekfrivp
-rwxr-xr-x aps- 2 user group 114688 Sep 17 06:41 bin/fekfrivp
Certains services Developer for System z facultatifs requièrent que les modules de chargement MVS soient disponibles pour z/OS UNIX. Pour ce faire, créez un module de remplacement (fichier factice) dans z/OS UNIX avec les données de rappel activées. Lorsque le module de remplacement est exécuté, z/OS UNIX recherche un module chargeable avec le même nom et exécute ce module chargeable MVS à la place.
Les données de rappel de z/OS UNIX sont définies pendant l'installation SMP/E, si nécessaire. Ces bits d'autorisation peuvent être perdus si vous ne les conservez pas lors de la copie manuelle des répertoires Developer for System z.
$ cd /usr/lpp/rdz
$ ls -l bin/CRA*
-rwxr-xr-t 2 user group 71 Jul 8 12:31 bin/CRASTART
$ cd /usr/lpp/rdz
$ su
# chmod +t bin/CRA*
# exit
$ ls -l bin/CRA*
-rwxr-xr-t 2 user group 71 Jul 8 12:31 bin/CRASTART
A l'aide de la commande netstat (TSO ou z/OS UNIX), vous pouvez connaître les ports actuellement utilisés. Le résultat de cette commande s'apparente à l'exemple ci-après. Les ports utilisés sont le dernier chiffre (après les ..) dans la colonne "Local Socket". Ces ports étant déjà utilisés, vous ne pouvez pas vous en servir pour la configuration de Developer for System z.
MVS TCP/IP NETSTAT CS VxRy TCPIP Name: TCPIP 16:36:42
User Id Conn Local Socket Foreign Socket State
------- ---- ------------ -------------- -----
BPXOINIT 00000014 0.0.0.0..10007 0.0.0.0..0 Listen
INETD4 0000004D 0.0.0.0..512 0.0.0.0..0 Listen
RSED 0000004B 0.0.0.0..4035 0.0.0.0..0 Listen
JMON 00000038 0.0.0.0..6715 0.0.0.0..0 Listen
MVS TCP/IP NETSTAT CS VxRy TCPIP Name: TCPIP 12:46:25
User Id Conn State
------- ---- -----
BPXOINIT 00000018 Listen
Local Socket: 0.0.0.0..10007
Foreign Socket: 0.0.0.0..0
INETD4 00000046 Listen
Local Socket: 0.0.0.0..512
Foreign Socket: 0.0.0.0..0
RSED 0000004B Listen
Local Socket: 0.0.0.0..4035
Foreign Socket: 0.0.0.0..0
JMON 00000037 Listen
Local Socket: 0.0.0.0..6715
Foreign Socket: 0.0.0.0..0
Les ports TCP/IP réservés peuvent présenter une autre limitation. Il existe deux espaces communs pour réserver des ports TCP/IP :
Il s'agit du fichier auquel se rapporte l'instruction de définition de données PROFILE de la tâche lancée par TCP/IP, souvent appelée SYS1.TCPPARMS(TCPPROF).
Pour plus d'informations sur ces instructions, voir Communications Server: IP Configuration Guide (SC31-8775).
Les ports réservés peuvent être répertoriés à l'aide de la commande netstat portl (TSO ou z/OS UNIX), qui crée une sortie comparable à celle de l'exemple ci-dessous :
MVS TCP/IP NETSTAT CS VxRy TCPIP Name: TCPIP 17:08:32
Port# Prot User Flags Range IP Address
----- ---- ---- ----- ----- ----------
00007 TCP MISCSERV DA
00009 TCP MISCSERV DA
00019 TCP MISCSERV DA
00020 TCP OMVS D
00021 TCP FTPD1 DA
00025 TCP SMTP DA
00053 TCP NAMESRV DA
00080 TCP OMVS DA
03500 TCP OMVS DAR 03500-03519
03501 TCP OMVS DAR 03500-03519
Pour plus d'informations sur la commande NETSTAT , voir le document Communications Server: IP System Administrator’s Commands (SC31-8781).
Le démon RSE, qui est un processus z/OS UNIX Java, requiert une taille de région élevée pour exécuter ses fonctions. Il est donc important de définir des limites de mémoire importantes pour les espaces adresse OMVS.
Le démon RSE est démarré par le JCL à l'aide de BPXBATSL, dont la taille de la région doit être 0.
Attribuez la valeur 2G à MAXASSIZE dans SYS1.PARMLIB(BPXPRMxx) pour définir la taille de la région de l'espace adresse (processus) OMVS par défaut. Il s'agit de la valeur maximale autorisée. Il s'agit d'une limite à l'échelle du système. Elle est donc active pour tous les espaces adresse z/OS UNIX. Si elle ne répond pas à vos attentes, vous pouvez la définir uniquement pour Developer for System z dans votre logiciel de sécurité.
Vérifiez ASSIZEMAX dans le segment OMVS de l'ID utilisateur du démon et définissez-le à 2147483647 ou, de préférence, à NONE pour utiliser la valeur SYS1.PARMLIB(BPXPRMxx).
Assurez-vous que vous n'autorisez pas aux sorties du systèmeIEFUSI ou IEALIMIT de contrôler les tailles de région d'adresse OMVS. Il est possible de réaliser cela en codant SUBSYS(OMVS,NOEXITS) dans SYS1.PARMLIB(SMFPRMxx).
Le mot clé MEMLIMIT dans SYS1.PARMLIB(SMFPRMxx) limite la quantité de stockage virtuel qu'une tâche 64 bits peut allouer au-delà de la barre des 2 Go. Contrairement au paramètre REGION du JCL, MEMLIMIT=0M signifie qu'il n'est pas possible d'utiliser un stockage virtuel au-delà de la barre.
Si MEMLIMIT n'est pas spécifié dans SMFPRMxx, la valeur par défaut est 0M, et donc des tâches sont liées aux 2 Go (31 bits) situés en dessous de la barre. La valeur par défaut est remplacée dans z/OS 1.10 par 2G, ce qui permet aux tâches 64 bits d'utiliser jusqu'à 4 GB (les 2 Go en dessous de la barre et les 2 Go au-dessus de la barre, accordés par MEMLIMIT).
Vous pouvez aussi spécifier MEMLIMIT comme paramètre sur une carte EXEC dans un JCL. Si aucun paramètre MEMLIMIT n'est spécifié, la valeur par défaut est la valeur définie pour SMF, en revanche, si REGION=0M est spécifié, la valeur par défaut est NOLIMIT.
Lorsqu'un utilisateur sélectionne un retour d'informations sur les erreurs pendant une action de compilation, plusieurs fichiers temporaires sont créés par Developer for System z. Si l'espace est insuffisant pour l'un de ces fichiers, la tâche de compilation s'interrompt avec une erreur de type fin anormale pour manque d'espace B37-04.
Attribuez suffisamment d'espace dans FEK.SFEKPROC(FEKFERRF) lorsque les utilisateurs rencontrent ce problème. La valeur par défaut est SPACE(200,40) TRACKS.
SYS1.PARMLIB(BPXPRMxx) définit plusieurs limitations liées à z/OS UNIX, qui peuvent être atteintes lorsque plusieurs clients de Developer for System z sont actifs. La plupart des valeurs BPXPRMxx peuvent être modifiées de façon dynamique avec les commandes de la console SETOMVS et SET OMVS.
Utilisez la commande de console SETOMVS LIMMSG=ALL pour que z/OS UNIX affiche les messages de console (BPXI040I) lorsque l'une des limites BPXPRMxx est sur le point d'être atteinte.
Cette section vous aide à résoudre certains des incidents qui peuvent se produire lors de la configuration de SSL (Secure Socket Layer) ou pendant la vérification ou la modification d'une configuration existante. Elle contient également un exemple de configuration pour prendre en charge l'authentification des utilisateurs à l'aide d'un certificat X.509.
Une communication sécurisée vous assure que votre partenaire de communication est bien celui qu'il prétend être, et que la transmission des informations se fait d'une manière qui rend difficile toute interception et lecture des données par des tiers. Le protocole SSL fournit cette capacité dans un réseau TCP/IP. Il fonctionne par l'emploi de certificats numériques pour vous identifier et d'un protocole à clé publique pour chiffrer la communication. Voir le document Security Server RACF Security Administrator's Guide (SA22-7683) pour de plus amples informations sur les certificats numériques et le protocole de clé publique utilisés par le protocole SSL.
Les actions nécessaires pour la configuration des communications SSL pour Developer for System z varient largement d'un site à l'autre, selon les véritables besoins, la méthode de communication RSE employée, et ce qui est déjà disponible au niveau du site.
Dans la présente section, nous allons cloner les définitions RSE en cours de manière à avoir une seconde connexion au démon RSE qui utilisera le protocole SSL. Nous créerons également nos propres certificats de sécurité destinés à être utilisés par les différents composants de la connexion RSE.
Certaines des tâches décrites dans les sections suivantes nécessitent des actions de votre part dans z/OS UNIX. Vous pouvez les effectuer en lançant la commande TSO OMVS. Utilisez la commande exit pour retourner à TSO.
La variable DSTORE_SSL_ALGORITHM de la directive _RSE_JAVAOPTS du fichier rsed.envvars vous permet de choisir entre SSL et son successeur TLS (Transport Layer Security) pour la méthode de chiffrement, comme indiqué à la section sur la définition de paramètres de démarrage Java supplémentaires avec _RSE_JAVAOPTS dans le document Guide de configuration de l'hôte (SC23-7658).
Les certificats d'identité et les clés de chiffrement/déchiffrement utilisés par le protocole SSL sont stockés dans un fichier de clés. Différentes implémentations de ce fichier de clés existent, selon le type d'application.
Toutefois, toutes les implémentations suivent le même principe. Une commande génère une paire de clés (une clé publique et la clé privée associée). La commande intègre ensuite la clé publique à un certificat X.509 autosigné, qui est stocké comme une chaîne de certificats à un seul élément. Cette chaîne de certificats et la clé privée sont stockées en tant qu'entrée (identifiée par un alias) dans un fichier de clés.
Stockage des certificats | Créé et géré par | Démon RSE | Serveur RSE |
---|---|---|---|
Fichier de clés | Produit de sécurité compatible avec SAF | pris en charge | pris en charge |
Base de données de clés | gskkyman de z/OS UNIX | pris en charge | / |
Magasin de clés | Outil de clé de Java | / | pris en charge |
STEPLIB=$STEPLIB:SYS1.SIEALNKE
Pour obtenir des informations sur RACF et les certificats numériques, voir le document Security Server RACF Security Administrator’s Guide (SA22-7683). La documentation relative à gskkyman est disponible dans le document System SSL Programming (SC24-5901) et la documentation de keytool se trouve à l'adresse http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html.
N'exécutez pas cette étape si vous utilisez gskkyman pour créer la base de données de clés du démon RSE et keytool pour créer le magasin de clés du serveur RSE.
La commande RACDCERT installe et maintient les clés privées et les certificats dans RACF. RACF prend en charge la gestion en groupe de multiples clés privées et certificats. Ces groupes sont des fichiers de clés.
Les certificats peuvent être autosignés ou signés par une autorité de certification (CA). Un certificat signé par une autorité de certification signifie que l'autorité de certification garantit que le propriétaire du certificat est bien la personne qu'il prétend être. La procédure de signature ajoute les données d'identification (certificat) de l'autorité de certification à votre certificat pour former une chaîne de certificats à plusieurs éléments.
Lorsque vous utilisez un certificat signé par une autorité de certification, vous pouvez éviter les questions de validation de la relation de confiance du client Developer for System z si le client fait déjà confiance à l'autorité de certification.
Pour obtenir des informations détaillées sur la commande RACDCERT, voir le document Security Server RACF Command Language Reference (SA22-7687).
# permit RSE daemon to access certificates
RDEFINE FACILITY IRR.DIGTCERT.LIST UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.LISTRING UACC(NONE)
PERMIT IRR.DIGTCERT.LIST CLASS(FACILITY) ACCESS(READ) ID(stcrse)
PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ACCESS(READ) ID(stcrse)
# refresh to make the changes visible
SETROPTS RACLIST(FACILITY) REFRESH
# create self-signed certificate
RACDCERT ID(stcrse) GENCERT SUBJECTSDN(CN('rdz rse ssl') +
OU('rdz') O('IBM') L('Raleigh') SP('NC') C('US')) +
NOTAFTER(DATE(2017-05-21)) WITHLABEL('rdzrse') KEYUSAGE(HANDSHAKE)
# (optional) additional steps required to use a signed certificate
# 1. create a signing request for the self-signed certificate
RACDCERT ID(stcrse) GENREQ (LABEL('rdzrse')) DSN(dsn)
# 2. send the signing request to your CA of choice
# 3. check if the CA credentials (also a certificate) are already known
RACDCERT CERTAUTH LIST
# 4. mark the CA certificate as trusted
RACDCERT CERTAUTH ALTER(LABEL('CA cert')) TRUST
# or add the CA certificate to the database
RACDCERT CERTAUTH ADD(dsn) WITHLABEL('CA cert') TRUST
# 5. add the signed certificate to the database;
# this will replace the self-signed one
RACDCERT ID(stcrse) ADD(dsn) WTIHLABEL('rdzrse') TRUST
# Do NOT delete the self-signed certificate before replacing it.
# If you do, you lose the private key that goes with the certificate,
# which makes the certificate useless.
RACDCERT ID(stcrse) ADDRING(rdzssl.racf)
RACDCERT ID(stcrse) CONNECT(LABEL('rdzrse') RING(rdzssl.racf) +
DEFAULT USAGE(PERSONAL))
# additional step required to use a signed certificate
# 6. add CA certificate to key ring
RACDCERT ID(stcrse) CONNECT(CERTAUTH LABEL('CA cert') +
RING(rdzssl.racf))
# refresh to make the changes visible
SETROPTS RACLIST(DIGTCERT) REFRESH
L'exemple précédent commence par la création des profils nécessaires et par l'autorisation d'accès de l'ID utilisateur STCRSE aux jeux de clés et aux certificats détenus par cet ID utilisateur. L'ID utilisateur utilisé doit correspondre à celui employé pour exécuter le démon RSE SSL. L'étape suivante crée un certificat auto-signé avec l'intitulé rdzrse. Aucun mot de passe n'est nécessaire. Ce certificat est alors ajouté au fichier de clés nouvellement créé (rdzssl.racf). Exactement comme avec le certificat, aucun mot de passe n'est nécessaire pour le fichier de clés. Les étapes nécessaires pour utiliser un certificat signé sont également indiqués.
Notez que le certificat de l'autorité de certification utilisé pour signer votre certificat peut, à son tour, également être signé par un autre certificat de l'autorité de certification de niveau supérieur. Si cela se produit, le certificat de l'autorité de certification de niveau supérieur doit également être ajouté au fichier de clés. Ce processus se répète jusqu'à ce que le certificat de l'autorité de certification de niveau supérieur soit un certificat de l'autorité de certification racine, lequel est toujours un certificat autosigné.
Le résultat peut être vérifié par l'intermédiaire des options list et listring suivantes :
RACDCERT ID(stcrse) LIST
Digital certificate information for user STCRSE:
Label: rdzrse
Certificate ID: 2QjW1OXi0sXZ1aaEqZmihUBA
Status: TRUST
Start Date: 2007/05/24 00:00:00
End Date: 2017/05/21 23:59:59
Serial Number:
>00<
Issuer's Name:
>CN=my CA.OU=rdz.O=IBM.L=Raleigh.SP=NC.C=US<
Subject's Name:
>CN=rdz rse ssl.OU=rdz.O=IBM.L=Raleigh.SP=NC.C=US<
Private Key Type: Non-ICSF
Private Key Size: 1024
Ring Associations:
Ring Owner: STCRSE
Ring:
>rdzssl.racf<
RACDCERT ID(stcrse) LISTRING(rdzssl.racf)
Digital ring information for user STCRSE:
Ring:
>rdzssl.racf<
Certificate Label Name Cert Owner USAGE DEFAULT
-------------------------------- ------------ -------- -------
rdzrse ID(STCRSE) PERSONAL YES
CA cert CERTAUTH CERTAUTH NO
Dans cette étape, une nouvelle instance des fichiers de configuration RSE est créée, pour que la configuration SSL puisse être exécutée en parallèle avec celle(s) qui existe(nt) déjà. Les exemples de commandes suivants prévoient le stockage des fichiers de configuration dans le répertoire /etc/rdz/, ce qui est l'emplacement par défaut utilisé dans la section "Configuration personnalisée" du Guide de configuration de l'hôte (SC11-6285).
$ cd /etc/rdz
$ mkdir ssl
$ cp rsed.envvars ssl
$ cp ssl.properties ssl
$ ls ssl
rsed.envvars ssl.properties
Les commandes z/OS UNIX répertoriées ci-dessus permettent de créer un sous-répertoire appelé ssl et d'y placer les fichiers de configuration qui nécessitent des modifications. Les autres fichiers de configuration, le répertoire d'installation et les composants MVS sont partagés car ils ne sont pas propres à SSL.
La réutilisation de la plupart des fichiers de configuration permet de se consacrer aux modifications nécessaires à la configuration SSL et d'éviter de réaliser de nouveau la configuration RSE (par exemple, vous pouvez éviter de définir un nouvel emplacement pour ISPF.conf.)
Jusqu'à présent, les définitions sont une copie exacte de la configuration en cours, ce qui signifie que les journaux du nouveau démon RSE remplacent les fichiers journaux du serveur en cours. RSE doit également savoir où se trouvent les fichiers de configuration qui n'ont pas été copiés dans le répertoire ssl. Ces deux problèmes peuvent être corrigés en apportant des modifications mineures au fichier rsed.envvars.
$ oedit /etc/rdz/ssl/rsed.envvars
-> change: _RSE_RSED_PORT=4047
-> change: -Ddaemon.log=/var/rdz/logs/ssl
-> change: -Duser.log=/var/rdz/logs/ssl
-> add at the END:
# -- NEEDED TO FIND THE REMAINING CONFIGURATION FILES
CFG_BASE=/etc/rdz
CLASSPATH=.:$CFG_BASE:$CLASSPATH
# --
Les modifications illustrées dans l'exemple précédent définissent un nouvel emplacement de journal (qui est créé par le démon RSE si l'emplacement de journal n'existe pas). Elles mettent également à jour la variable CLASSPATH afin que les processus RSE SSL recherchent les fichiers de configuration dans le répertoire en cours (/etc/rdz/ssl), puis dans le répertoire d'origine (/etc/rdz).
Le fichier ssl.properties est mis à jour afin de demander à RSE de démarrer en utilisant une communication chiffrée SSL.
$ oedit /etc/rdz/ssl/ssl.properties
-> change: enable_ssl=true
-> uncomment and change: daemon_keydb_file=rdzssl.racf
-> uncomment and change: daemon_key_label=rdzrse
-> uncomment and change: server_keystore_file=rdzssl.racf
-> uncomment and change: server_keystore_label=rdzrse
-> uncomment and change: server_keystore_type=JCERACFKS
Les modifications indiquées précédemment activent SSL et indiquent au démon RSE et au serveur RSE que leur certificat (partagé) est stocké sous le nom rdzrse dans le fichier de clés rdzssl.racf. Le mot clé JCERACFKS indique au serveur RSE qu'un fichier de clés conforme à SAF est utilisé en tant que magasin de clés.
Notez que System SSL (utilisé par le démon) utilise toujours ICSF, l'interface avec le matériel de chiffrement de System z, si elle est disponible. Pour pouvoir partager les définitions de démon avec le serveur lors de l'utilisation d'ICSF, vous devez spécifier server_keystore_type JCECCARACFKS. Ici, un fichier de clés compatible avec SAF est également utilisé en tant que magasin de clés pour les clés publiques, mais la clé privée est stockée dans ICSF. Comme indiqué dans le document Cryptographic Services ICSF Administrator's Guide (SA22-7521), ICSF utilise des profils dans les classes de sécurité CSFKEYS et CSFSERV pour contrôler qui peut utiliser les clés et les services de chiffrement.
//RSEDSSL JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1),USER=STCRSE
//*
//* RSE DAEMON - SSL
//*
//RSED PROC TMPDIR=,
// PORT=,
// IVP=, * 'IVP' to do an IVP test
// CNFG='/etc/rdz/ssl',
// HOME='/usr/lpp/rdz'
//*
//RSED EXEC PGM=BPXBATSL,REGION=0M,TIME=NOLIMIT,
// PARM='PGM &HOME./bin/rsed.sh &IVP -C&CNFG -P&PORT -T&TMPDIR'
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
// PEND
//*
//RSED EXEC RSED
//*
La configuration de l'hôte SSL est maintenant terminée et le démon RSE pour la couche SSL peut être démarré par la soumission du travail FEK.#CUST.PROCLIB(RSEDSSL) précédemment créé.
La nouvelle configuration peut maintenant être testée via la connexion au client System z. Dans la mesure où nous avons créé une configuration pour l'utilisation avec SSL (par clonage d'une configuration existante), une nouvelle connexion doit être définie sur le client avec l'utilisation du port 4047 pour le démon RSE.
A la connexion, l'hôte et le client démarrent avec un protocole d'établissement de liaison pour configurer un chemin d'accès sécurisé. L'échange de certificats fait partie de ce protocole d'établissement de liaison. Si le client Developer for System z ne reconnaît pas le certificat de l'hôte ou l'autorité de certification qui l'a signé, il demande à l'utilisateur si ce certificat est digne de confiance.
En cliquant sur le bouton Terminer, l'utilisateur peut accepter le certificat comme étant sécurisé, après quoi l'initialisation de la connexion se poursuit.
Une fois que le client connaît le certificat, cette boîte de dialogue n'est plus affichée. La liste des certificats de confiance peut être gérée en sélectionnant Fenêtre > Préférences... > Systèmes distants > SSL, ce qui provoque l'affichage de la boîte de dialogue suivante :
En cas d'échec des communications SSL le client renvoie un message d'erreur. Des informations complémentaires sont disponibles dans les différents fichiers journaux du serveur et de l'utilisateur, comme indiqué à la section Journalisation du démon RSE et du pool d'unités d'exécution et Journalisation pour l'utilisateur RSE.
Le démon RSE prend en charge les utilisateurs qui s'authentifient eux-mêmes à l'aide d'un certificat X.509. L'utilisation de communications chiffrées SSL est indispensable pour cette fonction car il s'agit d'une extension de l'authentification hôte avec un certificat utilisé dans SSL.
Il y a plusieurs méthodes pour effectuer l'authentification d'un utilisateur via un certificat, comme indiqué à la section Authentification du client à l'aide de certificats X.509. Les étapes suivantes décrivent la configuration nécessaire pour que votre logiciel de sécurité authentifie le certificat à l'aide de l'extension de certificat HostIdMappings.
RACDCERT CERTAUTH ALTER(LABEL('HighTrust CA')) HIGHTRUST
RACDCERT ID(stcrse) CONNECT(CERTAUTH LABEL('HighTrust CA') +
RING(rdzssl.racf))
La configuration du certificat de l'autorité de certification est terminée.
RDEFINE SERVAUTH IRR.HOST.CDFMVS08.RALEIGH.IBM.COM UACC(NONE)
PERMIT IRR.HOST.CDFMVS08.RALEIGH.IBM.COM CLASS(SERVAUTH) +
ACCESS(READ) ID(stcrse)
SETROPTS CLASSACT(SERVAUTH) RACLIST(SERVAUTH)
ou
SETROPTS RACLIST(SERVAUTH) REFRESH
La configuration du logiciel de sécurité pour l'extension HostMappingscat de l'autorité de certification est terminée.
N'exécutez pas cette étape si vous utilisez un fichier de clés conforme à SAF pour la base de données de clés du démon RSE.
gskkyman est un programme z/OS UNIX basé sur le shell, piloté par menus, qui crée, remplit et gère un fichier z/OS UNIX qui contient les clés privées, les demandes de certificats et les certificats. Ce fichier z/OS UNIX est une base de données de clés.
PATH=$PATH:/usr/lpp/gskssl/bin
export NLSPATH=/usr/lpp/gskssl/lib/nls/msg/En_US.IBM-1047/%N:$NLSPATH
export STEPLIB=$STEPLIB:SYS1.SIEALNKE
$ cd /etc/rdz/ssl
$ gskkyman Menu de la base de données
1 - Create new database
Enter option number: 1
Enter key database name (press ENTER to return to menu): rdzssl.kdb
Enter database password (press ENTER to return to menu): rsessl
Re-enter database password: rsessl
Enter password expiration in days (press ENTER for no expiration):
Enter database record length (press ENTER to use 2500):
Key database /etc/rdz/ssl/rdzssl.kdb created.
Press ENTER to continue.
Key Management Menu
6 - Create a self-signed certificate
Enter option number (press ENTER to return to previous menu): 6
Certificate Type
5 - User or server certificate with 1024-bit RSA key
Select certificate type (press ENTER to return to menu): 5
Enter label (press ENTER to return to menu): rdzrse
Enter subject name for certificate
Common name (required): rdz rse ssl
Organizational unit (optional): rdz
Organization (required): IBM
City/Locality (optional): Raleigh
State/Province (optional): NC
Country/Region (2 characters - required): US
Enter number of days certificate will be valid (default 365): 3650
Enter 1 to specify subject alternate names or 0 to continue: 0
Please wait .....
Certificate created.
Press ENTER to continue.
Key Management Menu
0 - Exit program
Enter option number (press ENTER to return to previous menu): 0
$ ls -l rdzssl.*
total 152
-rw------- 1 IBMUSER SYS1 35080 May 24 14:24 rdzssl.kdb
-rw------- 1 IBMUSER SYS1 80 May 24 14:24 rdzssl.rdb
$ chmod 644 rdzssl.*
$ ls -l rdzssl.*
-rw-r--r-- 1 IBMUSER SYS1 35080 May 24 14:24 rdzssl.kdb
-rw-r--r-- 1 IBMUSER SYS1 80 May 24 14:24 rdzssl.rdb
L'exemple précédent commence par la création d'une base de données de clés appelée rdzssl.kdb avec le mot de passe rsessl. Lorsque la base de données existe, elle est enrichie en créant un certificat autosigné valide pendant 10 ans environ (sans compter les jours des années bissextiles). Le certificat est conservé sous le nom rdzrse et avec même le mot de passe (rsessl) que celui utilisé pour la base de données de clés (il s'agit d'un élément prérequis par RSE).
gskkyman attribue un masque de bits d'autorisation (très sûr, accès du seul propriétaire) de 600 à la base de données de clés. Mis à part le cas où le démon utilise le même ID utilisateur que le créateur de la base de données de clés, les autorisations doivent être définies d'une manière moins restrictive. Le masque 644 (le propriétaire a des droits d'accès en lecture/écriture, tout le monde a des droits d'accès en lecture) est utilisable pour la commande chmod.
Ce résultat peut être vérifié en sélectionnant l'option Show certificate information dans le sous-menu Manage keys and certificates :
$ gskkyman
Database Menu
2 - Open database
Enter option number: 2
Enter key database name (press ENTER to return to menu): rdzssl.kdb
Enter database password (press ENTER to return to menu): rsessl
Key Management Menu
1 - Manage keys and certificates
Enter option number (press ENTER to return to previous menu): 1
Key and Certificate List
1 - rdzrse
Enter label number (ENTER to return to selection menu, p for previous list): 1
Key and Certificate Menu
1 - Show certificate information
Enter option number (press ENTER to return to previous menu): 1
Certificate Information
Label: rdzrse
Record ID: 14
Issuer Record ID: 14
Trusted: Yes
Version: 3
Serial number: 45356379000ac997
Issuer name: rdz rse ssl
rdz
IBM
Raleigh
NC
US
Subject name: rdz rse ssl
rdz
IBM
Raleigh
NC
US
Effective date: 2007/05/24
Expiration date: 2017/05/21
Public key algorithm: rsaEncryption
Public key size: 1024
Signature algorithm: sha1WithRsaEncryption
Issuer unique ID: None
Subject unique ID: None
Number of extensions: 3
Enter 1 to display extensions, 0 to return to menu: 0
Key and Certificate Menu
0 - Exit program
Enter option number (press ENTER to return to previous menu): 0
L'exemple de fichier ssl.properties ci-après indique que les directives daemon_* diffèrent de celles de l'exemple de fichier de clés SAF présenté plus haut.
$ oedit /etc/rdz/ssl/ssl.properties
-> change: enable_ssl=true
-> uncomment and change: daemon_keydb_file=rdzssl.kdb
-> uncomment and change: daemon_keydb_password=rsessl
-> uncomment and change: daemon_key_label=rdzrse
-> uncomment and change: server_keystore_file=rdzssl.racf
-> uncomment and change: server_keystore_label=rdzrse
-> uncomment and change: server_keystore_type=JCERACFKS
Les modifications précédentes activent SSL et indiquent au démon RSE que le certificat est stocké sous le nom rdzrse dans la base de données de clés rdzssl.kdb avec le mot de passersessl. Le serveur RSE continue à utiliser un fichier de clés conforme à SAF.
N'exécutez pas cette étape si vous utilisez un fichier de clés conforme à SAF pour le magasin de clés du serveur RSE.
Toutes les informations peuvent être transmises comme paramètres, mais en raison des limitations de longueur de la ligne de commande, une certaine interactivité est nécessaire :
$ cd /etc/rdz/ssl
$ keytool -genkey -alias rdzrse -validity 3650 -keystore rdzssl.jks -storepass
rsessl -keypass rsessl
What is your first and last name?
[Unknown]: rdz rse ssl
What is the name of your organizational unit?
[Unknown]: rdz
What is the name of your organization?
[Unknown]: IBM
What is the name of your City or Locality?
[Unknown]: Raleigh
What is the name of your State or Province?
[Unknown]: NC
What is the two-letter country code for this unit?
[Unknown]: US
Is CN=rdz rse ssl, OU=rdz, O=IBM, L=Raleigh, ST=NC, C=US correct? (type "yes"
or "no")
[no]: yes
$ ls -l rdzssl.*
-rw-r--r-- 1 IBMUSER SYS1 1224 May 24 14:17 rdzssl.jks
Le certificat autosigné créé dans l'exemple précédent est valide pendant environ 10 ans (sans compter les jours des années bissextiles). Il est stocké dans /etc/rdz/ssl/rdzssl.jks avec l'alias rdzrse. Son mot de passe (rsessl) est identique au mot de passe du fichier de clés, ce qui est un élément prérequis pour RSE.
Le résultat peut être vérifié par l'intermédiaire de l'option -list :
$ keytool -list -alias rdzrse -keystore rdzssl.jks -storepass rsessl -v
Alias name: rdzrse
Creation date: May 24, 2007
Entry type: keyEntry
Certificate chain length: 1
Certificate 1¨:
Owner: CN=rdz rse ssl, OU=rdz, O=IBM, L=Raleigh, ST=NC, C=US
Issuer: CN=rdz rse ssl, OU=rdz, O=IBM, L=Raleigh, ST=NC, C=US
Serial number: 46562b2b
Valid from: 5/24/07 2:17 PM until: 5/21/17 2:17 PM
Certificate fingerprints:
MD5: 9D:6D:F1:97:1E:AD:5D:B1:F7:14:16:4D:9B:1D:28:80
SHA1: B5:E2:31:F5:B0:E8:9D:01:AD:2D:E6:82:4A:E0:B1:5E:12:CB:10:1C
Dans l'exemple de fichier ssl.properties ci-après, les directives server_* diffèrent de celles de l'exemple de fichier de clés SAF présenté plus haut.
$ oedit /etc/rdz/ssl/ssl.properties
-> change: enable_ssl=true
-> uncomment and change: daemon_keydb_file=rdzssl.racf
-> uncomment and change: daemon_key_label=rdzrse
-> uncomment and change: server_keystore_file=rdzssl.jks
-> uncomment and change: server_keystore_password=rsessl
-> uncomment and change: server_keystore_label=rdzrse
-> optionally uncomment and change: server_keystore_type=JKS
Les modifications précédentes activent SSL et indiquent au serveur RSE que le certificat est stocké sous le nom rdzrse dans le magasin de clés rdzssl.jks avec le mot de passe rsessl. Le démon RSE utilise toujours un fichier de clés conforme à SAF.
Cette section vous aide à résoudre certains problèmes susceptibles de se produire lors de la configuration d'AT-TLS (Application Transparent Transport Layer Security) ou pendant la vérification ou la modification d'une configuration existante.
Le protocole TLS (Transport Layer Security) défini dans RFC 2246 offre une confidentialité pour les communications sur Internet. Comme son prédécesseur SSL (Secure Socket Layer), ce protocole permet aux applications client et serveur de communiquer de façon à empêcher les écoutes clandestines, les contrefaçons et la falsification des messages. Le protocole AT-TLS (Application Transparent Transport Layer Security) consolide l'implémentation de TLS pour les applications z/OS dans un emplacement, ce qui permet à toutes les applications de prendre en charge le chiffrement TLS sans avoir connaissance du protocole TLS. Pour plus d'informations sur AT-TLS, voir le document Communications Server IP Configuration Guide (SC31-8775).
Le débogueur intégré de IBM Rational Developer for System z s'appuie sur AT-TLS pour les communications chiffrées avec le client car les données de la session de débogage ne passent pas par le même canal que les autres communications client/hôte de Developer for System z.
Les actions nécessaires pour configurer AT-TLS varient d'un site à l'autre, selon les véritables besoins et ce qui est déjà disponible au niveau du site.
Certaines des tâches décrites dans les sections suivantes nécessitent des actions de votre part dans z/OS UNIX. Vous pouvez les effectuer en lançant la commande TSO OMVS. Utilisez la commande oedit pour éditer les fichiers sous z/OS UNIX. Utilisez la commande exit pour retourner à TSO.
La documentation TCP/IP conseille d'écrire les messages de l'agent de règles dans le journal système (syslog) z/OS UNIX au lieu d'utiliser le fichier journal par défaut. AT-TLS écrit toujours les messages dans le journal système (syslog) z/OS UNIX.
Pour ce faire, le démon syslog z/OS UNIX, syslogd, doit être configuré et actif. Vous devez également disposer d'un mécanisme permettant de contrôler la taille des fichiers journaux créés par syslogd.
syslog 514/udp
# /etc/syslog.conf - control output of syslogd
# 1. all files with will be printed to /tmp/syslog.auth.log
auth.* /tmp/syslog.auth.log
# 2. all error messages printed to /tmp/syslog.error.log
*.err /tmp/syslog.error.log
# 3. all debug and above messages printed to /tmp/syslog.debug.log
*.debug /tmp/syslog.debug.log
# The files named must exist before the syslog daemon is started,
# unless -c startup option is used
# Start the SYSLOGD daemon for logging
# (clean up old logs)
sed -n '/^#/!s/.* \(.*\)/\1/p' /etc/syslog.conf | xargs -i rm {}
# (create new logs and add userid of message sender)
_BPX_JOBNAME='SYSLOGD' /usr/sbin/syslogd -cuf /etc/syslog.conf &
sleep 5
La prise en charge AT-TLS est activée par le paramètre TTLS sur l'instruction TCPCONFIG dans le fichier PROFILE.TCPIP. AT-TLS est géré par l'agent de règles qui doit être actif pour pouvoir appliquer la règle AT-TLS. Etant donné que l'agent de règles doit attendre que TCP/IP soit actif, l'instruction AUTOSTART dans PROFILE.TCPIP est un endroit approprié pour déclencher le démarrage de ce serveur.
TCPCONFIG TTLS ; Required for AT-TLS
AUTOLOG
PAGENT ; POLICY AGENT, required for AT-TLS
ENDAUTOLOG
//PAGENT PROC PRM='-L SYSLOGD' * '' or '-L SYSLOGD'
//*
//* TCP/IP POLICY AGENT
//* (PARM) (envar)
//* default cfg file: /etc/pagent.conf (-C) (PAGENT_CONFIG_FILE)
//* default log file: /tmp/pagent.log (-L) (PAGENT_LOG_FILE)
//* default log size: 300,3 (3x 300KB files) (PAGENT_LOG_FILE_CONTROL)
//*
//PAGENT EXEC PGM=PAGENT,REGION=0M,TIME=NOLIMIT,
// PARM='ENVAR("TZ=EST5DST")/&PRM'
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//*
#
# TCP/IP Policy Agent configuration information.
#
TTLSConfig /etc/pagent.ttls.conf
# Specifies the path of a TTLS policy file holding stack specific
# statements.
#
#TcpImage TCPIP /etc/pagent.conf
# If no TcpImage statement is specified, all policies will be installed
# to the default TCP/IP stack.
#
#LogLevel 31
# The sum of the following values that represent log levels:
# LOGL_SYSERR 1
# LOGL_OBJERR 2
# LOGL_PROTERR 4
# LOGL_WARNING 8
# LOGL_EVENT 16
# LOGL_ACTION 32
# LOGL_INFO 64
# LOGL_ACNTING 128
# LOGL_TRACE 256
# Log Level 31 is the default log loglevel.
#
#Codepage IBM-1047
# Specify the EBCDIC code page to be used for reading all configuration
# files and policy definition files. IBM-1047 is the default code page.
Cet exemple de fichier de configuration indique l'endroit où l'agent de règles peut trouver la règle TTLS. Il utilise les valeurs par défaut de l'agent de règles pour d'autres instructions.
Une règle TTLS décrit les règles AT-TLS souhaitées. Comme défini dans le fichier de configuration de l'agent de règles, la règle TTLS se trouve dans /etc/pagent.ttls.conf. Les définitions nécessaires dans le logiciel de sécurité sont abordées ultérieurement.
##
## TCP/IP Policy Agent AT-TLS configuration information.
##
##-----------------------------
TTLSRule RDz_Debug_Manager
{
LocalPortRange 5335
Direction Inbound
TTLSGroupActionRef grp_Production
TTLSEnvironmentActionRef act_RDz_Debug_Manager
}
##-----------------------------
TTLSEnvironmentAction act_RDz_Debug_Manager
{
HandshakeRole Server
TTLSKeyRingParms
{
Keyring dbgmgr.racf # Keyring must be owned by the Debug Manager
}
TTLSEnvironmentAdvancedParms
{
## TLSV1.2 only for z/OS 2.1 and higher
# TLSV1.2 On # SSLv3, TLSv1 & TLSv1.1 are on by default
}
}
##-----------------------------
TTLSRule RDz_Debug_Probe-Client
{
RemotePortRange 8001
Direction Outbound
TTLSGroupActionRef grp_Production
TTLSEnvironmentActionRef act_RDz_Debug_Probe-Client
}
##-----------------------------
TTLSEnvironmentAction act_RDz_Debug_Probe-Client
{
HandshakeRole Client
TTLSKeyRingParms
{
Keyring *AUTH*/* # virtual key ring holding CA certificates
}
TTLSEnvironmentAdvancedParms
{
## TLSV1.2 only for z/OS 2.1 and higher
# TLSV1.2 On # SSLv3, TLSv1 & TLSv1.1 are on by default
}
}
##-----------------------------
TTLSGroupAction grp_Production
{
TTLSEnabled On
## TLSv1.2zOS1.13 only for z/OS 1.13
TTLSGroupAdvancedParmsRef TLSv1.2zOS1.13
Trace 3 # Log Errors to syslogd & IP joblog
#Trace 254 # Log everything to syslogd
}
##-----------------------------
TTLSGroupAdvancedParms TLSv1.2zOS1.13
{
Envfile /etc/pagent.ttls.TLS1.2zOS1.13.env
}
Une règle TTLS permet à tout un ensemble de filtres d'indiquer le moment où une règle s'applique.
Le gestionnaire de débogage est un serveur qui écoute sur le port 5335 les connexions entrantes en provenance du moteur de débogage. Ces informations sont capturées dans la règle RDz_Debug_Manager.
Etant donné que SSL et TLS nécessitent l'utilisation d'un certificat serveur, indiquez que le gestionnaire de règles doit utiliser les certificats dans le fichier de clés dbgmgr.racf qui appartient à l'ID utilisateur de la tâche démarrée par le gestionnaire de débogage. Par défaut, la prise en charge de TLS v1.2 est désactivée, donc cette règle l'active explicitement.
Lorsque la sonde de débogage est démarrée avec l'option Language Environment (LE) TEST(,,,TCPIP&&ipaddress%8001:*), il lui est demandé de ne pas utiliser le gestionnaire de débogage, mais de contacter directement le client Developer for System z sur le port 8001. Du point de vue de TCP/IP, cela implique que la sonde de débogage client soit un client qui contacte un serveur (l'interface graphique de débogage) dans le client Developer for System z. Ces informations sont capturées dans la règle RDz_Debug_Probe-Client.
L'hôte étant un client TCP/IP, le gestionnaire de règles devra disposer d'un moyen lui permettant de valider le certificat serveur présenté par l'interface graphique de débogage. Au lieu d'utiliser un fichier de clés nommé de manière uniforme pour tous les utilisateurs qui peuvent requérir une session de débogage chiffrée, nous utilisons le fichier de clés virtuel CERTAUTH de RACF (*AUTH*/*). Ce fichier de clés virtuel contient les certificats publics des autorités de certification et peut être utilisé si l'interface graphique de débogage présente un certificat serveur signé par l'une des autorités de certification sécurisées.
Notez que pour des règles plus complexes, il est conseillé d'utiliser l'assistant de configuration IBM pour z/OS Communications Server. Il s'agit d'un outil de type interface graphique qui fournit une interface guidée permettant de configurer les fonctions réseau basées sur des règles TCP/IP et qui est disponible comme une tâche dans IBM z/OS Management Facility (z/OSMF), et comme une application de poste de travail autonome.
La prise en charge de TLS v1.2 est devenue disponible dans z/OS 2.1, et elle est désactivée par défaut. Cette règle montre la commande (TLSV1.2 On) qui permet de l'activer explicitement, mais elle est mise en commentaire car le système cible utilise z/OS 1.13.
#
# Add TLSv1.2 support to AT-TLS
# requires z/OS 1.13 with OA39422 and PM62905
#
GSK_RENEGOTIATION=ALL
GSK_PROTOCOL_TLSV1_2=ON
Plusieurs mises à jour de sécurité sont requises pour permettre le bon fonctionnement de AT-TLS. Cette section comporte des exemples de commande RACF permettant d'effectuer la configuration requise.
# define started task user ID
# BPX.DAEMON permit is required for non-zero UID
ADDUSER PAGENT DFLTGRP(SYS1) OMVS(UID(0) SHARED HOME('/')) +
NAME('TCP/IP POLICY AGENT') NOPASSWORD
# define started task
RDEFINE STARTED PAGENT.* STDATA(USER(PAGENT) GROUP(SYS1)) +
DATA('TCP/IP POLICY AGENT')
# refresh to make the changes visible
SETROPTS RACLIST(STARTED) REFRESH
# restrict startup of policy agent
RDEFINE OPERCMDS MVS.SERVMGR.PAGENT UACC(NONE) +
DATA('restrict startup of policy agent')
PERMIT MVS.SERVMGR.PAGENT CLASS(OPERCMDS) ACCESS(CONTROL) ID(PAGENT)
# refresh to make the changes visible
SETROPTS RACLIST(OPERCMDS) REFRESH
# block stack access between stack and AT-TLS availability
# SETROPTS GENERIC(SERVAUTH)
# SETROPTS CLASSACT(SERVAUTH) RACLIST(FACILITY)
RDEFINE SERVAUTH EZB.INITSTACK.** UACC(NONE)
# Policy Agent
PERMIT EZB.INITSTACK.** CLASS(SERVAUTH) ACCESS(READ) ID(PAGENT)
# OMPROUTE daemon
PERMIT EZB.INITSTACK.** CLASS(SERVAUTH) ACCESS(READ) ID(OMPROUTE)
# SNMP agent and subagents
PERMIT EZB.INITSTACK.** CLASS(SERVAUTH) ACCESS(READ) ID(OSNMPD)
PERMIT EZB.INITSTACK.** CLASS(SERVAUTH) ACCESS(READ) ID(IOBSNMP)
# NAME daemon
PERMIT EZB.INITSTACK.** CLASS(SERVAUTH) ACCESS(READ) ID(NAMED)
# refresh to make the changes visible
SETROPTS RACLIST(SERVAUTH) REFRESH
# restrict access to pasearch command
# RDEFINE SERVAUTH EZB.PAGENT.** UACC(NONE) +
# DATA('restrict access to pasearch command')
# PERMIT EZB.PAGENT.** CLASS(SERVAUTH) ACCESS(READ) ID(tcpadmin)
# refresh to make the changes visible
# SETROPTS RACLIST(SERVAUTH) REFRESH
# permit Debug Manager to access certificates
#RDEFINE FACILITY IRR.DIGTCERT.LIST UACC(NONE)
#RDEFINE FACILITY IRR.DIGTCERT.LISTRING UACC(NONE)
PERMIT IRR.DIGTCERT.LIST CLASS(FACILITY) ACCESS(READ) ID(stcdbm)
PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ACCESS(READ) ID(stcdbm)
# refresh to make the changes visible
SETROPTS RACLIST(FACILITY) REFRESH
# create self-signed certificate
RACDCERT ID(stcdbm) GENCERT SUBJECTSDN(CN('RDz Debug Manager') +
OU('RTP labs') O('IBM') L('Raleigh') SP('NC') C('US')) +
NOTAFTER(DATE(2015-12-31)) KEYUSAGE(HANDSHAKE) WITHLABEL('dbgmgr')
# (optional) additional steps required to use a signed certificate
# 1. create a signing request for the self-signed certificate
RACDCERT ID(stcdbm) GENREQ (LABEL('dbgmgr')) DSN(dsn)
# 2. send the signing request to your CA of choice
# 3. check if the CA credentials (also a certificate) are already known
RACDCERT CERTAUTH LIST
# 4. mark the CA certificate as trusted
RACDCERT CERTAUTH ALTER(LABEL('CA cert')) TRUST
# or add the CA certificate to the database
RACDCERT CERTAUTH ADD(dsn) WITHLABEL('CA cert') TRUST
# 5. add the signed certificate to the database;
# this will replace the self-signed one
RACDCERT ID(stcdbm) ADD(dsn) WTIHLABEL('dbgmgr') TRUST
# Do NOT delete the self-signed certificate before replacing it.
# If you do, you lose the private key that goes with the certificate,
# which makes the certificate useless.
# create key ring
RACDCERT ID(stcdbm) ADDRING(dbgmgr.racf)
# add certificate to key ring
RACDCERT ID(stcbm) CONNECT(LABEL('dbgmgr') +
RING(dbgmgr.racf) USAGE(PERSONAL) DEFAULT)
# additional step required to use a signed certificate
# 6. add CA certificate to key ring
RACDCERT ID(stcdbm) CONNECT(CERTAUTH LABEL('CA cert') +
RING(dbgmgr.racf))
# refresh to make the changes visible
SETROPTS RACLIST(DIGTCERT) REFRESH
# check if the CA credentials (also a certificate) are already known
RACDCERT CERTAUTH LIST
# mark the CA certificate as trusted
RACDCERT CERTAUTH ALTER(LABEL('CA cert')) TRUST
# or add the CA certificate to the database
RACDCERT CERTAUTH ADD(dsn) WITHLABEL('CA cert') TRUST
# refresh to make the changes visible
SETROPTS RACLIST(DIGTCERT) REFRESH
# verify started task setup
LISTGRP SYS1 OMVS
LISTUSER PAGENT OMVS
RLIST STARTED PAGENT.* ALL STDATA
# verify Policy Agent startup permission
RLIST OPERCMDS MVS.SERVMGR.PAGENT ALL
# verify initstack protection
RLIST SERVAUTH EZB.INITSTACK.** ALL
# verify pasearch protection
RLIST SERVAUTH EZB.PAGENT.** ALL
# verify certificate setup
RACDCERT CERTAUTH LIST(LABEL('CA cert'))
RACDCERT ID(stcdbm) LIST(LABEL('dbgmgr'))
RACDCERT ID(stcdbm) LISTRING(dbgmgr.racf)
TCPCONFIG TTLS
V TCPIP,,OBEY,TCPIP.TCPPARMS(OBEY)
EZZ4249I stackname INSTALLED TTLS POLICY HAS NO RULES
S PAGENT
EZD1586I PAGENT HAS INSTALLED ALL LOCAL POLICIES FOR stackname
P DBGMGR
S DBBMGR
Cette section vous aide à résoudre certains des incidents qui peuvent se produire lors de la configuration de TCP/IP ou pendant la vérification ou la modification d'une configuration existante.
Pour plus d'informations sur la configuration TCP/IP, voir Communications Server: IP Configuration Guide (SC31-8775) et Communications Server: IP Configuration Reference (SC31-8776).
Lorsque vous utilisez APPC pour le service Commandes TSO, Developer for System z dépend de la validité du nom d'hôte du protocole TCP/IP quand il est initialisé. Cela implique que les différents fichiers de configuration TCP/IP et du programme de résolution soient configurés correctement.
Vous pouvez tester votre configuration TCP/IP à l'aide du programme de vérification d'installation fekfivpt. La commande doit renvoyer un résultat comparable à celui de cet exemple ($ correspond à l'invite z/OS UNIX) :
$ fekfivpt
Wed Jul 2 13:11:54 EDT 2008
uid=1(USERID) gid=0(GROUP)
using /etc/rdz/rsed.envvars
-------------------------------------------------------------
TCP/IP resolver configuration (z/OS UNIX search order):
-------------------------------------------------------------
Resolver Trace Initialization Complete -> 2008/07/02 13:11:54.745964
res_init Resolver values:
Global Tcp/Ip Dataset = None
Default Tcp/Ip Dataset = None
Local Tcp/Ip Dataset = /etc/resolv.conf
Translation Table = Default
UserId/JobName = USERID
Caller API = LE C Sockets
Caller Mode = EBCDIC
(L) DataSetPrefix = TCPIP
(L) HostName = CDFMVS08
(L) TcpIpJobName = TCPIP
(L) DomainOrigin = RALEIGH.IBM.COM
(L) NameServer = 9.42.206.2
9.42.206.3
(L) NsPortAddr = 53 (L) ResolverTimeout = 10
(L) ResolveVia = UDP (L) ResolverUdpRetries = 1
(*) Options NDots = 1
(*) SockNoTestStor
(*) AlwaysWto = NO (L) MessageCase = MIXED
(*) LookUp = DNS LOCAL
res_init Succeeded
res_init Started: 2008/07/02 13:11:54.755363
res_init Ended: 2008/07/02 13:11:54.755371
************************************************************************
MVS TCP/IP NETSTAT CS V1R9 TCPIP Name: TCPIP 13:11:54
Tcpip started at 01:28:36 on 06/23/2008 with IPv6 enabled
-------------------------------------------------------------
host IP address:
-------------------------------------------------------------
hostName=CDFMVS08
hostAddr=9.42.112.75
bindAddr=9.42.112.75
localAddr=9.42.112.75
Success, addresses match
Le programme de résolution joue le rôle des programmes comme un client qui accède aux serveurs de noms pour une résolution nom/adresse ou adresse/nom. Pour résoudre la requête du programme demandeur, le programme de résolution peut accéder aux serveurs de noms disponibles, utiliser des définitions locales (/etc/resolv.conf, /etc/hosts, /etc/ipnodes, HOSTS.SITEINFO, HOSTS.ADDRINFO, ou ETC.IPNODES, par exemple) ou utiliser une combinaison des deux.
Quand l'espace adresse du programme de résolution démarre, il lit un fichier de configuration du programme de résolution facultatif indiqué par la carte SETUP DD dans la procédure JCL du programme de résolution. Si les informations de configuration ne sont pas fournies, le programme de résolution utilise l'ordre de recherche MVS ou z/OS UNIX natif applicable, sans aucune information GLOBALTCPIPDATA, DEFAULTTCPIPDATA, GLOBALIPNODES, DEFAULTIPNODES ou COMMONSEARCH.
Il est important de connaître les fonctions de l'ordre de recherche des fichiers de configuration utilisés par TCP/IP, et de savoir quand vous pouvez remplacer l'ordre de recherche par défaut par des variables d'environnement, JCL ou autre variable fournie. Vous pouvez ainsi adapter votre fichier de données locales et les normes de dénomination d'un fichier d'un système hiérarchique ; il est également utile de savoir s'il s'agit du fichier de données de configuration ou du fichier du système hiérarchique qui est utilisé au moment d'identifier les incidents.
Autre point important, quand un ordre de recherche est appliqué à n'importe quel fichier de configuration, la recherche s'arrête au premier fichier trouvé. Par conséquent, vous risquez de trouver des résultats inattendus si vous enregistrez des informations de configuration dans un fichier qui n'est jamais trouvé, soit parce que d'autres fichiers le précèdent dans l'ordre de recherche ou parce que le fichier n'est pas inclus dans l'ordre de recherche choisi par l'application.
Quand vous recherchez des fichiers de configuration, vous pouvez indiquer clairement au protocole TCP/IP l'emplacement de la plupart des fichiers de configuration en utilisant des instructions de définition de données dans les procédures JCL ou en définissant des variables d'environnement. Sinon, vous pouvez laisser le protocole TCP/IP déterminer de manière dynamique l'emplacement des fichiers de configuration, en fonction des ordres de recherche documentés dans le guide Communications Server: IP Configuration Guide (SC31-8775).
Le composant de configuration de la pile TCP/IP utilise TCPIP.DATA au cours de l'initialisation de la pile TCP/IP afin d'en déterminer le paramètre HOSTNAME. Pour obtenir sa valeur, l'ordre de recherche de l'environnement z/OS UNIX est utilisé.
Le tableau ou fichier particulier recherché correspond à un fichier MVS ou à un fichier de système hiérarchique, en fonction des paramètres de configuration du programme de résolution et de la présence de ces fichiers sur le système.
Le fichier de configuration du programme de résolution de base contient des instructions TCPIP.DATA. Outre les directives du programme de résolution, il est référencé pour déterminer, entre autres, le préfixe du fichier (valeur de l'instruction DATASETPREFIX) à utiliser lors de la tentative d'accès à certains des fichiers de configuration spécifiés dans cette section.
L'ordre de recherche permettant d'accéder au fichier de configuration du programme de résolution de base est le suivant :
Si ce fichier est défini, la valeur de l'instruction de configuration GLOBALTCPIPDATA du programme de résolution est utilisée (voir aussi Présentation des programmes de résolution). La recherche se poursuit pour trouver un autre fichier de configuration. La recherche s'arrête avec le fichier trouvé suivant.
La valeur utilisée est celle de la variable d'environnement. La recherche échoue si le fichier n'existe pas ou s'il se trouve dans un autre emplacement.
Le fichier utilisé est celui qui est attribué au nom DD SYSTCPD. Dans l'environnement z/OS UNIX, un processus enfant n'a pas accès à SYSTCPD DD. En effet, l'attribution SYSTCPD n'est pas héritée du processus père sur le processus parallèle de traitement() ou les appels de fonction de commande exec.
userid désigne l'ID utilisateur qui est associé à l'environnement de sécurité en cours (espace adresse, tâche ou unité d'exécution).
jobname correspond au nom indiqué dans l'instruction JCL JOB pour les travaux par lots ou le nom de la procédure pour une procédure démarrée.
Si ce fichier est défini, la valeur de l'instruction de configuration DEFAULTTCPIPDATA du programme de résolution est utilisée (voir aussi Présentation des programmes de résolution).
Les tables de conversion (EBCDIC en ASCII et ASCII en EBCDIC) permettent de déterminer les fichiers de conversion à utiliser. L'ordre de recherche permettant d'accéder à ce fichier de configuration est le suivant. L'ordre de recherche s'arrête au premier fichier trouvé :
userid désigne l'ID utilisateur qui est associé à l'environnement de sécurité en cours (espace adresse ou tâche/unité d'exécution).
jobname correspond au nom indiqué dans l'instruction JCL JOB pour les travaux par lots ou le nom de la procédure pour une procédure démarrée.
hlq représente la valeur de l'instruction DATASETPREFIX spécifiée dans le fichier de configuration du programme de résolution de base (le cas échéant) ; sinon, hlq correspond au protocole TCPIP par défaut.
Par défaut, le programme de résolution tente tout d'abord d'utiliser n'importe quel serveur de noms de domaine configuré pour les demandes de résolution. Si la demande de résolution n'est pas satisfaite, les tables de système hôte local sont utilisées. Le comportement du programme de résolution est contrôlé par les instructions TCPIP.DATA.
Les instructions du programme de résolution TCPIP.DATA définissent si et comment des serveurs de noms de domaine doivent être utilisés. L'instruction LOOKUP TCPIP.DATA permet également de contrôler l'utilisation des serveurs de noms de domaine et des tables de système hôte local. Pour de plus amples informations sur les instructions TCPIP.DATA, voir le document Communications Server: IP Configuration Reference (SC31-8776).
Le programme de résolution se sert de l'ordre de recherche unique Ipv4 pour trouver des informations de nom de site sans restrictions pour les appels API getnetbyname. L'ordre de recherche unique Ipv4 pour des informations de nom de site est le suivant. La recherche s'arrête au premier fichier trouvé :
La valeur de la variable d'environnement correspond au nom du fichier d'informations HOSTS.SITEINFO créé par la commande TSO MAKESITE.
La valeur de la variable d'environnement correspond au nom du fichier d'informations HOSTS.ADDRINFO créé par la commande TSO MAKESITE.
userid désigne l'ID utilisateur qui est associé à l'environnement de sécurité en cours (espace adresse ou tâche/unité d'exécution).
jobname correspond au nom indiqué dans l'instruction JCL JOB pour les travaux par lots ou le nom de la procédure pour une procédure démarrée.
hlq représente la valeur de l'instruction DATASETPREFIX spécifiée dans le fichier de configuration du programme de résolution de base (le cas échéant) ; sinon, hlq correspond au protocole TCPIP par défaut.
Comme indiqué précédemment, Developer for System z dépend de la validité du nom d'hôte TCP/IP lors de son initialisation, lors de l'utilisation d'APPC. Cela implique que les différents fichiers de configuration TCP/IP et du programme de résolution soient configurés correctement.
L'exemple ci-dessous présente certaines tâches de la configuration TCP/IP et du programme de résolution. Il ne couvre pas l'ensemble de la configuration TCP/IP ou du programme de résolution, il souligne uniquement certains aspects clés qui peuvent s'appliquer à votre site :
//TCPIP PROC PARMS=’CTRACE(CTIEZB00)’,PROF=TCPPROF,DATA=TCPDATA
//*
//* TCP/IP NETWORK
//*
//TCPIP EXEC PGM=EZBTCPIP,REGION=0M,TIME=1440,PARM=&PARMS
//PROFILE DD DISP=SHR,DSN=SYS1.TCPPARMS(&PROF)
//SYSTCPD DD DISP=SHR,DSN=SYS1.TCPPARMS(&DATA)
//SYSPRINT DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136)
//ALGPRINT DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136)
//CFGPRINT DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136)
//SYSOUT DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136)
//CEEDUMP DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136)
//SYSERROR DD SYSOUT=*
; HOSTNAME indique le nom d'hôte TCP de ce système. S'il n'est pas
; spécifié, le paramètre HOSTNAME par défaut sera le nom de noeud spécifié
; dans le membre IEFSSNxx PARMLIB.
;
; HOSTNAME
;
; DOMAINORIGIN indique l'origine du domaine qui sera ajoutée
; aux noms d'hôte transmis au programme de résolution. Si un nom d'hôte contient
; des points, le paramètre DOMAINORIGIN ne sera pas ajouté au
; nom d'hôte.
;
DOMAINORIGIN RALEIGH.IBM.COM
;
; NSINTERADDR indique l'adresse IP du serveur de noms.
; LOOPBACK (14.0.0.0) indique votre serveur de noms local. Si vous n'utilisez
; pas de serveur de noms, ne codez pas d'instruction NSINTERADDR.
; (Mettez en commentaire la ligne NSINTERADDR ci-dessous). Cette action va
; résoudre tous les noms via la consultation du tableau de site.
;
; NSINTERADDR 14.0.0.0
;
; TRACE RESOLVER va créer une trace complète des requêtes à destination
; et des réponses provenant du serveur de noms ou des tableaux de site
; à écrire dans la console de l'utilisateur. Cette commande s'applique à
des fins de débogage uniquement.
;
; TRACE RESOLVER
//RESOLVER PROC PARMS=’CTRACE(CTIRES00)’
//*
//* IP NAME RESOLVER – START WITH SUB=MSTR
//*
//RESOLVER EXEC PGM=EZBREINI,REGION=0M,TIME=1440,PARM=&PARMS
//*SETUP DD DISP=SHR,DSN=USER.PROCLIB(RESSETUP),FREE=CLOSE
TCPIPJOBNAME TCPIP
DomainOrigin RALEIGH.IBM.COM
HostName CDFMVS08
Comme mentionné dans Ordres de recherche utilisés dans l'environnement z/OS UNIX, le fichier de configuration de base contient des instructions TCPIP.DATA. Si le nom du système est CDFMVS08 (TCPDATA indique que le nom du système est utilisé comme nom d'hôte), vous pouvez constater que /etc/resolv.conf est en synchronisation avec SYS1.TCPPARMS(TCPDATA). Aucune définition de système de nom de domaine n'existe, par conséquent la consultation du tableau de site sera utilisée.
# Resolver /etc/hosts file cdfmvs08
9.42.112.75 cdfmvs08 # CDFMVS08 Host
9.42.112.75 cdfmvs08.raleigh.ibm.com # CDFMVS08 Host
127.0.0.1 localhost
Le contenu minimal de ce fichier comprend des informations sur le système actuel. Dans l'exemple ci-dessus, cdfmvs08 etcdfmvs08.raleigh.ibm.com sont définis en tant que nom valide pour l'adresse IP du système z/OS.
Si vous utilisiez un serveur de noms de domaine (DNS), le DNS contiendrait des informations /etc/hosts, et /etc/resolv.conf et SYS1.TCPPARMS(TCPDATA) auraient des instructions identifiant le DNS sur votre système.
Pour éviter toute confusion, il est recommandé de conserver les fichiers de configuration TCP/IP et du programme de résolution en synchronisation les uns avec les autres.
description de type de fichier | API concernée(s) | Fichiers candidats |
---|---|---|
Fichiers de configuration du programme de résolution de base | Toutes les API |
|
Tables de conversion | Toutes les API |
|
Tables de système hôte local | endhostent |
IPv4
IPv6
|
clientip(0.0.0.0) <> callerip(<adresse IP de l'hôte>)
Resolver Trace Initialization Complete -> 2008/07/02 13:11:54.745964
res_init Resolver values:
Global Tcp/Ip Dataset = None
Default Tcp/Ip Dataset = None
Local Tcp/Ip Dataset = /etc/resolv.conf
Translation Table = Default
UserId/JobName = USERID
Caller API = LE C Sockets
Caller Mode = EBCDIC
Vérifiez que les définitions du fichier référencées par “Fichier Tcp/Ip local” sont correctes.
Cette zone est vide si vous n'utilisez pas un nom par défaut pour le fichier du programme de résolution IP (à l'aide de l'ordre de recherche z/OS UNIX). Si tel est le cas, ajoutez l'instruction suivante dans rsed.envvars, où <fichier du programme de résolution> ou <données du programme de résolution> représente le nom de votre fichier de programme de résolution IP :
RESOLVER_CONFIG=<fichier du programme de résolution>
ou
RESOLVER_CONFIG=’<données du programme de résolution>’
Les publications suivantes sont référencées dans ce document :
Titre de la publication | Référence de la commande | Référence | Site Web de référence |
---|---|---|---|
Répertoire du programme d'IBM Rational Developer for System z | GI11-7314 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Répertoire du programme pour l'utilitaire hôte IBM Rational Developer for System z | GI11-7463 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Conditions requises pour IBM Rational Developer for System z | SC11-6252 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
IBM Rational Developer for System z - Guide de démarrage rapide de configuration de l'hôte | GI11-7313 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
IBM Rational Developer for System z - Guide de configuration de l'hôte | SC11-6285 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
IBM Rational Developer for System z - Guide de référence de configuration de l'hôte | SC11-6869 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
IBM Rational Developer for System z - Guide de l'utilitaire de configuration de l'hôte | SC11-6859 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
IBM Rational Developer for System z - Messages et codes | SC11-7014 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
IBM Rational Developer for System z Answers to common host configuration and maintenance issues | SC14-7373 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
IBM Rational Developer for System z Common Access Repository Manager Developer's Guide | SC23-7660 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Conditions requises pour IBM Rational Developer for System z | SC11-6252 | Developer for System z | http://www.ibm.com/software/rational/products/developer/systemz/library/index.html |
IBM Rational Developer for System z - Guide de démarrage rapide de configuration de l'hôte | GI11-7313 | Developer for System z | http://www.ibm.com/software/rational/products/developer/systemz/library/index.html |
SCLM Developer Toolkit - Guide d'administration | SC11-6464 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Using APPC to provide TSO command services | SC14-7291 | Livre blanc | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Using ISPF Client Gateway to provide CARMA services | SC14-7292 | Livre blanc | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Communications Server IP Configuration Guide | SC31-8775 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP Configuration Reference | SC31-8776 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP Diagnosis Guide | GC31-8782 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP System Administrator's Commands | SC31-8781 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server SNA Network Implementation Guide | SC31-8777 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server SNA Operations | SC31-8779 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Cryptographic Services System SSL Programming | SC24-5901 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
DFSMS Macro Instructions for Data Sets | SC26-7408 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
DFSMS Using data sets | SC26-7410 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Language Environment Customization | SA22-7564 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Language Environment Debugging Guide | GA22-7560 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Diagnosis: Tools and Service Aids | GA22-7589 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Initialization and Tuning Guide | SA22-7591 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Initialization and Tuning Reference | SA22-7592 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS JCL Reference | SA22-7597 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Planning APPC/MVS Management | SA22-7599 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Planning Workload Management | SA22-7602 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS System Commands | SA22-7627 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Security Server RACF Command Language Reference | SA22-7687 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Security Server RACF Security Administrator's Guide | SA22-7683 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
TSO/E Customization | SA22-7783 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
TSO/E REXX Reference | SA22-7790 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services Command Reference | SA22-7802 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services Planning | GA22-7800 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services User's Guide | SA22-7801 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Using REXX and z/OS UNIX System Services | SA22-7806 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Java™ Diagnostic Guide | SC34-6650 | Java 6.0 | http://www.ibm.com/developerworks/java/jdk/diagnosis/ |
Java SDK and Runtime Environment User Guide | / | Java 6.0 | http://www-03.ibm.com/servers/eserver/zseries/software/java/ |
Resource Definition Guide | SC34-6430 | CICSTS 3.1 | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
Resource Definition Guide | SC34-6815 | CICSTS 3.2 | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
Resource Definition Guide | SC34-7000 | CICSTS 4.1 | https://publib.boulder.ibm.com/infocenter/cicsts/v4r1/index.jsp?topic=/com.ibm.cics.ts.home.doc/library/library_html.html |
Resource Definition Guide | SC34-7181 | CICSTS 4.2 | https://publib.boulder.ibm.com/infocenter/cicsts/ v4r2/index.jsp?topic=/com.ibm.cics.ts.home.doc/ library/library_html.html |
RACF Security Guide | SC34-6454 | CICSTS 3.1 | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
RACF Security Guide | SC34-6835 | CICSTS 3.2 | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
RACF Security Guide | SC34-7003 | CICSTS 4.1 | https://publib.boulder.ibm.com/infocenter/cicsts/v4r1/index.jsp?topic=/com.ibm.cics.ts.home.doc/library/library_html.html |
RACF Security Guide | SC34-7179 | CICSTS 4.2 | https://publib.boulder.ibm.com/infocenter/cicsts/v4r2/index.jsp?topic=/com.ibm.cics.ts.home.doc/library/library_html.html |
Language Reference | SC27-1408 | Enterprise COBOL for z/OS | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
Description | Site Web de référence |
---|---|
IBM Knowledge Center Developer for System z | http://www-01.ibm.com/support/knowledgecenter/SSQ2R2_9.1.0/com.ibm.etools.getstart.wsentdev.doc/kc_version_welcome_rdz.html |
Bibliothèque Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Page d'accueil Developer for System z | http://www-03.ibm.com/software/products/en/developerforsystemz/ |
Developer for System z Recommended service | http://www-01.ibm.com/support/docview.wss?rs=2294&context=SS2QJ2&uid=swg27006335 |
Developer for System z - Demande d'amélioration | https://www.ibm.com/developerworks/support/rational/rfe/ |
Bibliothèque Internet z/OS | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
IBM Knowledge Center CICSTS | https://publib.boulder.ibm.com/infocenter/cicsts/v4r1/index.jsp |
IBM Tivoli Directory Server | http://www-01.ibm.com/software/tivoli/products/directory-server/ |
Plug-ins d'outils d'identification des incidents | http://www-01.ibm.com/software/awdtools/deployment/pdtplugins/ |
Java Security information | http://www.ibm.com/developerworks/java/jdk/security/ |
Télécharger Apache Ant | http://ant.apache.org/ |
Documentation du l'outil de clé Java | http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html |
Page d'accueil du support de l'autorité de certification | https://support.ca.com/ |
Titre de la publication | Référence de la commande | Référence | Site Web de référence |
---|---|---|---|
ABCs of z/OS System Programming Volume 9 (z/OS UNIX) | SG24-6989 | Redbook | http://www.redbooks.ibm.com/ |
Guide du programmeur système pour : Workload Manager | SG24-6472 | Redbook | http://www.redbooks.ibm.com/ |
TCPIP Implementation Volume 1: Base Functions, Connectivity, and Routing | SG24-7532 | Redbook | http://www.redbooks.ibm.com/ |
TCPIP Implementation Volume 3: High Availability, Scalability, and Performance | SG24-7534 | Redbook | http://www.redbooks.ibm.com/ |
TCP/IP Implementation Volume 4: Security and Policy-Based Networking | SG24-7535 | Redbook | http://www.redbooks.ibm.com/ |
Tivoli Directory Server for z/OS | SG24-7849 | Redbook | http://www.redbooks.ibm.com/ |
© Copyright IBM Corporation 1992, 2013.
U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Le présent document peut contenir des informations ou des références concernant certains produits, logiciels ou services IBM non annoncés dans certains pays. Pour plus de détails, référez-vous aux documents d'annonce disponibles dans votre pays ou adressez-vous à votre partenaire commercial IBM. Toute référence à un produit, logiciel ou service IBM n'implique pas que seul ce produit, logiciel ou service IBM puisse être utilisé. Tout autre élément fonctionnellement équivalent peut être utilisé, s'il n'enfreint aucun droit IBM. Toutefois, il appartient à l'utilisateur d'évaluer et de vérifier le fonctionnement de produits, logiciels ou services non expressément référencés par IBM.
IBM peut détenir des brevets ou des demandes de brevet couvrant les produits mentionnés dans la présente documentation. La remise de ce document ne vous donne aucun droit de licence sur ces brevets ou demandes de brevet. Si vous désirez recevoir des informations concernant l'acquisition de licences, veuillez en faire la demande par écrit à l'adresse suivante :
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
U.S.A.
IBM Director of Commercial Relations
IBM Canada Ltd.
3600 Steeles Avenue East
Markham, Ontario
L3R 9Z7
Canada
Les informations sur les licences concernant les produits utilisant un jeu de caractères double octet peuvent être obtenues auprès du IBM Intellectual Property Department de votre pays ou par écrit à l'adresse suivante :
Intellectual Property Licensing
Legal and Intellectual Property Law
IBM Japan, Ltd.
19-21, Nihonbashi-Hakozakicho, Chuo-ku
Tokyo 103-8510, Japan
Le paragraphe suivant ne s'applique ni au Royaume-Uni, ni dans aucun pays dans lequel il serait contraire aux lois locales. LE PRESENT DOCUMENT EST LIVRE EN L'ETAT SANS AUCUNE GARANTIE EXPLICITE OU IMPLICITE. IBM DECLINE NOTAMMENT TOUTE RESPONSABILITE RELATIVE A CES INFORMATIONS EN CAS DE CONTREFACON AINSI QU'EN CAS DE DEFAUT D'APTITUDE A L'EXECUTION D'UN TRAVAIL DONNE. Certaines juridictions n'autorisent pas l'exclusion des garanties implicites, auquel cas l'exclusion ci-dessus ne vous sera pas applicable.
Le présent document peut contenir des inexactitudes ou des coquilles. Elle est mise à jour périodiquement. Chaque nouvelle édition inclut les mises à jour. IBM peut, à tout moment et sans préavis, modifier les produits et/ou programmes décrits dans ce document.
Les références à des sites web non IBM sont fournies à titre d'information uniquement et n'impliquent en aucun cas une adhésion aux données qu'ils contiennent. Les éléments figurant sur ces sites web ne font pas partie des éléments du présent produit IBM et l'utilisation de ces sites relève de votre seule responsabilité.
IBM pourra utiliser ou diffuser, de toute manière qu'elle jugera appropriée et sans aucune obligation de sa part, tout ou partie des informations qui lui seront fournies.
Les licenciés souhaitant obtenir des informations permettant : (i) l'échange des données entre des logiciels créés de façon indépendante et d'autres logiciels (dont celui-ci), et (ii) l'utilisation mutuelle des données ainsi échangées, doivent adresser leur demande à :
Intellectual Property Dept. for Rational Software
IBM Corporation
Silicon Valley Lab
555 Bailey Avenue
San Jose, CA 95141-1003
U.S.A.
Ces informations peuvent être soumises à des conditions particulières, prévoyant notamment le paiement d'une redevance.
Le logiciel sous licence décrit dans cette documentation et tous les éléments sous licence disponibles s'y rapportant sont fournis par IBM conformément aux dispositions de l'IBM Customer Agreement, des Conditions internationales d'utilisation des logiciels IBM ou de tout autre accord équivalent.
Les données de performance indiquées dans ce document ont été déterminées dans un environnement contrôlé. Par conséquent, les résultats peuvent varier de manière significative selon l'environnement d'exploitation utilisé. Certaines mesures évaluées sur des systèmes en cours de développement ne sont pas garanties sur tous les systèmes disponibles. En outre, elles peuvent résulter d'extrapolations. Les résultats peuvent donc varier. Il incombe aux utilisateurs de ce document de vérifier si ces données sont applicables à leur environnement d'exploitation.
Les informations concernant des produits non IBM ont été obtenues auprès des fournisseurs de ces produits, par l'intermédiaire d'annonces publiques ou via d'autres sources disponibles. IBM n'a pas testé ces produits et ne peut confirmer l'exactitude de leurs performances, ni leur compatibilité. Elle ne peut recevoir aucune réclamation concernant des produits non-IBM. Toute question concernant les performances de produits non IBM doit être adressée aux fournisseurs de ces produits.
Toute instruction relative aux intentions d'IBM pour ses opérations à venir est susceptible d'être modifiée ou annulée sans préavis, et doit être considérée uniquement comme un objectif.
Le présent document contient des exemples de données et de rapports utilisés couramment dans l'environnement professionnel. Ces exemples mentionnent des noms fictifs de personnes, de sociétés, de marques ou de produits à des fins illustratives ou explicatives uniquement. Toute ressemblance avec des noms de personnes, de sociétés ou des données réelles serait purement fortuite.
Le présent logiciel contient des exemples de programmes d'application en langage source destinés à illustrer les techniques de programmation sur différentes plateformes d'exploitation. Vous avez le droit de copier, de modifier et de distribuer ces exemples de programmes sous quelque forme que ce soit et sans paiement d'aucune redevance à IBM, à des fins de développement, d'utilisation, de vente ou de distribution de programmes d'application conformes aux interfaces de programmation des plateformes pour lesquels ils ont été écrits ou aux interfaces de programmation. Ces exemples de programmes n'ont pas été rigoureusement testés dans toutes les conditions. Par conséquent, IBM ne peut garantir expressément ou implicitement la fiabilité, la maintenabilité ou le fonctionnement de ces programmes. Les exemples de programme sont fournis en l'état, sans garantie d'aucune sortie. IBM ne sera en aucun cas responsable des dommages résultant de votre utilisation des exemples de programmes.
Toute copie totale ou partielle de ces Programmes exemples et des oeuvres qui en sont dérivées doit comprendre une notice de copyright, libellée comme suit :
© (nom de votre société) (année). Des segments de code sont dérivés des Programmes exemples d'IBM Corp. © Copyright IBM Corp. 1992, 2013.
Si vous visualisez la copie logicielle de ces informations, les photographies et les illustrations en couleurs peuvent ne pas s'afficher.
Les Logiciels IBM, y compris les Logiciels sous forme de services ("Offres Logiciels") peuvent utiliser des cookies ou d'autres technologies pour collecter des informations sur l'utilisation des produits, améliorer l'acquis utilisateur, personnaliser les interactions avec celui-ci, ou dans d'autres buts. Bien souvent, aucune information personnelle identifiable n'est collectée par les Offres Logiciels. Certaines Offres Logiciels vous permettent cependant de le faire. Si la présente Offre Logiciels utilise des cookies pour collecter des informations personnelles identifiables, des informations spécifiques sur cette utilisation sont fournies ci-dessous.
Cette Offre Logiciels n'utilise pas de cookies ou d'autres techniques pour collecter des informations personnelles identifiables.
IBM, le logo IBM et ibm.com sont des marques d'International Business Machines dans de nombreux pays. Les autres noms de produits et de services sont des marques d'IBM ou d'autres sociétés. La liste actualisée de toutes les marques d'IBM est disponible sur la page Web "Copyright and trademark information" à www.ibm.com/legal/copytrade.shtml.
Applicabilité
Ces dispositions s'ajoutent aux conditions d'utilisation du site Web IBM.
Usage personnel
Vous pouvez reproduire ces publications pour votre usage personnel, non commercial, sous réserve que toutes les mentions de propriété soient conservées. Vous ne pouvez distribuer ni publier tout ou partie de ces publications ou en faire des oeuvres dérivées sans le consentement exprès d'IBM.
Usage commercial
Vous pouvez reproduire, distribuer et publier ces publications uniquement au sein de votre entreprise, sous réserve que toutes les mentions de propriété soient conservées. Vous n'êtes pas autorisé à reproduire, distribuer ou afficher tout ou partie de ces publications, ni à créer une oeuvre dérivée de ces dernières en dehors de votre entreprise, sans l'autorisation expresse d'IBM®.
Droits
Excepté les droits d'utilisation expressément accordés dans ce document, aucun autre droit, licence ou autorisation, implicite ou explicite, n'est accordé pour ces publications ou autres informations, données, logiciels ou droits de propriété intellectuelle contenus dans ces publications.
IBM se réserve le droit de retirer les autorisations accordées ici si, à sa discrétion, l'utilisation des publications s'avère préjudiciable à ses intérêts ou que, selon son appréciation, les instructions susmentionnées n'ont pas été respectées.
Vous ne pouvez télécharger, exporter ou réexporter ces informations qu'en total accord avec toutes les lois et règlements applicables dans votre pays, y compris les lois et règlements américains relatifs à l'exportation.
IBM NE FOURNIT AUCUNE GARANTIE QUANT AU CONTENU DE CES PUBLICATIONS. LES PUBLICATIONS SONT LIVREES "EN L'ETAT" SANS AUCUNE GARANTIE EXPLICITE OU IMPLICITE. IBM DECLINE NOTAMMENT TOUTE RESPONSABILITE RELATIVE A CES PUBLICATIONS EN CAS DE CONTREFAÇON AINSI QU'EN CAS DE DEFAUT D'APTITUDE A L'EXECUTION D'UN TRAVAIL DONNE.
Le présent logiciel contient des exemples de programmes d'application en langage source destinés à illustrer les techniques de programmation sur différentes plateformes d'exploitation. Vous avez le droit de copier, de modifier et de distribuer ces exemples de programmes sous quelque forme que ce soit et sans paiement d'aucune redevance à IBM, à des fins de développement, d'utilisation, de vente ou de distribution de programmes d'application conformes aux interfaces de programmation des plateformes pour lesquels ils ont été écrits ou aux interfaces de programmation IBM. Ces exemples de programmes n'ont pas été rigoureusement testés dans toutes les conditions. Par conséquent, IBM ne peut garantir expressément ou implicitement la fiabilité, la maintenabilité ou le fonctionnement de ces programmes. Les exemples de programme sont fournis "EN L'ETAT", sans garantie d'aucune sorte. IBM ne peut en aucun cas être tenu pour responsable des dommages liés à l'utilisation de ces exemples de programme.
IBM, le logo IBM et ibm.com sont des marques d'International Business Machines Corp. dans de nombreux pays. Les autres noms de produit et service sont des marques d'IBM ou d'autres sociétés. La liste actualisée de toutes les marques d'IBM est disponible sur la page Web "Copyright and trademark information" à http://www.ibm.com/legal/copytrade.shtml.
Adobe et PostScript sont des marques d'Adobe Systems Incorporated.
Cell Broadband Engine - Sony Computer Entertainment Inc.
Rational est une marque d'International Business Machines Corporation et de Rational Software Corporation aux Etats-Unis et/ou dans certains autres pays.
Intel, Intel Centrino, Intel SpeedStep, Intel Xeon, Celeron, Itanium et Pentium sont des marques d'Intel Corporation aux Etats-Unis et/ou dans certains autres pays.
IT Infrastructure Library est une marque de Central Computer and Telecommunications Agency.
ITIL est une marque de Minister for the Cabinet Office.
Linear Tape-Open, LTO et Ultrium sont des marques de HP, IBM Corp. et Quantum.
Linux est une marque de Linus Torvalds.
Microsoft, Windows et le logo Windows sont des marques ou des marques déposées de Microsoft Corporation au Etats-Unis et/ou dans certains autres pays.
Java et toutes les marques et logos incluant Java sont des marques de Sun Microsystems, Inc. aux Etats-Unis et/ou dans certains autres pays.
UNIX est une marque enregistrée de The Open Group aux Etats-Unis et/ou dans certains autres pays.