Avant d'utiliser le présent document et le produit associé, prenez connaissance des informations générales figurant à la section Remarques relatives à la documentation pour IBM Rational Developer for System z.
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 17 avenue de l'Europe 92275 Bois-Colombes Cedex
© Copyright IBM France 2010. Tous droits réservés.
Le présent manuel décrit les fonctions de configuration d'IBM Rational Developer for System z. Il fournit les instructions permettant de configurer IBM Rational Developer for System z Version 7.6.1 sur votre système hôte z/OS.
A partir de maintenant, les noms suivants sont utilisés dans le présent ouvrage :
Pour les éditions antérieures, telles qu'IBM WebSphere Developer for System z, IBM WebSphere Developer for zSeries et IBM® WebSphere Studio Enterprise Developer, utilisez les informations du guide de configuration de l'hôte et des répertoires de programme de ces éditions.
Le présent document s'adresse aux programmeurs système qui souhaitent installer et configurer IBM Rational Developer for System z Version 7.6.1, FMID HHOP760, sur leur système hôte z/OS.
Il fournit les procédures détaillées de configuration complète du produit, y compris certains scénarios autres que ceux fournis par défaut. 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 changements apportés au document Rational Developer for System z Version 7.6.1 - Guide de configuration de l'hôte, SC11-6285-03 (mise à jour mai 2010).
Les changements et ajouts techniques au texte et illustrations sont indiqués par un trait vertical situé à gauche du changement.
Ce document contient des informations précédemment présentées dans le document Rational Developer for System z Version 7.6 - Guide de configuration de l'hôte, SC11-6285-02.
Nouvelles informations :
Cette section récapitule les informations présentées dans ce document.
Utilisez les informations du présent chapitre afin de planifier l'installation et le déploiement de Developer for System z.
La procédure de personnalisation ci-dessous s'applique à la configuration du produit Developer for System z de base :
Common Access Repository Manager (CARMA) représente un gain de productivité pour les développeurs qui créent des gestionnaires d'accès au référentiel (RAM). Un RAM constitue une interface de programmation d'application pour les gestionnaires de configuration logicielle (SCM) basés sur z/OS.
Inversement, les applications créées par des utilisateurs peuvent démarrer un serveur CARMA qui charge les RAM et fournit une interface standard pour accéder au SCM.
L'interface d'IBM Rational Developer for System z pour le gestionnaire de configuration logicielle de CA Endevor donne aux clients Developer for System z un accès direct au SCM de CA Endevor SCM.
Developer for System z utilise certaines fonctions du Gestionnaire de déploiement d'application comme approche commune de déploiement pour plusieurs composants. La personnalisation facultative active davantage de fonctions d'Application Deployment Manager et peut ajouter les services suivants à Developer for System z :
SCLM Developer Toolkit fournit les outils nécessaires à l'extension des fonctions de SCLM sur le client. SCLM est lui-même un gestionnaire de code source hôte livré comme partie intégrante d'ISPF.
SCLM Developer Toolkit intègre un module d'extension reposant sur Eclipse qui sert d'interface avec SCLM et fournit l'accès à tous les processus SCLM de développement du code existant. Il assure également la prise en charge du développement intégral de Java et J2EE sur le poste de travail avec la synchronisation de SCLM sur le grand système, y compris la construction, l'assemblage et le déploiement du code J2EE à partir du grand système.
La présente section regroupe diverses tâches de personnalisation facultatives. Suivez les instructions de la section adéquate pour configurer le service souhaité.
Une fois que vous avez terminé la personnalisation du produit, vous pouvez utiliser les programmes de vérification de l'installation décrits dans ce chapitre pour vérifier que l'installation des principaux composants du produit a abouti.
Le présent chapitre répertorie les commandes de l'opérateur (ou de la console) disponibles pour Developer for System z.
Le présent chapitre vous aide à résoudre certains incidents fréquents qui peuvent survenir lors de la configuration de Developer for System z. Il se compose des sections suivantes :
Developer for System z fournit un accès grand système aux utilisateurs d'un poste de travail standard. 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.
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.
Contrairement à des 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 16 unités d'exécution, d'une certaine quantité de mémoire et éventuellement d'un ou de plusieurs espaces adresses 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 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.
La présente section met en évidence les modifications de l'installation et de la configuration par rapport aux précédentes éditions du produit. Elle fournit également des instructions générales pour la migration de cette édition. Pour de plus amples informations, consultez les sections associées dans ce manuel.
Cette annexe vous aide à résoudre certains incidents fréquents qui peuvent survenir lors de la configuration du protocole SSL (Secure Socket Layer), ou au cours de la vérification ou de la modification d'une configuration existante. Elle contient un exemple de configuration pour prendre en charge les utilisateurs qui s'authentifient à l'aide d'un certificat X.509.
Cette annexe vous aide à résoudre certains incidents fréquents qui peuvent survenir lors de la configuration du TCP/IP, ou au cours de la vérification ou de la modification d'une configuration existante.
Cette annexe vous aide à résoudre certains incidents fréquents qui peuvent survenir lors de la configuration d'INETD ou au cours de la vérification ou de la modification d'une configuration existante. INETD est utilisé par Developer for System z pour la fonction REXEC/SSH.
Cette annexe vous aide à résoudre certains incidents fréquents qui peuvent survenir lors de la configuration d'APPC (Advanced Program-to-Program Communication) ou au cours de la vérification ou de la modification d'une configuration existante.
La présente annexe répertorie les conditions requises et les corequis liés à l'hôte correspondant à cette version de Developer for System z.
Utilisez les informations du présent chapitre conjointement avec les informations contenues de l'Annexe E. Conditions requises afin de planifier l'installation et le déploiement de Developer for System z. Les sujets suivants sont abordés :
Le Guide de migration décrit les modifications de l'installation et de la configuration par rapport aux précédentes éditions du produit. Utilisez ces informations pour planifier votre migration vers la version en cours de Developer for System z.
Developer for System z est composé d'un client, installé sur l'ordinateur personnel de l'utilisateur, et d'un serveur, installé sur un ou plusieurs hôtes. La présente documentation va porter sur l'hôte, à savoir un système z/OS. Toutefois, d'autres systèmes d'exploitation comme AIX et Linux® on System z, sont également pris en charge.
Le client offre aux développeurs un environnement de développement reposant sur Eclipse- et assurant à l'hôte l'uniformité de l'interface graphique, ce qui permet, entre autres, de décharger les travaux de l'hôte sur le client, en économisant les ressources de l'hôte.
La partie de l'hôte est composée de plusieurs tâches actives en permanence et de tâches démarrées ad-hoc. Ces tâches permettent au client de gérer les différents composants de l'hôte z/OS (les ensembles de données MVS, les commandes TSO, les fichiers et commandes z/OS UNIX, les soumissions de travaux et les sorties de travaux, par exemple).
Developer for System z peut également interagir avec les sous-systèmes et les autres logiciels d'application installés sur l'hôte (CICS, Debug Tool et les gestionnaires de configuration de logiciel (SCM), par exemple) si Developer for system z est configuré pour le faire, et si ces produits (configuration annexe requise) sont disponibles.
Voir le Compréhension de Developer for System z pour obtenir des informations de base sur la conception de Developer for System z.
Consultez le site Web de Developer for System z (http://www-01.ibm.com/software/awdtools/rdz/) ou votre représentant IBM local pour obtenir des informations complémentaires sur les fonctionnalités proposées par Developer for System z.
Des compétences SMP/E minimales sont nécessaires pour installer l'hôte Developer for System z.
La configuration de Developer for System z nécessite plus de droits et de connaissances que ceux dont dispose habituellement le programmeur système. Une assistance peut donc s'avérer nécessaire. Le tableau 3 et le tableau 4 répertorient les administrateurs nécessaires pour effectuer les tâches de personnalisation obligatoires et facultatives.
Le temps nécessaire à l'installation et à la configuration des composants de l'hôte System z varie en fonction des facteurs suivants :
L'expérience a montré qu'un et quatre jours sont nécessaires pour mener à bien le processus d'installation et de configuration de System z. Il s'agit du temps nécessaire à une installation impeccable réalisée par un programmeur système expérimenté. En cas d'incidents ou d'indisponibilité des compétences requises, l'installation peut prendre plus de temps.
Voir le document Program Directory for IBM Rational Developer for System z (GI11-7314) pour obtenir des instructions détaillées sur l'installation SMP/E du produit.
Voir Exécution de plusieurs instances si vous prévoyez d'exécuter plusieurs instances de Developer for System z.
Developer for System z vous permet de choisir le mode d'accès au service Commandes TSO. Le choix effectué ici a un impact sur la configuration des prérequis nécessaire. Vous devez sélectionner et configurer l'une des méthodes suivantes :
L'Annexe E. Conditions requises contient une liste de logiciels prérequis qui doivent être installés et opérationnels pour que Developer for System z fonctionne. Il y a également une liste de logiciels corequis pour la prise en charge de fonctions spécifiques de Developer for System z. Ces éléments requis doivent être installés et opérationnels au moment de l'exécution pour que les fonctions correspondantes opèrent selon leur conception.
Voir Rational Developer for System z Prerequisites (SC23-7659) dans la bibliothèque en ligne de Developer for System z (http://www-01.ibm.com/software/awdtools/rdz/library/) pour obtenir une liste à jour des produits requis et corequis pour votre version de Developer for System z. Planifiez à l'avance l'obtention de ces produits requis car la procédure peut prendre du temps, en fonction des règles en vigueur sur votre site. Les principales conditions requises d'une configuration de base sont les suivantes :
Developer for System z nécessite d'allouer les ressources système répertoriées dans le tableau 1. Les ressources répertoriées dans tableau 2 sont requises pour des services en option. Anticipez l'obtention de ces ressources disponibles, car leur obtention peut prendre du temps, suivant les règles en vigueur sur votre site.
Ressource | Valeur par défaut | Information |
---|---|---|
fichier APF autorisé | FEK.SFEKAUTH | Autorisations APF dans PROGxx |
tâche démarrée | JMON, RSED et LOCKD | Remarques relatives au serveur |
port pour une utilisation limitée au système hôte | 6715 | FEJJCNFG, fichier de configuration du moniteur de travaux JES |
port pour une utilisation limitée au système hôte | 4036 | rsed.envvars - Fichier de configuration RSE |
port pour les communications client-hôte | 4035 | Modifications de PROCLIB |
plage de ports pour les communications client-hôte | tout port disponible est utilisé | Définition de PORTRANGE disponible pour un serveur RSE |
Définition de sécurité d'application | Accès universel READ (lecture) pour FEKAPPL | Définition de la protection d'application pour RSE |
Définition de sécurité PassTicket (mot de passe associé) | aucun port par défaut | Définition du support de mots de passe PassTicket pour RSE |
Ressource | Valeur par défaut | Information |
---|---|---|
fichier LINKLIST | FEK.SFEKAUTH et FEK.SFEKLOAD | (Facultatif) SCLM Developer Toolkit |
Ensemble de données LPA | FEK.SFEKLPA | (Facultatif) Common Access Repository Manager (CARMA) |
plage de ports pour une utilisation limitée au système hôte | 5227-5326 (100 ports) | (Facultatif) Common Access Repository Manager (CARMA) |
ports pour une utilisation limitée au système hôte | tout port disponible est utilisé | (Facultatif) Transaction APPC pour le service Commandes TSO |
port pour les communications client-hôte | aucun port par défaut | (Facultatif) Gestionnaire de déploiement d'application |
mise à jour CSD CICS | valeurs multiples | (Facultatif) Gestionnaire de déploiement d'application |
mise à jour du JCL CICS | FEK.SFEKLOAD |
La configuration de Developer for System z nécessite plus de droits et de connaissances que ceux dont dispose habituellement le programmeur système. Une assistance minimale peut donc s'avérer nécessaire. Le tableau 3 et le tableau 4 répertorient les administrateurs nécessaires pour effectuer les tâches de personnalisation obligatoires et facultatives.
Administrateur | Tâche | Information |
---|---|---|
Système | Des actions typiques du programmeur système sont requises pour les tâches de personnalisation | Sans objet |
Sécurité |
|
Remarques relatives à la sécurité |
TCP/IP | Définition de nouveaux ports TCP/IP | Ports TCP/IP |
WLM | Attribution des objectifs de la tâche démarrée aux serveurs et à leurs processus enfants | Remarques à propos de WLM |
Administrateur | Tâche | Information |
---|---|---|
Système | Des actions typiques du programmeur système sont requises pour les tâches de personnalisation | Sans objet |
Sécurité |
|
|
TCP/IP | Définition de nouveaux ports TCP/IP | Ports TCP/IP |
SCLM |
|
(Facultatif) SCLM Developer Toolkit |
CICS TS |
|
|
DB2 | Définition d'une procédure mémorisée DB2 | (Facultatif) Procédure mémorisée DB2 |
WLM |
|
|
APPC | Définition d'une transaction APPC | (Facultatif) Transaction APPC pour le service Commandes TSO |
Contrairement aux application z/OS classiques, 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 qui constituent Developer for System z interagissent pour offrir au client un accès à des services et des données d'hôte. Voir Remarques à propos de WLM pour prévoir votre configuration WLM en conséquence.
Developer for System z utilise un nombre variable de ressources système (les espaces adresse et les processus et unités d'exécution z/OS UNIX, par exemple). La disponibilité de ces ressources est limitée par différentes définitions du système. Voir le Remarques relatives à l'optimisation pour estimer l'utilisation des ressources clé et planifier la configuration système en conséquence.
Vérifiez auprès de votre programmeur système MVS, de votre administrateur sécurité et de votre administrateur TCP/IP que les logiciels et produits requis sont installés, testés et qu'ils fonctionnent. Certaines tâches de personnalisation requises facilement omises sont répertoriées ci-après :
L'ID d'un utilisateur de Developer for System z doit contenir (au moins) les attributs suivants :
Exemple (commande LISTUSER userid NORACF OMVS) :
USER=userid OMVS INFORMATION ---------------- UID= 0000003200 HOME= /u/userid PROGRAM= /bin/sh CPUTIMEMAX= NONE ASSIZEMAX= NONE FILEPROCMAX= NONE PROCUSERMAX= NONE THREADSMAX= NONE MMAPAREAMAX= NONE
Exemple (commande LISTGRP group NORACF OMVS):
GROUP group OMVS INFORMATION ---------------- GID= 0000003243
Developer for System z comprend trois serveurs actifs en permanence, qui peuvent être des tâches démarrées ou des travaux utilisateur. Ces serveurs fournissent les services demandés eux-mêmes ou démarrent d'autres serveurs (tels que des unités d'exécution ou travaux utilisateur z/OS UNIX ) pour fournir le service.
Le moniteur de travaux JES (JMON) fournit tous les services relatifs à JES.
L'Explorateur de systèmes distants (RSE) est le composant Developer for System z qui fournit les services de base comme la connexion du client à l'hôte.
Comme expliqué à la section Ports TCP/IP, certains services hôte (et donc leurs ports) doivent être disponibles pour que le client puisse s'y connecter et doivent être définis sur le pare-feu qui protège l'hôte. Tous les autres ports utilisés par Developer for System z reçoivent un trafic réservé à l'hôte. Les ports répertoriés ci-après sont les ports requis pour une configuration de base du produit Developer for System z.
A partir de la version 7.6.1, Developer for System z offre une méthode alternative, via une application de panneaux ISPF, pour la configuration du côté hôte du produit. Ceci vous donne un choix parmi les méthodes suivantes :
Developer for System z prend en charge le clonage d'une installation sur un système différent, ce qui évite d'avoir à installer SMP/E sur chaque système.
Les ensembles de fichiers, répertoires et fichiers suivants sont obligatoires pour le déploiement sur d'autres systèmes. Si vous avez copié un fichier à un emplacement différent, ce fichier doit remplacer son équivalent dans la liste ci-après.
Pour plus d'informations sur les exemples de commande ci-dessous qui permettent d'archiver et de restaurer le répertoire d'installation de Developer for System z, voir le document UNIX System Services Command Reference (SA22-7802)
Les utilisateur du client Developer for System z doivent connaître les résultats de certaines personnalisations de l'hôte, telles que les numéros de port TCP/IP, pour que le client fonctionne correctement. Utilisez les listes de contrôle ci-après pour rassembler les informations nécessaires.
La liste de contrôle dans le tableau 5 répertorie les résultats requis pour les étapes de personnalisation obligatoires. Le tableau 6 répertorie les résultats requis pour les étapes de personnalisation facultatives.
Personnalisation | Valeur |
---|---|
Numéro de port de serveur du moniteur de travaux JES
(par défaut 6715) :
Voir SERV_PORT dans FEJJCNFG, fichier de configuration du moniteur de travaux JES. |
|
Numéro de port TCP/IP du démon RSE (4035 par défaut) :
Voir Démon RSE. |
Personnalisation | Valeur |
---|---|
Emplacement des procédures ELAXF* si elles ne se trouvent
pas dans une bibliothèque de procédure système.
Voir les annotations sur JCLLIB dans Procédures de construction à distance ELAXF*. |
|
Procédure ou noms des étapes des procédures ELAXF* si elles ont été modifiées.
Voir les annotations sur leur modification dans Procédures de construction à distance ELAXF*. |
|
Nom de la procédure mémorisée DB2 (ELAXMSAM par défaut) :
Voir les informations sur les procédures mémorisées DB2 dans le Exécution de plusieurs instances. |
|
Emplacement de la procédure mémorisée DB2 si elle ne se trouve pas dans une bibliothèque de procédure système : | |
(corequis) Numéro de port TN3270 de Host Connect Emulator (23, par défaut). | |
(corequis) Numéro de port REXEC ou SSH (par défaut, 512 ou 22, respectivement) : | |
Emplacement du fichier server.zseries si la méthode de connexion REXEC/SSH est utilisée (par défaut /etc/rdz). | |
Emplacement du JCL CRA#ASLM pour les allocations
de fichiers RAM SCLM CARMA (par défaut FEK.#CUST.JCL):
Voir les annotations concernant CRA#ASLM dans Activation du RAM SCLM. |
La procédure de personnalisation ci-dessous s'applique à la configuration du produit Developer for System z de base. Reportez-vous aux chapitres relatifs aux composants facultatifs pour connaître leurs exigences de personnalisation.
Vous avez besoin de l'aide d'un administrateur de sécurité et d'un administrateur TCP/IP pour effectuer cette tâche de personnalisation, qui requiert les tâches de personnalisation spéciales et les ressources suivantes :
Pour vérifier l'installation et commencer à utiliser Developer for System z sur votre site, vous devez effectuer les tâches ci-après. Sauf indication contraire, toutes les tâches sont obligatoires.
Developer for System z est fourni avec plusieurs exemples de fichiers de configuration et de langage JCL. Pour que vos personnalisations ne soient pas remplacées lors de l'application de la maintenance, il est recommandé de copier tous ces membres et les fichiers z/OS UNIX à un emplacement différent, puis de personnaliser la copie.
Certaines fonctions de Developer for System z requièrent également l'existence de certains répertoires dans z/OS UNIX, qui doivent être créés pendant la personnalisation du produit. Pour faciliter la procédure d'installation, un exemple de travail, FEKSETUP, est fourni pour créer les copies et les répertoires requis.
Personnalisez et soumettez l'exemple de membre FEKSETUP dans le fichier FEK.SFEKSAMP pour créer des copies personnalisables des fichiers de configuration et du JCL de configuration, et les répertoires z/OS UNIX requis. La procédure de personnalisation requise est décrite dans ce membre.
Dans ce travail vous devez effectuer les tâches suivantes :
mkdir /usr/lpp/rdz/cust ln -s /usr/lpp/rdz/cust /etc/rdz
Pour plus d'informations sur les définitions de PARMLIB répertoriées ci-dessous, reportez-vous au document MVS Initialization and Tuning Reference (SA22-7592). Voir le document MVS System Commands (SA22-7627) pour de plus amples informations sur les exemples de commandes de la console.
l'Explorateur de systèmes distants (RSE), qui fournit des services de base (la connexion du client à l'hôte et le démarrage d'autres serveurs, par exemple) est un processus reposant sur z/OS UNIX. Il est donc indispensable de définir des valeurs appropriée pour les limites système z/OS UNIX dans BPXPRMxx, en fonction du nombre d'utilisateurs Developer for System z actifs simultanément et de leur charge de travail moyenne.
Voir le Remarques relatives à l'optimisation pour plus d'informations sur les différentes limites définies dans BPXPRMxx et leur incidence sur Developer for System z.
MAXASSIZE définit la taille de la région de l'espace adresse maximal (processus). Définissez MAXASSIZE dans SYS1.PARMLIB(BPXPRMxx) sur 2G. 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 adresses 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é (voir Définition des tâches démarrées Developer for System z).
MAXTHREADS indique le nombre maximal d'unités d'exécution actives pour un même processus. Associez MAXTHREADS dans SYS1.PARMLIB(BPXPRMxx) à 1500 ou à une valeur supérieure. Il s'agit d'une limite à l'échelle du système. Elle est donc active pour tous les espaces adresses 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é (voir Définition des tâches démarrées Developer for System z).
MAXTHREADTASKS indique le nombre maximal de tâches MVS actives pour un même processus. Attribuez la valeur 1500 ou une valeur supérieure à MAXTHREADTASKS dans SYS1.PARMLIB(BPXPRMxx). Il s'agit d'une limite à l'échelle du système. Elle est donc active pour tous les espaces adresses 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é (voir Définition des tâches démarrées Developer for System z).
MAXPROCUSER définit le nombre maximal de processus qui peuvent être actifs simultanément pour un même ID utilisateur z/OS UNIX. Définissez MAXPROCUSER dans SYS1.PARMLIB(BPXPRMxx) sur 50 ou une valeur supérieure. Ce paramètre est censé être une limite à l'échelle du système, étant donné qu'il doit être actif pour chaque client utilisant Developer for System z.
Ces valeurs peuvent être vérifiées et définies dynamiquement (jusqu'à la procédure de chargement initial suivante) à l'aide des commandes de la console ci-dessous :
Ajoutez des commandes de démarrage à SYS1.PARMLIB(COMMANDxx) pour les serveurs RSED, LOCKD et JMON Developer for System z afin qu'ils soient démarrés automatiquement lors de la prochaine procédure IPL.
Une fois définis et configurés, les serveurs peuvent être démarrés de manière dynamique (jusqu'au prochain démarrage système) à l'aide des commandes de la console suivantes :
Le service facultatif CARMA (Common Access Repository Manager) prend en charge des méthodes de démarrage du serveur alternatives qui ne requièrent pas l'utilisation d'un initiateur JES. La plus flexible de ces alternatives requiert que le module CRASTART dans la bibliothèque de chargement FEK.SFEKLPA se trouve dans la zone permanente de programme (LPA).
Les fichiers LPA sont définis dans SYS1.PARMLIB(LPALSTxx).
Les définitions LPA peuvent être définies dynamiquement (jusqu'au prochain démarrage système) à l'aide des commandes de la console suivantes :
Pour que le moniteur de travaux JES puisse accéder aux fichiers spoule JES, le module FEJJMON de la bibliothèque de chargement FEK.SFEKAUTH et des bibliothèques d'exécution Language Environment (LE) (CEE.SCEERUN*) doit être autorisé APF.
Pour que le service SCLM Developer Toolkit (facultatif) fonctionne, le module BWBTSOW de la bibliothèque de chargement FEK.SFEKAUTH et de la bibliothèque d'exécution REXX (REXX.*.SEAGLPA) doit être autorisé APF.
Pour qu'ISPF crée la passerelle client TSO/ISPF, le module ISPZTSO dans SYS1.LINKLIB doit être autorisé APF. La passerelle client TSO/ISPF est utilisée par le service Commandes de Developer for System z', SCLM Developer Toolkit et éventuellement CARMA.
Les autorisations de l'APF sont définies dans SYS1.PARMLIB(PROGxx), si votre site se conforme aux recommandations IBM.
Les autorisations APF peuvent être définies de manière dynamique (jusqu'au prochain démarrage système) à l'aide des commandes de la console suivantes où volser correspond au volume sur lequel le fichier se trouve s'il n'est pas géré par SMS :
Les définitions LINKLIST de Developer for System z peuvent être regroupées en 3 catégories :
Pour que le service SCLM Developer Toolkit (facultatif) fonctionne, tous les modules BWB* des bibliothèques de chargement FEK.SFEKAUTH et FEK.SFEKLOAD doivent être disponibles via STEPLIB ou LINKLIST.
Si vous optez pour l'utilisation de STEPLIB, vous devez définir les bibliothèques non disponibles via LINKLIST dans la directive STEPLIB du fichier de configuration RSE rsed.envvars. Gardez toutefois les remarques suivantes à l'esprit :
Les fichiers LINKLIST sont définis dans SYS1.PARMLIB(PROGxx), si votre site se conforme aux recommandations IBM.
Les définitions requises se présentent comme suit, où nomListe correspond au nom du fichier LINKLIST qui va être activé et volser au volume dans lequel se trouve le fichier s'il n'est pas placé dans le catalogue maître :
Les définitions LINKLIST peuvent être créées de manière dynamique (jusqu'au prochain démarrage du système) à l'aide du groupe de commandes de console suivant, listname étant le nom du fichier LINKLIST en cours et volser étant le volume dans lequel réside le fichier s'il n'est pas placé dans la catalogue maître :
L'Explorateur de systèmes distants (RSE) est un processus z/OS UNIX qui requiert l'accès aux bibliothèques de chargement MVS. Les bibliothèques (prérequises) suivantes doivent être disponibles, via STEPLIB ou LINKLIST/LPALIB :
Les bibliothèques supplémentaires suivantes doivent être disponibles via STEPLIB ou LINKLIST/LPALIB 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 Debug Tool, par exemple) :
Les fichiers LINKLIST sont définis dans SYS1.PARMLIB(PROGxx), si votre site se conforme aux recommandations IBM. Les fichiers LPA sont définis dans SYS1.PARMLIB(LPALSTxx).
Si vous optez pour l'utilisation de STEPLIB, vous devez définir les bibliothèques non disponibles via LINKLIST/LPALIB dans la directive STEPLIB du fichier de configuration RSE rsed.envvars. Gardez toutefois les remarques suivantes à l'esprit :
Le client Developer for System z contient un composant de génération de code appelé Enterprise Service Tools (EST). Pour que le code généré émette des messages d'erreur de diagnostic, tous les modules IRZ* et IIRZ* de la bibliothèque de charge FEK.SFEKLOAD doivent être disponibles par l'intermédiaire de STEPLIB ou de LINKLIST.
Les fichiers LINKLIST sont définis dans SYS1.PARMLIB(PROGxx), si votre site se conforme aux recommandations IBM.
Si vous optez pour l'utilisation de STEPLIB, vous devez définir les bibliothèques non disponibles via LINKLIST dans la directive STEPLIB de la tâche qui exécute le code (IMS ou le travail par lots). Toutefois, n'oubliez pas que :
Les procédures de tâche démarrée et de génération à distance répertoriées ci-dessous doivent résider dans une bibliothèque de procédures système définie pour votre sous-système JES. Dans les instructions ci-dessous, la bibliothèque de procédures par défaut IBM, SYS1.PROCLIB, est utilisée.
Personnalisez l'exemple de membre de tâche démarrée, FEK.#CUST.PROCLIB(JMON), comme décrit dans le membre, et copiez-le dans SYS1.PROCLIB. Comme indiqué dans l'exemple de code suivant, vous devez spécifier les éléments suivants :
//*
//* JES JOB MONITOR
//*
//JMON PROC PRM=, * PRM='-TV' TO START TRACING
// LEPRM='RPTOPTS(ON)',
// HLQ=FEK,
// CFG=FEK.#CUST.PARMLIB(FEJJCNFG)
//*
//JMON EXEC PGM=FEJJMON,REGION=0M,TIME=NOLIMIT,
// PARM=('&LEPRM,ENVAR("_CEE_ENVFILE_S=DD:ENVIRON")/&PRM')
//STEPLIB DD DISP=SHR,DSN=&HLQ..SFEKAUTH
//ENVIRON DD DISP=SHR,DSN=&CFG
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
// PEND
//*
Personnalisez l'exemple de membre de tâche démarrée, FEK.#CUST.PROCLIB(RSED), comme décrit dans le membre, et copiez-le dans SYS1.PROCLIB. Comme indiqué dans l'exemple de code suivant, vous devez spécifier les éléments suivants :
//* //* RSE DAEMON //* //RSED PROC IVP='', * 'IVP' to do an IVP test // PORT=4035, // HOME='/usr/lpp/rdz', // CNFG='/etc/rdz' //* //RSE EXEC PGM=BPXBATSL,REGION=0M,TIME=NOLIMIT, // PARM='PGM &HOME/bin/rsed.sh &IVP &PORT &CNFG' //STDERR DD SYSOUT=* //STDOUT DD SYSOUT=* // PEND //*
Personnalisez l'exemple de membre de tâche démarrée, FEK.#CUST.PROCLIB(LOCKD), comme indiqué dans le membre, et copiez-le dans SYS1.PROCLIB. Comme indiqué dans l'exemple de code suivant, vous devez spécifier les éléments suivants :
//* //* RSE LOCK DAEMON //* //LOCKD PROC HOME='/usr/lpp/rdz', // CNFG='/etc/rdz', // LOG=1 //* //LOCKD EXEC PGM=BPXBATSL,REGION=0M,TIME=NOLIMIT, PARM=PGM &HOME./bin/lockd.sh &CNFG &LOG' //STDOUT DD SYSOUT=* //STDERR DD SYSOUT=* // PEND //*
La longueur maximale de la variable PARM est de 100 caractères, longueur qui peut engendrer des problèmes si vous utilisez des noms de répertoire personnalisés. Pour contourner ce problème, vous pouvez :
Les liens symboliques peuvent être utilisés comme abréviation pour un nom de répertoire long. L'exemple de commande z/OS UNIX suivant définit un lien symbolique (/usr/lpp/rdz) vers un autre répertoire (/long/directory/name/usr/lpp/rdz).
ln -s /long/directory/name/usr/lpp/rdz /usr/lpp/rdz
Lorsque la zone PARM est vide, BPXBATSL lance un shell z/OS UNIX et exécute le script de shell fourni par STDIN. Notez que STDIN doit être un fichier z/OS UNIX (alloué en tant que ORDONLY) et que son utilisation désactive les variables ROC pour le port etc. En outre, le shell doit exécuter les scripts de connexion du shell /etc/profile et $HOME/.profile.
Pour utiliser cette méthode, vous devez d'abord mettre à jour le code JCL pour qu'il corresponde à l'exemple suivant :
//* //* RSE DAEMON - USING STDIN //* //RSED PROC CNFG='/etc/rdz' //* //RSE EXEC PGM=BPXBATSL,REGION=0M,TIME=NOLIMIT //STDOUT DD SYSOUT=* //STDERR DD SYSOUT=* //STDIN DD PATHOPTS=(ORDONLY),PATH='&CNFG./rsed.stdin.sh' //STDENV DD PATHOPTS=(ORDONLY),PATH='&CNFG./rsed.envvars' // PEND //*
Vous devez ensuite créer le script de shell (/etc/rdz/rsed.stdin.sh dans le présent exemple) qui démarrera le démon RSE. Le contenu de ce script ressemblera à l'exemple suivant :
/long/directory/name/usr/lpp/rdz/bin/rsed.sh 4035 /etc/rdz
Developer for System z fournit des exemples de procédures JCL qui peuvent être utilisés lors de la construction du code JCL, de la génération de projets distants et pour les fonctions de vérification syntaxique à distance des mappes BMS CICS, des écrans MFS IMS et des programmes COBOL, PL/I, Assembler et C/C++. Ces procédures permettent aux installations d'appliquer leurs propres normes et garantissent que les développeurs utilisent les mêmes procédures, options de compilation et niveaux de compilateur.
Les exemples de procédures et leurs fonctions sont répertoriées dans le tableau 7.
Membre | Fonction |
---|---|
ELAXFADT | Modèle de procédure pour l'assemblage et le débogage des programmes Assembleur de haut niveau. |
ELAXFASM | Modèle de procédure pour l'assemblage des programmes Assembleur de haut niveau. |
ELAXFBMS | Modèle de procédure de création d'un objet BMS CICS BMS et de sa copie correspondante, dsect, ou du membre d'inclusion. |
ELAXFCOC | Modèle de procédure pour l'exécution de compilations COBOL, de traductions CICS et DB2 intégrées. |
ELAXFCOP | Modèle de procédure pour l'exécution du pré-processus DB2 des instructions SQL EXEC intégrées dans des programmes COBOL. |
ELAXFCOT | Modèle de procédure pour l'exécution d'une traduction CICS des instructions CICS EXEC intégrées dans des programmes COBOL. |
ELAXFCPC | Modèle de procédure pour l'exécution de compilations C. |
ELAXFCPP | Modèle de procédure pour l'exécution de compilations C++. |
ELAXFCP1 | Exemple de procédure pour les compilations COBOL avec des instructions de préprocesseur SCM (-INC et ++INCLUDE). |
ELAXFDCL | Exemple de procédure d'exécution d'un programme en mode TSO. |
ELAXFGO | Modèle de procédure pour l'étape GO. |
ELAXFLNK | Modèle de procédure pour la liaison des programmes C/C++, COBOL. PLI et Assembleur de haut niveau. |
ELAXFMFS | Modèle de procédure pour la création d'écrans IMS MFS. |
ELAXFPLP | Modèle de procédure pour l'exécution du pré-processus DB2 des instructions SQL EXEC intégrées dans des programmes PLI. |
ELAXFPLT | Modèle de procédure pour l'exécution d'une conversion CICS des instructions CICS EXEC intégrées dans des programmes PLI. |
ELAXFPL1 | Modèle de procédure pour l'exécution de compilations PL/I, de traductions CICS et DB2 intégrées. |
ELAXFPP1 | Exemple de procédure pour les compilations PL/I avec des instructions de préprocesseur SCM (-INC and ++INCLUDE). |
ELAXFTSO | Exemple de procédure pour exécuter/déboguer le code DB2généré en mode TSO. |
ELAXFUOP | Modèle de procédure pour générer l'étape UOPT lors de la création de programmes de génération s'exécutant dans CICS ou des sous-systèmes IMS. |
Les noms des procédures et les noms des étapes des procédures correspondent aux propriétés par défaut livrées avec le client Developer for System z. Si vous décidez de modifier le nom d'une procédure ou le nom d'une étape de la procédure, le fichier des propriétés correspondantes des clients doit également être mis à jour. Nous recommandons de ne pas modifier les noms de procédure et d'étape.
Personnalisez les exemples de membres de procédure de génération, FEK.#CUST.PROCLIB(ELAXF*), comme décrit dans les membres, et copiez-les dans SYS1.PROCLIB. Vous devez fournir les qualificatifs de haut niveau appropriés des différentes bibliothèques de produits, comme décrit dans le tableau 8.
Produit | Valeur par défaut HLQ | Valeur |
---|---|---|
Developer for System z | FEK | |
CICS | CICSTS32.CICS | |
DB2 | DSN910 | |
IMS | IMS | |
COBOL | IGY.V4R1M0 | |
PL/I | IBMZ.V3R8M0 | |
C/C++ | CBC | |
LE | CEE | |
système LINKLIB | SYS1 | |
système MACLIB | SYS1 |
Si les procédures ELAXF* ne peuvent pas être copiées dans une bibliothèque de procédures système, demandez aux utilisateurs de Developer for System z d'ajouter une carte JCLLIB (tout de suite après la carte JOB) aux propriétés du travail sur le client.
//MYJOB JOB <paramètres du travail> //PROCS JCLLIB ORDER=(FEK.#CUST.PROCLIB)
Personnalisez et soumettez l'exemple de membre FEKRACF dans le fichier FEK.#CUST.JCL en vue de créer les définitions de sécurité pour Developer for System z. L'utilisateur qui soumet le travail doit disposer des privilèges d'administrateur de la sécurité (RACF SPECIAL, par exemple).
La liste des définitions obligatoires associées à la sécurité pour Developer for System z est décrite en détail dans le Remarques relatives à la sécurité. Ce chapitre traite également de la sécurité générale concernant Developer for System z, notamment des aspects relatifs à la sécurité des produits requis non couverts dans l'exemple de travail FEKRACF.
Avertissement : La demande de connexion du client n'aboutit pas si la sécurité de l'application et les mots de passe PassTickets ne sont pas correctement configurés. |
Le moniteur de travaux JES (JMON) offre tous les services liés à JES. Son comportement peut être contrôlé à l'aide des définitions indiquées dans FEJJCNFG.
FEJJCNFG se trouve dans FEK.#CUST.PARMLIB, sauf si vous avez indiqué un autre emplacement lorsque vous avez personnalisé et soumis le travail FEK.SFEKSAMP(FEKSETUP). Pour plus d'informations, voir Configuration personnalisée.
Personnalisez l'exemple de membre de configuration du moniteur de travaux JES FEJJCNFG, comme indiqué dans l'exemple suivant. Les lignes de commentaire commencent par un signe dièse (#) lorsque vous utilisez une page de codes US. Les lignes de données ne peuvent comporter qu'une directive et la valeur associée. Les commentaires ne sont pas autorisés sur la même ligne.
SERV_PORT=6715
TZ=EST5EDT
#_BPXK_SETIBMOPT_TRANSPORT=TCPIP
#APPLID=FEKAPPL
#AUTHMETHOD=SAF
#CODEPAGE=UTF-8
#CONCHAR=$
#CONSOLE_NAME=JMON
#GEN_CONSOLE_NAME=OFF
#HOST_CODEPAGE=IBM-1047
#LIMIT_COMMANDS=NOLIMIT
#LIMIT_VIEW=USERID
#LISTEN_QUEUE_LENGTH=5
#MAX_DATASETS=32
#MAX_THREADS=200
#TIMEOUT=3600
#TIMEOUT_INTERVAL=1200
#SUBMITMETHOD=TSO
#TSO_TEMPLATE=FEK.#CUST.CNTL(FEJTSO)
Le numéro de port du serveur hôte du moniteur de travaux JES. Le port par défaut est 6715. Vous pouvez le modifier mais le serveur et les clients Developer for System z doivent TOUS DEUX être configurés avec le même numéro de port. Si vous modifiez le numéro de port du serveur, tous les clients doivent modifier le port du moniteur de travaux JES de ce système dans la vue Systèmes distants.
Les définitions suivantes sont facultatives. Si vous les omettez, les valeurs par défaut seront utilisées comme indiqué ci-dessous :
Quel que soit le nom de console utilisé, l'ID utilisateur du client qui demande la commande est utilisé en tant qu'unité logique de la console et est consigné dans les messages syslog IEA630I et IEA631.
IEA630I OPERATOR console NOW ACTIVE, SYSTEM=sysid, LU=id IEA631I OPERATOR console NOW INACTIVE, SYSTEM=sysid, LU=id
Cette directive est utilisée uniquement lorsque CONSOLE_NAME égale &SYSUID et que l'ID utilisateur n'est pas disponible en tant que nom de console.
Si GEN_CONSOLE_NAME=ON, un nom de console alternatif est généré en ajoutant une seule valeur numérique à l'ID utilisateur. Des tentatives sont effectuées en utilisant des valeurs comprises 0 à 9. Si aucune console disponible n'est trouvée, la commande exécutée par le client échoue.
Si GEN_CONSOLE_NAME=OFF, la commande exécutée par le client échoue.
A partir de la version 7.6.1 comprise, les clients Developer for System z ignorent la valeur HOST_CODEPAGE spécifiée ici et utilisent la page de codes spécifiée localement dans les propriétés du sous-système de "fichiers MVS".
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 |
Les processus du démon lock RSE et duserveur RSE (démon RSE, pool d'unités d'exécution RSE et serveur RSE) utilisent les définitions figurant dans le fichier rsed.envvars. Le composant Developer for System z facultatif et les services tiers peuvent également recourir à ce fichier de configuration en vue de définir des variables à utiliser.
L'Explorateur de systèmes distants (RSE) fournit des services de base, comme la connexion du client à l'hôte et le démarrage d'autres serveurs pour des services spécifiques. Le démon lock fournit des services de suivi pour les verrous de fichiers.
Le fichier rsed.envvars se trouve dans /etc/rdz/, sauf si vous avez indiqué un emplacement différent lorsque vous avez personnalisé et soumis le travail FEK.SFEKSAMP(FEKSETUP). Pour plus d'informations, voir Configuration personnalisée. Vous pouvez modifier le fichier à l'aide de la commande TSO OEDIT.
Consultez l'exemple de fichier rsed.envvars suivant qui doit être personnalisé pour correspondre à votre environnement système. Les lignes de commentaire commencent par un signe dièse (#) lorsque vous utilisez une page de codes US. Les lignes de données ne peuvent comporter qu'une directive et la valeur associée. Les commentaires ne sont pas autorisés sur la même ligne. Les continuations de ligne et les espaces autour du signe égal (=) ne sont pas pris en charge.
#============================================================= # (1) required definitions JAVA_HOME=/usr/lpp/java/J5.0 RSE_HOME=/usr/lpp/rdz _RSE_LOCKD_PORT=4036 _RSE_HOST_CODEPAGE=IBM-1047 TZ=EST5EDT LANG=C PATH=/bin:/usr/sbin _CEE_DMPTARG=/tmp STEPLIB=NONE #STEPLIB=$STEPLIB:CEE.SCEERUN:CEE.SCEERUN2:CBC.SCLBDLL _RSE_SAF_CLASS=/usr/include/java_classes/IRRRacf.jar _RSE_JAVAOPTS="" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Xms1m -Xmx256m" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Ddaemon.log=/var/rdz/logs" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Duser.log=/var/rdz/logs" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDSTORE_LOG_DIRECTORY=" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dmaximum.clients=60" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dmaximum.threads=1000" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dminimum.threadpool.process=1" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dmaximum.threadpool.process=100" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dipv6=true" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dkeep.last.log=true" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Denable.standard.log=true" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Denable.port.of.entry=true" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Denable.certificate.mapping=false" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Denable.automount=true" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Denable.audit.log=true" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Daudit.cycle=30" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Daudit.retention.period=0" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Ddeny.nonzero.port=true" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dsingle.logon=false" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dprocess.cleanup.interval=0" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DAPPLID=FEKAPPL" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDENY_PASSWORD_SAVE=true" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DHIDE_ZOS_UNIX=true" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDSTORE_IDLE_SHUTDOWN_TIMEOUT=3600000" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDSTORE_TRACING_ON=true" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDSTORE_MEMLOGGING_ON=true" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DTSO_SERVER=APPC" #============================================================= # (2) required definitions for TSO/ISPF Client Gateway _CMDSERV_BASE_HOME=/usr/lpp/ispf _CMDSERV_CONF_HOME=/etc/rdz _CMDSERV_WORK_HOME=/var/rdz #STEPLIB=$STEPLIB:ISP.SISPLOAD:ISP.SISPLPA:SYS1.LINKLIB _RSE_CMDSERV_OPTS="" #_RSE_CMDSERV_OPTS="$_RSE_CMDSERV_OPTS&ISPPROF=&SYSUID..ISPPROF" #============================================================= # (3) required definitions for SCLM Developer Toolkit _SCLMDT_CONF_HOME=/var/rdz/sclmdt #STEPLIB=$STEPLIB:FEK.SFEKAUTH:FEK.SFEKLOAD #_SCLMDT_TRANTABLE=FEK.#CUST.LSTRANS.FILE #ANT_HOME=/usr/lpp/Apache/Ant/apache-ant-1.7.1 #============================================================= # (4) optional definitions #_RSE_PORTRANGE=8108-8118 #_BPXK_SETIBMOPT_TRANSPORT=TCPIP #_FEKFSCMD_TP_NAME_=FEKFRSRV #_FEKFSCMD_PARTNER_LU_=lu_name #GSK_CRL_SECURITY_LEVEL=HIGH #GSK_LDAP_SERVER=ldap_server_url #GSK_LDAP_PORT=ldap_server_port #GSK_LDAP_USER=ldap_userid #GSK_LDAP_PASSWORD=ldap_server_password #=============================================================
# (5) do not change unless directed by IBM support center _CEE_RUNOPTS="ALL31(ON) HEAP(32M,32K,ANYWHERE,KEEP,,) TRAP(ON)" _BPX_SHAREAS=YES _BPX_SPAWN_SCRIPT=YES JAVA_PROPAGATE=NO RSE_LIB=$RSE_HOME/lib PATH=.:$JAVA_HOME/bin:$RSE_HOME/bin:$_CMDSERV_BASE_HOME/bin:$PATH LIBPATH=$JAVA_HOME/bin:$JAVA_HOME/bin/classic:$RSE_LIB:$RSE_LIB/icuc LIBPATH=.:/usr/lib:$LIBPATH CLASSPATH=$RSE_LIB:$RSE_LIB/dstore_core.jar:$RSE_LIB/clientserver.jar CLASSPATH=$CLASSPATH:$RSE_LIB/dstore_extra_server.jar CLASSPATH=$CLASSPATH:$RSE_LIB/zosserver.jar CLASSPATH=$CLASSPATH:$RSE_LIB/dstore_miners.jar CLASSPATH=$CLASSPATH:$RSE_LIB/universalminers.jar:$RSE_LIB/mvsminers.jar CLASSPATH=$CLASSPATH:$RSE_LIB/carma.jar:$RSE_LIB/luceneminer.jar CLASSPATH=$CLASSPATH:$RSE_LIB/mvsluceneminer.jar:$RSE_LIB/cdzminer.jar CLASSPATH=$CLASSPATH:$RSE_LIB/mvscdzminer.jar:$RSE_LIB/jesminers.jar CLASSPATH=$CLASSPATH:$RSE_LIB/FAMiner.jar CLASSPATH=$CLASSPATH:$RSE_LIB/mvsutil.jar:$RSE_LIB/jesutils.jar CLASSPATH=$CLASSPATH:$RSE_LIB/lucene-core-2.3.2.jar CLASSPATH=$CLASSPATH:$RSE_LIB/cdtparser.jar CLASSPATH=$CLASSPATH:$RSE_LIB/wdzBidi.jar:$RSE_LIB/fmiExtensions.jar CLASSPATH=$CLASSPATH:$_RSE_SAF_CLASS CLASSPATH=.:$CLASSPATH _RSE_CMDSERV_OPTS="&SESSION=SPAWN$_RSE_CMDSERV_OPTS" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -DISPF_OPTS='$_RSE_CMDSERV_OPTS'" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -DA_PLUGIN_PATH=$RSE_LIB" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Xbootclasspath/p:$RSE_LIB/bidiTools.jar" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dfile.encoding=$_RSE_HOST_CODEPAGE" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dconsole.encoding=$_RSE_HOST_CODEPAGE" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDSTORE_SPIRIT_ON=true" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -DSPIRIT_EXPIRY_TIME=6" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -DSPIRIT_INTERVAL_TIME=6" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dcom.ibm.cacheLocalHost=true" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Duser.home=$HOME" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dclient.username=$RSE_USER_ID" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dlow.heap.usage.ratio=15" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dmaximum.heap.usage.ratio=40" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDSTORE_KEEPALIVE_ENABLED=true" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDSTORE_KEEPALIVE_RESPONSE_TIMEOUT=30000" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -DDSTORE_IO_SOCKET_READ_TIMEOUT=90000" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -DRSECOMM_LOGFILE_MAX=0" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dlock.daemon.port=$_RSE_LOCKD_PORT" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dlock.daemon.cleanup.interval=1440" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -showversion" _RSE_SERVER_CLASS=org.eclipse.dstore.core.server.Server _RSE_DAEMON_CLASS=com.ibm.etools.zos.server.RseDaemon _RSE_POOL_SERVER_CLASS=com.ibm.etools.zos.server.ThreadPoolProcess _RSE_LOCKD_CLASS=com.ibm.ftt.rse.mvs.server.miners.MVSLockDaemon _RSE_SERVER_TIMEOUT=120000 _SCLMDT_BASE_HOME=$RSE_HOME _SCLMDT_WORK_HOME=$_CMDSERV_WORK_HOME CGI_DTWORK=$_SCLMDT_WORK_HOME #============================================================= # (6) additional environment variables
Les définitions suivantes sont requises :
Pour plus d'informations, reportez-vous au document UNIX System Services Command Reference (SA22-7802).
Vous pouvez supprimer le besoin de disposer de bibliothèques (prérequises) dans LINKLIST/LPALIB en supprimant la mise en commentaire et en personnalisant une ou plusieurs des directives STEPLIB suivantes. Voir Modifications de PARMLIB pour plus d'informations sur l'utilisation des bibliothèques répertoriées ci-après :
STEPLIB=$STEPLIB:CEE.SCEERUN:CEE.SCEERUN2:CBC.SCLBDLL STEPLIB=$STEPLIB:ISP.SISPLOAD:ISP.SISPLPA:SYS1.LINKLIB STEPLIB=$STEPLIB:FEK.SFEKAUTH:FEK.SFEKLOAD
Par défaut, Developer for System z utilise la passerelle client TSO/ISPF d'ISPF pour le service Commandes TSO. Une transaction APPC est utilisée à la place lorsque l'option _RSE_JAVAOPTS suivante est retirée de la mise en commentaire :
RSE_JAVAOPTS="$_RSE_JAVAOPTS -DTSO_SERVER=APPC"
Les définitions suivantes sont nécessaires si la passerelle client TSO/ISPF d'ISPF est utilisée pour le service Commandes TSO, SCLM Developer Toolkit ou CARMA.
Remarques :
Les définitions suivantes sont requises si SCLM Developer Toolkit est utilisé.
Les définitions suivantes sont facultatives. Si vous les omettez, les valeurs par défaut seront utilisées :
Le nom d'hôte peut être une adresse TCP/IP ou une adresse URL. Chaque nom d'hôte peut inclure un numéro de port facultatif séparé du nom d'hôte pas le signe deux points (:).
Les définitions suivantes sont nécessaires, et ne doivent pas être modifiées sans instruction du point service IBM :
Cette partie de la personnalisation de rsed.envvars spécifie les ports par lesquels le serveur RSE peut communiquer avec le client. Cette plage de ports n'a pas de connexion avec le port du démon RSE.
Afin de mieux comprendre l'utilisation des ports, une brève description du processus de connexion RSE est incluse ci-dessous :
Pour spécifier la gamme de ports permettant au client de communiquer avec z/OS, supprimez la mise en commentaire et personnalisez la ligne suivante dans rsed.envvars:
#_RSE_PORTRANGE=8108-8118
Le format du paramètre PORTRANGE est le suivant : _RSE_PORTRANGE=min-max (max est non inclusif ; par exemple _RSE_PORTRANGE=8108-8118 indique que la plage des ports 8108 à 8117 peut être utilisée). Le numéro de port utilisé par le serveur RSE est déterminé en fonction des priorités suivantes :
Avec les différentes directives _RSE_*OPTS, rsed.envvars permet de transmettre des paramètres supplémentaires à Java lors du démarrage des processus RSE. Les exemples d'options inclus dans rsed.envvars peuvent être activés en supprimant la mise en commentaire.
_RSE_JAVAOPTS définit les options Java standard et spécifiques de RSE.
Les directives suivantes sont mises en commentaire par défaut.
Avec les différentes directives _RSE_*OPTS, rsed.envvars permet de transmettre des paramètres supplémentaires à Java lors du démarrage des processus RSE. Les exemples d'options inclus dans rsed.envvars peuvent être activés en supprimant la mise en commentaire.
Les directives _RSE_CMDSERV_OPTS sont des options Java spécifiques de RSE et prennent effet uniquement lorsque Developer for System z utilise la passerelle client TSO/ISPF d'ISPF (valeur par défaut).
Les variables suivantes peuvent être utilisées dans le nom du fichier :
Le service de passerelle client TSO/ISPF d'ISPF utilise les définitions figurant dans ISPF.conf pour créer un environnement valide en vue d'exécuter les commandes de traitement par lots TSO et ISPF. Developer for System z utilise cet environnement pour exécuter certains services MVS. Citons parmi ces services, le service Commandes TSO, le service SCLM Developer Toolkit et une méthode de démarrage CARMA alternative.
Le fichier ISPF.conf se trouve dans /etc/rdz/, sauf si vous avez indiqué un emplacement différent lorsque vous avez personnalisé et soumis le travail FEK.SFEKSAMP(FEKSETUP). Pour plus d'informations, voir Configuration personnalisée. Vous pouvez modifier le fichier à l'aide de la commande TSO OEDIT.
Les lignes mises en commentaire commencent par un astérisque (*) lorsque vous utilisez une page de codes US. Les lignes de données ne peuvent comporter qu'une directive et la valeur associée. Les commentaires ne sont pas autorisés sur la même ligne. La continuation de ligne n'est pas prise en charge. Lorsque vous concaténez les noms de fichiers, ajoutez-les sur la même ligne et séparez les noms avec une virgule (,).
Outre les noms des fichiers ISPF appropriés, vous devez ajouter le nom du fichier du service Commandes TSO, FEK.SFEKPROC, à l'instruction SYSPROC ou SYSEXEC, comme indiqué dans l'exemple suivant.
* REQUIRED:
sysproc=ISP.SISPCLIB,FEK.SFEKPROC
ispmlib=ISP.SISPMENU
isptlib=ISP.SISPTENU
ispplib=ISP.SISPPENU
ispslib=ISP.SISPSLIB
ispllib=ISP.SISPLOAD
* OPTIONAL:
*allocjob = FEK.#CUST.CNTL(CRAISPRX)
*ISPF_timeout = 900
Par exemple :
ISPTRACE=nullfile
La procédure de personnalisation ci-dessus s'applique à la configuration du produit Developer for System z de base. Reportez-vous aux chapitres relatifs aux composants facultatifs pour connaître leurs exigences de personnalisation :
Vous trouverez la description des différents programmes de vérification d'installation (IVP pour Installation Verification Program) dans Vérification de l'installation, car certains des IVP sont destinés à des composants facultatifs.
Common Access Repository Manager (CARMA) représente un gain de productivité pour les développeurs qui créent des gestionnaires d'accès au référentiel (RAM). Un RAM constitue une interface de programmation d'application pour les gestionnaires de configuration logicielle (SCM) basés sur z/OS basé sur .
Inversement, les applications créées par des utilisateurs peuvent démarrer un serveur CARMA qui charge les RAM et fournit une interface standard pour accéder au SCM.
Developer for System z prend en charge plusieurs méthodes de lancement d'un serveur CARMA, chacune possédant ses avantages et inconvénients.
Vous avez besoin de l'aide d'un administrateur de sécurité et d'un administrateur TCP/IP pour effectuer cette tâche de personnalisation, qui requiert les ressources ou tâches de personnalisation spéciales ci-après :
Pour commencer à utiliser CARMA sur votre site, vous devez effectuer les tâches ci-après. Sauf indication contraire, toutes les tâches sont obligatoires.
Les composants CARMA suivants doivent être personnalisés, indépendamment de la méthode de démarrage choisie. Les exemples de membre indiqués ci-après se trouvent dans FEK.#CUST.JCL, sauf si vous avez indiqué un emplacement différent lorsque vous avez personnalisé et soumis le travail FEK.SFEKSAMP(FEKSETUP). Pour plus d'informations, voir Configuration personnalisée.
Developer for System z version 7.6.1 prend en charge un nouvel agencement de structure de données pour les fichiers VSAM d'informations personnalisées CARMA, CRASTRS, pour supprimer des limitations de longueur de messages.
Dans les versions de Developer for System z antérieures à la version 7.6.1, les chaînes définies dans le fichier VSAM d'informations personnalisées CARMA sont limités aux longueurs prédéfinies. Cette limitation oblige les développeurs RAM à réduire les chaînes de description ou à utiliser des plug-ins côté client pour afficher des chaînes sur toute leur longueur.
Developer for System z version 7.6.1 prend en charge un nouvel agencement de structure de données, de longueur variable, pour des fichiers VSAM d'informations personnalisées CARMA, CRASTRS, dans lequel des chaînes sont séparées par un caractère délimiteur, au lieu d'avoir une longueur fixe.
Personnalisez et soumettez le JCL FEK.SFEKSAMP(CRA#VS2) pour convertir votre fichier VSAM d'informations personnalisées CARMA de longueur fixe, CRASTRS, au nouveau format de longueur variable.
Le serveur CARMA fournit une interface API standard pour d'autres produits hôte permettant d'accéder à un ou plusieurs gestionnaires de configuration de logiciel (SCM). Cependant, il ne fournit pas de méthodes permettant la communication directe avec un PC client. Pour cela, il s'appuie sur d'autres produits tels que le serveur RSE. Le serveur RSE utilise les paramètres de CRASRV.properties pour démarrer et se connecter au serveur CARMA.
Le fichier CRASRV.properties se trouve dans /etc/rdz/, sauf si vous avez indiqué un emplacement différent lorsque vous avez personnalisé et soumis le travail FEK.SFEKSAMP(FEKSETUP). Pour plus d'informations, voir Configuration personnalisée. Vous pouvez modifier le fichier à l'aide de la commande TSO OEDIT.
# CRASRV.properties - CARMA configuration options # port.start=5227 port.range=100 startup.script.name=/usr/lpp/rdz/bin/carma.startup.rex clist.dsname='FEK.#CUST.CNTL(CRASUBMT)' crastart.stub=/usr/lpp/rdz/bin/CRASTART crastart.configuration.file=/etc/rdz/crastart.conf crastart.syslog=Partial crastart.timeout=420 #crastart.steplib=FEK.SFEKLPA #crastart.tasklib=TASKLIB
La valeur par défaut est 'FEK.#CUST.CNTL(CRASUBMT)'. Ce CLIST démarrera un serveur CARMA lors de l'ouverture d'une connexion à l'aide de la méthode de soumission par lots.
A (All) | Toutes les informations de traçage sont imprimées dans le journal système |
P (Partial) | Seules les informations de connexion, de déconnexion et d'erreur sont imprimées dans le journal système |
anything else | Seules les conditions d'erreur sont imprimées dans le journal système |
Cette directive est uniquement utilisée si la directive clist.dsname possède la valeur*CRASTART.
Les informations de la présente section décrivent comment configurer la méthode par défaut pour Developer for System z afin de démarrer le serveur CARMA. Cette étape de personnalisation peut être ignorée si vous utilisez une autre méthode de démarrage.
Developer for System z utilise par défaut la méthode de démarrage du serveur CARMA via la soumission par lots, qui n'oblige pas à placer le module CRASTART dans la zone LPA et qui ne dépend pas de la passerelle client TSO/ISPF. La méthode soumet le serveur CARMA sous la forme d'un travail par lot à exécution longue dans JES.
Le serveur RSE utilise les paramètres de /etc/rdz/CRASRV.properties pour démarrer et se connecter à un serveur CARMA, tel qu'indiqué dans interface RSE avec CARMA. Vous pouvez modifier le fichier à l'aide de la commande TSO OEDIT. Notez que RSE doit être redémarré pour que les modifications prennent effet.
Modifiez la valeur de la directive clist.dsname en indiquant le nom du fichier ou du membre de la liste CLIST de démarrage du serveur CARMA CRASUBMT, comme indiqué dans l'exemple ci-dessous. Pour plus d'informations sur les différentes directives, voir interface RSE avec CARMA.
port.start=5227 port.range=100 startup.script.name=/usr/lpp/rdz/bin/carma.startup.rex clist.dsname='FEK.#CUST.CNTL(CRASUBMT)'
Personnalisez la liste CLIST CRASUBMT, comme indiqué dans l'exemple de code ci-dessous. Pour obtenir des instructions de personnalisation, consultez la documentation qui se trouve dans CRASUBMT. La liste de commandes CRASUBMT soumet un serveur CARMA.
CRASUBMT se trouve dans FEK.#CUST.CNTL, sauf si vous avez indiqué un autre emplacement lorsque vous avez personnalisé et soumis le travail FEK.SFEKSAMP(FEKSETUP). Pour plus d'informations, voir Configuration personnalisée.
PROC 1 PORT TIMEOUT(420) SUBMIT * END($$) //CRA&PORT JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1) //RUN EXEC PGM=IKJEFT01,DYNAMNBR=25,REGION=1024K,TIME=NOLIMIT //STEPLIB DD DISP=SHR,DSN=FEK.SFEKLOAD //* DD DISP=SHR,DSN=FEK.#CUST.LOAD //CRADEF DD DISP=SHR,DSN=FEK.#CUST.CRADEF //CRAMSG DD DISP=SHR,DSN=FEK.#CUST.CRAMSG //CRASTRS DD DISP=SHR,DSN=FEK.#CUST.CRASTRS //*CRARAM1 DD DISP=SHR,DSN=FEK.#CUST.CRARAM1 //* //ISPPROF DD DISP=(NEW,DELETE,DELETE), // SPACE=(TRK,(1,1,5)),LRECL=80,RECFM=FB,UNIT=SYSALLDA //ISPMLIB DD DISP=SHR,DSN=ISP.SISPMENU //ISPPLIB DD DISP=SHR,DSN=ISP.SISPPENU //ISPSLIB DD DISP=SHR,DSN=ISP.SISPSENU //ISPTLIB DD DISP=SHR,DSN=ISP.SISPTENU //ISPEXEC DD DISP=SHR,DSN=ISP.SISPEXEC //SYSPROC DD DISP=SHR,DSN=ISP.SISPCLIB //* //CARMALOG DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * ISPSTART PGM(CRASERV) PARM(&PORT &TIMEOUT) //* $$ EXIT CODE(0)
Les informations de la présente section décrivent comment configurer une méthode alternative pour Developer for System z afin de démarrer un serveur CARMA. Cette étape de personnalisation peut être ignorée si vous utilisez une autre méthode de démarrage.
Developer for System z prend en charge une méthode de démarrage d'un serveur CARMA alternatif qui ne dépend pas de la passerelle client TSO/ISPF et qui ne soumet pas un travail de serveur à l'aide d'un initiateur JES. La méthode utilise CRASTART pour démarrer le serveur CARMA en tant que sous-tâche au sein de RSE et ressemble au service de passerelle client TSO/ISPF.
Le serveur RSE utilise les paramètres de /etc/rdz/CRASRV.properties pour démarrer et se connecter à un serveur CARMA, tel qu'indiqué dans interface RSE avec CARMA. Vous pouvez modifier le fichier à l'aide de la commande TSO OEDIT. Notez que RSE doit être redémarré pour que les modifications prennent effet.
Modifiez la valeur de la directive clist.dsname par *CRASTART et entrez les bonnes valeurs pour les directives crastart.* comme illustré dans l'exemple suivant. Pour plus d'informations sur les différentes directives, voir interface RSE avec CARMA.
port.start=5227 port.range=100 startup.script.name=/usr/lpp/rdz/bin/carma.startup.rex clist.dsname=*CRASTART crastart.stub=/usr/lpp/rdz/bin/CRASTART crastart.configuration.file=/etc/rdz/crastart.conf crastart.syslog=Partial crastart.timeout=420 #crastart.steplib=FEK.SFEKLPA #crastart.tasklib=TASKLIB
Conservez une sortie imprimée de l'élément CRASUBMT (voir Démarrage du serveur CARMA à l'aide de la soumission par lots) à portée de main pour pouvoir vous y référer facilement pendant cette étape de personnalisation. La sortie imprimée sera utile même si vous n'avez pas personnalisé le membre.
CRASTART utilise les définitions de crastart.conf pour créer un environnement valide afin d'exécuter les commandes TSO et ISPF par lots. Developer for System z utilise cet environnement pour exécuter le serveur CARMA appelé CRASERV.
Le fichier crastart.conf se trouve dans /etc/rdz/, sauf si vous avez indiqué un emplacement différent lorsque vous avez personnalisé et soumis le travail FEK.SFEKSAMP(FEKSETUP). Pour plus d'informations, voir Configuration personnalisée. Vous pouvez modifier le fichier à l'aide de la commande TSO OEDIT.
Les étapes de personnalisation ci-dessous sont requises pour ajuster le fichier de configuration illustré dans l'exemple de code suivant.
* crastart.conf - CARMA allocation options TASKLIB = FEK.SFEKLOAD CRADEF = FEK.#CUST.CRADEF CRAMSG = FEK.#CUST.CRAMSG CRASTRS = FEK.#CUST.CRASTRS *CRARAM1 = FEK.#CUST.CRARAM1 * CARMALOG = SYSOUT(H) SYSTSPRT = SYSOUT(H) SYSTSIN = DUMMY -COMMAND=ALLOC FI(SCRATCH) NEW DELETE DSORG(PS) RECFM(F,B) LRECL(80) UNIT(VIO) * PROGRAM=IKJEFT01 CRASERV &CRAPRM1. &CRAPRM2.
Les variables suivantes peuvent être utilisées dans le fichier de configuration :
&CRAUSER. | ID utilisateur de connexion du client. |
&CRADATE. | Date actuelle au format Dyyyyddd (7 caractères juliens). |
&CRATIME. | Heure actuelle au format Thhmmss (heure minute seconde). |
&CRAPRM3. à &CRAPRM9. |
Variables supplémentaires avec des valeurs attribuées à l'utilisateur. L'utilisation de ces variables requiert la personnalisation du REXX de démarrage CARMA référencé par startup.script.name dans CRASRV.properties. Lorsque vous utilisez ces variables, vous devez personnaliser une copie du REXX de démarrage par défaut, /usr/lpp/rdz/bin/carma.startup.rex, et faire pointer startup.script.name sur cette copie. Ceci pour éviter de perdre votre travail lors des mises à jour de maintenance du REXX par défaut. |
symbole système | Tout symbole système défini dans SYS1.PARMLIB(IEASYMxx) |
-<DD> | Un trait d'union (-) suivi d'un nom de définition de données défini précédemment agit comme une référence amont *.ddname dans JCL. La définition de données d'origine doit être attribuée à l'aide de l'instruction -COMMAND. |
Les informations de la présente section décrivent comment configurer une méthode alternative pour Developer for System z afin de démarrer un serveur CARMA. Cette étape de personnalisation peut être ignorée si vous utilisez une autre méthode de démarrage.
Developer for System z prend en charge une méthode de démarrage d'un serveur CARMA alternatif qui ne requiert pas que le module CRASTART se trouve dans la LPA et qui ne soumet pas un travail de serveur à l'aide d'un initiateur JES. Cette méthode utilise la passerelle client TSO/ISPF d'ISPF et est similaire au mode d'accès par défaut au service Commandes TSO.
Le serveur RSE utilise les paramètres de /etc/rdz/CRASRV.properties pour démarrer et se connecter à un serveur CARMA, tel qu'indiqué dans interface RSE avec CARMA. Vous pouvez modifier le fichier à l'aide de la commande TSO OEDIT. Notez que RSE doit être redémarré pour que les modifications prennent effet.
Modifiez la valeur de la directive clist.dsname par *ISPF, comme illustré dans l'exemple suivant. Pour plus d'informations sur les différentes directives, voir interface RSE avec CARMA.
port.start=5227 port.range=100 startup.script.name=/usr/lpp/rdz/bin/carma.startup.rex clist.dsname=*ISPF
Conservez une sortie imprimée de l'élément CRASUBMT (voir Démarrage du serveur CARMA à l'aide de la soumission par lots) à portée de main pour pouvoir vous y référer facilement pendant cette étape de personnalisation. La sortie imprimée sera utile même si vous n'avez pas personnalisé le membre.
Le service de passerelle client TSO/ISPF d'ISPF utilise les définitions figurant dans ISPF.conf pour créer un environnement valide en vue d'exécuter les commandes de traitement par lots TSO et ISPF. Developer for System z utilise cet environnement pour exécuter le serveur CARMA.
Le fichier ISPF.conf se trouve dans /etc/rdz/, sauf si vous avez indiqué un emplacement différent lorsque vous avez personnalisé et soumis le travail FEK.SFEKSAMP(FEKSETUP). Pour plus d'informations, voir Configuration personnalisée. Vous pouvez modifier le fichier à l'aide de la commande TSO OEDIT.
Les étapes de personnalisation ci-dessous sont requises pour ajuster le fichier de configuration illustré dans l'exemple de code suivant.
sysproc=ISP.SISPCLIB,FEK.SFEKPROC ispllib=FEK.SFEKLOAD ispmlib=ISP.SISPMENU isptlib=ISP.SISPTENU ispplib=ISP.SISPPENU ispslib=ISP.SISPSLIB CRADEF =FEK.#CUST.CRADEF CRAMSG =FEK.#CUST.CRAMSG CRASTRS=FEK.#CUST.CRASTRS *CRARAM1=FEK.#CUST.CRARAM1 allocjob=FEK.#CUST.CNTL(CRAISPRX)
Les définitions de données CARMALOG font référence par défaut à SYSOUT=* qui ne peut pas être mappé dans ISPF.conf. Vous ne pouvez pas mapper les définitions de données directement sur un fichier, car tous les utilisateurs de Developer for System z utiliseront le même fichier ISPF.conf et, par conséquent, les mêmes fichiers.
En revanche, comme indiqué au Personnalisation de l'environnement TSO, section Avancé - Utilisation d'une commande exec d'allocation, vous pouvez utiliser une instruction exec d'allocation et allouer un fichier en fonction de l'ID utilisateur actif. Consultez l'exemple de membre CRAISPRX dans le fichier FEK.#CUST.CNTL en tant qu'exemple qui attribue les définitions de données CARMALOG au nom de fichier TSOPREFIX'.'USERID'.CRA.'TIMESTAMP'.CARMALOG'.
Les gestionnaires d'accès au référentiel (RAM) sont des API écrites par l'utilisateur permettant d'interfacer avec les gestionnaires de configuration de logiciel z/OS. Pour activer les modèles de RAM voulus, suivez les instructions des sections suivantes.
Voir le document Rational Developer for System z Common Access Repository Manager Developer's Guide (SC23-7660) pour plus d'informations sur les exemples de RAM et de code source fournis.
Les exemples de membre indiqués ci-après se trouvent dans FEK.#CUST.JCL, sauf si vous avez indiqué un emplacement différent lorsque vous avez personnalisé et soumis le travail FEK.SFEKSAMP(FEKSETUP). Pour plus d'informations, voir Configuration personnalisée.
Le RAM PDS donne une liste de fichiers analogues aux fichiers MVS -> Mes fichiers de la vue Systèmes distants. Le RAM PDS utilise l'ID RAM 0 par défaut.
Le RAM SCLM offre une entrée de base à SCLM, le gestionnaire de configuration de logiciel d'ISPF. Le RAM SCLM utilise l'ID RAM 1 par défaut.
Le RAM du squelette offre un cadre qui peut être utilisé pour développer vos RAM personnelles. Le RAM du squelette utilise l'ID RAM 3 par défaut.
L'interface d'IBM Rational Developer for System z pour le gestionnaire de configuration logicielle de CA Endevor donne aux clients Developer for System z un accès direct au SCM de CA Endevor SCM. A partir de maintenant, l'interface IBM Rational Developer for System z pour le SCM de CA Endevor est abrégé en CA Endevor SCM RAM (Repository Access Manager).
Contrairement aux modèles de RAM présentés dans cette publication, CA Endevor SCM RAM est un RAM de type production. Il est recommandé de ne pas activer les deux types de RAM dans la même configuration.
Attention : les travaux de configuration proposés pour CA Endevor SCM RAM remplacent la configuration CARMA active par une autre ne contenant que CA Endevor SCM RAM. |
Vous avez besoin de l'aide d'un administrateur de sécurité et d'un administrateur TCP/IP pour effectuer cette tâche de personnalisation, qui requiert les ressources ou tâches de personnalisation spéciales ci-après :
Pour commencer à utiliser CA Endevor SCM RAM sur votre site, vous devez effectuer les tâches ci-après. Sauf indication contraire, toutes les tâches sont obligatoires.
Les composants CARMA suivants doivent être personnalisés, indépendamment de la méthode de démarrage choisie. Les exemples de membre indiqués ci-après se trouvent dans FEK.#CUST.JCL, sauf si vous avez indiqué un emplacement différent lorsque vous avez personnalisé et soumis le travail FEK.SFEKSAMP(FEKSETUP). Pour plus d'informations, voir Configuration personnalisée.
Ne suivez pas cette étape si vous utilisez la méthode CRASTART pour démarrer le serveur CARMA avec CA Endevor SCM RAM.
Developer for System z peut utiliser la méthode de démarrage du serveur CARMA par soumission par lots pour démarrer CA Endevor SCM RAM. La méthode soumet le serveur CARMA sous la forme d'un travail par lot à exécution longue dans JES.
Pour plus d'informations sur la méthode de démarrage par soumission par lots, Démarrage du serveur CARMA à l'aide de la soumission par lots.
Le serveur RSE utilise les paramètres de /etc/rdz/CRASRV.properties pour démarrer et se connecter à un serveur CARMA, tel qu'indiqué dans interface RSE avec CARMA. Vous pouvez modifier le fichier à l'aide de la commande TSO OEDIT. Notez que RSE doit être redémarré pour que les modifications prennent effet.
Changez la valeur de la directive clist.dsname en indiquant le nom du fichier ou du membre de la liste CLIST de démarrage du serveur CARMA CRASUBCA, comme indiqué dans l'exemple ci-dessous. Pour plus d'informations sur les différentes directives, voir interface RSE avec CARMA.
port.start=5227 port.range=100 startup.script.name=/usr/lpp/rdz/bin/carma.startup.rex clist.dsname='FEK.#CUST.CNTL(CRASUBCA)'
Personnalisez la liste CLIST CRASUBCA, comme indiqué dans l'exemple de code ci-dessous. Pour obtenir des instructions de personnalisation, consultez la documentation qui se trouve dans CRASUBCA. La liste de commandes CRASUBCA soumet un serveur CARMA pour le gestionnaire de configuration logicielle (SCM) de CA Endevor.
CRASUBCA se trouve dans FEK.#CUST.CNTL, sauf si vous avez indiqué un autre emplacement lorsque vous avez personnalisé et soumis le travail FEK.SFEKSAMP(FEKSETUP). Pour plus d'informations, voir Configuration personnalisée.
PROC 1 PORT TIMEOUT(420) SUBMIT * END($$) //CRA&PORT JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1) //RUN EXEC PGM=IKJEFT01,DYNAMNBR=125,REGION=0M,TIME=NOLIMIT, // PARM='%CRANDVRA NDVRC1 PGM(CRASERV) PARM(&PORT &TIMEOUT)' //STEPLIB DD DISP=SHR,DSN=FEK.SFEKLOAD // DD DISP=SHR,DSN=CA.NDVR.AUTHLIB // DD DISP=SHR,DSN=CA.NDVRU.AUTHLIB //CRADEF DD DISP=SHR,DSN=FEK.#CUST.CRADEF //CRAMSG DD DISP=SHR,DSN=FEK.#CUST.CRAMSG //CRASTRS DD DISP=SHR,DSN=FEK.#CUST.CRASTRS //* //SYSPROC DD DISP=SHR,DSN=ISP.SISPCLIB // DD DISP=SHR,DSN=FEK.SFEKPROC //ISPEXEC DD DISP=SHR,DSN=ISP.SISPEXEC //ISPMLIB DD DISP=SHR,DSN=ISP.SISPMENU //ISPPLIB DD DISP=SHR,DSN=ISP.SISPPENU //ISPSLIB DD DISP=SHR,DSN=ISP.SISPSENU //ISPTLIB DD DISP=SHR,DSN=ISP.SISPTENU //ISPCTL0 DD DISP=(NEW,DELETE,DELETE),UNIT=SYSALLDA, // SPACE=(TRK,(1,1)),LRECL=80,RECFM=FB //ISPCTL1 DD DISP=(NEW,DELETE,DELETE),UNIT=SYSALLDA, // SPACE=(TRK,(1,1)),LRECL=80,RECFM=FB //ISPPROF DD DISP=(NEW,DELETE,DELETE),UNIT=SYSALLDA, // SPACE=(TRK,(1,1,5)),LRECL=80,RECFM=FB //* //CARMALOG DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSTSIN DD DUMMY //* //CONLIB DD DISP=SHR,DSN=CA.NDVR.CONLIB //JCLOUT DD SYSOUT=(A,INTRDR),DCB=(LRECL=80,RECFM=F,BLKSIZE=80) //EXT1ELM DD DISP=(NEW,DELETE),UNIT=SYSALLDA, // RECFM=VB,LRECL=4096,BLKSIZE=27998,SPACE=(TRK,(5,5)) //EXT1DEP DD DISP=(NEW,DELETE),UNIT=SYSALLDA, // RECFM=VB,LRECL=4096,BLKSIZE=27998,SPACE=(TRK,(5,5)) //MSG3FILE DD DISP=(NEW,DELETE),UNIT=SYSALLDA, // RECFM=FB,LRECL=133,BLKSIZE=27930,SPACE=(TRK,(5,5)) //C1MSGS1 DD DISP=(NEW,DELETE),UNIT=SYSALLDA, // RECFM=FB,LRECL=133,BLKSIZE=27930,SPACE=(TRK,(5,5)) //C1EXMSGS DD DISP=(NEW,DELETE),UNIT=SYSALLDA, // RECFM=FB,LRECL=133,BLKSIZE=27930,SPACE=(TRK,(5,5)) //TYPEMAP DD DISP=SHR,DSN=FEK.#CUST.PARMLIB(CRATMAP) //SHOWVIEW DD DISP=SHR,DSN=FEK.#CUST.PARMLIB(CRASHOW) $$ EXIT CODE(0)
Ne suivez pas cette étape si vous utilisez la méthode de soumission par lots pour démarrer le serveur CARMA avec CA Endevor SCM RAM.
Developer for System z peut utiliser la méthode de démarrage du serveur CARMA à l'aide de CRASTART pour démarrer CA Endevor SCM RAM. La méthode utilise CRASTART pour démarrer le serveur CARMA comme une sous-tâche au sein de RSE.
Pour plus d'informations sur la méthode de démarrage CRASTART, (Facultatif) Démarrage du serveur CARMA alternatif à l'aide de CRASTART.
Le serveur RSE utilise les paramètres de /etc/rdz/CRASRV.properties pour démarrer et se connecter à un serveur CARMA, tel qu'indiqué dans interface RSE avec CARMA. Vous pouvez modifier le fichier à l'aide de la commande TSO OEDIT. Notez que RSE doit être redémarré pour que les modifications prennent effet.
Modifiez la valeur de la directive clist.dsname par *CRASTART et entrez les bonnes valeurs pour les directives crastart.* comme illustré dans l'exemple suivant. Pour plus d'informations sur les différentes directives, voir interface RSE avec CARMA.
port.start=5227 port.range=100 startup.script.name=/usr/lpp/rdz/bin/carma.startup.rex clist.dsname=*CRASTART crastart.stub=/usr/lpp/rdz/bin/CRASTART crastart.configuration.file=/etc/rdz/crastart.endevor.conf crastart.syslog=Partial crastart.timeout=420 #crastart.steplib=FEK.SFEKLPA #crastart.tasklib=TASKLIB
CRASTART utilise les définitions de crastart.endevor.conf pour créer un environnement (TSO/ISPF) valide pour appeler CA Endevor SCM. Developer for System z utilise cet environnement pour exécuter CA Endevor SCM RAM.
Le fichier crastart.endevor.conf se trouve dans /etc/rdz/, sauf si vous avez indiqué un emplacement différent lorsque vous avez personnalisé et soumis le travail FEK.SFEKSAMP(FEKSETUP). Pour plus d'informations, voir Configuration personnalisée. Vous pouvez modifier le fichier à l'aide de la commande TSO OEDIT.
TASKLIB = FEK.SFEKLOAD,CA.NDVR.AUTHLIB,CA.NDVRU.AUTHLIB CRADEF = FEK.#CUST.CRADEF CRAMSG = FEK.#CUST.CRAMSG CRASTRS = FEK.#CUST.CRASTRS SYSPROC = ISP.SISPCLIB,FEK.SFEKPROC SYSEXEC = ISP.SISPEXEC ISPMLIB = ISP.SISPMENU ISPPLIB = ISP.SISPPENU ISPSLIB = ISP.SISPSENU -COMMAND=ALLOC FI(ISPCTL0) NEW DELETE DSORG(PS) RECFM(F,B) LRECL(80) BLKSIZE(6160) SPACE(2,2) TRACKS UNIT(SYSALLDA) -COMMAND=ALLOC FI(ISPCTL1) NEW DELETE DSORG(PS) RECFM(F,B) LRECL(80) BLKSIZE(6160) SPACE(2,2) TRACKS UNIT(SYSALLDA) -COMMAND=ALLOC FI(ISPPROF) NEW DELETE DSORG(PO) DIR(5) RECFM(F,B) LRECL(80) BLKSIZE(6160) SPACE(2,2) TRACKS UNIT(SYSALLDA) ISPTLIB = -ISPPROF,ISP.SISPTENU ISPTABL = -ISPPROF CARMALOG = SYSOUT(H) SYSPRINT= SYSOUT(H) SYSTSPRT = SYSOUT(H) SYSTSIN = DUMMY TYPEMAP = FEK.#CUST.PARMLIB(CRATMAP) SHOWVIEW= FEK.#CUST.PARMLIB(CRASHOW) CONLIB = CA.NDVR.CONLIB -COMMAND=ALLOC FI(JCLOUT) SYSOUT(A) WRITER(INTRDR) RECFM(F) LRECL(80) BLKSIZE(80) -COMMAND=ALLOC FI(EXT1ELM) NEW DELETE DSORG(PS) RECFM(V,B) LRECL(4096) BLKSIZE(27998) SPACE(5,5) TRACKS UNIT(SYSALLDA) -COMMAND=ALLOC FI(EXT1DEP) NEW DELETE DSORG(PS) RECFM(V,B) LRECL(4096) BLKSIZE(27998) SPACE(5,5) TRACKS UNIT(SYSALLDA) -COMMAND=ALLOC FI(MSG3FILE) NEW DELETE DSORG(PS) RECFM(F,B) LRECL(133) BLKSIZE(27930) SPACE(5,5) TRACKS UNIT(SYSALLDA) -COMMAND=ALLOC FI(C1EXMSGS) NEW DELETE DSORG(PS) RECFM(F,B) LRECL(133) BLKSIZE(27930) SPACE(5,5) TRACKS UNIT(SYSALLDA) -COMMAND=ALLOC FI(C1MSGS1) NEW DELETE DSORG(PS) RECFM(F,B) LRECL(133) BLKSIZE(27930) SPACE(5,5) TRACKS UNIT(SYSALLDA) PROGRAM=IKJEFT01 %CRANDVRA NDVRC1 PGM(CRASERV) PARM(&CRAPRM1. &CRAPRM2.)
Les deux méthodes de démarrage (soumission par lots et CRASTART) appellent une commande exec REXX CRANDVRA pour allouer des fichiers spécifiques de l'utilisateur utilisés par CA Endevor SCM RAM.
DD | Nom du fichier | Type |
---|---|---|
DEPEND | &SYSPREF..&SYSUID..&SYSNAME..CRA$NDVR.DEPEND | Permanent |
BROWSE | &SYSPREF..&SYSUID..&SYSNAME..CRA$NDVR.BROWSE | Temporaire |
C1PRINT | &SYSPREF..&SYSUID..&SYSNAME..CRA$NDVR.LISTING | Temporaire |
Vous pouvez personnaliser une copie de cette commande exec REXX d'allocation REXX si certaines valeurs par défaut comme le nom du fichier, ne correspondent pas aux normes établies pour votre site. CRANDVRA se trouve dans FEK.SFEKPROC, sauf si vous avez utilisé un qualificateur de niveau supérieur durant l'installation de SMP/E de System z.
Pour obtenir des instructions de personnalisation, consultez la documentation qui se trouve dans CRANDVRA.
Les composants CARMA suivants peuvent être personnalisés, indépendamment de la méthode de démarrage choisie. Les exemples de membre indiqués ci-après se trouvent dans FEK.#CUST.PARMLIB, sauf si vous avez indiqué un emplacement différent lorsque vous avez personnalisé et soumis le travail FEK.SFEKSAMP(FEKSETUP). Pour plus d'informations, voir Configuration personnalisée.
CARMA permet que plusieurs RAM soient définis et peut les exécuter simultanément. Toutefois, puisqu'un seul serveur CARMA est actif par utilisateur, même s'il existe plusieurs RAM, certains changements de configuration peuvent s'avérer nécessaires pour permettre à cette configuration de fonctionner.
Un développeur RAM définit les RAM dans le fichier VSAM de configuration CARMA, CRADEF. Durant le démarrage, le serveur CARMA, CRASERV, identifie tous les RAM définis et présente les informations au client CARMA. L'utilisateur peut alors sélectionner un ou plusieurs RAM qui seront chargés dans le serveur CARMA.
Puisque les RAM sont actifs comme des plug-ins du serveur CARMA, vous devez vous assurer que tous les éléments prérequis (comme toutes les allocations de fichiers) de chaque RAM sont disponibles dans l'espace adresse du serveur CARMA. Ceci pourrait nécessiter des changements dans les modèles de configuration CARMA, comme CRASUBMT ou crastart.conf, qui sont fournis avec Developer for System z.
Dans l'exemple suivant, vous démarrez à partir d'une configuration existante avec CA Endevor SCM RAM, à l'aide de la méthode de démarrage CRASTART et ajoutez le modèle PDS RAM.
Définition pour CA Endevor SCM RAM :
Definitions pour PDS RAM:
Le processus démarre avec un développeur RAM réunissant les données et informations requises par le programmeur système pour compléter la configuration.
Le programmeur système utilise ensuite ces données pour créer les fichiers VSAM CARMA mis à jour et utilise les informations des éléments prérequis pour créer un fichier de configuration CRASTART qui est en mesure de prendre en charge les deux RAM.
CA Endevor SCM RAM est actif dans un environnement ISPF, ce qui implique que l'environnement TSO requis par le PDS RAM est également disponible.
Si le serveur CARMA est démarré à l'aide de TSO (IKJEFTxx), vous pouvez rencontrer des incidents si vos RAM appellent des services qui à leur tour appellent l'interface de traitement par lots REXX IRXJCL. L'incident peut survenir lorsque les processeurs appelés par le RAM étaient précédemment exécutés sans TSO ou uniquement dans le TSO en ligne et attribuaient dynamiquement des définitions de données SYSTSIN ou SYSTSPRT. Un exemple de programme, CRAXJCL, est fourni afin de contourner l'incident.
Votre processeur peut échouer s'il tente d'attribuer SYSTSIN ou SYSTSPRT (requis pour IRXJCL) car le TSO de traitement par lots (requis pour CARMA) a déjà attribué et ouvert ses noms de définition de données. Le module de remplacement CRAXJCL tente d'attribuer SYSTSIN et SYSTSPRT à DUMMY mais ignore les erreurs qui se produisent si les attributions échouent.
Cela signifie que lorsque vos processeurs sont exécutés dans un environnement CARMA démarré par TSP, les attributions à SYSTSIN et SYSTSPRT sont identiques à celles utilisées par CARMA. Lorsque les processeurs sont exécutés à l'extérieur de TSO/CARMA, les attributions SYSTSIN et SYSTSPRINT seront créées par CRAXJCL. Par conséquent, vos processeurs ne doivent pas se fonder sur le contenu du fichier attribué à SYSTSIN.
Les appels vers IRXJCL sont supposés utiliser le champ PARM pour transmettre le nom REXX et les paramètres de démarrage (voir le document TSO/E REXX Reference (SA22-7790). Cela signifie que SYSTSIN peut être utilisé en toute sécurité par CARMA. Toute sortie envoyée vers SYSTSPRT par IRXJCL finira dans le journal CARMA.
Les processeurs qui appellent le module de remplacement CRAXJCL ne doivent pas essayer d'attribuer des définitions de données SYSTSIN ou SYSTSPRT avant d'appeler CRAXJCL.
Le module de remplacement CRAXJCL est fourni au format source car vous aurez besoin de le personnaliser pour spécifier des attributions spécifiques que vous souhaitez utiliser pour SYSTSPRT. SYSTSIN doit généralement être attribué à un fichier factice.
L'exemple de code source en assembleur et l'exemple de travail de compilation/liaison sont fournis respectivement en tant que FEK.#CUST.ASM(CRAXJCL) et FEK.#CUST.JCL(CRA#CIRX) à moins que vous n'ayez spécifié un emplacement différent lorsque vous avez personnalisé et soumis le travail FEK.SFEKSAMP(FEKSETUP). Pour plus d'informations, voir Configuration personnalisée.
Personnalisez le code source en assembleur CRAXJCL en fonction de vos besoins en utilisant la documentation fournie dans le membre. Ensuite, personnalisez et soumettez le langage JCL CRA#CIRX pour créer le module de chargement CRAXJCL. Voir la documentation fournie dans CRA#CIRX pour consulter les instructions de personnalisation.
Developer for System z utilise certaines fonctions du Gestionnaire de déploiement d'application comme approche commune de déploiement pour plusieurs composants. Les étapes de personnalisation répertoriées dans le présent chapitre sont requises si vos développeurs utilisent l'une des fonctions suivantes :
Le gestionnaire de personnalisation de déploiement d'application ajoute le serveur de définition de ressources CICS, qui s'exécute en tant qu'application CICS sur z/OS pour prendre en charge les fonctions suivantes :
Les administrateurs CICS peuvent consulter davantage d'informations relatives au serveur CRD dans le Remarques à propos de CICSTS.
Vous aurez besoin de l'aide d'un administrateur CICS, d'un administrateur TCP/IP et d'un administrateur de sécurité pour effectuer cette tâche de personnalisation, qui requiert les tâches de personnalisation spéciales ou les ressources suivantes :
Pour commencer à utiliser le gestionnaire de déploiement d'application sur votre site, vous devez effectuer les tâches ci-après : Sauf indication contraire, toutes les tâches sont obligatoires.
Personnalisez et soumettez un travail ADNVCRD pour attribuer et initialiser le fichier de la méthode d'accès VSAM du référentiel CRD. Pour obtenir les instructions de personnalisation, consultez la documentation qui se trouve dans le membre.
ADNVCRD 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 Configuration personnalisée.
Il est recommandé de créer un référentiel séparé pour chaque région de connexion primaire CICS. Le partage du référentiel implique que toutes les régions CICS concernées utiliseront les mêmes valeurs stockées dans le référentiel.
Les utilisateurs doivent posséder les droits d'accès READ au référentiel de CRD, les administrateurs CICS devant posséder les droits d'accès UPDATE.
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 le modèle de travail ADNJSPAU. 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 vous avez indiqué un autre emplacement lorsque vous avez personnalisé et soumis le travail FEK.SFEKSAMP(FEKSETUP). Pour plus d'informations, voir Configuration personnalisée.
Pour de plus amples informations, voir Remarques à propos de CICSTS.
Les versions 1.4 et ultérieures de CICS Transaction Server proposent un support pour l'interface HTTP reposant sur 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, le cas échéant. 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 avertissements relatives aux définitions en double lorsque la deuxième interface est définie dans la région.
Les informations de la présente section expliquent comment définir le serveur CRD qui utilise l'interface RESTful pour communiquer avec le client Developer for System z.
Les interfaces RESTful et Web Service peuvent être activées simultanément dans une seule région CICS, le cas échéant. 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 avertissements relatives aux définitions en double lorsque la deuxième interface est définie dans la région.
Le serveur CRD doit être défini pour la région de connexion primaire. Il s'agit de la région gérant le Web (WOR) qui traite les requêtes de service Web en provenance de Developer for System z.
ADNCSDRS 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 Configuration personnalisée.
CEDA INSTALL GROUP(ADNPCRGP)
Le serveur CRD peut également être utilisé avec une ou plusieurs régions de connexion secondaires supplémentaires, qui sont généralement des régions gérant les applications (AOR).
ADNCSDAR 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 Configuration personnalisée.
CEDA INSTALL GROUP(ADNARRGP)
Developer for System z fournit plusieurs transactions utilisées par le serveur CRD lors de la définition et de la consultation des ressources CICS.
Transaction | Description |
---|---|
ADMS | Pour les demandes, par l'outil de traitement des manifestes, de modification des ressources CICS. En règle générale, destiné aux administrateurs CICS. |
ADMI | Pour les demandes qui définissent, installent ou désinstallent les ressources CICS. |
ADMR | Pour toutes les autres demandes qui récupèrent des informations sur les ressources ou l'environnement CICS. |
Vous pouvez modifier les ID transaction de sorte qu'ils correspondent aux normes de votre site en suivant la procédure ci-dessous :
Les informations de la présente section expliquent comment définir le serveur CRD qui utilise l'interface Web Service pour communiquer avec le client Developer for System z.
Les interfaces RESTful et Web Service peuvent être activées simultanément dans une seule région CICS, le cas échéant. 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 avertissements relatives aux définitions en double lorsque la deuxième interface est définie dans la région.
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. Voir Remarques à propos de CICSTS pour en savoir davantage sur le gestionnaire de message de pipeline et la configuration de sécurité requise.
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 ADNTMSGH en fonction de l'opération demandée. Un exemple de langage COBOL est proposé afin de permettre une personnalisation spécifique au site dans ADNTMSGH :
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. |
ADMI | Pour les demandes qui définissent, installent ou désinstallent les ressources CICS. |
ADMR | Pour toutes les autres demandes qui récupèrent des informations sur les ressources ou l'environnement CICS. |
Utilisation des valeurs par défaut :
Personnalisation d'ADNTMSGH :
Les exemples de membres ADNMSGH* se trouvent dans FEK.#CUST.JCL et dans FEK.#CUST.COBOL, sauf si vous avez indiqué un emplacement différent lorsque vous avez personnalisé et soumis le travail FEK.SFEKSAMP(FEKSETUP). Pour plus d'informations, voir Configuration personnalisée.
Le serveur CRD doit être défini pour la région de connexion primaire. Il s'agit de la région qui traite les demandes de service provenant de Developer for System z.
ADNCSDWS 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 Configuration personnalisée.
CEDA INSTALL GROUP(ADNPCRGP)
Le serveur CRD peut également être utilisé avec une ou plusieurs régions de connexion secondaires supplémentaires, qui sont généralement des régions gérant les applications (AOR).
ADNCSDAR 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 Configuration personnalisée.
CEDA INSTALL GROUP(ADNARRGP)
Developer for System z permet aux clients de parcourir et éventuellement de modifier les manifestes qui décrivent les ressources CICS sélectionnées. En fonction des droits d'accès définis par l'administrateur CICS, les modifications peuvent être effectuées directement dans le référentiel de manifestes ou exportées dans celui-ci afin d'être traitées ultérieurement par l'administrateur CICS.
Personnalisez et soumettez le travail ADNVMFST pour allouer et initialiser le fichier VSAM du référentiel de manifestes et le définir dans la région de connexion CICS primaire. Pour obtenir les instructions de personnalisation, consultez la documentation qui se trouve dans le membre. Un référentiel de manifestes distinct doit être créé pour chaque région de connexion primaire CICS. Tous les utilisateurs doivent posséder des droits d'accès UPDATE au référentiel de manifestes.
ADNVMFST 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 Configuration personnalisée.
SCLM Developer Toolkit fournit les outils nécessaires à l'extension des fonctions de SCLM sur le client. SCLM est lui-même un gestionnaire de code source hôte livré comme partie intégrante d'ISPF.
SCLM Developer Toolkit intègre un module d'extension reposant sur Eclipse qui sert d'interface avec SCLM et fournit l'accès à tous les processus SCLM de développement du code existant. Il assure également la prise en charge du développement intégral de Java et J2EE sur le poste de travail avec la synchronisation de SCLM sur le grand système, y compris la construction, l'assemblage et le déploiement du code J2EE à partir du grand système.
Vous aurez besoin de l'aide d'un administrateur SCLM et éventuellement d'un administrateur de sécurité pour effectuer cette tâche de personnalisation, qui requiert les tâches de personnalisation spéciales et/ou les ressources suivantes :
Pour commencer à utiliser SCLM Developer Toolkit sur votre site, vous devez effectuer les tâches ci-après. Sauf indication contraire, toutes les tâches sont obligatoires.
Pour obtenir la liste relative à la maintenance SCLM requise, voir Annexe E. Conditions requises.
Cette annexe fournit également les spécifications Ant requises pour les générations JAVA/J2EE dans SCLM Developer Toolkit.
Avertissement : SCLM Developer Toolkit nécessite l'utilisation de la passerelle
client TSO/ISPF d'ISPF et, par conséquent, z/OS version 1.8 ou
supérieure est requis. |
Comme décrit dans la section Modifications de PARMLIB, SCLM Developer Toolkit requiert une personnalisation supplémentaire des paramètres système. Ces modifications sont les suivantes :
SCLM Developer Toolkit utilise également l'utilitaire SDSF ou la commande TSO OUTPUT pour extraire l'état d'achèvement et la sortie du travail. Voici quelques détails supplémentaires sur ces deux méthodes :
Les utilisateurs doivent détenir les droits d'accès READ, WRITE et EXECUTE aux répertoires z/OS UNIX /tmp/ and /var/rdz/WORKAREA/. Le répertoire WORKAREA/ se trouve dans /var/rdz/, sauf si vous avez indiqué un emplacement différent lorsque vous avez personnalisé et soumis le travail FEK.SFEKSAMP(FEKSETUP). Pour plus d'informations, voir Configuration personnalisée.
SCLM Developer Toolkit utilise les squelettes ISPF/SCLM standard. Par conséquent, vous devez vous assurer que la bibliothèque de squelettes ISP.SISPSLIB est allouée à la concaténation ISPSLIB dans ISPF.conf. L'utilisation du fichier ISP.SISPSENU est facultative.
Le fichier ISPF.conf se trouve dans /etc/rdz/, sauf si vous avez indiqué un emplacement différent lorsque vous avez personnalisé et soumis le travail FEK.SFEKSAMP(FEKSETUP). Pour plus d'informations, voir Configuration personnalisée. Vous pouvez modifier le fichier à l'aide de la commande TSO OEDIT.
L'exemple de code suivant illustre le fichier ISPF.conf qui doit être personnalisé pour correspondre à votre environnement système. Les lignes mises en commentaire commencent par un astérisque (*). Ajoutez des fichiers à la concaténation sur la même ligne et séparez les noms par une virgule (,). Pour plus d'informations sur la personnalisation d'ISPF.conf, voir la section ISPF.conf, fichier de configuration de la passerelle client TSO/ISPF d'ISPF .
* REQUIRED: sysproc=ISP.SISPCLIB,FEK.SFEKPROC ispmlib=ISP.SISPMENU isptlib=ISP.SISPTENU ispplib=ISP.SISPPENU ispslib=ISP.SISPSLIB * OPTIONAL: *allocjob = FEK.#CUST.CNTL(CRAISPRX) *ISPF_timeout = 900
ispslib=hlq.USERSKEL,ISP.SISPSLIB
SCLM Developer Toolkit utilise certaines directives définies dans rsed.envvars pour localiser les fichiers et les répertoires.
Le fichier rsed.envvars se trouve dans /etc/rdz/, sauf si vous avez indiqué un emplacement différent lorsque vous avez personnalisé et soumis le travail FEK.SFEKSAMP(FEKSETUP). Pour plus d'informations, voir Configuration personnalisée. Vous pouvez modifier le fichier à l'aide de la commande TSO OEDIT.
L'exemple de code suivant illustre les directives SCLMDT dans rsed.envvars qui doivent être personnalisées pour correspondre à votre environnement système. Voir rsed.envvars - Fichier de configuration RSE pour obtenir de plus amples informations sur la personnalisation de rsed.envvars.
_SCLMDT_CONF_HOME=/var/rdz/sclmdt #STEPLIB=$STEPLIB:FEK.SFEKAUTH:FEK.SFEKLOAD #_SCLMDT_TRANTABLE=FEK.#CUST.LSTRANS.FILE #ANT_HOME=/usr/lpp/Apache/Ant/apache-ant-1.7.1 _SCLMDT_BASE_HOME=$RSE_HOME _SCLMDT_WORK_HOME=$_CMDSERV_WORK_HOME CGI_DTWORK=$_SCLMDT_WORK_HOME
SCLM Developer Toolkit permet d'enregistrer dans SCLM des fichiers dont le nom est long (comportant plus de 8 caractères ou une casse mixte). Cela s'effectue à l'aide d'un fichier VSAM contenant le mappage du nom de fichier long sur le nom de membre à 8 caractères utilisé dans SCLM.
Personnalisez et soumettez un exemple de membre FLM02LST dans l'exemple de bibliothèque ISPF ISP.SISPSAMP, pour créer la conversion de nom long/abrégé VSAM. Les étapes de configuration dans la présente publication s'attendent à ce que VSAM s'appelle FEK.#CUST.LSTRANS.FILE, comme illustré dans l'exemple de JCL de configuration.
//FLM02LST JOB <paramètres du travail> //* //* CAUTION: This is neither a JCL procedure nor a complete job. //* Before using this sample, you will have to make the following //* modifications: //* 1. Change the job parameters to meet your system requirements. //* 2. Change ****** to the volume that will hold the VSAM. //* 3. Change all references of FEK.#CUST.LSTRANS.FILE to //* match your naming convention for the SCLM translate VSAM. //* //CREATE EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * DELETE FEK.#CUST.LSTRANS.FILE SET MAXCC=0 DEFINE CLUSTER(NAME(FEK.#CUST.LSTRANS.FILE) - VOLUMES(******) - RECORDSIZE(58 2048) - SHAREOPTIONS(3 3) - CYLINDERS(1 1) - KEYS(8 0) - INDEXED) - DATA (NAME(FEK.#CUST.LSTRANS.FILE.DATA)) - INDEX (NAME(FEK.#CUST.LSTRANS.FILE.INDEX)) /* DEFINE ALTERNATE INDEX WITH NONUNIQUE KEYS -> ESDS */ DEFINE ALTERNATEINDEX(- NAME(FEK.#CUST.LSTRANS.FILE.AIX) - RELATE(FEK.#CUST.LSTRANS.FILE) - RECORDSIZE(58 2048) - VOLUMES(******) - CYLINDERS(1 1) - KEYS(50 8) - UPGRADE - NONUNIQUEKEY) - DATA (NAME(FEK.#CUST.LSTRANS.FILE.AIX.DATA)) - INDEX (NAME(FEK.#CUST.LSTRANS.FILE.AIX.INDEX)) /* //* //PRIME EXEC PGM=IDCAMS,COND=(0,LT) //SYSPRINT DD SYSOUT=* //INITREC DD * INITREC1 /* //SYSIN DD * REPRO INFILE(INITREC) - OUTDATASET(FEK.#CUST.LSTRANS.FILE) IF LASTCC = 4 THEN SET MAXCC=0 BLDINDEX IDS(FEK.#CUST.LSTRANS.FILE) - ODS(FEK.#CUST.LSTRANS.FILE.AIX) IF LASTCC = 0 THEN - DEFINE PATH (NAME(FEK.#CUST.LSTRANS.FILE.PATH) - PATHENTRY (FEK.#CUST.LSTRANS.FILE.AIX)) /*
Avant d'utiliser la conversion de noms longs/courts, supprimez la mise en commentaire et définissez la variable d'environnement _SCLMDT_TRANTABLE de rsed.envvars pour rechercher le nom de la méthode VSAM de conversion de noms longs/courts.
Le fichier rsed.envvars se trouve dans /etc/rdz/, sauf si vous avez indiqué un emplacement différent lorsque vous avez personnalisé et soumis le travail FEK.SFEKSAMP(FEKSETUP). Pour plus d'informations, voir Configuration personnalisée. Vous pouvez modifier le fichier à l'aide de la commande TSO OEDIT.
Cette étape est requise uniquement si vous projetez d'utiliser la prise en charge de la génération JAVA/J2EE dans SCLM.
Apache Ant est un outil de génération Java Open Source qui peut être téléchargé à partir du site http://ant.apache.org/. Ant est constitué de fichiers texte et de scripts distribués au format ASCII, et qui requièrent donc l'exécution d'une conversion ASCII/EBCDIC dans z/OS UNIX.
Effectuez les étapes suivantes afin de mettre en oeuvre Ant sur z/OS et de le définir dans Developer for System z:
JAVA_HOME=/usr/lpp/java/IBM/J5.0
ANT_HOME=/usr/lpp/Apache/Ant/apache-ant-1.7.1
Par exemple :
Pour tester la réussite de l'initialisation d'Ant, procédez comme suit :
Exemple :
export PATH=/usr/lpp/Apache/Ant/apache-ant-1.7.1/bin:$PATH export PATH=/usr/lpp/java/IBM/J5.0/bin:$PATH
Exemple :
ant -version
SCLM requiert également que la personnalisation fonctionne avec SCLM Developer Toolkit. Pour plus d'informations sur les tâches de personnalisation requises, voir le document IBM Rational Developer for System z SCLM Developer Toolkit - Guide d'administration (SC11-6464) :
Pour effectuer des tâches de personnalisation et de définition de projet, l'administrateur SCLM doit connaître plusieurs valeurs personnalisables de Developer for System z, tel que décrit dans le tableau 13.
Description |
|
Valeur |
---|---|---|
Exemple de bibliothèque Developer for System z |
|
|
Exemple de répertoire Developer for System z |
|
|
Répertoire bin Java |
|
|
Répertoire bin Ant |
|
|
Répertoire initial WORKAREA |
|
|
Répertoire initial de configuration de projet SCLMDT |
|
|
Méthode d'accès VSAM de conversion de nom long/court |
|
SCLM Developer Toolkit et la passerelle client TSO/ISPF d'ISPF partagent le même répertoire WORKAREA, dans lequel il peut s'avérer utile de procéder à un nettoyage périodique. Voir (Facultatif) Nettoyage du répertoire WORKAREA pour de plus amples informations.
La présente section regroupe diverses tâches de personnalisation facultatives. Suivez les instructions de la section adéquate pour configurer le service souhaité.
Vous aurez besoin de l'aide d'un administrateur WLM et d'un administrateur DB2 pour effectuer ces tâches de personnalisation qui requièrent les ressources ou les tâches de personnalisation spécifiques suivantes :
|
Developer for System z propose un modèle de procédure mémorisée DB2 (compilateur de procédure mémorisée PL/I et COBOL) permettant de générer des procédures mémorisées COBOL et PL/I dans le client Developer for System z.
Au moyen des panneaux de gestion de charge de travail (WLM), associez un environnement d'application à la procédure JCL de l'espace adresse WLM du compilateur de procédures mémorisées PL/I et COBOL. Voir le document MVS Planning Workload Management (SA22-7602) pour de plus amples informations sur cette opération.
Personnalisez l'exemple de tâche de procédure mémorisée FEK.#CUST.PROCLIB(ELAXMSAM), comme décrit dans le membre, et copiez-le dans SYS1.PROCLIB. Comme indiqué dans l'exemple de code suivant, vous devez spécifier les éléments suivants :
//ELAXMSAM PROC RGN=0M, // NUMTCB=1, // APPLENV=#wlmwd4z, // DB2SSN=#ssn, // DB2PRFX='DSN810', // COBPRFX='IGY.V3R4M0', // PLIPRFX='IBMZ.V3R6M0', // LIBPRFX='CEE', // LODPRFX='FEK' //* //DSNX9WLM EXEC PGM=DSNX9WLM,REGION=&RGN,TIME=NOLIMIT,DYNAMNBR=10, // PARM='&DB2SSN,&NUMTCB,&APPLENV' //STEPLIB DD DISP=SHR,DSN=&DB2PRFX..SDSNEXIT // DD DISP=SHR,DSN=&DB2PRFX..SDSNLOAD // DD DISP=SHR,DSN=&LIBPRFX..SCEERUN // DD DISP=SHR,DSN=&COBPRFX..SIGYCOMP // DD DISP=SHR,DSN=&PLIPRFX..SIBMZCMP //SYSEXEC DD DISP=SHR,DSN=&LODPRFX..SFEKPROC //SYSTSPRT DD SYSOUT=* //CEEDUMP DD SYSOUT=* //SYSABEND DD DUMMY //SYSUT1 DD UNIT=SYSALLDA,SPACE=(CYL,(1,1)) //SYSUT2 DD UNIT=SYSALLDA,SPACE=(CYL,(1,1)) //SYSUT3 DD UNIT=SYSALLDA,SPACE=(CYL,(1,1)) //SYSUT4 DD UNIT=SYSALLDA,SPACE=(CYL,(1,1)) //SYSUT5 DD UNIT=SYSALLDA,SPACE=(CYL,(1,1)) //SYSUT6 DD UNIT=SYSALLDA,SPACE=(CYL,(1,1)) //SYSUT7 DD UNIT=SYSALLDA,SPACE=(CYL,(1,1)) //*
Personnalisez et soumettez l'exemple de membre ELAXMJCL du fichier FEK.#CUST.JCL afin de définir la procédure mémorisée sur DB2. Pour obtenir les instructions de personnalisation, consultez la documentation qui se trouve dans le membre.
//ELAXMJCL JOB <paramètres du travail> //JOBPROC JCLLIB ORDER=(#hlq.SDSNPROC) //JOBLIB DD DISP=SHR,DSN=#hlq.SDSNEXIT // DD DISP=SHR,DSN=#hlq.SDSNLOAD //* //RUNTIAD EXEC PGM=IKJEFT01,DYNAMNBR=20 //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * DSN S(#ssn) R(1) T(1) RUN PROGRAM(DSNTIAD) PLAN(DSNTIAD) - LIB('#hlq.RUNLIB.LOAD') //SYSPRINT DD SYSOUT=* //SYSIN DD * CREATE PROCEDURE SYSPROC.ELAXMREX ( IN FUNCTION_REQUEST VARCHAR(20) CCSID EBCDIC , IN SQL_ROUTINE_NAME VARCHAR(27) CCSID EBCDIC , IN SQL_ROUTINE_SOURCE VARCHAR(32672) CCSID EBCDIC , IN BIND_OPTIONS VARCHAR(1024) CCSID EBCDIC , IN COMPILE_OPTIONS VARCHAR(255) CCSID EBCDIC , IN PRECOMPILE_OPTIONS VARCHAR(255) CCSID EBCDIC , IN PRELINK_OPTIONS VARCHAR(32672) CCSID EBCDIC , IN LINK_OPTIONS VARCHAR(255) CCSID EBCDIC , IN ALTER_STATEMENT VARCHAR(32672) CCSID EBCDIC , IN SOURCE_DATASETNAME VARCHAR(80) CCSID EBCDIC , IN BUILDOWNER VARCHAR(8) CCSID EBCDIC , IN BUILDUTILITY VARCHAR(18) CCSID EBCDIC , OUT RETURN_VALUE VARCHAR(255) CCSID EBCDIC ) PARAMETER STYLE GENERAL RESULT SETS 1 LANGUAGE REXX EXTERNAL NAME ELAXMREX COLLID DSNREXCS WLM ENVIRONMENT ELAXMSAM PROGRAM TYPE MAIN MODIFIES SQL DATA STAY RESIDENT NO COMMIT ON RETURN NO ASUTIME NO LIMIT SECURITY USER; COMMENT ON PROCEDURE SYSPROC.ELAXMREX IS 'PLI & COBOL PROCEDURE PROCESSOR (ELAXMREX), INTERFACE LEVEL 0.01'; GRANT EXECUTE ON PROCEDURE SYSPROC.ELAXMREX TO PUBLIC; //*
Cette tâche de personnalisation ne requiert aucune aide, ressource ou tâche de personnalisation spécifique. |
Le client Developer for System z contient un composant de génération de code appelé Enterprise Service Tools (EST). Selon le type de code généré, ce code s'appuie sur les fonctions fournies par l'installation de l'hôte Developer for System z. Les sections suivantes expliquent comment rendre ces fonctions de l'hôte disponibles :
Vous aurez besoin de l'aide d'un administrateur CICS pour effectuer cette tâche de personnalisation qui requiert les ressources ou les tâches de personnalisation spécifiques suivantes :
|
Les composants de l'outil EST (Developer for System z Enterprise Service Tools) prennent en charge différents formats de messages d'interface en arabe et en hébreu, ainsi que la présentation et l'édition des données bidirectionnelles dans tous les éditeurs et dans toutes les vues. Dans les applications de terminal, les écrans de gauche à droite et de droite à gauche sont pris en charge, ainsi que les zones numériques et les zones orientées dans le sens contraire de l'écran.
Les fonctions et fonctionnalités bidirectionnelles supplémentaires comprennent notamment :
De plus, le code généré par EST peut prendre en charge la transformation bidirectionnelle dans d'autres environnements que SFR CICS (Service Flow Runtime). Les applications par lots en sont un exemple. Vous pouvez inclure dans les générateurs EST des appels de routines de conversion bidirectionnelle en spécifiant les options de transformation bidi appropriées dans les assistants de génération EST et en éditant des liens entre les programmes générés et la bibliothèque de conversion bidirectionnelle appropriée, FEK.SFEKLOAD.
Appliquez la procédure suivante pour activer la prise en charge de la langue bidirectionnelle CICS :
CEDA DEF PROG(FEJBDCMP) LANG(LE) G(xxx) CEDA DEF PROG(FEJBDTRX) LANG(LE) G(xxx)
Vous n'avez pas besoin d'aide pour effectuer cette tâche de personnalisation, mais des ressources ou tâches de personnalisation spéciales ci-dessous :
|
Le client Developer for System z contient un composant de génération de code appelé Enterprise Service Tools (EST). Pour que le code généré émette des messages d'erreur de diagnostic, tous les modules IRZ* et IIRZ* de la bibliothèque de charge FEK.SFEKLOAD doivent être mis à sa disposition. EST peut générer un code pour les environnements suivants :
Lorsque le code généré est exécuté dans une transaction CICS, ajoutez tous les modules IRZ* et IIRZ* de FEK.SFEKLOAD dans la définition de données DFHRPL de la région CICS. Pour ce faire , il est recommandé d'ajouter le fichier d'installation à la concaténation pour que l'opération de maintenance appliquée soit automatiquement disponible dans CICS.
Dans toutes les autres situations, mettez à disposition tous les modules IRZ* et IIRZ* de FEK.SFEKLOAD par l'intermédiaire de STEPLIB ou de LINKLIST. Pour ce faire , il est recommandé d'ajouter le fichier d'installation à la concaténation pour que l'opération de maintenance appliquée soit automatiquement disponible dans CICS.
Si vous décidez d'utiliser STEPLIB, vous devez définir les modules non disponibles via LINKLIST dans la directive STEPLIB de la tâche qui exécute le code.
Si les modules de chargement ne sont pas disponibles et que le code généré rencontre une erreur, le message suivant s'affiche :
IRZ9999S L'extraction du texte d'un message d'exécution Language Environment a échoué. Vérifiez que le module de messages d'exécution Language Environment pour la fonction IRZ est installé dans DFHRPL ou STEPLIB.
Vous aurez besoin de l'aide d'un administrateur de sécurité pour effectuer cette tâche de personnalisation, qui requiert les tâches de personnalisation spéciales ou les ressources suivantes :
|
Les communications externes (client-hôte) peuvent être chiffrées à l'aide de SSL (Secure Socket Layer). Cette fonction est désactivée par défaut et est contrôlée par les paramètres du fichier ssl.properties.
Le fichier ssl.properties se trouve dans /etc/rdz/, sauf si vous avez indiqué un emplacement différent lorsque vous avez personnalisé et soumis le travail FEK.SFEKSAMP(FEKSETUP). Pour plus d'informations, voir Configuration personnalisée. Vous pouvez modifier le fichier à l'aide de la commande TSO OEDIT. Notez que RSE doit être redémarré pour que les modifications prennent effet.
Le client communique avec le démon RSE pendant la configuration de la connexion et avec le serveur RSE pendant la session réelle. Les deux flux de données sont chiffrés lorsque SSL est activé.
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 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 |
Le démon RSE utilise les fonctions System SSL pour gérer 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.
L'exemple de code suivant présente le fichier ssl.properties qui doit être personnalisé en fonction de votre environnement système. Les lignes mises en commentaire commencent par un signe dièse (#) lorsque vous utilisez une page de codes US. Les lignes de données ne peuvent comporter qu'une directive et la valeur associée. Les commentaires ne sont pas autorisés sur la même ligne. La continuation de ligne n'est pas prise en charge.
# ssl.properties - fichier de configuration SSL enable_ssl=false # Daemon Properties #daemon_keydb_file= #daemon_keydb_password= #daemon_key_label= # Server Properties #server_keystore_file= #server_keystore_password= #server_keystore_label= #server_keystore_type=JCERACFKS
Les propriétés du serveur et du démon doivent être configurées uniquement si vous activez la couche SSL. Pour plus d'informations sur la configuration de SSL, voir l'Annexe A. Configuration de l'authentification SSL et X.509.
Mot clé | Type de fichier de clés |
---|---|
JKS | Fichier de clés Java |
JCERACFKS | Fichier de clés conforme à SAF, où la clé privé du certificat est stockée dans la base de données de sécurité. |
JCECCARACFKS | Fichier de clés conforme à SAF dans lequel la clé privée du certificat est stockée à l'aide d'ICSF, l'interface du matériel de chiffrement de System z. |
security.provider.1=com.ibm.crypto.hdwrCCA.provider.IBMJCECCA
Le fichier de résultats doit ressembler à ce qui suit :
security.provider.1=com.ibm.crypto.hdwrCCA.provider.IBMJCECCA security.provider.2=com.ibm.jsse2.IBMJSSEProvider2 security.provider.3=com.ibm.crypto.provider.IBMJCE security.provider.4=com.ibm.security.jgss.IBMJGSSProvider security.provider.5=com.ibm.security.cert.IBMCertPath security.provider.6=com.ibm.security.sasl.IBMSASL
Cette tâche de personnalisation ne requiert aucune aide, ressource ou tâche de personnalisation spécifique. |
Developer for System z prend en charge différents niveaux de trace du flux de programme interne à des fins de résolution des incidents. RSE et certains des services appelés par RSE, utilisent les paramètres du fichier rsecomm.properties pour obtenir le niveau de détails voulu dans les fichiers journaux de sortie.
Avertissement : La modification de ces paramètres réduit les performances et ne
doit être effectuée que sur indication du centre de support
IBM. |
Le fichier rsecomm.properties se trouve dans /etc/rdz/, sauf si vous avez indiqué un emplacement différent lorsque vous avez personnalisé et soumis le travail FEK.SFEKSAMP(FEKSETUP). Pour plus d'informations, voir Configuration personnalisée. Vous pouvez modifier le fichier à l'aide de la commande TSO OEDIT.
L'exemple de code suivant illustre le fichier rsecomm.properties qui peut être personnalisé pour répondre à vos besoins de traçage. Les lignes de commentaire commencent par un signe dièse (#) lorsque vous utilisez une page de codes US. Les lignes de données ne peuvent comporter qu'une directive et la valeur associée. Les commentaires ne sont pas autorisés sur la même ligne. La continuation de ligne n'est pas prise en charge.
# server.version - DO NOT MODIFY! server.version=5.0.0 # Logging level # 0 - Log error messages # 1 - Log error and warning messages # 2 - Log error, warning and info messages debug_level=1 # Log location # Log_To_StdOut # Log_To_File log_location=Log_To_File
Les valeurs acceptées sont les suivantes :
0 | Messages d'erreurs de consignation uniquement. |
1 | Messages d'erreurs de consignation et d'avertissement. |
2 | Messages d'erreurs de consignation, d'avertissement et d'information. |
Les valeurs acceptées sont les suivantes :
Log_To_File | Envoie les messages de consignation dans un fichier distinct du répertoire de sortie de la consignation.
|
Log_To_StdOut | Envoie les messages de consignation à stdout.
|
daemonlog est la valeur de la directive daemon.log dans rsed.envvars. Si la directive daemon.log est mise en commentaire ou omise, le chemin du répertoire de base de l'ID utilisateur affecté à la tâche démarrée RSED est utilisé. Le chemin du répertoire de base est défini dans le segment de sécurité OMVS de l'ID utilisateur.
Les journaux propres à l'utilisateur sont placés dans userlog/.eclipse/RSE/$LOGNAME, où userlog est la valeur de la directive user.log 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.
Cette tâche de personnalisation ne requiert aucune aide, ressource ou tâche de personnalisation spécifique. |
Les clients Developer for System z peuvent définir des groupes de propriétés qui contiennent des valeurs par défaut pour diverses propriétés (par exemple, les options de compilation COBOL à utiliser lorsque vous compilez le code source COBOL). Certaines valeurs par défaut sont intégrées à Developer for System z, mais il est également possible de définir des valeurs par défaut personnalisées spécifiques au système.
L'emplacement du groupe de propriétés personnalisé et des fichiers de configuration de valeur par défaut est défini dans propertiescfg.properties, qui se trouve dans /etc/rdz/, sauf si vous avez indiqué un emplacement différent lorsque vous avez personnalisé et soumis le travail FEK.SFEKSAMP(FEKSETUP). Pour plus d'informations, voir Configuration personnalisée. Vous pouvez modifier le fichier à l'aide de la commande TSO OEDIT. Notez que RSE doit être redémarré pour que les modifications prennent effet.
L'exemple de code suivant illustre le fichier propertiescfg.properties qui doit être personnalisé pour correspondre à votre environnement système. Les lignes mises en commentaire commencent par un signe dièse (#) lorsque vous utilisez une page de codes US. Les lignes de données ne peuvent comporter qu'une directive et la valeur associée. Les commentaires ne sont pas autorisés sur la même ligne. La continuation de ligne n'est pas prise en charge.
# # host based property groups - root configuration file # ENABLED=FALSE RDZ-VERSION=7.5.0.0 PROPERTY-GROUP=/var/rdz/properties DEFAULT-VALUES=/var/rdz/properties
Pour plus d'informations sur la création du fichier de configuration des groupes de propriétés (propertygroups.xml) et du fichier de configuration des valeurs par défaut (defaultvalues.xml), voir le centre de documentation de Developer for System z (http://publib.boulder.ibm.com/infocenter/ratdevz/v7r6/index.jsp).
Cette tâche de personnalisation ne requiert aucune aide, ressource ou tâche de personnalisation spécifique. |
Vous pouvez définir des projets z/OS individuellement via la perspective Projets z/OS du client ou de manière centrale sur l'hôte et les envoyer au client sur une base 'Par utilisateur'. Ces "projets basés sur l'hôte" ressemblent et fonctionnent exactement comme des projets définis sur le client, sauf que leurs structure, membres et propriétés ne sont pas modifiables par le client et qu'ils sont accessibles uniquement lorsque ce dernier est connecté à l'hôte.
L'emplacement des définitions de projet est défini dans le fichier projectcfg.properties qui se trouve dans /etc/rdz/, sauf si vous avez indiqué un emplacement différent lorsque vous avez personnalisé et soumis le travail FEK.SFEKSAMP(FEKSETUP). Pour plus d'informations, voir Configuration personnalisée. Vous pouvez modifier le fichier à l'aide de la commande TSO OEDIT. Notez que RSE doit être redémarré pour que les modifications prennent effet.
L'exemple de code suivant illustre le fichier projectcfg.properties qui doit être personnalisé pour correspondre à votre environnement système. Les lignes mises en commentaire commencent par un signe dièse (#) lorsque vous utilisez une page de codes US. Les lignes de données ne peuvent comporter qu'une directive et la valeur associée. Les commentaires ne sont pas autorisés sur la même ligne. La continuation de ligne n'est pas prise en charge.
# # host based projects - root configuration file # # WSED-VERSION - do not modify ! WSED-VERSION=7.0.0.0 # specify the location of the host based project definition files PROJECT-HOME=/var/rdz/projects
Pour plus d'informations sur les projets basés sur l'hôte, voir le centre de documentation de Developer for System z (http://publib.boulder.ibm.com/infocenter/ratdevz/v7r6/index.jsp).
Vous aurez besoin de l'aide d'un administrateur de la sécurité pour effectuer cette tâche de personnalisation qui requiert les ressources ou les tâches de personnalisation spécifiques suivantes :
|
Developer for System z prend en charge l'accès direct du client à un ensemble limité de fonctions d'IBM File Manager for z/OS. IBM File Manager for z/OS met à disposition des outils pour travailler avec les fichiers MVS, les fichiers z/OS UNIX, les données DB2, IMS et CICS. Ces outils comportent les fonctionnalités habituelles de navigation, d'édition, de copie et d'impression que l'on trouve dans ISPF, améliorées afin de répondre aux besoins des développeurs d'applications. Dans la version en cours de Developer for System z, prend uniquement en charge la visualisation et l'édition des fichiers MVS (y compris tous les types de VSAM), la création et l'édition des modèles de fichiers MVS (dont les modèles dynamiques), ainsi que les utilitaires de copie avancée.
Notez que le produit IBM File Manager for z/OS doit être commandé, installé et configuré séparément. Voir le document Rational Developer for System z Prerequisites (SC23-7659) pour connaître le niveau de File Manager requis pour votre version de Developer for System z. L'installation et la personnalisation de ce produit ne sont pas décrites dans le présent ouvrage.
Notez que Developer for System z et File Manager ne prennent plus en charge l'interface de traitement par lots pour accéder aux services de File Manager. Il est désormais obligatoire d'utiliser le programme d'écoute de File Manager.
Les définitions File Manager Integration requises par Developer for System z sont stockées dans le fichier FMIEXT.properties disponible dans /etc/rdz/, sauf si vous avez indiqué un emplacement différent lorsque vous avez personnalisé et soumis le travail FEK.SFEKSAMP(FEKSETUP). Pour plus d'informations, voir Configuration personnalisée. Vous pouvez modifier le fichier à l'aide de la commande TSO OEDIT. Notez que RSE doit être redémarré pour que les modifications prennent effet.
L'exemple de code suivant illustre le fichier FMIEXT.properties qui doit être personnalisé pour correspondre à votre environnement système. Les lignes mises en commentaire commencent par un signe dièse (#) lorsque vous utilisez une page de codes US. Les lignes de données ne peuvent comporter qu'une directive et la valeur associée. Les commentaires ne sont pas autorisés sur la même ligne. La continuation de ligne n'est pas prise en charge.
# File Manager Integration (FMI) Extension properties # enabled=false fmlistenport=1960
Cette tâche de personnalisation ne requiert aucune aide, ressource ou tâche de personnalisation spécifique. |
Certains caractères ne sont pas convertis correctement entre les pages de codes hôte (EBCDIC) et les pages de codes client (ASCII). L'éditeur client Developer for System z utilise les définitions du fichier uchars.settings afin d'identifier ces caractères non éditables. Lors de l'ouverture d'un fichier avec un caractère identifié dans uchars.settings, l'éditeur impose le mode lecture seule, pour éviter la corruption du fichier lors de sa sauvegarde.
Le fichier uchars.settings se trouve dans /etc/rdz/, sauf si vous avez indiqué un emplacement différent lorsque vous avez personnalisé et soumis le travail FEK.SFEKSAMP(FEKSETUP). Pour plus d'informations, voir Configuration personnalisée. Vous pouvez modifier le fichier à l'aide de la commande TSO OEDIT. Notez que RSE doit être redémarré pour que les modifications prennent effet. Il est recommandé de ne pas modifier ce fichier à moins d'y être invité par le centre de service technique IBM.
# uchars.settings - uneditable code points # * * 0D 15 25; # DBCS (Japonais, Coréen & Chinois) IBM-930 * 0D 15 1E 1F 25; IBM-933 * 0D 15 1E 1F 25; IBM-935 * 0D 15 1E 1F 25; IBM-937 * 0D 15 1E 1F 25; IBM-939 * 0D 15 1E 1F 25; IBM-1390 * 0D 15 1E 1F 25; IBM-1399 * 0D 15 1E 1F 25; IBM-1364 * 0D 15 1E 1F 25; IBM-1371 * 0D 15 1E 1F 25; IBM-1388 * 0D 15 1E 1F 25; # UNICODE UTF-8 * 0D 0A; UTF-16BE * 0D 0A; UTF-16LE * 0D 0A; UTF-16 * 0D 0A;
Le fichier se compose de plusieurs entrées au format suivant :
HOST-CODEPAGE LOCAL-CODEPAGE HEX-CODEPOINTS ;
HEX-CODEPOINTS représente une liste de points de code hexadécimaux à deux chiffres et séparés par des espaces vides qui identifient les caractères non éditables. Cette liste s'achève par un point-virgule (;).
Les règles de syntaxe suivantes s'appliquent :
Cette tâche de personnalisation ne requiert aucune aide, ressource ou tâche de personnalisation spécifique. |
REXEC (exécution à distance) est un service TCP/IP qui permet aux clients d'exécuter une commande sur l'hôte. SSH (interpréteur de commandes sécurisé) est un service similaire mais toutes les communications sont chiffrées à l'aide de la couche SSL (Secure Socket Layer). Developer for System z utilise l'un de ces services pour effectuer des actions à distance (basées sur l'hôte) dans des sous-projets z/OS UNIX.
Developer for System z peut également être configuré pour utiliser REXEC (ou SSH) afin de démarrer un serveur RSE sur l'hôte. Notez toutefois, que chaque connexion lancée à l'aide de ce procédé entraînera le démarrage d'un autre serveur RSE, chaque serveur utilisant un nombre considérable de ressources système. Aussi, cette méthode de connexion alternative est uniquement viable pour un petit nombre de connexions.
En outre, l'autre méthode de connexion REXEC (ou SSH) ignorant le démon RSE, elle n'a pas accès à tous les services hôte décrits dans le présent document (l'audit et le traitement d'un seul serveur, par exemple). Contactez le service de support technique IBM pour savoir si un service hôte spécifique est pris en charge par la méthode de connexion alternative REXEC.
Les actions à distance (basées sur l'hôte) pour les sous-projets z/OS UNIX nécessitent que REXEC ou SSH soit actif sur l'hôte. Si REXEC/SSH n'est pas configuré pour utiliser le port par défaut, le client de Developer for System z doit définir le port correct à utiliser avec les sous-projets z/OS UNIX. Pour cela, sélectionnez la page de préférences Fenêtre > Préférences... > Solutions z/OS > Sous-projets USS > Options d'action distante. Voir Configuration de REXEC (ou SSH) pour connaître le port utilisé.
Les clients Developer for System z doivent connaître les deux valeurs suivantes pour démarrer une connexion RSE via REXEC (ou SSH) :
Le script server.zseries se trouve dans /etc/rdz/, sauf si vous avez indiqué un emplacement différent lorsque vous avez personnalisé et soumis le travail FEK.SFEKSAMP(FEKSETUP). Pour plus d'informations, voir Configuration personnalisée.
cp /usr/lpp/rdz/bin/server.zseries /etc/rdz
Voir Configuration de REXEC (ou SSH) pour connaître le port utilisé.
Le document Communications Server IP Configuration Guide (SC31-8775) décrit les étapes à suivre pour configurer REXEC (ou SSH). Voir Annexe C. Configuration d'INETD pour connaître les remarques de configuration spécifiques de Developer for System z (il n'y a pas d'étape de configuration spécifique pour Developer for System z).
Le port généralement utilisé par REXEC est le 512. Pour vérifier, vous pouvez contrôler /etc/inetd.conf et /etc/services afin de trouver le numéro de port utilisé.
exec stream tcp nowait OMVSKERN /usr/sbin/orexecd rexecd -LV
exec 512/tcp #REXEC Command Server
Le même principe s'applique à SSH. Le port qu'il utilise généralement est le 22 et le nom du serveur est sshd.
Vous aurez besoin de l'aide d'un administrateur APPC et d'un administrateur WLM pour effectuer cette tâche de personnalisation, qui requiert les tâches de personnalisation spéciales ou les ressources suivantes :
|
Le service Commandes TSO peut être mis en oeuvre comme un programme transactionnel APPC, FEKFRSRV. Cette transaction fait office de serveur hôte pour l'exécution des commandes TSO et ISPF soumises à partir du poste de travail. Il n'est pas nécessaire d'installer APPC sur le poste de travail, car le client communique avec FEKFRSRV via RSE. Chaque client peut disposer d'une connexion active à plusieurs hôtes simultanément.
/* REXX -- Administration APPC utilisant les panneaux ISPF */ address ISPEXEC "LIBDEF ISPMLIB DATASET ID('ICQ.ICQMLIB') STACK" "LIBDEF ISPPLIB DATASET ID('ICQ.ICQPLIB') STACK" "LIBDEF ISPSLIB DATASET ID('ICQ.ICQSLIB') STACK" "LIBDEF ISPTLIB DATASET ID('ICQ.ICQTLIB') STACK" address TSO "ALTLIB ACT APPLICATION(CLIST)", "DSN('ICQ.ICQCCLIB') UNCOND QUIET" "SELECT CMD(%ICQASRM0) NEWAPPL(ICQ) PASSLIB" address TSO "ALTLIB DEACT APPLICATION(CLIST) QUIET" "LIBDEF ISPMLIB" "LIBDEF ISPPLIB" "LIBDEF ISPSLIB" "LIBDEF ISPTLIB" exit
Compétences | Information obligatoire :
|
Valeur |
---|---|---|
APPC | Nom de fichier de TPDATA
|
|
APPC | Nom de transaction à utiliser (peut ne pas exister)
|
|
APPC | Classe de transaction APPC à utiliser
|
|
WLM/SRM | Domaine et groupe de performances TSO
|
|
RACF | Chaque utilisateur de
Developer for System z dispose d'un accès à un
segment OMVS (obligatoire).
|
|
RACF | Chaque utilisateur de
Developer for System z doit disposer de droits
d'accès READ à hlq.SFEKPROC(FEKFRSRV)
|
Voir le document MVS Planning Workload Management (SA22-7602) pour de plus amples informations sur la gestion WLM/SRM. Pour plus d'informations sur les segments OMVS et les profils de protection des fichiers, voir le document Security Server RACF Security Administrator's Guide (SA22-7683).
CLASSADD CLASSNAME(A) MAX(20) MIN(1) MSGLIMIT(200)
Vous pouvez tester la configuration TCP/IP en démarrant le démon RSE à l'aide du paramètre IVP=IVP ou du programme de vérification de l'installation fekfivpt, comme indiqué dans Vérification de l'installation.
Cette tâche de personnalisation ne requiert aucune aide, ressource ou tâche de personnalisation spécifique. |
La passerelle client TSO/ISPF d'ISPF et la fonction SCLM Developer Toolkit utilisent le répertoire WORKAREA pour stocker des fichiers de travail temporaires qui sont supprimés avant la fermeture de la session. Cependant, la sortie temporaire est parfois conservée, par exemple, en cas d'erreur de communication en cours de traitement. C'est la raison pour laquelle il est recommandé de nettoyer régulièrement le répertoire WORKAREA.
z/OS UNIX fournit un script de shell, skulker, qui supprime les fichiers en fonction du répertoire dans lequel ils se trouvent et de leur durée de vie. A l'aide du démon cron z/OS UNIX qui exécute les commandes à des dates et heures données, vous pouvez configurer un outil automatisé qui nettoie régulièrement le répertoire WORKAREA. Voir le document UNIX System Services Command Reference (SA22-7802) pour plus d'informations relatives au script skulker et au démon cron.
Une fois que vous avez terminé la personnalisation du produit, vous pouvez utiliser les programmes de vérification de l'installation décrits dans ce chapitre pour vérifier que l'installation des principaux composants du produit a abouti.
Lancez la tâche démarrée JMON (ou le travail utilisateur). Les informations de démarrage de la définition de données STDOUT doivent se terminer par le message suivant :
JM200I Server initialization complete.
Si le travail s'arrête avec un code retour 66, cela signifie que l'APF n'autorise pas FEK.SFEKAUTH.
Lancez la tâche démarrée LOCKD (ou le travail utilisateur). Le démon lock émet le message de console suivant si le démarrage a abouti :
FEK501I Lock daemon started, port=4036, cleanup interval=1440, log level=1
Lancez la tâche démarrée RSED (ou le travail utilisateur) avec le paramètre IVP=IVP. Avec ce paramètre, le serveur s'interrompra après avoir effectué certains tests de vérification de l'installation. Les résultats de ces tests sont disponibles dans DD STDOUT. Si des erreurs sont survenues, les données seront également disponibles dans DD STDERR. Les données STDOUT doivent ressembler à l'exemple suivant :
FEK002I RseDaemon started. (port=4035)
Test IVP du démon RSE Wed Jul 2 17:11:52 2008 UTC uid=8(STCRSE) gid=1(STCGROUP) RSE daemon port is 4035 RSE configuration files located in /etc/rdz ------------------------------------------------------------- current environment variables ------------------------------------------------------------- @="/usr/lpp/rdz/bin/rsed.sh" @[1]="4035" @[2]="/etc/rdz" CGI_DTCONF="/var/rdz/sclmdt" CGI_DTWORK="/var/rdz" CGI_TRANTABLE="FEK.#CUST.LSTRANS.FILE" CLASSPATH=".:/usr/lpp/rdz/lib:/usr/lpp/rdz/lib/dstore_core.jar:/usr/lpp/ ERRNO="0" HOME="/tmp" IFS=" " JAVA_HOME="/usr/lpp/java/J5.0" JAVA_PROPAGATE="NO" LANG="C" LIBPATH=".:/usr/lib:/usr/lpp/java/J5.0/bin:/usr/lpp/java/J5.0/bin/classi LINENO="66" LOGNAME="STCRSE" MAILCHECK="600" OLDPWD="/tmp" OPTIND="1" PATH=".:/usr/lpp/java/J5.0/bin:/usr/lpp/rdz/bin:/usr/lpp/ispf/bin:/bin:/ PPID="33554711" PS1="\$ " PS2="> " PS3="#? " PS4="+ " PWD="/etc/rdz" RANDOM="27298" RSE_CFG="/etc/rdz" RSE_HOME="/usr/lpp/rdz" RSE_LIB="/usr/lpp/rdz/lib" SECONDS="0" SHELL="/bin/sh" STEPLIB="NONE" TZ="EST5EDT" _BPX_SHAREAS="YES" _BPX_SPAWN_SCRIPT="YES" _CEE_DMPTARG="/tmp" _CEE_RUNOPTS="ALL31(ON) HEAP(32M,32K,ANYWHERE,KEEP,,) TRAP(ON)" _CMDSERV_BASE_HOME="/usr/lpp/ispf" _CMDSERV_CONF_HOME="/etc/rdz" _CMDSERV_WORK_HOME="/var/rdz" _RSE_CMDSERV_OPTS="&SESSION=SPAWN" _RSE_DAEMON_CLASS="com.ibm.etools.zos.server.RseDaemon" _RSE_DAEMON_IVP_TEST="1" _RSE_DAEMON_PORT="4035" _RSE_JAVAOPTS=" -DISPF_OPTS='&SESSION=SPAWN' -DA_PLUGIN_PATH=/usr/lpp/rd _RSE_POOL_SERVER_CLASS="com.ibm.etools.zos.server.ThreadPoolProcess" _RSE_PWD="/tmp" _RSE_SERVER_CLASS="org.eclipse.dstore.core.server.Server" _RSE_SERVER_TIMEOUT="120000" _SCLMDT_BASE_HOME="/usr/lpp/rdz" _SCLMDT_CONF_HOME="/var/rdz/sclmdt" _SCLMDT_TRANTABLE="FEK.#CUST.LSTRANS.FILE" _SCLMDT_WORK_HOME="/var/rdz" _SCLM_BASE="/var/rdz/WORKAREA" _SCLM_BWBCALL="/usr/lpp/rdz/bin/BWBCALL" _SCLM_DWGET="/var/rdz/WORKAREA" _SCLM_DWTRANSFER="/var/rdz/WORKAREA" _SCLM_J2EEPUT="/var/rdz/WORKAREA" ------------------------------------------------------------- java startup test... ------------------------------------------------------------- java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pmz31dev-2008031 IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 z/OS s390-31 j9vmmz3123-2008 J9VM - 20080314_17962_bHdSMr JIT - 20080130_0718ifx2_r8 GC - 200802_08) JCL - 20080314 ------------------------------------------------------------- TCP/IP IVP test... ------------------------------------------------------------- Wed Jul 2 13:11:54 EDT 2008 uid=8(STCRSE) gid=1(STCGROUP) 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 = STCRSE 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 ------------------------------------------------------------- PassTicket IVP test... ------------------------------------------------------------- Success, PassTicket IVP finished normally ------------------------------------------------------------- IVP du démon RSE terminé
L'installation de Developer for System z met à disposition plusieurs programmes de vérification de l'installation (IVP) pour les services de base et facultatifs. Les scripts IVP se trouvent dans le répertoire d'installation, /usr/lpp/rdz/bin/ par défaut.
Les tâches décrites ci-dessous nécessitent des actions de votre part dans le système z/OS UNIX. Vous pouvez les effectuer en lançant la commande TSO OMVS. Utilisez la commande exit pour retourner à TSO.
Une taille de région importante est nécessaire pour l'ID utilisateur qui exécute les IVP, car les fonctions telles que Java, qui demandent beaucoup de mémoire, vont être exécutées. Il est recommandé d'attribuer au moins 131072 octets (128 mégaogtets) ou plus à la taille de région.
L'exemple d'erreur suivant est une indication précise d'une taille de région insuffisante (mais d'autres erreurs peuvent également se produire. Par exemple, Java peut ne pas démarrer).
CEE5213S The signal SIGPIPE was received. %z/OS UNIX command%: command was killed by signal number 13 %line-number% *-* %REXX command% +++ RC(137) +++
Tous les exemples de commandes de la présente section sous-entendent que les variables de l'environnement sont configurées. De cette manière, les scripts IVP sont disponibles par l'intermédiaire de l'instruction PATH, et l'emplacement des fichiers de configuration personnalisés est connu. Utilisez les commandes pwd et cd pour vérifier votre répertoire de travail, et en changer pour le répertoire qui contient les fichiers de configuration personnalisés. Le script de shell ivpinit peut alors être utilisé pour configurer les variables d'environnement RSE, comme dans l'exemple ci-après ($ est l'invite UNIX z/OS) :
$ pwd /u/userid $ cd /etc/rdz $ . ./ivpinit RSE configuration files located in /etc/rdz --default ont ajouté /usr/lpp/rdz/bin dans PATH
Le premier "." (point) dans . ./ivpinit est une commande z/OS UNIX qui permet d'exécuter le shell dans l'environnement en cours afin que les variables d'environnement définies dans le shell soient effectives même après la sortie du shell. Le second fait référence au répertoire de travail.
/usr/lpp/rdz/bin/fekfivpr 512 USERIDLa plupart des scripts fekfivp* demanderont également l'emplacement du rsed.envvars personnalisé si ./ivpinit n'est pas exécuté en premier.
$ EXPORT STEPLIB=$STEPLIB:TCPIP.SEZALOAD
Notez que l'ajout d'une bibliothèque non autorisée par APF dans un STEPLIB existant entraîne la suppression de l'autorisation APF pour les fichiers STEPLIB existants.
De même, si CEE.SCEELKED se trouve dans LINKLIST ou STEPLIB, TCPIP.SEZALOAD doit être placé avant CEE.SCEELKED. Tout manquement à cette règle entraîne une fin anormale du système 0C1 pour les appels de prise TCP/IP REXX.
Pour plus d'informations concernant le diagnostic des incidents de connexion RSE, voir Identification des incidents liés à la configuration ou la page relative aux notes techniques de Developer for System z (http://www-306.ibm.com/software/awdtools/rdz/support/).
La disponibilité des ports du moniteur de travaux JES, du démon RSE et éventuellement de REXEC et/ou SSH peut être vérifiée en exécutant la commande netstat . Le résultat doit présenter les ports utilisés par ces services, comme dans les exemples ci-dessous ($ est l'invite de z/OS UNIX) :
IPv4
$ netstat MVS TCP/IP NETSTAT CS VxRy TCPIP Name: TCPIP 13:57:36 User Id Conn Local Socket Foreign Socket State ------- ---- ------------ -------------- ----- RSED 0000004B 0.0.0.0..4035 0.0.0.0..0 Listen LOCKD 0000004C 0.0.0.0..4036 0.0.0.0..0 Listen JMON 00000037 0.0.0.0..6715 0.0.0.0..0 Listen
IPv6
$ netstat MVS TCP/IP NETSTAT CS VxRy TCPIP Name: TCPIP 14:03:35 User Id Conn State ------- ---- ----- RSED 0000004B Listen Local Socket: 0.0.0.0..4035 Foreign Socket: 0.0.0.0..0 LOCKD 0000004C Listen Local Socket: 0.0.0.0..4036 Foreign Socket: 0.0.0.0..0 JMON 00000037 Listen Local Socket: 0.0.0.0..6715 Foreign Socket: 0.0.0.0..0
Lorsque vous utilisez APPC pour le service Commandes TSO, Developer for System z dépend de la validité du nom d'hôte du TCP/IP quand il est initialisé. Cela implique que les différents fichiers de configuration du TCP/IP et du programme de résolution Resolver soient configurés correctement. Voir l'Annexe B. Configuration de TCP/IP pour de plus amples informations sur la configuration de TCP/IP et du programme de résolution. Vérifiez les paramètres actuels en exécutant la commande suivante :
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 current address space size limit is 1914675200 (1826.0 MB) maximum address space size limit is 2147483647 (2048.0 MB) ------------------------------------------------------------- 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
Testez la connexion du démon RSE en exécutant la commande ci-dessous. Remplacez 4035 par le port utilisé par le démon RSE et USERID par un ID utilisateur valide.
fekfivpd 4035 USERID
Après vous avoir demandé un mot de passe, la commande doit renvoyer un résultat semblable à celui de cet exemple ($ est l'invite z/OS UNIX) :
$ fekfivpd 4035 USERID Wed Jul 2 15:00:27 EDT 2008 uid=1(USERID) gid=0(GROUP) using /etc/rdz/rsed.envvars current address space size limit is 1914675200 (1826.0 MB) maximum address space size limit is 2147483647 (2048.0 MB) Password: SSL is disabled connected 8108 570655399 Success
Testez la connexion du moniteur de travaux JES en exécutant la commande ci-dessous. Remplacez 6715 par le numéro de port du moniteur de travaux JES.
fekfivpj 6715
La commande doit renvoyer l'accusé de réception du moniteur de travaux JES, comme dans l'exemple ci-dessous ($ est l'invite de z/OS UNIX) :
$ fekfivpj 6715 Wed Jul 2 15:00:27 EDT 2008 uid=1(USERID) gid=0(GROUP) using /etc/rdz/rsed.envvars current address space size limit is 1914675200 (1826.0 MB) maximum address space size limit is 2147483647 (2048.0 MB) hostName=CDFMVS08 hostAddr=9.42.112.75 Waiting for JES Job Monitor response... ACKNOWLEDGE01v03 Success
Vérifiez la connexion du démon lock en exécutant la commande ci-dessous.
fekfivpl
La commande doit renvoyer un résultat comparable à celui de l'exemple ci-dessous ($ correspond à l'invite z/OS UNIX) :
$ fekfivpl Mon Jun 29 08:00:38 EDT 2009 uid=1(USERID) gid=0(GROUP) using /etc/rdz/rsed.envvars current address space size limit is 1914675200 (1826.0 MB) maximum address space size limit is 2147483647 (2048.0 MB) hostName=CDFMVS08 hostAddr=9.42.112.75 Registering user to Lock Daemon... Waiting for Lock Daemon response... Querying to Lock Daemon... Waiting for Lock Daemon response... USERID Unregistering user from Lock Daemon... Waiting for Lock Daemon response... Querying to Lock Daemon... Waiting for Lock Daemon response... Success
Vérifiez la connexion de la passerelle client TSO/ISPF d'ISPF en exécutant la commande suivante :
fekfivpi
La commande doit renvoyer le résultat des vérifications relatives à la passerelle client TSO/ISPF d'ISPF (variables, modules HFS, démarrage et arrêt de la session TSO/ISPF), comme celui de l'exemple ci-dessous ($ représente l'invite z/OS UNIX) :
$ fekfivpi Wed Jul 2 15:00:27 EDT 2008 uid=1(USERID) gid=0(GROUP) using /etc/rdz/rsed.envvars current address space size limit is 1914675200 (1826.0 MB) maximum address space size limit is 2147483647 (2048.0 MB) ------------------------------------------------------------- /etc/rdz/ISPF.conf content: ------------------------------------------------------------- ispmlib=ISP.SISPMENU isptlib=ISP.SISPTENU ispplib=ISP.SISPPENU ispslib=ISP.SISPSLIB sysproc=ISP.SISPCLIB,FEK.SFEKPROC ------------------------------------------------------------- Host install verification for RSE Review IVP log messages from HOST below : ------------------------------------------------------------- RSE connection and base TSO/ISPF session initialization check only *** CHECK : ENVIRONMENT VARIABLES - key variables displayed below : Server PATH = /usr/lpp/java/J5.0/bin:/usr/lpp/rdz/lib:/usr/lpp/ispf/bin: /bin:/usr/sbin:. STEPLIB = FEK.SFEKAUTH:FEK.SFEKLOAD _CMDSERV_BASE_HOME = /usr/lpp/ispf _CMDSERV_CONF_HOME = /etc/rdz _CMDSERV_WORK_HOME = /var/rdz ------------------------------------------------------------- *** CHECK : USS MODULES Checking ISPF Directory : /usr/lpp/ispf Checking modules in /usr/lpp/ispf/bin directory Checking for ISPF configuration file ISPF.conf RC=0 MSG: SUCCESSFUL ------------------------------------------------------------- *** CHECK : TSO/ISPF INITIALIZATION ( TSO/ISPF session will be initialized ) RC=0 MSG: SUCCESSFUL ------------------------------------------------------------- *** CHECK: Shutting down TSO/ISPF IVP session RC=0 MSG: SUCCESSFUL ------------------------------------------------------------- Host installation verification completed successfully -------------------------------------------------------------
fekfivpi présente plusieurs paramètres facultatifs ne dépendant pas de la position :
Testez la connexion au serveur Commandes TSO (en utilisant APPC) en exécutant la commande ci-dessous. Remplacez USERID par un ID utilisateur valide :
fekfivpa USERID
Après vous avoir demandé un mot de passe, la commande doit renvoyer la conversation APPC, comme celle de l'exemple ci-dessous ($ est l'invite de z/OS UNIX) :
$ fekfivpa USERID Enter password: Wed Jul 2 15:00:27 EDT 2008 uid=1(USERID) gid=0(GROUP) using /etc/rdz/rsed.envvars current address space size limit is 1914675200 (1826.0 MB) maximum address space size limit is 2147483647 (2048.0 MB) 20070607 13:57:18.584060 /usr/lpp/rdz/bin/fekfscmd: version=Oct 2003 20070607 13:57:18.584326 Input parms: 1.2.3.4 * NOTRACE USERID ******** 20070607 13:57:18.586800 APPC: Allocate succeeded 20070607 13:57:18.587022 Conversation id is 0DDBD3F80000000D 20070607 13:57:18.587380 APPC: Set Send Type succeeded 20070607 13:57:26.736674 APPC: Confirm succeeded 20070607 13:57:26.737027 Req to send recd value is 0 20070607 13:57:26.737546 APPC: SEND_DATA return_code = 0 20070607 13:57:26.737726 request_to_send_received = 0 20070607 13:57:26.737893 Send Data succeeded 20070607 13:57:26.738169 APPC: Set Prepare to Receive type succeeded 20070607 13:57:26.738580 APPC: Prepare to Receive succeeded 20070607 13:57:26.808899 APPC: Receive data 20070607 13:57:26.809122 RCV return_code = 0 20070607 13:57:26.809270 RCV data_received= 2 20070607 13:57:26.809415 RCV received_length= 29 20070607 13:57:26.809556 RCV status_received= 4 20070607 13:57:26.809712 RCV req_to_send= 0 20070607 13:57:26.809868 Receive succeeded :IP: 0 9.42.112.75 1674 50246 20070607 13:57:26.810533 APPC: CONFIRMED succeeded
Vérifiez la connexion de SCLM Developer Toolkit en exécutant la commande suivante :
fekfivps
La commande doit renvoyer le résultat des vérifications relatives à SCLM Developer Toolkit (variables, modules HFS, environnement d'exécution REXX, démarrage et arrêt de session TSO/ISPF), comme celui de l'exemple suivant ($ est l'invite de z/OS UNIX ) :
$ fekfivps Wed Jul 2 15:00:27 EDT 2008 uid=1(USERID) gid=0(GROUP) using /etc/rdz/rsed.envvars current address space size limit is 1914675200 (1826.0 MB) maximum address space size limit is 2147483647 (2048.0 MB) ------------------------------------------------------------- /etc/rdz/ISPF.conf content: ------------------------------------------------------------- ispmlib=ISP.SISPMENU isptlib=ISP.SISPTENU ispplib=ISP.SISPPENU ispslib=ISP.SISPSLIB sysproc=ISP.SISPCLIB,FEK.SFEKPROC ------------------------------------------------------------- Host install verification for RSE Review IVP log messages from HOST below : ------------------------------------------------------------- *** CHECK : ENVIRONMENT VARIABLES - key variables displayed below : Server PATH = /usr/lpp/java/J5.0/bin:/usr/lpp/rdz/lib:/usr/lpp/ispf/bin: /bin:/usr/sbin:. STEPLIB = FEK.SFEKAUTH:FEK.SFEKLOAD _CMDSERV_BASE_HOME = /usr/lpp/ispf _CMDSERV_CONF_HOME = /etc/rdz _CMDSERV_WORK_HOME = /var/rdz _SCLMDT_CONF_HOME = /var/rdz/sclmdt _SCLMDT_WORK_HOME = /var/rdz _SCLMDT_TRANTABLE = FEK.#CUST.LSTRANS.FILE ------------------------------------------------------------- *** CHECK : JAVA PATH SETUP VERIFICATION RC=0 MSG: SUCCESSFUL ------------------------------------------------------------- *** CHECK : USS MODULES Checking ISPF Directory : /usr/lpp/ispf Checking modules in /usr/lpp/ispf/bin directory Checking for ISPF configuration file ISPF.conf Checking install bin Directory : /usr/lpp/rdz/bin RC=0 MSG: SUCCESSFUL ------------------------------------------------------------- *** CHECK : REXX RUNTIME ENVIRONMENT RC=0 MSG: SUCCESSFUL ------------------------------------------------------------- *** CHECK : TSO/ISPF INITIALIZATION ( TSO/ISPF session will be initialized ) RC=0 MSG: SUCCESSFUL ------------------------------------------------------------- *** CHECK: Shutting down TSO/ISPF IVP session RC=0 MSG: SUCCESSFUL ------------------------------------------------------------- Host installation verification completed successfully -------------------------------------------------------------
fekfivps présente plusieurs paramètres facultatifs ne dépendant pas de la position :
Testez la connexion REXEC en exécutant la commande ci-dessous. Remplacez 512 par le port utilisé par REXEC et USERID par un ID utilisateur valide.
fekfivpr 512 USERID
Après vous avoir invité à saisir un mot de passe, la commande doit renvoyer la trace REXEC, un avertissement de dépassement du délai d'attente, la version de Java et le message du serveur RSE, comme dans l'exemple ci-après ($ est l'invite de z/OS UNIX) :
$ fekfivpr 512 USERID Enter password: Wed Jul 2 15:00:27 EDT 2008 uid=1(USERID) gid=0(GROUP) using /etc/rdz/rsed.envvars current address space size limit is 1914675200 (1826.0 MB) maximum address space size limit is 2147483647 (2048.0 MB) $ EZYRC01I Calling function rexec_af with the following: EZYRC02I Host: CDFMVS08, user USERID, cmd cd /etc/rdz;export RSE_USER_ID=USERI D;./server.zseries -ivp, port 512 EZYRC19I Data socket = 4, Control socket = 6. RSE server IVP test CDFMVS08 -- Wed Jul 2 15:00:27 EDT 2008 uid=1(USERID) gid=0(GROUP) RSE configuration files located in /etc/rdz --default RSE userid is USERID --default ------------------------------------------------------------- Address Space size limits ------------------------------------------------------------- current address space size limit is 2147483647 (2048.0 MB) maximum address space size limit is 2147483647 (2048.0 MB) ------------------------------------------------------------- service history ------------------------------------------------------------- Fri Jun 19 00:01:00 2009 -- COPY -- HHOP760 v7600 created 18 Jun 2009 ------------------------------------------------------------- expect to see time out messages after a successful IVP test ------------------------------------------------------------- starting RSE server in background -- Fri Jun 19 15:59:05 EDT 2009 ------------------------------------------------------------- java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pmz31dev-20070201 (SR4)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 z/OS s390-31 j9vmmz3123-20070201 (JI T enabled) J9VM - 20070131_11312_bHdSMr JIT - 20070109_1805ifx1_r8 GC - 200701_09) JCL - 20070126 DStore Server Starting... Server Started Successfully 8108 Server running on: CDFMVS08
Connection error Server: error initializing socket: java.net.SocketTimeoutException: Accept timed out
Ce test IVP peut être évité si le test précédent décrit dans (Facultatif) Connexion à REXEC, a été réussi.
Testez le script utilisé par la connexion REXEC et SSH en exécutant la commande ci-dessous :
fekfivpz
La commande doit renvoyer un avertissement de dépassement du délai d'attente, la version de Java et le message du serveur RSE, comme dans l'exemple ci-dessous ($ est l'invite de z/OS UNIX) :
$ fekfivpz Wed Jul 2 15:00:27 EDT 2008 uid=1(USERID) gid=0(GROUP) using /etc/rdz/rsed.envvars current address space size limit is 1914675200 (1826.0 MB) maximum address space size limit is 2147483647 (2048.0 MB) ------------------------------------------------------------- RSE server IVP test CDFMVS08 -- Wed Jul 2 15:00:27 EDT 2008 uid=1(USERID) gid=0(GROUP) RSE configuration files located in /etc/rdz --default RSE userid is USERID --default ------------------------------------------------------------- Address Space size limits ------------------------------------------------------------- current address space size limit is 2147483647 (2048.0 MB) maximum address space size limit is 2147483647 (2048.0 MB) ------------------------------------------------------------- service history ------------------------------------------------------------- Fri Jun 19 00:01:00 2009 -- COPY -- HHOP760 v7600 created 18 Jun 2009 ------------------------------------------------------------- expect to see time out messages after a successful IVP test ------------------------------------------------------------- starting RSE server in background -- Fri Jun 19 15:59:05 EDT 2009 ------------------------------------------------------------- java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pmz31dev-20070201 (SR4)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 z/OS s390-31 j9vmmz3123-20070201 (JI T enabled) J9VM - 20070131_11312_bHdSMr JIT - 20070109_1805ifx1_r8 GC - 200701_09) JCL - 20070126 DStore Server Starting... Server Started Successfully 8108 Server running on: CDFMVS08
Connection error Server: error initializing socket: java.net.SocketTimeoutException: Accept timed out
Le présent chapitre répertorie les commandes de l'opérateur (ou de la console) disponibles pour System z. Si vous avez besoin de vous familiariser avec les diagrammes de syntaxe utilisés pour expliquer le format de commande, reportez-vous à la section Comment lire un diagramme de syntaxe.
Utilisez la commande START pour lancer dynamiquement une tâche démarrée (STC). La version abrégée de la commande est la lettre S.
La commande MODIFY permet d'interroger et de modifier de manière dynamique les caractéristiques d'une tâche active. La version abrégée de la commande est la lettre F.
<IDclient> : <IDutilisateur> : <connecté depuis>
ProcessId(<processid>) Memory Usage(<utilisation de segment de mémoire java>%) Clients(<nombre de clients>) Order(<ordre de démarrage>) <état d'erreur>
Dans les situations normales, <état d'erreur> est vide. Le tableau 18 docummente les valeurs non-blanches possibles pour <état d'erreur>.
Etat | Description |
---|---|
*severe error* | Le processus du pool d'unités d'exécution a fait l'objet d'une erreur irrémédiable et à interrompu les opérations. Les autres zones d'état affichent les dernières valeurs connues. Utilisez l'option CLEANUP de la commande de modification DISPLAY PROCESS pour supprimer cette entrée de la table. |
*killed process* | Le processus du pool d'unités d'exécution a été arrêté par Java, z/OS UNIX ou une commande de l'opérateur. Les autres zones d'état affichent les dernières valeurs connues. Utilisez l'option CLEANUP de la commande de modification DISPLAY PROCESS pour supprimer cette entrée de la table. |
*timeout* | Le processus du pool d'unités d'exécution n'a pas répondu dans le délai imparti au démon RSE lors d'une demande de connexion d'un client. Les autres zones d'état affichent les valeurs en cours. Le pool d'unités d'exécution est exclu des futures demandes de connexion client. L'état *timeout* est réinitialisé lorsqu'un client pris en charge par ce pool d'unités d'exécution se déconnecte. |
Des informations supplémentaires sont fournies lorsque vous utilisez l'option DETAIL de la commande de modification DISPLAY PROCESS :
ProcessId(33555087) ASId(002E) JobName(RSED8) Order(1) PROCESS LIMITS: CURRENT HIGHWATER LIMIT JAVA HEAP USAGE(%) 10 56 100 CLIENTS 0 25 60 MAXFILEPROC 83 103 64000 MAXPROCUSER 97 99 200 MAXTHREADS 9 14 1500 MAXTHREADTASKS 9 14 1500
Le champ ASId est l'ID d'espace adresse, en notation hexadécimal. La table des limites du processus montre l'usage actuel des ressources, la cote d'alerte haute pour l'usage des ressources et la liste des ressources. Notez qu'en raison d'autres facteurs de limitation, la limite définie ne pourrait jamais être atteinte.
E ou 0 ou OFF | Messages d'erreur uniquement. |
W ou 1 | Messages d'erreur et d'avertissement. Il s'agit du paramètre par défaut de rsecomm.properties. |
I ou 2 ou ON | Messages d'erreur, d'avertissement et d'information. |
La fonction de trace détaillée réduit les performances et ne doit être effectuée que sur indication du centre de support IBM.
E ou 0 ou OFF | Messages d'erreur uniquement. |
I ou 2 ou ON | Messages d'erreur, d'avertissement et d'information. |
La fonction de trace détaillée réduit les performances et ne doit être effectuée que sur indication du centre de support IBM.
E ou 0 ou OFF | Messages d'erreur uniquement. |
I ou 2 ou ON | Messages d'erreur, d'avertissement et d'information. |
La fonction de trace détaillée réduit les performances et ne doit être effectuée que sur indication du centre de support IBM.
La fonction de trace détaillée réduit les performances et ne doit être effectuée que sur indication du centre de support IBM.
BPXM023I (stclock) dataset[(member)] NOT LOCKED BPXM023I (stclock) dataset[(member)] LOCKED BY userid
Le message de console FEK513W est généré lorsque le serveur RSE n'est pas en mesure d'enregistrer le client auprès du démon lock. Les valeurs ASID et TCB mentionnées dans ce message peuvent être comparées au résultat de la commande de l'opérateur D GRS,RES=(*,dataset[(member)]) pour identifier l'utilisateur qui maintient le verrou.
Utilisez la commande STOP pour arrêter une tâche active. La version abrégée de la commande est la lettre P.
Le moniteur de travaux JES ne comporte pas de messages de console spécifiques au produit. Le serveur compte sur z/OS et JES pour générer des messages de console pour les actions effectuées par les clients Developer for System z.
Le tableau 19 répertorie les messages de console propres au produit générés par le démon RSE, le serveur de pool d'unités d'exécution RSE et le démon lock.
ID du message | Texte du message |
---|---|
FEK001I | RseDaemon étant initialisé en mode bit {0} |
FEK002I | Démon RSE démarré. (port={0}) |
FEK003I | Commande d'arrêt en cours de traitement |
FEK004I | Démon RSE : Taille de pile maximale={0}Mo et Taille AS privée={1}Mo |
FEK005I | Processus serveur démarré (processId={0}) |
FEK009I | RseDaemon attend le démarrage du processus serveur. |
FEK010I | (emplacement rsed.envvars = {0}) |
FEK011I | (répertoire de journalisation = {0}) |
FEK100E | Le port du démon / la valeur de délai d'attente doit être des chiffres |
FEK101E | JRE {0} ou supérieur requis |
FEK102E | Arguments non valides reçus : {0} |
FEK103E | Le disque est presque plein dans {0} |
FEK104E | Le nombre maximal de traitements a été atteint |
FEK105E | Erreur lors de l'envoi des données d'audit (rc={0}) |
FEK110E | Echec de socket(). motif=({0}) |
FEK111E | Echec de setsockopt(). motif=({0}) |
FEK112E | Echec de bind(). motif=({0}) |
FEK113E | Echec de listen(). motif=({0}) |
FEK114E | Echec de accept(). motif=({0}) |
FEK115E | Echec de write(). motif=({0}) |
FEK116E | Echec de pipe(). motif=({0}) |
FEK117E | Echec de socketpair(). motif=({0}) |
FEK118E | Echec de select(). motif=({0}) |
FEK119E | Echec de _console(). motif=({0}) |
FEK130E | Echec de gsk_environment_open(). motif=({0}) |
FEK131E | Echec de gsk_attribute_set_enum(GSK_PROTOCOL_SSLV2). motif=({0}) |
FEK132E | Echec de gsk_attribute_set_enum(GSK_PROTOCOL_SSLV3). motif=({0}) |
FEK133E | Echec de gsk_attribute_set_enum(GSK_PROTOCOL_TLSV1). motif=({0}) |
FEK134E | Echec de gsk_attribute_set_buffer(GSK_KEYRING_FILE). motif=({0}) |
FEK135E | Echec de gsk_attribute_set_buffer(GSK_KEYRING_PW). motif=({0}) |
FEK136E | Echec de gsk_environment_init(). motif=({0}) |
FEK137E | Echec de gsk_secure_socket_open(). motif=({0}) |
FEK138E | Echec de gsk_attribute_set_numeric_value(GSK_FD). motif=({0}) |
FEK139E | Echec de gsk_attribute_set_buffer(GSK_KEYRING_LABEL). motif=({0}) |
FEK140E | Echec de gsk_attribute_set_enum(GSK_SESSION_TYPE). motif=({0}) |
FEK141E | Echec de gsk_attribute_set_callback(GSK_IO_CALLBACK). motif=({0}) |
FEK142E | Echec de gsk_secure_socket_init(). motif=({0}) |
FEK143E | Echec de gsk_attribute_set_enum(GSK_CLIENT_AUTH_TYPE). motif=({0}) |
FEK144E | Echec de gsk_get_cert_info. motif=({0}) |
FEK145E | Echec de gsk_secure_socket_read(). motif=({0}) |
FEK146E | Echec de gsk_secure_socket_write(). motif=({0}) |
FEK150E | Fin anormale du démon RSE ; {0} |
FEK201I | La commande {0} a été traitée |
FEK202E | Commande non valide saisie |
FEK203E | Commande d'affichage non valide : Afficher le processus|le client |
FEK204E | Commande d'annulation non valide : ID d'annulation=|Utilisateur= |
FEK205E | La commande n'a pas été traitée en raison de SWITCH consécutifs |
FEK206E | La fonction de journal d'audit n'est pas active |
FEK207I | Aucun client à afficher |
FEK208I | {0} annulé |
FEK209I | Aucun processus à afficher |
FEK210I | {0} annulé(s) en raison d'une connexion en double |
FEK501I | Démon lock démarré, port={0}, intervalle de nettoyage={1}, niveau de consignation={2} |
FEK502I | Arrêt en cours du démon lock |
FEK510E | Démon lock, port manquant |
FEK511E | Démon lock, port erroné, port={0} |
FEK512E | Démon lock, erreur de socket, port={0} |
FEK513W | Démon lock, échec de l'enregistrement, ASID={0}, TCB={1}, UTILISATEUR={2} |
FEK514W | Démon lock, niveau de consignation erroné, niveau de consignation={0} |
BPXM023I | (stclock) dataset[(member)] NOT LOCKED |
BPXM023I | (stclock) dataset[(member)] LOCKED BY userid |
BPXM023I | (stclock) command, WRONG COMMAND |
BPXM023I | (stclock) command, MISSING ARGUMENT |
BPXM023I | (stclock) argument, WRONG ARGUMENT |
Le diagramme de syntaxe montre comment entrer une commande pour qu'elle soit correctement interprétée par le système d'exploitation. La lecture du diagramme de syntaxe s'effectue de la gauche vers la droite et de haut en bas, en suivant la ligne horizontale (chemin principal).
Les symboles utilisés dans les diagrammes de syntaxe sont les suivants :
Symbole | Description |
---|---|
>> | Marque le début du diagramme de syntaxe. |
> | Indique que le diagramme de syntaxe a une suite. |
| | Marque le début et la fin d'un fragment ou d'une partie du diagramme de syntaxe. |
>< | Marque la fin du diagramme de syntaxe. |
Les types d'opérandes utilisés dans les diagrammes de syntaxe sont les suivants :
>>--OPERANDE_REQUIS--><
>>-*------------------*->< *-OPERANDE_FACULTATIF-*
*-OPERANDE_PAR_DEFAUT-* >>-*-----------------*-><
Les opérandes sont classés comme mots clés ou variables :
Dans l'exemple suivant, la commande USER est un mot clé. Le paramètre de variable requis est id_utilisateur et le paramètre de variable facultatif est motdepasse. Remplacez les paramètres de variable par vos propres valeurs :
>>--USER--id_utilisateur-*----------*---------------------------------->< *-motdepasse-*
Si un diagramme contient un caractère non alphanumérique (parenthèse, point, virgule, signe égal et espace), vous devez coder ce caractère dans la syntaxe. Dans notre exemple, vous devez coder OPERAND=(001 0.001) :
>>--OPERANDE--=--(--001-- --0.001--)------------------------><
Une flèche orientée vers la gauche dans un groupe d'opérandes indique que plusieurs d'entre eux peuvent être sélectionnés et qu'un seul peut être répété: :
>>--*----------------------*---------------------------->< *-OPERANDE_REPRODUCTIBLE_1-* *-OPERANDE_REPRODUCTIBLE_2-* *-<--------------------*
Si un diagramme dépasse une ligne, la première ligne se termine par une pointe de flèche et la deuxième ligne commence par une pointe de flèche :
>>--| Première ligne d'un diagramme de syntaxe sur plusieurs lignes |--> >--| Suite des sous-commandes, des paramètres ou des deux |---------><
Certains diagrammes peuvent contenir des fragments de syntaxe, qui servent à fractionner les diagrammes lorsqu'ils sont trop longs, trop complexes ou comportent trop de répétitions. Les noms de fragment de syntaxe peuvent avoir une casse mixte et ils apparaissent dans les diagrammes et dans l'en-tête du fragment. Le fragment est placé sous le diagramme principal :
>>--| Fragment de syntaxe |--------------------------------------->< Fragment de syntaxe : **|--1er_OPERANDE--,--2ème_OPERANDE--,--3ème_OPERANDE--|
Le présent chapitre vous aide à résoudre certains incidents fréquents qui peuvent survenir lors de la configuration de Developer for System z. Il se compose des sections suivantes :
Pour plus d'informations, reportez-vous à la section Support du site Web de Developer for System z (http://www-306.ibm.com/software/awdtools/rdz/support/) 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-306.ibm.com/software/awdtools/rdz/library/), 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://publib.boulder.ibm.com/infocenter/ratdevz/v7r6/index.jsp) 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/.
Veuillez nous tenir informé de l'absence d'une certaine fonction de Developer for System z. Vous pouvez ouvrir une demande d'amélioration (RFE) à l'adresse suivante :
https://www.ibm.com/developerworks/support/rational/rfe/
Developer for System z propose 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). Pour plus d'informations, voir Configuration personnalisée.
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_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.
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.
Les données réacheminées de stdout, la sortie standard Java. La valeur par défaut du modèle JCL FEK.#CUST.PROCLIB(LOCKD) est SYSOUT=*.
Les données réacheminées de stderr, la sortie des erreurs standard Java. La valeur par défaut du modèle JCL FEK.#CUST.PROCLIB(LOCKD) est SYSOUT=*.
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 Fault Analyzer Integration, 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 File Manager Integration, 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.
Le SYSPRINT du travail de serveur contient le journal du serveur CARMA, dans le cas où l'instruction de définition de données CARMALOG n'est pas définie.
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.
Quand l'utilitaire d'administration APPC ajoute et modifie un profil de programme transactionnel, il vérifie que le profil du programme transactionnel et son JCL ne contiennent pas d'erreurs de syntaxe. Le résultat de cette phase se compose de messages d'erreur de syntaxe de profil du programme transactionnel, de messages de traitement de l'utilitaire et d'instructions de conversion JCL. La journalisation des messages de cette phase est contrôlée par l'instruction SYSPRINT DD pour l'utilitaire ATBSDFMU. La valeur par défaut du modèle JCL FEK.SFEKSAMP(FEKAPPCC) est SYSOUT=*. Pour des informations détaillées, voir MVS Planning: APPC/MVS Management (SA22-7599).
Quand un programme transactionnel s'exécute, les messages d'exécution associés, tels que les messages d'allocation et de fin, sont envoyés vers un journal appelé par le mot clé MESSAGE_DATA_SET dans le profil du programme transactionnel. La valeur par défaut du modèle JCL FEK.SFEKSAMP(FEKAPPCC) est &SYSUID.FEKFRSRV.&TPDATE.&TPTIME.LOG. Pour des informations détaillées, voir MVS Planning: APPC/MVS Management (SA22-7599).
Sortie de la commande fekfivpi -file (passerelle client TSO/ISPF associée au test du programme de vérification d'installation), 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.
Sortie de la commande fekfivps -file (test du programme de vérification d'installation lié à SCLMDT), 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 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. Par conséquent, ils peuvent ne pas être créés, ou être créés à des emplacements différents que ceux mentionnés ci-dessous.
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.
Les types de vidage qui peuvent être produits sont :
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. Si vous ne désirez pas que des clichés de transaction soient réalisés, ajoutez la variable d'environnement IBM_JAVA_ZOS_TDUMP=NO à rsed.envvars.
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.
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.
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 moniteur de travaux JES est contrôlée par l'opérateur système dans Commandes de l'opérateur.
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, lock.log et rsecomm.log est déterminée par la commande opérateur modify rsecommlog ou par le paramètre debug_level dans rsecomm.properties. Pour plus d'informations, voir le Commandes de l'opérateur et la section (Facultatif) Fonction de trace RSE.
La création de fichiers journaux .dstore* est contrôlée par les options de démarrage Java -DDSTORE_* (voir Définition de paramètres de démarrage Java supplémentaires avec _RSE_JAVAOPTS).
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. Pour plus d'informations, voir Commandes de l'opérateur et (Facultatif) Fonction de trace RSE.
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.
Le journal propre au démon lock se trouve dans la définition de données STDOUT DD de la tâche démarrée LOCKD. Le volume des données consignées dans le journal est déterminé par le paramètre de démarrage LOG. Pour plus d'informations, voir Commandes de l'opérateur et (Facultatif) Fonction de trace RSE.
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 :
La valeur par défaut est la suivante :
Journalisation des erreurs
Pour plus d'informations sur l'emplacement des fichiers journaux, voir Fichiers journaux.
La procédure suivante permet de rassembler les informations nécessaires au diagnostic des incidents de suivi des erreurs avec les procédures d'assemblage à distance. La fonction de trace réduit les performances et ne doit être effectuée que sur indication du centre de support IBM. Toutes les références à hlq que vous trouverez dans cette section se rapportent au qualificatif de haut niveau utilisé au cours de l'installation de Developer for System z. L'installation par défaut est FEK, mais peut ne pas s'appliquer à votre site.
//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 éloignés (RSE) est le composant de Developer for System z qui fournit les 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.
Le système de fichiers (HFS ou zFS) dans lequel Developer for System z est installé doit être monté avec le contrôle des données de droits SETUID activé (il s'agit de la valeur par défaut du système). Le montage du système de fichier avec le paramètre NOSETUID empêchera Developer for System z de créer l'environnement de sécurité utilisateur et l'exécution de la requête de connexion.
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... afin de 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 éloignés (RSE) est le composant de Developer for System z qui fournit les 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.
Les fichiers Developer for System z suivants doivent être contrôlés par programme :
Utilisez la commande z/OS UNIX ls -E pour répertorier les attributs étendus dans lesquels le bit de contrôle par programme est marqué avec la lettre p, comme indiqué dans l'exemple ci-après ($ 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
Utilisez la commande z/OS UNIX extattr +p afin de définir les données de contrôle de programmes manuellement, comme indiqué dans l'exemple suivant ($ et # représentent l'invite z/OS UNIX) :
$ 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
Remote Systems Explorer (RSE) est le composant de Developer for System z qui fournit les services de base comme la connexion du client à l'hôte. Il doit exécuter un APF autorisé 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 durant l'installation de SMP/E, si nécessaire. Cette donnée de droits pourrait être perdue si vous ne la conservez pas au cours d'une copie manuelle des répertoires de Developer for System z.
Les fichiers Developer for System z suivants doivent être autorisés APF :
Utilisez la commande z/OS UNIX ls -E pour répertorier les attributs étendus dans lesquels le bit APF est marqué avec la lettre a, comme indiqué dans l'exemple ci-après ($ 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 command 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 fichier fictif dans z/OS UNIX avec le bit "sticky" activé. Lorsque le module de remplacement est exécuté, z/OS UNIX recherche un module de chargement MVS portant le même nom, puis l'exécute.
Le bit "sticky" de z/OS UNIX est défini 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.
Les fichiers Developer for System z doivent avoir le bit "sticky" activé :
Utilisez la commande ls -l de z/OS UNIX pour afficher les droits. Les données de droit sont marquées par la lettre avec t, comme indiqué dans l'exemple ci-après ($ représente l'invite de z/OS UNIX) :
$ cd /usr/lpp/rdz $ ls -l bin/CRA* -rwxr-xr-t 2 user group 71 Jul 8 12:31 bin/CRASTART
Utilisez la commande chmod +t de z/OS UNIX pour définir le bit "sticky" manuellement, comme indiqué dans l'exemple ci-après ($ et # représentent l'invite de z/OS UNIX) :
$ 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 doit s'apparenter à l'exemple ci-dessous. Les ports utilisés sont le dernier chiffre (derrière les deux points "..") 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.
IPv4
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
IPv6
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 adresses 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é.
Cette valeur peut être vérifiée et définie de manière dynamique (jusqu'au prochain démarrage du système) à l'aide des commandes de console suivantes, décrites dans le document MVS System Commands (GC28-1781:
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).
Avec RACF, cette valeur peut être vérifiée et définie à l'aide des commandes TSO suivantes, décrites dans le document Security Server RACF Command Language Reference (SA22-7687) :
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).
Les valeurs de SYS1.PARMLIB(SMFPRMxx) peuvent être vérifiées et définies à l'aide des commandes de console suivantes, décrites dans le document MVS System Commands (GC28-1781) :
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 changée sous z/OS 1.10 pour 2 G, ce qui permet à une tâche 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).
Les valeurs de SYS1.PARMLIB(SMFPRMxx) peuvent être vérifiées et définies à l'aide des commandes de console suivantes, décrites dans le document MVS System Commands (GC28-1781) :
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.
Si vous ne pouvez pas utiliser la version APPC du service Commandes TSO, des incidents peuvent survenir dans les deux domaines suivants : le démarrage de la transaction du serveur APPC et la connexion au RSE.
Le REXX fourni dans (Facultatif) Transaction APPC pour le service Commandes TSO permet de résoudre les incidents APPC en vous donnant la possibilité de gérer les APPC de manière interactive via les panneaux ISPF. Toutefois, vous devez savoir que vous pouvez désactiver la transaction avec cet outil ; la transaction existe toujours mais n'accepte aucune connexion.
La liste suivante répertorie les fiches techniques disponibles dans la section Support du site Web (http://www-306.ibm.com/software/awdtools/rdz/support/). Pour de plus amples informations, consultez le site Web de support :
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.
Chaque connexion RSE lance plusieurs processus qui sont actifs de façon permanente. De nouvelles connexions peuvent être refusées en raison de la limite définie dans SYS1.PARMLIB(BPXPRMxx) concernant la quantité de processus, particulièrement lorsque les utilisateurs partagent le même ID utilisateur (lorsque le segment OMVS par défaut est utilisé, par exemple).
La limite d'espaces adresse z/OS et d'utilisateurs z/OS UNIX actifs représente une autre source de connexions refusées.
Lorsque vous utilisez APPC pour le service Commandes TSO, la lecture et l'écriture d'un fichier MVS nécessitent l'emploi d'un socket de domaine de système de fichiers physique. Si le système de fichiers n'est pas correctement défini ou s'il n'a pas suffisamment de sockets, le gestionnaire de verrous (FFS) peut échouer dans les requêtes de lecture/écriture. Le fichiers ffs*.log présenteront des messages comme :
Assurez-vous que le membre SYS1.PARMLIB(BPXPRMxx) contient les instructions suivantes :
FILESYSTYPE TYPE(UDS) ENTRYPOINT(BPXTUINT) NETWORK DOMAINNAME(AF_UNIX) DOMAINNUMBER(1) MAXSOCKETS(2000) TYPE(UDS)
Un autre motif pouvant être à l'origine de cet incident lorsque vous utilisez APPC pour le service Commandes TSO est que le programme de résolution TCP/IP ne parvient pas à résoudre l'adresse hôte correctement en raison d'un fichier de configuration du programme de résolution manquant ou incomplet. Le message lock.log suivant est une indication évidente de l'apparition de cet incident :
clientip(0.0.0.0) <> callerip(<adresse IP de l'hôte>)
Exécutez le programme de vérification d'installation TCP/IP fekfivpt tel que décrit au Vérification de l'installation. La section relative à la configuration du programme de résolution de la sortie ressemblera à l'exemple suivant :
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='<fichier du programme de résolution>'
Developer for System z fournit un accès grand système aux utilisateurs d'un poste de travail standard. 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 résider dans un système de fichiers sécurisé. 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 le Compréhension 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.
Les données d'authentification fournies par le client ne sont utilisées qu'une seule fois, pendant la configuration de la connexion initiale. Une fois que l'ID utilisateur est authentifié, l'ID utilisateur et les mots de passe Passticket générés automatiquement sont utilisés pour toutes les actions qui requièrent une authentification.
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é.
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é.
Cette méthode d'authentification est prise en charge uniquement par la méthode de connexion du démon RSE. SSL doit également être activé.
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 :
Différents niveaux de sécurité des communications sont pris en charge par RSE, qui contrôle toutes les communications entre le client et les services Developer for System z :
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.
Afin de mieux comprendre l'utilisation des ports, une brève description du processus de connexion RSE est incluse ci-après :
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). L'utilisation de la couche SSL est contrôlée par les paramètres du fichier de configuration ssl.properties, comme décrit dans la section Communication chiffrée à l'aide du protocole SSL.
L'émulateur de connexion à l'hôte sur le client se connecte à un serveur TN3270 sur l'hôte. L'utilisation de SSL est contrôlée par TN3270, comme indiqué dans le document Communications Server IP Configuration Guide (SC31-8775).
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 TS CICS (voir 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.
La figure 40 illustre les ports TCP/IP que Developer for System z peut utiliser. Les flèches indiquent la partie qui assure la liaison (tête de flèche) et celle qui assure la connexion.
Définissez les ports suivants sur le pare-feu qui protège l'hôte z/OS car ils sont utilisés pour les communications client-hôte (via le protocole tcp) :
Plusieurs services hôte Developer for System z s'exécutent dans des unités d'exécution ou espaces adresse séparés et utilisent des sockets TCP/IP comme mécanisme de communication. Tous ces services utilisent RSE pour communiquer avec le client et limitent leur flux de données à l'hôte. Pour certains services, n'importe quel port est utilisé. Pour d'autres, le programmeur système peut sélectionner un port ou une plage de ports à utiliser :
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, 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.
Ainsi, dans une perspective TCP/IP, RSE est le serveur assurant la connexion au port (par l'intermédiaire de l'exploitant CARMA), le serveur CARMA étant le client qui s'y connecte.
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é.
Afin de mieux comprendre l'utilisation de PassTicket, une brève description du processus de sécurité RSE est incluse ci-après :
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 d'application par défaut MVS, qui 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).
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.
Plusieurs options de rsed.envvars influencent la fonction d'audit, comme indiqué à la section Définition de paramètres de démarrage Java supplémentaires avec _RSE_JAVAOPTS.
La commande de l'opérateur modify switch peut être utilisée pour basculer manuellement vers un nouveau fichier journal d'audit, comme expliqué au Commandes de l'opérateur.
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. Pour obtenir la liste des messages de la console générés par RSE, voir Messages de la console.
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 actions suivantes sont consignées :
Chaque action consignée est conservée (avec une date/un horodatage) au format CSV qui peut être lu par un outil d'automatisation ou d'analyse de données.
Les journaux d'audit dispose du masque de contrôle des données d'autorisation 640 (-rw-r-----), ce qui signifie que le propriétaire (ID utilisateur z/OS UNIX du démon RSE) dispose de droits en lecture et en écriture et que le groupe (par défaut) du propriétaire dispose d'un accès en lecture. 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 au profil SUPERUSER.FILESYS dans la classe UNIXPRIV.
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 JESprend 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 21 sont, par défaut, limitées aux travaux dont l'utilisateur est le propriétaire. Cette limitation peut être modifiée avec la directive LIMIT_COMMANDS, comme spécifié dans FEJJCNFG, fichier de configuration du moniteur de travaux JES.
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.
Si LIMIT_COMMANDS n'est pas USERID, le moniteur de travaux JES demandera le droit d'accès au profil associé dans de la classe JESSPOOL, comme indiqué dans le tableau suivant :
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 |
Utilisez les substitutions suivantes dans le tableau précédent :
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, les valeurs LIMITED et NOLIMIT de LIMIT_COMMANDS auront un comportement différent, comme expliqué dans le tableau 9. 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 opérateur JES demandées par un utilisateur via une console EMCS dont le nom est contrôlé avec la directive CONSOLE_NAME, comme indiqué à la section FEJJCNFG, fichier de configuration du moniteur de travaux JES.
Cette configuration permet à l'administrateur de sécurité de définir des droits d'exécution des commandes complexesen utilisant les classes OPERCMDS et CONSOLE.
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.
Notez que le moniteur de travaux JES ne peut pas créer la console JMON lorsqu'une commande doit être exécutée si le nom de la console est déjà utilisé. Pour éviter cela, le programmeur système peut définir la directive GEN_CONSOLE_NAME=ON dans le fichier de configuration du moniteur de travaux JES ou l'administrateur de sécurité peut définir des profils de sécurité pour empêcher les utilisateurs TSO de créer une console. Les exemples de commandes RACF suivants empêchent tous les utilisateurs (sauf ceux qui sont autorisés) de créer une console TSO ou SDSF :
Pour plus d'informations sur la protection des commandes 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. Cette autorisation par défaut peut être modifiée avec la directive LIMIT_VIEW comme spécifié dans FEJJCNFG, fichier de configuration du moniteur de travaux JES.
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) peuvent être chiffrées à l'aide de SSL (Secure Socket Layer). Cette fonction est désactivée par défaut et est contrôlée par les paramètres du fichier ssl.properties (voir la section (Facultatif) Chiffrement SSL RSE).
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 .
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.
L'ID utilisateur RSE (STCRSE dans l'exemple de commande ci-dessous) doit disposer des droits nécessaires pour accéder à son fichier de clés et aux certificats associés lorsque des fichiers de clés conformes à SAF sont utilisés pour le démon ou le serveur RSE.
Pour plus d'informations sur l'activation de SSL pour Developer for System z, voir Annexe A. Configuration de l'authentification SSL et X.509.
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.
Si vous utilisez un fichier de clés SAF (méthode recommandée), vous devez ajouter le certificat de l'autorité de certification à votre base de données de sécurité sous la forme d'un certificat CERTAUTH associé à l'attribut TRUST ou HIGHTRUST, comme indiqué dans l'exemple de commande RACF ci-après :
La plupart des produits de sécurité possèdent des certificats d'autorité de certification reconnues dans leurs bases de données avec un état NOTRUST. Utilisez les exemples de commande RACF suivantes pour répertorier les certificats des autorités de certification et marquer un certificat comme sécurisé (trusted) en fonction du libellé qui lui est affecté.
Une fois que le certificat de l'autorité de certification est ajouté à la base de données de sécurité, il doit être connecté au fichier de clés RSE, comme indiqué dans l'exemple de commande RACF ci-aprè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. |
Si vous le souhaitez, vous pouvez demander au démon RSE de vérifier une ou plusieurs listes de révocation de certificat (CRL) pour renforcer la sécurité de la procédure de validation. Cette opération est effectuée en ajoutant des variables d'environnement liées aux listes de révocation de certificat au fichier rsed.envvars. Pour plus d'informations sur les exemples de variable suivants, voir rsed.envvars - Fichier de configuration RSE :
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é.
Les certificats sont définis dans RACF à l'aide de la commande RACDCERT, comme indiqué dans l'exemple suivant :
RACDCERT ID(userid) ADD(dsn) TRUST WITHLABEL('label')
La paire ID utilisateur et nom d'hôte est valide si toutes ces conditions sont remplies :
La définition de l'extension HostIdMappings dans la syntaxe ASN.1 est :
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, leur mode de gestion par RACF et les modalités de définition des filtres de nom de certificat, voir 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é .
La paire ID utilisateur et nom d'hôte est valide si toutes ces conditions sont remplies :
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). |
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. Cette fonction est désactivée par défaut et requiert la définition du profil de sécurité BPX.POE, comme le montrent les exemples de commandes RACF :
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).
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 à propos de 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 utilise les services Web TS CICS ou l'interface RESTful pour appeler le serveur CRD. L'utilisation de SSL pour ces communications est contrôlée par la définition TCPIPSERVICE TS CICS, comme indiqué dans le document 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).
Plusieurs fichiers de configuration Developer for System z contiennent des directives qui ont une incidence sur la configuration 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 les fichiers de spoule qui peuvent être consultés. Pour plus d'informations, voir Accès aux fichiers spoule.
ID application utilisé pour la création et la validation de mots de passe PassTicket. Pour plus d'informations, voir Utilisation de PassTickets.
Empêche les utilisateurs de sauvegarder leur mot de passe hôte sur le client. Pour plus d'informations, voir Définition de paramètres de démarrage Java supplémentaires avec _RSE_JAVAOPTS.
Délai de déconnexion des clients inactifs. Pour plus d'informations, voir Définition de paramètres de démarrage Java supplémentaires avec _RSE_JAVAOPTS.
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).
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.
Emplacement des fichiers 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 à l'aide du protocole SSL.
Nom du certificat du démon RSE. Pour plus d'informations, voir Communication chiffrée à l'aide du protocole SSL.
Emplacement du certificat du serveur RSE. Pour plus d'informations, voir Communication chiffrée à l'aide du protocole SSL.
Nom du certificat du serveur RSE. Pour plus d'informations, voir Communication chiffrée à l'aide du protocole SSL.
Type de fichier de clés utilisé (Java ou SAF). Pour plus d'informations, voir Communication chiffrée à l'aide du protocole SSL.
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 Configuration personnalisée.
Pour plus d'informations sur les commandes RACF, voir RACF Command Language Reference (SA22-7687).
Les sections ci-après décrivent les étapes requises, la configuration facultative et les alternatives possibles.
Pour procéder à la configuration de la sécurité, l'administrateur de la sécurité doit connaître les valeurs figurant dans le tableau 26. Ces valeurs ont été définies dans les étapes précédentes d'installation et de personnalisation de Developer for System z.
Description |
|
Valeur |
---|---|---|
Qualifiant de haut niveau du produit Developer for System z |
|
|
Qualifiant de haut niveau de personnalisation de Developer for System z |
|
|
Nom de tâche démarrée du moniteur de travaux JES |
|
|
Nom de tâche démarrée du démon RSE |
|
|
Nom de tâche démarrée du démon Lock |
|
|
ID application |
|
La liste ci-après présente les actions à effectuer pour obtenir une configuration de sécurité de base de Developer for System z. Comme indiqué dans les sections ci-après, différentes méthodes peuvent répondre à vos exigences, en fonction du niveau de sécurité recherché. Pour plus d'informations sur la configuration de sécurité des services facultatifs de Developer for System z, reportez-vous aux sections précédentes.
Developer for System z utilise différents mécanismes de sécurité pour fournir au client un environnement hôte sécurisé et contrôlé. Pour cela, plusieurs classes et paramètres de sécurité doivent être actifs, comme illustré par les exemples de commandes RACF ci-dessous :
SETROPTS LIST
SETROPTS GENERIC(FACILITY)
SETROPTS CLASSACT(FACILITY) RACLIST(FACILITY)
SETROPTS GENERIC(STARTED)
RDEFINE STARTED ** STDATA(USER(=MEMBER) GROUP(STCGROUP) TRACE(YES))
SETROPTS CLASSACT(STARTED) RACLIST(STARTED)
SETROPTS GENERIC(CONSOLE)
SETROPTS CLASSACT(CONSOLE) RACLIST(CONSOLE)
SETROPTS GENERIC(OPERCMDS)
SETROPTS CLASSACT(OPERCMDS) RACLIST(OPERCMDS)
SETROPTS GENERIC(APPL)
SETROPTS CLASSACT(APPL) RACLIST(APPL)
SETROPTS GENERIC(PTKTDATA)
SETROPTS CLASSACT(PTKTDATA) RACLIST(PTKTDATA)
RDEFINE PROGRAM ** ADDMEM('SYS1.CMDLIB'//NOPADCHK) UACC(READ)
SETROPTS WHEN(PROGRAM)
Attention : Certains produits (FTP, par exemple) doivent être contrôlés par programme si "WHEN PROGRAM" est actif. Vous devez les essayer avant de les activer sur un système de production. |
SETROPTS GENERIC(SERVAUTH)
SETROPTS CLASSACT(SERVAUTH) RACLIST(SERVAUTH)
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 groupe.
Dans l'exemple 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)
ALTGROUP #group-name OMVS(GID(#group-identifier))
Bien que cela soit déconseillé, vous pouvez utiliser le segment OMVS défini dans le profil BPX.DEFAULT.USER de la classe FACILITY afin de répondre aux exigences de segment OMVS pour Developer for System z.
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
Certains des composants Developer for System z facultatifs requièrent des profils de fichier de sécurité supplémentaires. Remplacez les marques de réservation #sysprog, #ram-developer et #cicsadmin par des ID utilisateur ou par des noms de groupes RACF valides :
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
Utilisez les exemples de commande RACF suivants pour obtenir une configuration encore plus sécurisée dans laquelle l'accès READ est également contrôlé.
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.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.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.SFEKLOAD CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.SFEKLOAD 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.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.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.SFEKPROC' CLASS(DATASET) ACCESS(READ) ID(#db2)
SETROPTS GENERIC(DATASET) REFRESH
Lorsque vous définissez le contrôle des droits d'accès en lecture (READ) aux fichiers système, vous devez fournir aux serveurs et aux utilisateurs de Developer for System z les droits d'accès en lecture (READ) aux fichiers suivants :
Les exemples de commande RACF ci-dessous créent les tâches démarrées JMON, RSED et LOCKD en leur affectant les ID utilisateur protégés (respectivement STCJMON, STCRSE et STCLOCK) et le groupe STCGROUP. Remplacez les marques de réservation #group-id et #user-id-* par des ID OMVS valides.
ADDGROUP STCGROUP OMVS(GID(#group-id)) DATA('GROUP WITH OMVS SEGMENT FOR STARTED TASKS')
ADDUSER STCJMON DFLTGROUP(STCGROUP) NOPASSWORD NAME('RDZ - JES JOBMONITOR') OMVS(UID(#user-id-jmon) HOME(/tmp) PROGRAM(/bin/sh) NOASSIZEMAX NOTHREADSMAX) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDUSER STCRSE DFLTGROUP(STCGROUP) NOPASSWORD NAME('RDZ - RSE DAEMON') OMVS(UID(#user-id-rse) HOME(/tmp) PROGRAM(/bin/sh) ASSIZEMAX(2147483647) NOTHREADSMAX) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDUSER STCLOCK DFLTGROUP(STCGROUP) NOPASSWORD NAME('RDZ - LOCK DAEMON') OMVS(UID(#user-id-lock) HOME(/tmp) PROGRAM(/bin/sh) NOASSIZEMAX) NOTHREADSMAX) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
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))
RDEFINE STARTED LOCKD.* DATA('RDZ - LOCK DAEMON') STDATA(USER(STCLOCK) GROUP(STCGROUP) TRUSTED(NO))
SETROPTS RACLIST(STARTED) REFRESH
Vous pouvez être amené à restreindre l'ID utilisateur STCRSE. Les utilisateurs possédant l'attribut RESTRICTED ne peuvent pas accéder aux ressources protégées (MVS) auxquelles ils ne sont pas autorisés à accéder de manière spécifique.
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, vous devez définir le profil RESTRICTED.FILESYS.ACCESS dans la classe UNIXPRIV avec UACC(NONE). Pour plus d'informations sur la restriction des ID utilisateur, voir Security Server RACF Security Administrator's Guide (SA22-7683).
Avertissement : Si vous utilisez des ID utilisateur restreints, vous devez ajouter de manière
explicite le droit d'accès à une ressource avec les commandes PERMIT TSO ou
setfacl z/OS
UNIX.
Cela inclut les ressources dans lesquelles la
documentation Developer for System z utilise UACC (tel que 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).
Vous devez les essayer avant de les activer sur
un système de production. |
Le moniteur de travaux JES émet toutes les commandes opérateur JES demandées par un utilisateur via une console EMCS dont le nom est contrôlé avec la directive CONSOLE_NAME, comme indiqué à la section FEJJCNFG, fichier de configuration du moniteur de travaux JES.
Dans l'exemple suivant, les commandes RACF donnent aux utilisateurs de Developer for System z un accès conditionnel à un jeu limité de commandes JES (Mettre en attente, Libérer, Annuler et Purger). Les utilisateurs possèdent des droits d'exécution uniquement s'ils lancent les commandes via le moniteur de travaux JES. Remplacez la marque de réservation #console par le nom réel de la console.
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 les essayer avant de les activer sur
un système de production. |
Le tableau 27 et le tableau 28 présentent des commandes 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} |
jesname.MODIFYHOLD.BAT jesname.MODIFYHOLD.STC jesname.MODIFYHOLD.TSU |
UPDATE |
Libérer | $Ax(jobid)
avec x = {J, S ou T} |
jesname.MODIFYRELEASE.BAT jesname.MODIFYRELEASE.STC jesname.MODIFYRELEASE.TSU |
UPDATE |
Annuler | $Cx(jobid)
avec x = {J, S ou T} |
jesname.CANCEL.BAT jesname.CANCEL.STC jesname.CANCEL.TSU |
UPDATE |
Purger | $Cx(jobid),P
avec x = {J, S ou T} |
jesname.CANCEL.BAT jesname.CANCEL.STC jesname.CANCEL.TSU |
UPDATE |
Action | Commande | Profil OPERCMDS | Droit d'accès requis |
---|---|---|---|
Mettre en attente | *F,J=jobid,H |
jesname.MODIFY.JOB |
UPDATE |
Libérer | *F,J=jobid,R |
jesname.MODIFY.JOB |
UPDATE |
Annuler | *F,J=jobid,C |
jesname.MODIFY.JOB |
UPDATE |
Purger | *F,J=jobid,C |
jesname.MODIFY.JOB |
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 (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.
RSE requiert un accès UPDATE au profil BPX.SERVER pour créer/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.
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. Cette configuration peut avoir une incidence sur
d'autres applications et opérations z/OS
UNIX. Vous devez les essayer avant de les 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. Cela 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é.
RSE utilise la bibliothèque système (SYS1.LINKLIB), l'environnement d'exécution de Language Environment' (CEE.SCEERUN*) et la bibliothèque de chargement de la passerelle client TSO/ISPF d'ISPF (ISP.SISPLOAD).
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 DebugTool, par exemple).
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
Comme indiqué plus en détails dans Définition du support de mots de passe PassTicket pour RSE, RSE prend en charge l'utilisation d'un ID application autre que FEKAPPL. La définition de classe APPL doit correspondre à l'ID application réel utilisé par RSE.
Avertissement : La demande de connexion du client n'aboutit pas si le profil de l'application n'est pas défini ou si l'utilisateur n'a pas l'accès en lecture au profil. |
Le mot de passe du client (ou toute autre méthode d'identification, telle que les certificats X.509) est utilisé uniquement pour vérifier son 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.
Les PassTickets sont des mots de passe générés par le système pour une durée d'environ 10 minutes. Ils s'appuient sur une clé confidentielle. Cette clé est un nombre de 64 bits (16 caractères hexadécimaux). Dans les exemples de commande RACF, remplacez la marque de réservation key16 ci-dessous par une chaîne hexadécimale de 16 caractères fournie par l'utilisateur (les caractères 0-9 et A-F).
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. Les définitions de classe PTKTDATA doivent correspondre à l'ID application réel utilisé par RSE.
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 d'application par défaut MVS, qui 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).
Avertissement : La demande de connexion du client n'aboutit pas si
les mots de passe PassTickets ne sont pas correctement configurés. |
Les serveurs disposant des droits BPX.SERVER doivent être exécutés dans un environnement propre, contrôlé par un programme. Cela 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).
Le serveur RSE utilise la bibliothèque partagée Java RACF(/usr/lib/libIRRRacf.so).
$ ls -Eog /usr/lib/libIRRRacf.so -rwxr-xr-x aps- 2 69632 Oct 5 2007 /usr/lib/libIRRRacf.so
Utilisez les exemples de commande ci-dessous pour afficher les résultats de vos personnalisations de la sécurité.
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.
Les rubriques suivantes sont traitées dans le présent chapitre :
La figure 41 illustre une présentation générale de Developer for System z sur votre système hôte.
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 42 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).
La mise en correspondance de ces informations de processus avec l'exemple RSE de la figure 42 permet d'obtenir le flux suivant :
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.
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 une quantité variable de blocs de contrôle du système (selon le nombre d'unités d'exécution actives).
La figure 43 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 43 présente les tâches démarrées de Developer for system z (LOCKD, JMON et RSED) ainsi que des exemples de tâches démarrées et des services système avec qui Developer for System z communique. Le gestionnaire de déploiement d'application (ADM) est actif au sein d'une région CICS. FMNCAS est la tâche démarrée de File Manager (gestionnaire de fichiers). La balise USS REXEC représente le service REXEC (ou SSH) z/OS UNIX.
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 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, File Manager démarrera un nouvel espace adresse pour chaque fichier (ou membre) qu'il a à traiter en faveur de Developer for System z. REXEC 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 43 restent dans le système suffisamment longtemps pour être visibles. Toutefois, vous devez être conscient qu'en raison de la conception de z/OS UNIX, il existe aussi des espaces adresses temporaires de durée de vie courte.
La figure 44 présente une vue schématique d'une connexion du client à l'hôte grâce à Developer for System z. De même, elle explique brièvement comment les mots de passe PassTickets sont utilisés.
La description ci-dessus 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 version mineure (un service propre à l'utilisateur) est active dans sa propre unité d'exécution dans le contexte de sécurité de l'utilisateur qui lui est attribué, garantissant 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 16, selon ls tâches réalisées).
du point de vue du réseau, Developer for system z agit comme FTP en mode poassif. Le client se connecte à un point focal (le démon RSE), supprime la connexion, puis se connecte de nouveau à un numéro de port fourni par le point focal. La logique ci-dessous permet de contrôler la sélection du port utilisé pour la deuxième connexion :
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 à volonté, 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).
La figure 45 explique schématiquement comment le démon lock détermine le client Developer for System z qui détient un verrou de fichier.
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. Les commandes système s'arrêtent au niveau de l'espace adresse, qui correspond au pool d'unités d'exécution.
Pour remédier à cette situation, Developer for System z propose le démon lock, qui peut suivre tous les verrous de fichier/membre placés par les utilisateurs RSE, et ceux placés par d'autres produits (ISPF, par exemple).
Le serveur RSE enregistre un utilisateur qui vient de se connecter avec le démon lock. Les informations d'enregistrement contiennent l'identificateur d'espace adresse (qui est celui du pool d'unités d'exécution), l'identificateur de bloc de contrôle des tâches (propre à l'utilisateur) et l'ID utilisateur.
Notez que l'enregistrement n'a lieu qu'au moment de la connexion. Par conséquent, tous les utilisateurs RSE actifs avant le démarrage (ou le redémarrage) du démon lock ne sont pas enregistrés.
Lorsque le démon lock reçoit une requête de fichier (au moyen d'une commande d'opérateur modify query ou de la part du client grâce au serveur RSE), il analyse les files d'attente de sérialisation d'accès des ressources partagées (GRS) du système. Si l'identificateur d'espace adresse et le bloc de contrôle des tâches correspondent à ceux d'un utilisateur enregistré, l'ID utilisateur est renvoyé en tant que propriétaire du verrou. Sinon, le nom de travail/l'ID utilisateur associé à l'identificateur d'espace adresse est renvoyé en tant que propriétaire du verrou.
Un message de console (FEK513W) avec les informations d'enregistrement s'affichent si l'enregistrement n'aboutit pas. Cela permet à un opérateur de mettre les valeurs en correspondance en fonction de la sortie d'une commande opérateur DISPLAY GRS,RES=(*,dataset*) afin de trouver le propriétaire du verrou.
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 (voir le Commandes de l'opérateur). Les verrous du fichier actif appartenant à cet utilisateur sont libérés lors du processus.
La figure 46 présente les répertoires de 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, son mode de changement et qui gère les données qu'il contient.
Les données de certains répertoires (/var/rdz/projects/, par exemple) sont gérées par des administrateurs non système (des responsables de projet, par exemple) susceptibles de ne pas détenir les droits de mise à jour dans z/OS UNIX. Si un seul ID utilisateur gère les fichiers, il n'y a aucun problème lorsque l'ID utilisateur devient le propriétaire du répertoire et de tous les éléments qu'il contient.
chown -R IBMUSER /var/rdz/projects/
Lorsque plusieurs ID utilisateur ont besoin des droits de mise à jour du répertoire, vous pouvez gérer les bits groupe-droits.
ADDGROUP RDZPROJ OMVS(GID(1200)) CONNECT IBMUSER GROUP(RDZPROJ) ALTUSER IBMUSER DFLTGRP(RDZPROJ)
chgrp -R IBMUSER /var/rdz/projects/
chmod -R 775 /var/rdz/projects/
Contrairement à des 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 dans Compréhension 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.
Les rubriques suivantes sont traitées dans le présent chapitre :
La figure 47 affiche une présentation de base des sous-systèmes au moyen desquels des charges de travail de Developer for System z sont présentées à WLM.
Le gestionnaire de déploiement d'application (ADM) est actif au sein d'une région CICS, et il suivra donc suivra les règles de classification CICS dans WLM.
Le démon RSE (RSED), le démon Lock (LOCKD) 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 47 restent dans le système suffisamment longtemps pour être visibles, vous devez cependant être conscient 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 (une partie de) le 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 services utilisés par Developer for System z, comme File Manager (FMNCAS) ou z/OS UNIX REXEC (génération USS) créent des espaces adresse.
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 29 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 30 Le Tableau 2 répertorie des qualificateurs supplémentaires que vous pouvez utiliser pour attribuer un 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 31 répertorie les espaces adresse utilisés par Developer for System z. z/OS UNIX substituera le "x" dans la colonne "Nom de la tâche" par un nombre aléatoire de 1 caractère.
Description | Nom de la tâche | Charge de travail |
---|---|---|
Moniteur de travaux JES | JMON | STC |
Démon lock | LOCKD | 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) | <userid> et <userid>x | OMVS |
Génération MVS (travail par lots) | * | JES |
Génération z/OS UNIX (commandes shell) | <ID utilisateur>x | OMVS |
Shell z/OS UNIX | <ID utilisateur> | OMVS |
Tâche File Manager | <ID utilisateur>x | OMVS |
Gestionnaire de déploiement d'application | CICSTS | CICS |
Les remarques générales suivantes relatives à WLM peuvent vous aider à bien définir les définitions d'objectifs correctes pour Developer for System z :
Lors de l'utilisation des objectifs de temps de réponse :
Lors de l'utilisation des objectifs de vitesse :
Toutes les tâches démarrées de Developer for System z, démon RSE, démon Lock 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 |
Démon lock | LOCKD | STC |
Démon RSE | RSED | STC |
Le moniteur de travaux JES fournit tous les services liés à JES comme des soumissions de travaux, la consultation de fichiers spoule et l'exécution de commande 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 démon Lock interroge les tables de mise en file d'attente GRS (sérialisation d'accès des ressources partagées) lors d'une demande du client ou de l'opérateur et fait correspondre le résultat par rapport à des utilisateurs Developer for System z connus. 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 à un utilisation des ressources 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 substituera le "x" de la colonne "Nom de la tâche" par un nombre aléatoire de 1 caractère.)
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) | <userid> et <userid>x | OMVS |
Génération z/OS UNIX (commandes shell) | <ID utilisateur>x | OMVS |
Shell z/OS UNIX | <ID utilisateur> | OMVS |
Tâche File Manager | <ID utilisateur>x | 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 mineures (unités d'exécution spécifiques de l'utilisateur) à l'intérieure 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.
Le 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) doit démarrer une tâche qui exécute plusieurs commandes shell z/OS UNIX shell 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 des commande shell z/OS UNIX é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.
Bien qu'il ne s'agisse pas d'espace adresse dans Developer for System z, les processus enfant File Manager générés sont répertoriés ici car ils peuvent être démarrés sur la demande d'un client Developer for System z client ; ces tâches utilisent la même convention d'attribution de nom que des tâches Developer for System z. Ces tâches File Manager traitent des actions de fichiers MVS complexes, comme une édition formatée d'un fichier VSAM. L'usage des ressources dépend fortement des actions des utilisateurs et donc fluctuera, mais on s'attend à être de type minimal à modéré.
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.
Lorsqu'un client initie une génération pour un projet MVS, Developer for System z doit démarrer une tâche en traitement par lots 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. Différentes stratégies d'objectifs à performances modérées peuvent être recommandées, selon des circonstances locales.
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.
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 qui sont actives dans cette région CICS, et ne sont donc pas abordées en détails.
WLM prend en charge plusieurs type de gestion que vous pouvez utiliser pour CICS :
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. WLM utilise les règles de classification JES ou STC pour les espaces adresse, mais n'utilise pas les règles de classification des sous-systèmes pour des 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. WLM utilise les règles de classification JES ou STC pour les espaces adresse et les règles de classification des sous-systèmes CICS pour des transactions.
Comme indiqué dans le Compréhension de Developer for System z, 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 16 unités d'exécution, d'une certaine quantité de mémoire et éventuellement d'un ou de plusieurs espaces adresses implique de configurer correctement Developer for System z et z/OS.
Les rubriques suivantes sont traitées dans le présent chapitre :
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).
Les tableaux ci-dessous présentent les nombres d'espaces adresses, de processus et d'unités d'exécution utilisés par Developer for System z. Plus d'informations sur les nombres présentés ici sont disponibles dans les sections suivantes :
Le tableau 37 donne une présentation générale des ressources essentielles utilisées par les tâches démarrées Developer for System z. Ces ressources ne sont attribuées qu'une seule fois. Elles sont partagées par tous les clients Developer for System z.
Tâche démarrée | Espaces adresses | Processus | Unités d'exécution |
---|---|---|---|
JMON | 1 | 1 | 3 |
LOCKD | 1 | 3 | 10 |
RSED | 1 | 3 | 11 |
RSEDx | (a) | 2 | 10 |
Le tableau 38 donne une présentation générale des ressources essentielles utilisées par les logiciels requis. Ces ressources sont attribuées pour chaque client Developer for System z qui appelle la fonction associée.
Logiciels requis | Espaces adresses | Processus | Unités d'exécution |
---|---|---|---|
Passerelle client ISPF | 1 | 2 | 4 |
APPC | 1 | 1 | 2 |
Gestionnaire de fichiers | 1 | 1 | 2 |
Le tableau 39 donne une présentation générale des ressources essentielles utilisées par chaque client Developer for System z lors de l'exécution de la fonction spécifiée. Les valeurs non numériques (ISPF, par exemple) font référence à la valeur correspondante du tableau 38.
Action de l'utilisateur
|
Espaces adresses
ID utilisateur |
Processus
ID utilisateur |
Unités d'exécution ID utilisateur RSEDx JMON |
||
---|---|---|---|---|---|
Connexion | - | - | - | 16 | 1 |
Temporisateur pour le délai d'inactivité | - | - | - | 1 | - |
Dé veloppement de PDS(E) | ISPF | ISPF | ISPF | - | - |
Ouverture du fichier | ISPF | ISPF | ISPF | - | - |
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 | 4 | - |
CARMA (ispf) | 4 | 4 | 7 | 5 | - |
SCLMDT | ISPF | ISPF | ISPF | - | - |
File Manager Integration | ISPF + FM | ISPF + FM | ISPF + FM | - | - |
Fault Analyzer Integration | - | - | - | - | - |
Le tableau 40 répertorie les espaces adresses utilisés par Developer for System z, où "u" de la colonne "Nombre" indique que la quantité doit être multipliée par le nombre d'utilisateurs actifs simultanés de la fonction. z/OS UNIX remplace "x" de la colonne "Nom de la tâche" par un numéro à un seul chiffre aléatoire.
Nombre | Description | Nom de la tâche | Partagé | Se termine après |
---|---|---|---|---|
1 | Moniteur de travaux JES | JMON | Oui | Jamais |
1 | Démon lock | LOCKD | Oui | Jamais |
1 | Démon RSE | RSED | Oui | Jamais |
(a) | Pool d'unités d'exécution RSE | 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) | (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 |
(c) | Gestionnaire de fichiers | <ID utilisateur>x | Non | Fin de la tâche |
Utilisez la formule de la figure 48 pour estimer le nombre maximal d'espaces adresses utilisés par Developer for System z.
Où
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) |
Utilisez la formule de la figure 49 pour estimer le nombre maximal d'espaces adresses utilisés par le client Developer for System z (sans compter les espaces adresses temporaires non documentés).
Où
Les définitions du tableau 41 peuvent limiter le nombre réel d'espaces adresses.
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 adresses |
ASCHPMxx | MAX | Limite le nombre de demandeurs APPC pour le service Commandes TSO (APPC) |
Le tableau 42 répertorie le nombre de processus par espace adresse utilisés par Developer for System z. où "u" de la colonne "Espaces adresses" indique que la quantité doit être multipliée par le nombre d'utilisateurs actifs simultanés de la fonction.
Processus | Espaces adresses | Description | ID utilisateur |
---|---|---|---|
1 | 1 | Moniteur de travaux JES | STCJMON |
3 | 1 | Démon lock | STCLOCK |
3 | 1 | Démon RSE | STCRSE |
2 | (a) | Pool d'unités d'exécution RSE | STCRSE |
2 | (b) | Passerelle client ISPF (service Commandes TSO et SCLMDT) | <ID utilisateur> |
1 | 1u | Service Commandes TSO (APPC) | <ID utilisateur> |
1 | 1u | CARMA (lot) | <ID utilisateur> |
1 | 1u | CARMA (crastart) | <ID utilisateur> |
1 | 1u | CARMA (ispf) | <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> |
1 | (c) | Gestionnaire de fichiers | <ID utilisateur> |
(5) | (u) | SCLM Developer Toolkit | <ID utilisateur> |
Utilisez la formule de la figure 50 pour estimer le nombre maximal de processus utilisés par Developer for System z.
Où
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) |
Utilisez la formule de la figure 51 pour estimer le nombre maximal de processus utilisés par le client Developer for System z (sans compter les espaces adresses temporaires non documentés).
Où
Les définitions du tableau 43 peuvent limiter le nombre réel de processus.
Adresse | Limite | Ressources affectées |
---|---|---|
BPXPRMxx | MAXPROCSYS | Limite le nombre de processus |
BPXPRMxx | MAXPROCUSER | Limite le nombre de processus par UID z/OS UNIX |
Remarque :
Le tableau 44 répertorie le nombre d'unités d'exécution utilisées par les fonctions sélectionnées de Developer for System z. La lettre "u" des colonnes "Unités d'exécution" indique que la quantité doit être multipliée par le nombre d'utilisateurs actifs simultanés de la fonction. Le nombre d'unités d'exécution est indiqué par processus, étant donné que les limites sont définies à ce niveau.
Unités d'exécution |
ID utilisateur | Description | ||
---|---|---|---|---|
RSEDx | Actif | Amorce | ||
- | 3 + 1u | - | STCJMON | Moniteur de travaux JES |
- | 10 | 2 | STCLOCK | Démon lock |
- | 11 | 2 | STCRSE | Démon RSE |
10 (a) + 16u | - | 1 (a) | STCRSE | Pool d'unités d'exécution RSE |
- | 4u (b) | 1u (b) | <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) |
4u | 2u | - | STCRSE et <ID utilisateur> | CARMA (crastart) |
5u | 4u | 3u | STCRSE et <ID utilisateur> | CARMA (ispf) |
- | 1u (d) | 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 |
- | 2u (c) | - | <ID utilisateur> | Gestionnaire de fichiers |
- | (5) | - | <ID utilisateur> | SCLM Developer Toolkit |
1u | - | - | STCRSE | Temporisateur pour le délai d'inactivité |
Utilisez la formule de la figure 52 pour estimer le nombre maximal d'unités d'exécution utilisées par un pool d'unités d'exécution RSE. Utilisez la formule de la figure 53 pour estimer le nombre maximal d'unités d'exécution utilisées par le moniteur de travaux JES.
Où
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) |
4 | CARMA (crastart) |
5 | CARMA (ispf) |
Les définitions du tableau 45 peuvent limiter le nombre réel d'unités d'exécution d'un processus, qui est en général important pour les pools d'unités d'exécution RSE.
Adresse | Limite | Ressources affectées |
---|---|---|
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 de pile Java maximale. 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.
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 64 Mo.
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.
La taille d'espace adresse souhaitée est spécifiée au démarrage (avec le paramètre REGION de JCL, par exemple). Toutefois, les caractéristiques du système peuvent limiter la taille d'espace adresse réelle. Voir Taille d'espace adresse pour en savoir plus sur ces limites.
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.
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.
Comme indiqué précédemment, l'utilisation réelle de l'espace de stockage par Developer for system z est fortement influencée par l'activité de l'utilisateur. Certaines actions utilisent une quantité fixe d'espace de stockage (connexion, par exemple), d'autres étant variables (liste des fichiers avec un qualificatif de haut niveau spécifié, par exemple).
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.
Utilisez l'un des scénarios suivants si la surveillance montre que la taille de pile Java est insuffisante comparée à la charge de travail réelle :
Les affichages des figures ci-dessous présentent des exemples de cas d'utilisation des ressources pour une configuration Developer for system z par défaut avec une modification. La taille maximale de la pile Java est de 10 Mo, une petite valeur maximale donnant lieu à un centile plus important d'utilisation et à des limites de taille de la pile atteintes plus tôt.
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 LOCKD 1.60 28.7M 14183 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 LOCKD 1.64 28.8M 14259 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 LOCKD 1.66 28.9M 14268 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 LOCKD 1.67 29.0M 14277 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 LOCKD 1.68 29.0M 14286 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 LOCKD 1.69 29.1M 14295 RSED 4.64 32.9M 16229 RSED8 4.78 62.4M 27413 RSED9 4.60 56.6M 24065
La figure 54 et la figure 55 illustrent un scénario dans lequel 5 clients se connectent à un démon RSE avec un pile Java de 10 Mo.
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 LOCKD 1.73 30.5M 14179 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 LOCKD 1.76 30.6M 14255 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 LOCKD 1.78 30.6M 14255 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 LOCKD 1.78 30.6M 14255 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 figure 56 illustre un scénario dans lequel un client se connecte au démon RSE avec un pile Java de 10 Mo, puis édite un membre PDS.
La plupart de 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.
Les données peuvent être regroupées dans les catégories suivantes :
Developer for System z écrit les journaux de l'hôte associé à RSE dans les répertoires z/OS UNIX suivants (voir Identification des incidents liés à la configuration) :
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 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 total 144 drwxrwxrwx 3 IBMUSER SYS1 8192 Jul 10 12:11 IBMUSER -rw-rw-rw- 1 STCRSE STCGRP 36655 Jul 10 12:11 rsedaemon.log -rw-rw-rw- 1 STCRSE STCGRP 1893 Jul 10 12:11 rseserver.log $ ls -l /var/rdz/logs/IBMUSER total 160 -rw-rw-rw- 1 IBMUSER SYS1 3459 Jul 10 12:11 ffs.log -rw-rw-rw- 1 IBMUSER SYS1 0 Jul 10 12:11 ffsget.log -rw-rw-rw- 1 IBMUSER SYS1 0 Jul 10 12:11 ffsput.log -rw-rw-rw- 1 IBMUSER SYS1 303 Jul 10 12:11 lock.log -rw-rw-rw- 1 IBMUSER SYS1 126 Jul 10 12:11 rmt_classloader_cache.jar -rw-rw-rw- 1 IBMUSER SYS1 7266 Jul 10 12:11 rsecomm.log -rw-rw-rw- 1 IBMUSER SYS1 0 Jul 10 12:11 stderr.log -rw-rw-rw- 1 IBMUSER SYS1 0 Jul 10 12:11 stdout.log logoff $ ls -l /var/rdz/logs total 80 drwxrwxrwx 3 IBMUSER SYS1 8192 Jul 10 12:11 IBMUSER -rw-rw-rw- 1 STCRSE STCGRP 36655 Jul 10 12:11 rsedaemon.log -rw-rw-rw- 1 STCRSE STCGRP 2208 Jul 10 12:11 rseserver.log $ ls -l /var/rdz/logs/IBMUSER total 296 -rw-rw-rw- 1 IBMUSER SYS1 6393 Jul 10 12:11 ffs.log -rw-rw-rw- 1 IBMUSER SYS1 0 Jul 10 12:11 ffsget.log -rw-rw-rw- 1 IBMUSER SYS1 0 Jul 10 12:11 ffsput.log -rw-rw-rw- 1 IBMUSER SYS1 609 Jul 10 12:11 lock.log -rw-rw-rw- 1 IBMUSER SYS1 126 Jul 10 12:11 rmt_classloader_cache.jar -rw-rw-rw- 1 IBMUSER SYS1 45157 Jul 10 12:11 rsecomm.log -rw-rw-rw- 1 IBMUSER SYS1 0 Jul 10 12:11 stderr.log -rw-rw-rw- 1 IBMUSER SYS1 176 Jul 10 12:11 stdout.log stop $ ls -l /var/rdz/logs total 80 drwxrwxrwx 3 IBMUSER SYS1 8192 Jul 10 12:11 IBMUSER -rw-rw-rw- 1 STCRSE STCGRP 36655 Jul 10 12:11 rsedaemon.log -rw-rw-rw- 1 STCRSE STCGRP 2490 Jul 10 12:12 rseserver.log
La figure 57 illustre l'utilisation minimale de l'espace du système de fichiers z/OS UNIX lors de l'utilisation du niveau de débogage 2 (messages d'information).
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. 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.
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 commence à manquer et que le contrôle est actif. 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. Pour obtenir la liste des messages de la console générés par RSE, voir Messages de la console.
Les définitions du tableau 46 contrôlent les données écrites dans les répertoires de journalisation ainsi que l'emplacement de ces répertoires.
Adresse | Directive | Fonction |
---|---|---|
resecomm.properties | debug_level | Définition du niveau de détails du journal par défaut. |
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 | Activationdu 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 |
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 principal des journaux utilisateur. |
Developer for System z, et les logiciels requis (ISPF Client Gateway, par exemple) écrit é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 (voir (Facultatif) Nettoyage du répertoire WORKAREA) peut être réalisé pratiquement à tout moment.
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. La section rsed.envvars - Fichier de configuration RSE décrit chaque variable définie dans le fichier exemple, les variables ci-dessous devant faire l'objet d'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 :
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.
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. La section FEJJCNFG, fichier de configuration du moniteur de travaux JES décrit chaque variable définie dans le fichier exemple, les variables ci-dessous devant faire l'objet d'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 :
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 :
Le membre parmlib de ASCHPMxx contient des informations de planification pour le répartiteur de transactions ASCH e 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 :
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.
Les pools d'unités d'exécution RSE sont le point focal de l'activité d'utilisateur dans Developer for System z et doivent donc être contrôlés pour assurer une utilisation optimale. Le démon RSE peut s'avérer nécessaire pour les informations qui ne peuvent pas être rassemblés avec les outils de contrôle du système habituels.
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)
Des informations supplémentaires sont fournies lorsque vous utilisez l'option DETAIL de la commande de modification DISPLAY PROCESS :
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 60 MAXFILEPROC 83 103 64000 MAXPROCUSER 97 99 200 MAXTHREADS 9 14 1500 MAXTHREADTASKS 9 14 1500
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
Lors de la prise en charge d'un nombre important de clients se connectant à l'hôte, Developer for System z et votre infrastructure réseau doivent être en mesure de gérer la charge de travail. La gestion du réseau est un sujet largement abordé qui entre dans le domaine d'application de la documentation Developer for System z. Par conséquent, seuls les pointeurs suivants sont fournis.
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.FEK.HHOP760) 3062/43200 4294967147 Available /var (OMVS.VAR) 27264/31680 4294967054 Available
L'exemple de configuration ci-dessous illustre la configuration requise permettant de prendre en charge ces exigences :
Par défaut, Developer for system z tente d'ajouter 60 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 44 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 60 utilisateurs dans un seul pool d'unités d'exécution, étant donné que 60*(16+1)=1020 et que, par défaut, la valeur 1000 a été attribuée à maximum.threads.
La valeur de maximum.threads pourrait être augmentée, mais compte tenu de l'obligation de prévoir une pile moyenne Java de 5 Mo par utilisateur, la valeur de maximum.clients a été abaissée à 50. La taille maximale de la pile de Java de 256 Mo (5*50 = 250) est respectée.
Avec 50 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 10 espaces adresses de pool d'unités d'exécution.
A l'aide des formules présentées ci-avant dans ce chapitre et les critères établis au début de la présente section, il est possible de déterminer l'utilisation des ressources.
3 + A + N*(x + y + z) + (2 + N*0.01)
3 + 10 + 500*1 + 200*1 + 300*1 + (2 + 500*0.01) = 1020
x + y + z
1 + 1 + 1 = 3
7 + 2*A + N*(x + y + z) + (10 + N*0.05)
7 + 2*10 + 500*2 + 200*1 + 300*0 + (10 + 500*0.05) = 1562
(x + y + z) + 5*s
(2 + 1 + 0) + 5*0 = 3
9 + N*(16 + x + y + z) + (20 + N*0.1)
9 + 60*(16 + 1 + 4 + 0) + (20 + 60*0.1) = 1295
3 + N
3 + 500 = 503
500 + 3 = 503
Les 3 ID utilisateur supplémentaires sont pour STCJMON, STCLOCK et STCRSE, les ID utilisateur de la tâche démarrée Developer for System z.
Maintenant que les numéros d'utilisation des ressources sont connus, il est possible de personnaliser les directives de personnalisation avec les valeurs appropriées.
Ce changement est facultatif ; RSE démarrera des nouveaux pools d'unités d'exécution, si nécessaire
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. La figure 58 affiche l'utilisation des ressources après la connexion de 495 utilisateurs. (L'exemple présenté sur la figure montre seulement la connexion. Aucune action utilisateur n'est indiquée dans l'exemple.)
BPXM023I (STCRSE) ProcessId(16779764) Memory Usage(10%) Clients(50) Order(1) ProcessId(67108892) Memory Usage(16%) Clients(50) Order(2) ProcessId(67108908) Memory Usage(10%) Clients(50) Order(3) ProcessId(67108898) Memory Usage(16%) Clients(50) Order(4) ProcessId(67108916) Memory Usage(16%) Clients(50) Order(5) ProcessId(67108897) Memory Usage(16%) Clients(50) Order(6) ProcessId(67108921) Memory Usage(16%) Clients(50) Order(7) ProcessId(83886146) Memory Usage(16%) Clients(50) Order(8) ProcessId(67108920) Memory Usage(16%) Clients(50) Order(9) ProcessId(3622 ) Memory Usage(8%) Clients(45) Order(10) Jobname Cpu time Storage EXCP -------- ----------- ------- ---------- JMON 1.74 43.0M 2753 LOCKD 10.05 31.9M 24621 RSED 6.65 40.1M 41780 RSED1 8.17 187.0M 76566 RSED2 13.04 184.9M 78946 RSED3 17.77 181.1M 76347 RSED4 11.63 174.9M 74638 RSED5 15.27 172.9M 72883 RSED6 13.85 180.8M 75031 RSED7 9.79 174.3M 76636 RSED8 21.59 176.1M 70583 RSED8 18.88 184.7M 76953 RSED9 9.52 189.8M 80490
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).
zFS (zSeries File System) et HFS (Hierarchical File System) sont tous deux des systèmes de fichiers UNIX qui peuvent être utilisés dans un environnement z/OS UNIX. Cependant, zFS fournit les fonctions et avantages suivants :
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 ci-avant, 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 ci-avant 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).
Afin d'améliorer les performances des contrôles d'autorisations d'accès effectués pour z/OS UNIX, définissez le profil BPX.SAFFASTPATH dans la classe FACILITY de votre logiciel de sécurité. Cela réduit le temps système des contrôles des droits d'accès de z/OS UNIX pour une large plage d'opérations. Cette gamme comprend le contrôle de l'accès aux fichiers, le contrôle de l'accès aux communications interprocessus, et le contrôle de propriété de processus. Pour plus d'informations sur ce profil, voir 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 des informations détaillées sur le 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 par défaut d'une machine virtuelle z/OS Java (JVM) est 1 mégaoctet. La taille maximale est 64 mégaoctets. Les limites peuvent être définies avec les options de ligne de commande -Xms (initiale) et -Xmx (maximale) Java.
Dans Developer for System z, les options de ligne de commande Java sont définies dans la directive _RSE_JAVAOPTS de rsed.envvars (voir la section Définition de paramètres de démarrage Java supplémentaires avec _RSE_JAVAOPTS).
#_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.
Pour activer l'option -Xquickstart pour le serveur RSE, ajoutez la directive suivante à la fin de rsed.envvars :
_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.
Pour activer le partage de classe pour le serveur RSE, ajoutez la directive suivante à la fin de rsed.envvars. La première instruction définit un cache nommé RSE avec accès de groupe et permet au serveur RSE de démarrer même si le partage de classes échoue. La seconde instruction est facultative. Elle définit la taille du cache à 6 mégaoctets (la valeur par défaut du système étant 16 mégaoctets). La troisième instruction ajoute les paramètres de partage de classe aux options de démarrage Java.
_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.
Certains paramètres de SYS1.PARMLIB(BPXPRMxx) affectent les performances des classes partagées. L'emploi des mauvais paramètres peut arrêter le fonctionnement des classes partagées. Ces paramètres peuvent également avoir un impact sur les performances. Pour de plus amples informations sur les implications relatives aux performances et à l'utilisation de ces paramètres, voir les documents MVS Initialization and Tuning Reference (SA22-7592) et UNIX System Services Planning (GA22-7800). Les paramètres BPXPRMxx les plus significatifs qui affectent le fonctionnement des classes partagées sont :
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.
La ligne de commande Java -Xshareclasses peut prendre un certain nombre d'options, dont certaines sont des utilitaires de gestion de cache. Trois d'entre-elles sont présentées dans l'exemple ci-après ($ est l'invite z/OS UNIX). Pour une présentation complète des options de ligne de commande prises en charge, voir le document Java SDK and Runtime Environment User Guide.
$ 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.
Habituellement, la définition des ressources dans CICS est gérée par un administrateur système CICS. Autoriser les développeurs d'applications à définir les ressources CICS n'est pas si simple, pour les raisons suivantes :
Developer for System z aborde ces questions en autorisant les administrateurs CICS à contrôler les valeurs par défaut de la 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 intégrante 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.
Pour plus d'informations sur les tâches requises pour configurer le gestionnaire de déploiement d'application sur votre système hôte, voir (Facultatif) Gestionnaire de déploiement d'application.
La personnalisation du gestionnaire de déploiement d'application ajoute les services suivants à Developer for System z :
Le serveur de définition de ressource CICS (CRD) du gestionnaire de déploiement d'application se compose du serveur CRD lui-même, d'un référentiel CRD, des définitions de ressource CICS associées, des fichiers de liens de service Web et d'un exemple de gestionnaire des messages de pipeline. Le serveur CRD doit être exécuté dans une région gérant le Web (WOR), référencée dans la documentation de Developer for System z sous le terme de région de connexion CICS primaire.
Voir le centre de documentation Developer for System z (http://publib.boulder.ibm.com/infocenter/ratdevz/v7r6/index.jsp) pour en savoir plus sur les services du gestionnaire de déploiement d'application disponibles dans la version en cours de Developer for System z.
Les versions 1.4 et ultérieures de CICS Transaction Server proposent un support pour l'interface HTTP reposant sur 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, le cas échéant. 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 avertissements relatives aux définitions en double lorsque la deuxième 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 vos définitions de ressources CICS, la directive CICSPlex SM EYUPARM BASLOGMSG doit être définie sur (YES) pour la consignation à créer.
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. Voir le (Facultatif) Gestionnaire de déploiement d'application pour plus d'informations sur la personnalisation des ID 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.
Les commandes RACF suivantes fournissent un exemple de procédé de protection des transactions du serveur CRD. Voir RACF Security Guide for CICSTS pour plus d'informations relatives à la définition de la sécurité CICS.
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 d'incident de fonction dans le gestionnaire de déploiement d'application, recherchez dans le fichier journal CICS les messages s'apparentant au suivant, puis procédez à l'action corrective (voir 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 offre les fonctions suivantes :
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). Pour plus d'informations, voir Configuration personnalisée.
Les instructions de contrôle d'entrée permettent de mettre à jour le référentiel CRD pour un environnement de test CICS dans lequel les règles de syntaxe suivantes sont d'application :
Les exemples de définition ci-dessous suivent la structure des commandes DFHCSDUP (voir le document CICS Resource Definition Guide for CICSTS). La seule différence concerne l'insertion des mots clés d'autorisation d'affichage suivants pour regrouper les valeurs d'attribut en trois ensembles de droits :
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 étapes suivantes décrivent l'activation de la prise en charge d'URIMAP, si vous utilisez un ancien référentiel CRD :
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.
Cette annexe 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.
Depuis la version 7.1, Developer for System z permet de choisir le mode d'accès au service Commandes TSO.
Consultez le fichier rsed.envvars pour déterminer la méthode d'accès utilisée pour les hôtes de la version 7.1 ou d'une version supérieure. Si les valeurs par défaut ont été utilisées pendant la procédure de configuration, rsed.envvars se trouve dans /etc/rdz/.
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.
La section principale du fichier de configuration définit les noms de définition de données et les concaténations de fichiers associées, comme ceux de l'exemple suivant :
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
Par défaut, la passerelle client TSO/ISPF crée un profil ISPF temporaire pour le service Commandes TSO. Cependant, vous pouvez demander à la passerelle client TSO/ISPF z d'utiliser une copie d'un profil ISPF existant. La clé est ici l'instruction _RSE_CMDSERV_OPTS du fichier rsed.envvars.
#_RSE_CMDSERV_OPTS="$_RSE_CMDSERV_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.
Les variables suivantes peuvent être utilisées dans le nom du fichier :
L'instruction allocjob du fichier ISPF.conf (mise en commentaire par défaut) pointe sur une commande exec qui peut être utilisée pour fournir des allocations de fichiers supplémentaires par ID utilisateur.
*allocjob = FEK.#CUST.CNTL(CRAISPRX)
Supprimez la mise en commentaire de l'instruction (en retirant l'astérisque (*) initial) et fournissez la référence complète à la commande exec d'allocation pour utiliser cette fonction.
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.
Un certain nombre de variations de ce scénario permettent d'utiliser les procédures d'ouverture de session TSO :
Si les scénarios exec d'allocation décrits ci-dessus ne répondent pas à vos besoins spécifiques, vous pouvez créer différentes instances de serveur de communication RSE Developer for System z,qui utilisent chacune leur 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 -> modification : _CMDSERV_CONF_HOME=/etc/rdz/tso2 -> suppression de la mise en commentaire et modification : -Ddaemon.log=/var/rdz/logs/tso2 -> ajout à la fin : # -- NECESSAIRE POUR TROUVER LES FICHIERS DE CONFIGURATION RESTANTS CFG_BASE=/etc/rdz CLASSPATH=.:$CFG_BASE:$CLASSPATH # -- $ oedit /etc/rdz/tso2/ISPF.conf -> modification : modifier si nécessaire
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 _CMDSERV_CONF_HOME de rsed.envvars doit être mise à jour pour définir le nouveau répertoire de base ISPF.conf, et daemon.log doit être mis à jour pour définir le nouvel emplacement du fichier journal (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 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 _CMDSERV_WORK_HOME 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.
Pour plus d'informations sur les actions présentées ci-dessus, voir les sections correspondantes dans ce document.
La définition d'une transaction APPC est constituée de paramètres APPC et d'un langage JCL de transaction. L'exemple de JCL utilisé pour créer une transaction Developer for System z APPC, FEK.#CUST.JCL(FEKAPPCC), renferme deux options de définition du JCL de transaction, avec et sans prise en charge ISPF.
//SYSIN DD DDNAME=SYSINISP * use SYSINTSO or SYSINISP
Le client obtient l'environnement TSO/ISPF défini dans le JCL de transaction, de sorte qu'en personnalisant cette section, suivant les règles de définition de données classiques, vous pouvez personnaliser l'environnement pour le client.
... //CMDSERV EXEC PGM=IKJEFT01,DYNAMNBR=50, // PARM='ISPSTART CMD(%FEKFRSRV TIMEOUT=60) NEWAPPL(ISR) NESTMACS' //SYSPROC DD DISP=SHR,DSN=FEK.SFEKPROC //ISPPLIB DD DISP=SHR,DSN=ISP.SISPPENU //ISPMLIB DD DISP=SHR,DSN=ISP.SISPMENU //ISPTLIB DD DISP=SHR,DSN=ISP.SISPTENU //ISPSLIB DD DISP=SHR,DSN=ISP.SISPSENU //ISPPROF DD DISP=(NEW,DELETE,DELETE),UNIT=SYSALLDA, // SPACE=(TRK,(1,1,5)),LRECL=80,RECFM=FB //SYSTSPRT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSTSIN DD DUMMY //MYDD DD DISP=SHR,DSN=HLQ1.LLQ1 // DISP=SHR,DSN=HLQ2.LLQ2
Si la prise en charge d'ISPF est sélectionnée, Developer for System z crée par défaut un profil ISPF temporaire pour le service Commandes TSO. Cependant, vous pouvez demander à Developer for System z d'utiliser une copie d'un profil ISPF existant. Comme décrit dans l'exemple de travail FEK.SFEKSAMP(FEKAPPCC), vous devez procéder comme suit :
...
//COPY EXEC PGM=IEBCOPY * (optional) clone existing ISPF profile
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DISP=SHR,DSN=&SYSUID..ISPROF//SYSUT2 DD DISP=(MOD,PASS),DSN=&&PROF,
// UNIT=SYSALLDA,
// LIKE=&SYSUID..ISPROF//*
//CMDSERV EXEC PGM=IKJEFT01,DYNAMNBR=50,
// PARM='ISPSTART CMD(%FEKFRSRV TIMEOUT=60) NEWAPPL(ISR) NESTMACS'
//*ISPPROF DD DISP=(NEW,DELETE,DELETE),UNIT=SYSALLDA,
//* SPACE=(TRK,(1,1,5)),LRECL=80,RECFM=FB
//ISPPROF DD DISP=(OLD,DELETE,DELETE),DSN=&&PROF
L'exemple de JCL de transaction appelle le service Commandes TSO directement en transmettant son nom (FEKFRSRV) en tant que paramètre au programme IKJEFT01. Vous pouvez effectuer des modifications pour appeler une autre commande exec. Cette commande exec peut effectuer des allocations en fonction de l'ID utilisateur courant, puis appeler le service Commandes TSO.
Contrairement à la méthode d'accès par passerelle client TSO/ISPF, les variables enregistrées dans le profil ISPF de l'utilisateur peuvent être utilisées par cette commande exec en vue de personnaliser l'environnement. N'oubliez pas cependant que les mises à jour de ce profil sont perdues à la fin de la session étant donné que vous utilisez une copie temporaire et non le profil réel.
Notez que l'utilisation d'une commande exec d'allocation dans la transaction APPC n'est pas prise en charge et que la description ci-dessus est conservée en l'état.
Si vous avez besoin d'environnements TSO multiples, vous pouvez créer différentes instances de serveur de communication RSE Developer for System z, utilisant chacune leur propre transaction APPC. 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 $ ls /etc/rdz/tso2/ rsed.envvars $ oedit /etc/rdz/tso2/rsed.envvars -> suppression de la mise en commentaire et modification : _FEKFSCMD_TP_NAME_=FEKFTSO2 -> suppression de la mise en commentaire et modification : -Ddaemon.log=/var/rdz/logs/tso2 -> ajout à la fin : # -- NECESSAIRE POUR TROUVER LES FICHIERS DE CONFIGURATION RESTANTS CFG_BASE=/etc/rdz CLASSPATH=.:$CFG_BASE:$CLASSPATH # --
Les commandes ci-dessus créent un répertoire tso2 et copie les fichiers de configuration Developer for System z à modifier dans le nouvel emplacement. La variable _ FEKFSCMD_TP_NAME_ du fichier rsed.envvars doit être mise à jour pour définir le nouveau nom de la transaction APPC, et daemon.log doit être mis à jour pour définir le nouvel emplacement du journal du démon (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 tso2.
//FEKAPPCC JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1),NOTIFY=&SYSUID//* //TPADD EXEC PGM=ATBSDFMU //SYSSDLIB DD DISP=SHR,DSN=SYS1.APPCTP //SYSSDOUT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSIN DD DDNAME=SYSINISP * use SYSINTSO or SYSINISP //SYSINISP DD DATA,DLM='QT' TPADD TPNAME(FEKFTSO2) ACTIVE(YES) TPSCHED_DELIMITER(DLM1) KEEP_MESSAGE_LOG(ERROR) MESSAGE_DATA_SET(&SYSUID..FEKFTSO2.&TPDATE..&TPTIME..LOG) DATASET_STATUS(MOD) CLASS(A) JCL_DELIMITER(DLM2) //FEKFTSO2 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1) //* //CMDSERV EXEC PGM=IKJEFT01,DYNAMNBR=50, // PARM='ISPSTART CMD(%FEKFRSRV TIMEOUT=60) NEWAPPL(ISR) NESTMACS' //SYSPROC DD DISP=SHR,DSN=FEK.SFEKPROC //ISPPLIB DD DISP=SHR,DSN=ISP.SISPPENU //ISPMLIB DD DISP=SHR,DSN=ISP.SISPMENU //ISPTLIB DD DISP=SHR,DSN=ISP.SISPTENU //ISPSLIB DD DISP=SHR,DSN=ISP.SISPSENU //ISPPROF DD DISP=(NEW,DELETE,DELETE),UNIT=SYSALLDA, // SPACE=(TRK,(1,1,5)),LRECL=80,RECFM=FB //SYSTSPRT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSTSIN DD DUMMY //MYDD DD DISP=SHR,DSN=HLQ1.LLQ1 // DISP=SHR,DSN=HLQ2.LLQ2 DLM2 DLM1 QT
Créez ensuite une transaction APPC en personnalisant et en soumettant l'exemple de travail FEK.#CUST.JCL(FEKAPPCC), comme indiqué dans l'exemple ci-dessus. Outre la personnalisation normale (décrite dans le code JCL), vous devez associer TPNAME à TPNAME(FEKFTSO2) pour qu'il corresponde à la définition _FEKFSCMD_TP_NAME_ du nouveau fichier rsed.envvars. Il est également recommandé de modifier le nom dans la variable MESSAGE_DATA_SET et le nom JOB dans le JCL de transaction.
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.
Pour plus d'informations sur les actions présentées ci-dessus, voir les sections correspondantes dans ce document.
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 annexe 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.
Pour plus d'informations sur les exemples de commande ci-dessous qui permettent d'archiver et de restaurer le répertoire d'installation de Developer for System z, voir le document UNIX System Services Command Reference (SA22-7802)
Les fichiers de configuration (et le code) Developer for System z peuvent être partagés entre différents systèmes dans un sysplex, chaque système exécutant sa propre copie identique de Developer System z, si de nouvelles instructions sont respectées.
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é ci-dessus, 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 -> Suppression de la mise en commentaire et modification : -Ddaemon.log=/var/rdz/logs/ssl -> ajout à la fin : # -- NECESSAIRE POUR TROUVER LES FICHIERS DE CONFIGURATION RESTANTS CFG_BASE=/etc/rdz CLASSPATH=.:$CFG_BASE:$CLASSPATH # -- $ oedit /etc/rdz/ssl/ssl.properties -> modification : modifier si nécessaire
Les commandes ci-dessus copient les fichiers de configuration Developer for System z à modifier dans le répertoire qui vient d'être créé, ssl. La variable daemon.log du fichier rsed.envvars doit être mise à jour pour définir le nouvel emplacement du journal du journal (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 ci-dessus, voir les sections correspondantes dans ce document.
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 :
//SYSIN DD * CREATE PROCEDURE SYSPROC.ELAXMRXX ( IN FUNCTION_REQUEST VARCHAR(20) CCSID EBCDIC ... , OUT RETURN_VALUE VARCHAR(255) CCSID EBCDIC ) PARAMETER STYLE GENERAL RESULT SETS 1 LANGUAGE REXX EXTERNAL NAME ELAXMRXX COLLID DSNREXCS WLM ENVIRONMENT ELAXMWDZ PROGRAM TYPE MAIN MODIFIES SQL DATA STAY RESIDENT NO COMMIT ON RETURN NO ASUTIME NO LIMIT SECURITY USER; COMMENT ON PROCEDURE SYSPROC.ELAXMRXX IS 'PLI & COBOL PROCEDURE PROCESSOR (ELAXMRXX), INTERFACE LEVEL 0.01'; GRANT EXECUTE ON PROCEDURE SYSPROC.ELAXMRXX TO PUBLIC; //
La présente section met en évidence les modifications de l'installation et de la configuration par rapport aux précédentes éditions du produit. Elle fournit également des instructions générales pour la migration de cette édition. Pour de plus amples informations, consultez les sections associées dans ce manuel.
Si vous disposez d'une version antérieure de Developer for System z, il est recommandé de sauvegarder les fichiers personnalisés associés avant d'installer cette version d'IBM Developer for System z.
Les fichiers personnalisables de Developer for system z sont disponibles dans les emplacements suivants :
Les configurations précédentes de Developer for system z documentent également les modifications apportées aux fichiers de configuration d'autres produits.
définissez une classe de transaction APPC du service Commandes TSO
définissez les valeurs par défaut du système z/OS UNIX
démarrez les serveurs lors de l'initialisation
ajoutez FEK.SFEKLPA à la zone LPA
accordez l'autorisation APF à FEK.SFEKAUTH
ajoutez FEK.SFEKAUTH et FEK.SFEKLOAD à LINKLIST
définissez une transaction APPC pour le service Commandes TSO
associez un programme transactionnel APPC à un groupe de performances TSO
associez un environnement d'application à une procédure mémorisée DB2
définissez une classe de transaction APPC du service Commandes TSO
définissez les valeurs par défaut du système z/OS UNIX
accordez l'autorisation APF à FEK.SFEKLOAD
définissez le port du démon RSE
définissez le service du démon RSE
définissez l'emplacement du serveur de commandes TSO
définissez une transaction APPC pour le service Commandes TSO
associez un programme transactionnel APPC à un groupe de performances TSO
associez un environnement d'application à une procédure mémorisée DB2
définissez une classe de transaction APPC du service Commandes TSO
définissez les valeurs par défaut du système z/OS UNIX
accordez l'autorisation APF à FEK.SFEKLOAD
définissez le port du démon RSE
définissez le service du démon RSE
définissez une transaction APPC pour le service Commandes TSO
associez un programme transactionnel APPC à un groupe de performances TSO
associez un environnement d'application à une procédure mémorisée DB2
Les notes de migration suivantes sont spécifiques de la version 7.6.1. Elles sont valides pour la migration depuis la version 7.6 ou viennent s'ajouter aux notes de migration vers la version 7.6 existante.
Le tableau 47 présente les fichiers qui sont personnalisés dans la version 7.6. Notez que les exemples de bibliothèque Developer for System z, FEK.SFEKSAMP, FEK.SFEKSAMV et /usr/lpp/rdz/samples/, sont fournies avec davantage de membres personnalisables que ceux répertoriés ici (le code source CARMA et les travaux pour leur compilation, par exemple).
Membre/Fichier | Emplacement par défaut | Fonction | Remarques sur la migration |
---|---|---|---|
FEKSETUP |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
Langage JCL permettant de créer des fichiers et des répertoires et de les remplir avec des fichiers personnalisables | Mis à jour pour inclure de nouveaux membres personnalisables |
JMON |
FEK.SFEKSAMP(FEJJJCL) [FEK.#CUST.PROCLIB] |
Langage JCL pour le moniteur de travaux JES | Option ajoutée pour modifier les options LE |
FEJJJCL |
FEK.SFEKSAMP [FEK.#CUST.PROCLIB(JMON)] |
Nom fourni pour le membre JMON | Voir membre JMON |
RSED |
FEK.SFEKSAMP(FEKRSED) [FEK.#CUST.PROCLIB] |
Langage JCL pour le démon RSE | none |
FEKRSED |
FEK.SFEKSAMP [FEK.#CUST.PROCLIB(RSED)] |
Nom fourni pour le membre RSED | Voir membre RSED |
LOCKD |
FEK.SFEKSAMP(FEKLOCKD) [FEK.#CUST.PROCLIB] |
JCL pour le démon lock | NOUVEAU, doit être personnalisé |
FEKLOCKD |
FEK.SFEKSAMP [FEK.#CUST.PROCLIB(LOCKD)] |
Nom fourni pour le membre LOCKD | Voir membre LOCKD |
ELAXF* |
FEK.SFEKSAMP [FEK.#CUST.PROCLIB] |
Code JCL pour les générations de projets distants, etc. | none |
FEKRACF |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
Langage JCL pour les définitions de sécurité | Mises à jour mineures |
FEJJCNFG |
FEK.SFEKSAMP [FEK.#CUST.PARMLIB] |
Fichier de configuration du moniteur de travaux JES | De nouvelles directives facultatives ont été ajoutées |
FEJTSO |
FEK.SFEKSAMP [FEK.#CUST.CNTL] |
Langage JCL pour les soumissions TSO | none |
CRA$VMSG |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
Le langage JCL doit créer la méthode d'accès VSAM au message du gestionnaire CARMA | none |
CRA$VDEF |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
Le langage JCL doit créer la méthode d'accès VSAM à la configuration du gestionnaire CARMA | none |
CRA$VSTR |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
Le langage JCL doit créer la méthode d'accès VSAM aux informations personnalisées du gestionnaire CARMA | none |
CRASUBMT |
FEK.SFEKSAMP [FEK.#CUST.CNTL] |
Démarrage par lots CARMA CLIST | none |
CRASUBCA |
FEK.SFEKSAMP [FEK.#CUST.CNTL] |
Liste de commandes de démarrage du traitement par lots CARMA pour CA Endevor SCM RAM | NOUVEAU, la personnalisation est facultative |
CRASHOW |
FEK.SFEKSAMP [FEK.#CUST.PARMLIB] |
Configuration CARMA pour CA Endevor SCM RAM | NOUVEAU, la personnalisation est facultative |
CRATMAP |
FEK.SFEKSAMP [FEK.#CUST.PARMLIB] |
Configuration CARMA pour CA Endevor SCM RAM | NOUVEAU, la personnalisation est facultative |
CRANDVRA | FEK.SFEKPROC | REXX d'allocation CARMA pour CA Endevor SCM RAM | NOUVEAU, la personnalisation est facultative |
CRAISPRX |
FEK.SFEKSAMP [FEK.#CUST.CNTL] |
Exemple de commande exec d'allocation de définition de données pour CARMA à l'aide de la passerelle client TSO/ISPF | none |
CRA#VSLM |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
Langage JCL de création de la méthode d'accès VSAM au message de la RAM du SCLM | none |
CRA#ASLM |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
Langage JCL de création de fichiers de la RAM du SCLM | none |
CRA#VPDS |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
Langage JCL de création de la méthode d'accès VSAM au message de la RAM du PDS | none |
CRA#CRAM |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
Langage JCL de compilation de la RAM du squelette | none |
CRA#VCAD |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL de création du VSAM de configuration CARMA pour CA Endevor SCM RAM | NOUVEAU, la personnalisation est facultative |
CRA#VCAS |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL de création du VSAM de personnalisation des informations CARMA pour CA Endevor SCM RAM | NOUVEAU, la personnalisation est facultative |
CRA#UADD |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL de fusion des définitions RAM | NOUVEAU, la personnalisation est facultative |
CRA#UQRY |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL d'extraction des définitions RAM | NOUVEAU, la personnalisation est facultative |
CRAXJCL |
FEK.SFEKSAMP [FEK.#CUST.ASM] |
Exemple de code source pour le remplacement de IRXJCL | none |
CRA#CIRX |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
Langage JCL de compilation de CRAXJCL | none |
ADNCSDRS |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
Langage JCL de définition du serveur CRD RESTful dans la région CICS primaire | NOUVEAU, la personnalisation est facultative |
ADNCSDTX |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
Langage JCL de définition d'autres ID transaction dans la région CICS | NOUVEAU, la personnalisation est facultative |
ADNTXNC |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
Langage JCL de création d'autres ID transaction | NOUVEAU, la personnalisation est facultative |
ADNMSGHC |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
Langage JCL de compilation d'ADNMSGHS | Renommé. S'appelait ADNCMSGH |
ADNMSGHS |
FEK.SFEKSAMP [FEK.#CUST.COBOL] |
Exemple de code source pour le gestionnaire de message de pipeline | Renommé. S'appelait ADNSMSGH |
ADNVCRD |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
Langage JCL de création du référentiel CRD | Renommé. S'appelait ADNVSAM |
ADNCSDWS |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
Langage JCL de définition du serveur CRD du service Web dans la région CICS primaire | Renommé. S'appelait ADNPCCSD |
ADNCSDAR |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL définissant le serveur CRD dans les régions CICS secondaires | Renommé. S'appelait ADNARCSD |
ADNJSPAU |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
Langage JCL de mise à jour des valeurs par défaut de CRD | Ajout de définitions pour le service RESTful. Personnalisations à refaire |
ADNVMFST |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
Langage JCL de création et de définition du référentiel de manifestes | Renommé. S'appelait ADNMFEST |
ELAXMSAM |
FEK.SFEKSAMP [FEK.#CUST.PROCLIB] |
Procédure JCL de l'espace adresse WLM du compilateur de procédures mémorisées PL/I et COBOL. | none |
ELAXMJCL |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
Langage JCL de définition du générateur de procédures mémorisées PL/I et COBOL dans DB2 | none |
FEKAPPCC |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
Le langage JCL doit créer une transaction APPC | none |
FEKAPPCL |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
Le langage JCL doit afficher une transaction APPC | none |
FEKAPPCX |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
Le langage JCL doit supprimer une transaction APPC | none |
FEKLOGS |
FEK.SFEKSAMP [FEK.#CUST.JCL] |
JCL permettant de collecter les journaux | NOUVEAU, la personnalisation est facultative |
rsed.envvars |
/usr/lpp/rdz/samples/ [/etc/rdz/] |
Variables d'environnement RSE | Les copies plus anciennes doivent être remplacées par celle-ci (les personnalisations doivent être effectuées une nouvelle fois) |
ISPF.conf |
/usr/lpp/rdz/samples/ [/etc/rdz/] |
Fichier de configuration de la passerelle client TSO/ISPF | ISP.SISPCLIB ajouté à SYSPROC pour SCLMDT |
CRASRV.properties |
/usr/lpp/rdz/samples/ [/etc/rdz/] |
Fichier de configuration du gestionnaire CARMA | none |
crastart.conf |
/usr/lpp/rdz/samples/ [/etc/rdz/] |
Fichier de configuration CARMA pour l'utilisation de CRASTART | none |
crastart.endevor.conf |
/usr/lpp/rdz/samples/ [/etc/rdz/] |
Fichier de configuration CARMA pour l'utilisation de CRASTART pour CA Endevor SCM RAM | NOUVEAU, la personnalisation est facultative |
ssl.properties |
/usr/lpp/rdz/samples/ [/etc/rdz/] |
Fichier de configuration SSL RSE | De nouvelles directives facultatives ont été ajoutées |
rsecomm.properties |
/usr/lpp/rdz/samples/ [/etc/rdz/] |
Fichier de configuration de trace RSE | none |
propertiescfg.properties |
/usr/lpp/rdz/samples/ [/etc/rdz/] |
Fichier de configuration des groupes de propriétés résidant sur l'hôte | none |
projectcfg.properties |
/usr/lpp/rdz/samples/ [/etc/rdz/] |
Fichier de configuration de projets résidant sur l'hôte | none |
FMIEXT.properties |
/usr/lpp/rdz/samples/ [/etc/rdz/] |
Fichier de configuration d'intégration de File Manager | Les copies plus anciennes doivent être remplacées par celle-ci (les personnalisations doivent être effectuées une nouvelle fois) |
uchars.settings |
/usr/lpp/rdz/samples/ [/etc/rdz/] |
Fichier de configuration des caractères non éditables | none |
Le tableau 48 présente les fichiers qui sont personnalisés dans la version 7.5. Notez que les exemples de bibliothèque Developer for System z, FEK.SFEKSAMP, FEK.SFEKSAMV et /usr/lpp/rdz/samples/ , sont fournies avec davantage de membres personnalisables que ceux répertoriés ici, tels que du code source CARMA et des travaux pour leur compilation.
Membre/Fichier | Emplacement par défaut | Fonction | Remarques sur la migration |
---|---|---|---|
FEKSETUP | FEK.SFEKSAMP
[FEK.#CUST.JCL] |
Langage JCL permettant de créer des fichiers et des répertoires et de les remplir avec des fichiers personnalisables | NOUVEAU, doit être personnalisé |
JMON | FEK.SFEKSAMP(FEJJJCL)
[FEK.#CUST.PROCLIB] |
Langage JCL pour le moniteur de travaux JES | STEPLIB remplacé par SFEKAUTH |
RSED | FEK.SFEKSAMP(FEKRSED)
[FEK.#CUST.PROCLIB] |
Langage JCL pour le démon RSE | NOUVEAU, doit être personnalisé |
ELAXF* | FEK.SFEKSAMP
[FEK.#CUST.PROCLIB] |
Langage JCL de génération de projets distants, etc. | ELAXFTSO, ELAXFCP1 et ELAXFPP1 sont nouveaux |
FEKRACF | FEK.SFEKSAMP
[FEK.#CUST.JCL] |
Langage JCL pour les définitions de sécurité | NOUVEAU, requis |
FEJJCNFG | FEK.SFEKSAMP
[FEK.#CUST.PARMLIB] |
Fichier de configuration du moniteur de travaux JES |
|
FEJTSO | FEK.SFEKSAMP
[FEK.#CUST.CNTL] |
Langage JCL pour les soumissions TSO | Le nom du travail peut à présent être une variable |
CRAISPRX | FEK.SFEKSAMP
[FEK.#CUST.CNTL] |
Exemple de commande exec d'allocation de définition de données pour CARMA à l'aide de la passerelle client TSO/ISPF | NOUVEAU, la personnalisation est facultative |
CRAXJCL | FEK.SFEKSAMP
[FEK.#CUST.ASM] |
Exemple de code source pour le remplacement de IRXJCL | NOUVEAU, la personnalisation est facultative |
CRA#CIRX | FEK.SFEKSAMP
[FEK.#CUST.JCL] |
Langage JCL de compilation de CRAXJCL | NOUVEAU, la personnalisation est facultative |
ADNSMSGH | FEK.SFEKSAMP
[FEK.#CUST.COBOL] |
Exemple de code source pour le gestionnaire de message de pipeline | Les copies plus anciennes doivent être remplacées par la présente (les personnalisations doivent être effectuées à nouveau) |
ADNPCCSD | FEK.SFEKSAMP
[FEK.#CUST.JCL] |
Langage JCL de définition du serveur CRD dans une région CICS primaire | Les copies plus anciennes doivent être remplacées par la présente (les personnalisations doivent être effectuées à nouveau) |
ADNJSPAU | FEK.SFEKSAMP
[FEK.#CUST.JCL] |
Langage JCL de mise à jour des valeurs par défaut de CRD | NOUVEAU, la personnalisation est facultative |
ADNMFEST | FEK.SFEKSAMP
[FEK.#CUST.JCL] |
Langage JCL de création et de définition du référentiel de manifestes | NOUVEAU, la personnalisation est facultative |
rsed.envvars | /usr/lpp/rdz/samples/
[/etc/rdz/] |
Variables d'environnement RSE | Les copies plus anciennes doivent être remplacées par la présente (les personnalisations doivent être effectuées à nouveau) |
ISPF.conf | /usr/lpp/rdz/samples/
[/etc/rdz/] |
Fichier de configuration de la passerelle client TSO/ISPF | Identique au fichier ISPF.conf fourni avec SCLMDT dans la v7.1 |
CRASRV.properties | /usr/lpp/rdz/samples/
[/etc/rdz/] |
Fichier de configuration du gestionnaire CARMA |
|
crastart.conf | /usr/lpp/rdz/samples/
[/etc/rdz/] |
Fichier de configuration CARMA pour l'utilisation de CRASTART | NOUVEAU, la personnalisation est facultative |
FMIEXT.properties | /usr/lpp/rdz/samples/
[/etc/rdz/] |
Fichier de configuration d'intégration de File Manager |
|
uchars.settings | /usr/lpp/rdz/samples/
[/etc/rdz/] |
Fichier de configuration des caractères non éditables | NOUVEAU, la personnalisation est facultative |
Le tableau 23 présente les fichiers qui sont personnalisés dans la version 7.1. Notez que les exemples de bibliothèque CARMA et Developer for System z CRA.SCRASAMP, FEK.SFEKSAMP et /usr/lpp/wd4z/rse/lib/ sont fournis avec davantage de membres personnalisables que ceux répertoriés ici (le code source CARMA et les travaux permettant de les compiler).
Membre/Fichier | Emplacement par défaut | Fonction | Remarques sur la migration |
---|---|---|---|
ELAXF* | FEK.SFEKSAMP | Code JCL pour les générations de projets distants et autres travaux. | ELAXFADT est nouveau |
CRA$VMSG | CRA.SCRASAMP | Le langage JCL doit créer la méthode d'accès VSAM au message du gestionnaire CARMA |
|
CRA$VDEF | CRA.SCRASAMP | Le langage JCL doit créer la méthode d'accès VSAM à la configuration du gestionnaire CARMA |
|
CRA$VSTR | CRA.SCRASAMP | Le langage JCL doit créer la méthode d'accès VSAM aux informations personnalisées du gestionnaire CARMA | Renommé. S'appelait CRASREPR |
CRASUBMT | CRA.SCRASAMP | Démarrage par lots CARMA CLIST | Ajout de DD CARMALOG |
CRA#VSLM | CRA.SCRASAMP | Langage JCL de création de la méthode d'accès VSAM au message de la RAM du SCLM | Renommé. S'appelait CRALREPR |
CRA#ASLM | CRA.SCRASAMP | Langage JCL de création de fichiers de la RAM du SCLM | Renommé. S'appelait CRASALX |
CRA#VPDS | CRA.SCRASAMP | Langage JCL de création de la méthode d'accès VSAM au message de la RAM du PDS | Renommé. S'appelait CRATREPR |
CRA#CRAM | CRA.SCRASAMP | Langage JCL de compilation de la RAM du squelette | Renommé. S'appelait CRARAMCM |
FEKAPPCC | FEK.SFEKSAMP | Le langage JCL doit créer une transaction APPC | Exploitation du support NEST ISPF |
rsed.envvars |
/usr/lpp/wd4z/rse/lib/ [/etc/wd4z/] |
Variables d'environnement RSE | Les copies plus anciennes doivent être remplacées par la présente (les personnalisations doivent être effectuées à nouveau) |
FMIEXT.properties |
/usr/lpp/wd4z/rse/lib/ [/etc/wd4z/] |
Fichier de configuration d'intégration de File Manager | NOUVEAU, doit être personnalisé |
Cette annexe vous aide à résoudre certains incidents fréquents qui peuvent survenir lors de la configuration du protocole SSL (Secure Socket Layer), ou au cours de la vérification et/ou de la modification d'une configuration existante. Elle contient un exemple de configuration pour prendre en charge les utilisateurs qui s'authentifient à 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 annexe, 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.
Une convention d'attribution de nom uniforme est utilisée dans cette annexe :
Certaines des tâches décrites ci-après 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.
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.
Le démon RSE est une application du système SSL, qui utilise un fichier de base de données de clés. Cette base de données de clés peut être un fichier physique créé par gskkyman ou un fichier de clés géré par votre logiciel de sécurité conforme à SAF (RACF, par exemple). Le serveur RSE (démarré par le démon) est une application SSL Java qui utilise un magasin de clés créé par keytool ou un fichier de clés géré par votre logiciel de sécurité.
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 |
Pour établir la connexion via SSL, le magasin de clés et le fichier de la base de données de clés sont nécessaires sous la forme d'un fichier z/OS UNIX ou d'un jeu de clés conforme à SAF :
STEPLIB=$STEPLIB:SYS1.SIEALNKE
Gardez toutefois les remarques suivantes à l'esprit :
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.
Pour obtenir des informations détaillées sur la commande RACDCERT, voir le document Security Server RACF Command Language Reference (SA22-7687).
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) SETROPTS RACLIST(FACILITY) REFRESH 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) RACDCERT ID(stcrse) ADDRING(rdzssl.racf) RACDCERT ID(stcrse) CONNECT(LABEL('rdzrse') RING(rdzssl.racf) + DEFAULT USAGE(PERSONAL))
L'exemple ci-dessus 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.
Le résultat peut être vérifié par l'intermédiaire de l'option list :
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=rdz rse ssl.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<
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.
Suivez les étapes suivantes pour créer et utiliser un certificat signé par une autorité de certification :
RACDCERT ID(stcrse) GENCERT WITHLABEL('rdzrse') . . .
RACDCERT ID(stcrse) GENREQ (LABEL('rdzrse')) DSN(dsn)
RACDCERT CERTAUTH LIST
RACDCERT CERTAUTH ALTER(LABEL('CA cert')) TRUST
Vous pouvez ajouter le certificat de l'autorité de certification de la base de données.
RACDCERT CERTAUTH ADD(dsn) WITHLABEL('CA cert') TRUST
RACDCERT ID(stcrse) ADD(dsn) WTIHLABEL('rdzrse') TRUST
RACDCERT ID(stcrse) ADDRING(rdzssl.racf)
RACDCERT ID(stcrse) CONNECT(ID(stcrse) LABEL('rdzrse') RING(rdzssl.racf))
RACDCERT ID(stcrse) CONNECT(CERTAUTH LABEL('CA cert') RING(rdzssl.racf))
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à. Dans les exemples de commandes ci-dessous, on suppose que les fichiers de configuration se trouvent dans /etc/rdz/ qui est l'emplacement utilisé par défaut pour l'étape Configuration personnalisée.
$ cd /etc/rdz $ mkdir ssl $ cp rsed.envvars ssl $ cp ssl.properties ssl $ ls ssl rsed.envvars ssl.properties
Les commandes z/OS UNIXindiquées ci-dessus créent un sous-répertoire appelé ssl pour y placer les fichiers de configuration à modifier. 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 -> Suppression de la mise en commentaire et modification : -Ddaemon.log=/var/rdz/logs/ssl -> Ajout à la fin : # -- NECESSAIRE POUR TROUVER LES FICHIERS DE CONFIGURATION RESTANTS CFG_BASE=/etc/rdz CLASSPATH=.:$CFG_BASE:$CLASSPATH # --
Les modifications ci-dessus définissent un nouvel emplacement du journal (qui est créé par le démon RSE si l'emplacement du 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 -> modification : enable_ssl=true -> suppression de la mise en commentaire et modification : daemon_keydb_file=rdzssl.racf -> suppression de la mise en commentaire et modification : daemon_key_label=rdzrse -> suppression de la mise en commentaire et modification : server_keystore_file=rdzssl.racf -> suppression de la mise en commentaire et modification : server_keystore_label=rdzrse -> suppression de la mise en commentaire et modification : server_keystore_type=JCERACFKS
Les modifications ci-dessus activent SSL et indiquent au démon 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.
Comme indiqué précédemment, nous allons créer une deuxième connexion qui utilisera la couche SSL, ce qui implique la création d'un démon RSE. Le démon RSE peut être une tâche démarrée ou un travail utilisateur. Nous utiliserons la méthode du travail utilisateur pour la configuration initiale (test). Dans les instructions suivantes, il est supposé que l'exemple de langage JCL se trouve dans FEK.#CUST.PROCLIB(RSED), qui est l'emplacement utilisé par défaut pour l'étape Configuration personnalisée:
//RSEDSSL JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1),USER=STCRSE //* //* RSE DAEMON - SSL //* //RSED PROC IVP='', * 'IVP' to do an IVP test // PORT=4047, // HOME='/usr/lpp/rdz', // CNFG='/etc/rdz/ssl' //* //RSE EXEC PGM=BPXBATSL,REGION=0M,TIME=NOLIMIT, // PARM='PGM &HOME./bin/rsed.sh &IVP &PORT &CNFG' //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 Finish, 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 Windows > Préférences... > Système distant > 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 -> modification : enable_ssl=true -> suppression de la mise en commentaire et modification : daemon_keydb_file=rdzssl.kdb -> suppression de la mise en commentaire et modification : daemon_keydb_password=rsessl -> suppression de la mise en commentaire et modification : daemon_key_label=rdzrse -> suppression de la mise en commentaire et modification : server_keystore_file=rdzssl.racf -> suppression de la mise en commentaire et modification : server_keystore_label=rdzrse -> suppression de la mise en commentaire et modification : server_keystore_type=JCERACFKS
Les modifications ci-dessus 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.
"keytool -genkey" génère une paire de clés privées et un certificat autosigné associé, qui est stocké sous la forme d'une entrée (identifiée par un alias) dans un (nouveau) magasin de clés.
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 d'auto-signature créé précédemment est valide pendant environ 10 ans (sans compter les jours intercalaires 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 -> modification : enable_ssl=true -> suppression de la mise en commentaire et modification : daemon_keydb_file=rdzssl.racf -> suppression de la mise en commentaire et modification : daemon_key_label=rdzrse -> suppression de la mise en commentaire et modification : server_keystore_file=rdzssl.jks -> suppression de la mise en commentaire et modification : server_keystore_password=rsessl -> suppression de la mise en commentaire et modification : server_keystore_label=rdzrse -> suppression de la mise en commentaire et modification facultatives : server_keystore_type=JKS
Les modifications ci-dessus 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 annexe vous aide à résoudre certains incidents fréquents qui peuvent survenir lors de la configuration du TCP/IP, ou au cours de la vérification ou de 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 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 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), nous pouvons voir 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, nous définissons cdfmvs08 etcdfmvs08.raleigh.ibm.com comme nom valide pour l'adresse IP du système z/OS.
Si nous utilisions 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 notre 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 endnetent getaddrinfo gethostbyaddr gethostbyname gethostent GetHostNumber GetHostResol GetHostString getnameinfo getnetbyaddr getnetbyname getnetent IsLocalHost Resolve sethostent setnetent |
IPv4
IPv6
|
Des incidents dans lesquels le programme de résolution TCP/IP ne parvient pas à résoudre correctement l'adresse hôte, peuvent être engendrés par un fichier de configuration manquant ou incomplet du programme de résolution. Le message lock.log suivant est une indication évidente de l'apparition de cet incident :
clientip(0.0.0.0) <> callerip(<adresse IP de l'hôte>)
Pour procéder à une vérification, exécutez le programme de vérification d'installation TCP/IP fekfivpt, comme spécifié au Vérification de l'installation. La section relative à la configuration du programme de résolution de la sortie ressemblera à l'exemple suivant :
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='<fichier du programme de résolution>'
Cette annexe vous aide à résoudre certains incidents fréquents qui peuvent survenir lors de la configuration d'INETD ou au cours de la vérification ou de la modification d'une configuration existante. INETD est utilisé par Developer for System z pour la fonction REXEC/SSH.
Le démon INETD fournit une gestion des services d'un réseau IP. Il réduit la charge du système en appelant d'autre démons uniquement lorsqu'ils sont nécessaires et en fournissant en interne des services Internet simples (écho, par exemple). INETD consulte le fichier de configuration inetd.conf afin de déterminer quels services supplémentaires proposer. ETC.SERVICES sert à lier les services aux ports.
Les services qui dépendent de INETD sont définis dans inetd.conf, qui est lu par INETD au moment du démarrage. Le nom et emplacement par défaut de inetd.conf est /etc/inetd.conf. Un exemple de fichier inetd.conf se trouve dans /samples/inetd.conf.
La syntaxe suivante s'applique aux entrées inetd.conf:
Chaque entrée se compose de 7 champs à position fixe, selon le format :
service_name socket_type protocol wait_flag userid server_program server_program_arguments
protocol peut être tcp[4|6] ou udp[4|6], et est utilisé pour qualifier plus avant le nom de service. Le nom de service et le protocole doivent tous les deux correspondre à une entrée dans ETC.SERVICES, mis à part que le "4" ou "6" ne devrait pas être inclus dans l'entrée ETC.SERVICES.
sndbuf et rcvbuf indiquent la taille des mémoires tampon d'envoi et de réception. La taille, représentée par n, peut être exprimée en octets, ou un "k" ou un "m" peuvent être nécessaires pour indiquer respectivement des kilooctets ou des mégaoctets. sndbug et rcvbuf peuvent être utilisés dans n'importe quel ordre.
wait ou nowait.wait indique que le démon dispose d'une seule unité d'exécution et qu'une nouvelle requête ne sera pas traitée tant que la précédente n'aura pas été terminée. Si nowait est indiqué, INETD émet une acceptation lorsqu'une demande de connexion est reçue sur une prise pour flot de données. Si wait est indiqué, il est de la responsabilité du serveur d'émettre une acceptation, s'il s'agit d'une prise pour flot de données.
max est le nombre maximum d'utilisateurs autorisés à effectuer une demande de service dans un intervalle de 60 secondes. La valeur par défaut est 40. En cas de dépassement, le port du service est arrêté.
userid est l'ID utilisateur que le démon en processus parallèle de traitement doit utiliser pour son exécution. Cet ID utilisateur peut être différent de celui d'INETD. Les autorisations affectées à cet ID utilisateur dépendent des besoins du service. L'ID utilisateur d'INETD nécessite une autorisation BPX.DAEMON pour faire passer le traitement par duplication à cet ID utilisateur.
La valeur facultative group, qui est séparée de l'ID utilisateur par un point (.), permet au serveur de s'exécuter avec un ID groupe différent de celui par défaut pour cet ID utilisateur.
INETD utilise ETC.SERVICES pour mapper les numéros de port et les protocoles vers les services qu'ils doivent prendre en charge. Il peut s'agir d'un fichier MVS ou z/OS UNIX. Un exemple est fourni dans SEZAINST(SERVICES), qui est également disponible comme /usr/lpp/tcpip/samples/services. L'ordre de recherche pour ETC.SERVICES dépend de la méthode de démarrage d'INETD : z/OS UNIXou MVS natif.
La syntaxe suivante s'applique à la spécification d'informations de maintenance :
Chaque entrée se compose de quatre champs à position fixe, selon le format :
service_name port_number/protocol aliases
L'ordre de recherche utilisé pour accéder à ETC.SERVICES dans z/OS UNIX est indiqué ci-après. La recherche s'arrête au premier fichier trouvé :
userid est l'ID utilisateur qui est utilisé pour démarrer INETD
.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.
L'ordre de recherche permettant d'accéder à ETC.SERVICES dans le système MVS natif est le suivant. La recherche s'arrête au premier fichier trouvé :
Le fichier alloué à l'instruction de définition de données SERVICES est utilisé.
userid est l'ID utilisateur qui est utilisé pour démarrer INETD
.jobname correspond au nom indiqué dans l'instruction JCL JOB pour les travaux par lots ou au 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.
Ne confondez pas les définitions PORT (ou PORTRANGE) de PROFILE.TCPIP avec les ports définis dans ETC.SERVICES dans la mesure où ces définitions ont des buts différents. Les ports définis dans PROFILE.TCPIP sont utilisés par le protocole TCPIP pour vérifier si le port est réservé pour un service donné. ETC.SERVICES est utilisé par INETD pour mapper un port à un service.
Lorsqu'INETD reçoit une demande sur un port contrôlé, il génère un processus enfant parallèle (avec le service demandé), qui est appelé inetdx, où inetd est le nom de travail pour INETD (selon la méthode de démarrage) et où x est un chiffre.
Cela complique la réservation de ports. Ainsi, dans le cas où un port contrôlé INETD est réservé dans PROFILE.TCPIP, il est recommandé d'utiliser le nom de la procédure JCL démarrée pour l'espace adresse de noyau z/OS UNIX afin de permettre à presque tous les processus de se lier au port. Ce nom est généralement OMVS, sauf si un nom différent est explicitement indiqué dans le paramètre STARTUP_PROC du membre parmlib BPXPRMxx.
La liste suivante explique comment déterminer le nom de travail, étant donné l'environnement dans lequel l'application est exécutée.
Le processus INETD crée un fichier temporaire, /etc/inetd.pid, qui contient l'ID processus (PID) du démon INETD donc l'exécution est en cours. Cette valeur de PID est utilisée pour identifier les enregistrements du journal système qui ont le processus INETD pour origine, et pour fournir la valeur de PID aux commandes qui en nécessitent une, comme arrêter. Elle est également utilisée comme mécanisme de verrouillage afin de ne pas avoir plusieurs INETD actifs.
La mise en oeuvre z/OS UNIX d'INETD est assurée par défaut dans /usr/sbin/inetd et prend en charge deux paramètres de démarrage facultatifs qui ne dépendent pas de la position :
/usr/sbin/inetd [-d] [inetd.conf]
Il est recommandé de démarrer INETD au moment de l'IPL. La façon la plus courante de procéder est de le démarrer à partir de /etc/rc ou de /etc/inittab (à partir de z/OS 1.8 seulement). Il peut également être démarré à partir d'un travail ou d'une tâche démarrée en utilisant BPXBATCH ou à partir d'une session de l'interpréteur de commandes d'un utilisateur ayant les droits d'accès correspondants.
Lorsqu'il est démarré à partir du script de shell d'initialisation de z/OS UNIX, /etc/rc, INETD utilise l'ordre de recherche de z/OS UNIX pour trouver ETC.SERVICES. Un exemple de fichier /etc/rc est fourni comme /samples/rc. Les exemples de commande suivants peuvent être utilisés pour démarrer INETD :
# Start INETD _BPX_JOBNAME='INETD' /usr/sbin/inetd /etc/inetd.conf & sleep 5
z/OS 1.8 et au dessus met à disposition une méthode alternative, /etc/inittab, pour l'émission des commandes lors de l'initialisation de z/OS UNIX. /etc/inittab permet de définir le paramètre respawn, qui redémarre automatiquement le processus lorsqu'il se termine (un WTOR est envoyé à l'opérateur pour un deuxième redémarrage dans les 15 minutes). Lorsqu'il est démarré à partir de /etc/inittab, INETD utilise l'ordre de recherche de z/OS UNIX pour trouver ETC.SERVICES. Un exemple de fichier /etc/inittab est fourni comme /samples/inittab. L'exemple de commande suivant peut être utilisé pour démarrer INETD :
# Start INETD inetd::respfrk:/usr/sbin/inetd /etc/inetd.conf
La méthode de démarrage BPXBATCH fonctionne pour les tâches démarrées et les travaux d'utilisateur. Veuillez noter qu'INETD est un processus d'arrière-plan, de sorte que l'étape BPXBATCH du démarrage d'INETD se termine en quelques secondes après le démarrage. Lorsqu'il est démarré par BPXBATCH, INETD utilise l'ordre de recherche de z/OS UNIX pour trouver ETC.SERVICES. Le langage JCL répertorié dans l'exemple de code suivant est un exemple de procédure de démarrage d'INETD (l'étape KILL retire un processus INETD actif, s'il y en a un) :
//INETD PROC PRM= //* //KILL EXEC PGM=BPXBATCH,REGION=0M, // PARM='SH ps -e | grep inetd | cut -c 1-10 | xargs -n 1 kill' //* //INETD EXEC PGM=BPXBATCH,REGION=0M, // PARM='PGM /usr/sbin/inetd &PRM' //STDERR DD SYSOUT=* //* STDIN, STDOUT and STDENV are defaulted to /dev/null //*
// PARM='PGM /usr/sbin/inetd //''SYS1.TCPPARMS(INETCONF)'' &PRM'
Lorsqu'il est démarré à partir d'une session de shell, INETD utilise l'ordre de recherche de z/OS UNIX pour trouver ETC.SERVICES. Les exemples de commande suivants peuvent être utilisés (par un utilisateur disposant des droits d'accès nécessaires) pour arrêter et démarrer INETD (# désigne l'invite z/OS UNIX) :
# ps -e | grep inetd 7 ? 0:00 /usr/sbin/inetd # kill 7 # _BPX_JOBNAME='INETD' /usr/sbin/inetd &
INETD est un processus z/OS UNIX et nécessite donc des définitions OMVS valides dans le logiciel de sécurité pour l'ID utilisateur associé à INETD. UID, HOME et PROGRAM doivent être définis pour l'ID utilisateur, ainsi que le GID pour le groupe par défaut de l'utilisateur. Si INETD est démarré par /etc/rc ou par /etc/inittab, l'ID utilisateur est hérité du noyau z/OS UNIX, il s'agit de OMVSKERN par défaut.
ADDGROUP OMVSGRP OMVS(GID(1)) ADDUSER OMVSKERN DFLTGRP(OMVSGRP) NOPASSWORD + OMVS(UID(0) HOME('/') PROGRAM('/bin/sh'))
INETD est un démon qui nécessite l'accès à des fonctions (setuid(), par exemple). L'ID utilisateur utilisé pour démarrer INETD nécessite ainsi des droits d'accès READ au profil BPX.DAEMON dans la classe FACILITY. Dans le cas où ce profil n'est pas défini, un UID 0 est obligatoire.
PERMIT BPX.DAEMON CLASS(FACILITY) ACCESS(READ) ID(OMVSKERN)
L'ID utilisateur INETD nécessite également des droits EXECUTE pour le programme inetd (/usr/sbin/inetd), des droits READ à vos fichiers inetd.conf et ETC.SERVICES et des droits WRITE à /etc/inetd.pid. Si vous désirez exécuter INETD sans UID 0, vous pouvez donner des droits d'accès CONTROL au profil SUPERUSER.FILESYS dans la classe UNIXPRIV afin de fournir les permissions nécessaires pour les fichiers z/OS UNIX.
Les programmes qui nécessitent des droits d'accès de démon doivent être contrôlés par programme si BPX.DAEMON est défini dans la classe FACILITY. Cela est déjà fait pour le programme INETD par défaut (/usr/sbin/inetd), mais doit être défini manuellement si vous utilisez une copie ou une version personnalisée. Utilisez la commande extattr +p pour rendre un fichier z/OS UNIX contrôlé par programme. Utilisez la classe RACF PROGRAM pour qu'un module de chargement MVS puisse être contrôlé par programme.
Les programmeurs système qui ont besoin de redémarrer INETD depuis leur session de shell démarreront INETD à l'aide de leurs autorisations. Ils doivent ainsi disposer de la même liste de permissions que les ID utilisateur INETD normaux. Ils doivent de plus disposer de permissions de lister et d'arrêter les processus INETD. Cela peut être accompli de plusieurs façons.
Cette solution n'est pas recommandée pour les ID utilisateur "humains" dans la mesure où il n'y a pas de restrictions liées à z/OS UNIX.
Permettent à l'utilisateur d'obtenir un UID 0 par l'intermédiaire de la commande su. Il s'agit de la configuration recommandée.
Voir le document UNIX System Services Command Reference (SA22-7802) pour en savoir plus sur les commandes extattr et su. Voir le document UNIX System Services Planning (GA22-7800) pour en savoir plus sur la classe UNIXPRIV et les profils BPX.* dans la classe FACILITY. Voir le document Security Server RACF Security Administrator's Guide (SA22-7683) pour obtenir davantage d'informations sur les définitions de segment OMVS et la classe PROGRAM.
Developer for System z dépend d'INETD pour la gestion REXEC et/ou SSH. Il peut également imposer des exigences supplémentaires à la configuration d'INETD décrite ci-avant.
REXEC (ou SSH) est utilisé aux fins suivantes, comme indiqué à la section (Facultatif) Utilisation de REXEC (ou SSH).
Les actions distantes dans les sous-projets z/OS UNIX ne requièrent pas de paramètres spécifique. En revanche, la méthode de démarrage RSE alternative requiert des paramètres spécifiques.
Les paramètres environnementaux d'INETD, qui sont transmis lors du démarrage du processus, ainsi que les permissions pour l'ID utilisateur d'INETD doivent être configurés convenablement pour qu'INETD puisse démarrer le serveur RSE.
Le démon REXEC (ou SSH) qui est démarré par INETD lorsqu'un client se connecte au port 512 (ou 22, respectivement) est utilisé pour procéder à l'authentification, démarrer le serveur RSE, et renvoyer le numéro de port pour la suite de la communication en retour vers le client. Pour cela, l'ID utilisateur qui est affecté au démon REXEC (ou SSH) (dans inetd.conf) nécessite les autorisations suivantes :
Cette annexe vous aide à résoudre certains incidents fréquents qui peuvent survenir lors de la configuration d'APPC (Advanced Program-to-Program Communication) ou au cours de la vérification ou de la modification d'une configuration existante.
Voir le document MVS Planning: APPC/MVS Management (SA22-7599) and MVS Initialization and Tuning Reference (SA22-7592) pour de plus amples informations sur la gestion APPC et sur les membres parmlib étudiés ci-après.
Notez que l'ensemble de la configuration d'APPC n'est pas abordé ici, mais uniquement certains aspects clés qui peuvent s'appliquer à votre site.
Le membre SYS1.SAMPLIB(ATBALL) contient une liste et des descriptions de tous les (exemples de) membres liés à APPC dans SYS1.SAMPLIB.
APPC/MVS stocke ses données de configuration dans les membres SYS1.PARMLIB suivants et dans deux fichiers VSAM :
Un TP est un programme d'application qui utilise APPC pour communiquer avec un TP sur le même système ou sur un autre afin d'accéder à des ressources. La configuration d'APPC pour Developer for System z active un nouveau TP appelé FEKFRSRV, qui est désigné comme le service Commandes TSO.
Le travail suivant est une concaténation des exemples de membre SYS1.SAMPLIB(ATBTPVSM) et SYS1.SAMPLIB(ATBSIVSM) et peut être utilisé pour définir les méthodes d'accès VSAM d'APPC.
//APPCVSAM JOB <paramètres du travail> //* //* CAUTION: This is neither a JCL procedure nor a complete job. //* Before using this sample, you will have to make the following //* modifications: //* 1. Change the job parameters to meet your system requirements. //* 2. Change ****** to the volume that will hold the APPC VSAMs. //* //TP EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * DEFINE CLUSTER (NAME(SYS1.APPCTP) - VOLUME(******) - INDEXED REUSE - SHAREOPTIONS(3 3) - RECORDSIZE(3824 7024) - KEYS(112 0) - RECORDS(300 150)) - DATA (NAME(SYS1.APPCTP.DATA)) - INDEX (NAME(SYS1.APPCTP.INDEX)) //* //SI EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * DEFINE CLUSTER (NAME(SYS1.APPCSI) - VOLUME(******) - INDEXED REUSE - SHAREOPTIONS(3 3) - RECORDSIZE(248 248) - KEYS(112 0) - RECORDS(50 25)) - DATA (NAME(SYS1.APPCSI.DATA)) - INDEX (NAME(SYS1.APPCSI.INDEX)) //*
APPC est une implémentation du protocole architecture SNA LU 6.2. L'architecture SNA fournit des formats et des protocoles qui définissent une plage de composants SNA physiques et logiques (l'unité logique (LU), par exemple). LU 6.2 est un type d'unité logique qui est spécialement conçue pour gérer les communications entre les programmes d'application.
Pour utiliser SNA sur MVS, vous devez installer et configurer la méthode d'accès virtuelle en télétraitement VTAM (Virtual Telecommunications Access Method). VTAM doit être active avant que les tâches système APPC puissent être utilisées.
La partie spécifique d'APPC de la configuration de VTAM se compose de trois étapes :
L'ACBNAME de MVSLU01 utilisé dans l'exemple de membre SYS1.SAMPLIB(ATBAPPL) peut être modifié pour se conformer aux normes du site, mais doit correspondre aux définitions dans le membre SYS1.PARMLIB(APPCPMxx).
MVSLU01 APPL ACBNAME=MVSLU01, C APPC=YES, C AUTOSES=0, C DDRAINL=NALLOW, C DLOGMOD=APPCHOST, C DMINWNL=5, C DMINWNR=5, C DRESPL=NALLOW, C DSESLIM=10, C LMDENT=19, C MODETAB=LOGMODES, C PARSESS=YES, C SECACPT=CONV, C SRBEXIT=YES, C VPACING=1
Voir le document Communications Server IP SNA Network Implementation Guide (SC31-8777) pour de plus amples informations sur la configuration de VTAM.
Pour activer et prendre en charge le flux de conversations entre les systèmes, les sites doivent définir des unités logiques entre lesquelles les sessions peuvent être liées. Un site a besoin de définir au moins une unité logique avant le traitement APPC/MVS, même quand le traitement APPC demeure sur un seul système. Les unités logiques correspondent à certaines des définitions créées dans SYS1.PARMLIB(APPCPMxx).
Le service Commandes TSO requiert de configurer APPC de façon à disposer d'une unité logique qui puisse traiter à la fois les demandes entrantes et sortantes.
La définition d'unité logique doit être ajoutée au membre SYS1.PARMLIB(APPCPMxx) et inclure les paramètres BASE et SCHED(ASCH). Le membre APPCPMxx spécifie également le profil de transaction (TP) et les fichiers VSAM d'informations complémentaires (SI) qui seront utilisés.
L'exemple de code suivant est un exemple de membre SYS1.PARMLIB(APPCPMxx) que vous pouvez utiliser pour le service Commandes TSO.
LUADD ACBNAME(MVSLU01) BASE SCHED(ASCH) TPDATA(SYS1.APPCTP) SIDEINFO DATASET(SYS1.APPCSI)
Lorsqu'un système comporte plusieurs noms d'unité logique, vous devrez peut-être apporter des modifications en fonction de l'unité logique sélectionnée par le système comme l'unité logique de base (BASE). L'unité logique de base du système est déterminée par les conditions suivantes :
Si votre système comporte une unité logique contenant les paramètres BASE et NOSCHED, elle sera utilisée comme l'unité logique de base mais le Service Commandes TSO ne fonctionnera pas, car cette unité ne possède pas de planificateur de transactions pour traiter les demandes pour la transaction FEKFRSRV. Si cette unité logique ne peut pas être modifiée pour supprimer le paramètre NOSCHED, la variable d'environnement rsed.envvars _FEKFSCMD_PARTNER_LU peut être définie avec l'unité logique qui possède les paramètres BASE et SCHED(ASCH), par exemple :
_FEKFSCMD_PARTNER_LU=MVSLU01
Pour plus d'informations sur rsed.envvars, voir rsed.envvars - Fichier de configuration RSE.
Le planificateur de transactions APPC/MVS (le nom par défaut est ASCH) lance et planifie des programmes de transaction en réponse aux demandes entrantes de conversations. Le membre SYS1.PARMLIB(ASCHPMxx) contrôle son fonctionnement, avec les définitions de classe de transaction par exemple.
La classe de transaction APPC utilisée pour le service Commandes TSO doit comporter suffisamment de demandeurs APPC pour en autoriser un par utilisateur de Developer for System z.
Le service Commandes TSO nécessite également que les spécifications par défaut soient indiquées dans les sections OPTIONS et TPDEFAULT.
L'exemple de code suivant est un membre SYS1.PARMLIB(ASCHPMxx) que vous pouvez utiliser pour le service Commandes TSO.
CLASSADD CLASSNAME(A) MAX(20) MIN(1) MSGLIMIT(200) OPTIONS DEFAULT(A) TPDEFAULT REGION(2M) TIME(5) MSGLEVEL(1,1) OUTCLASS(X)
Les modifications de configuration présentées dans les étapes précédentes peuvent maintenant être activées. Il est possible de procéder de différentes manières, selon les circonstances.
Ajoutez ces commandes à SYS1.PARMLIB(COMMNDxx) pour les lancer au démarrage du système.
Les commandes de la console D APPC et D ASCH peuvent être employées pour vérifier la configuration d'APPC. Voir le document MVS System Commands (GC28-1781) pour de plus amples informations sur les commandes de la console.
Une fois qu'APPC/MVS est actif, le service Commandes TSO de Developer for System z peut être défini, voir (Facultatif) Transaction APPC pour le service Commandes TSO.
La définition de la transaction APPC décrite s'effectue par personnalisation et soumission de FEK.#CUST.JCL(FEKAPPCC).
La transaction APPC peut également être définie en mode interactif par l'intermédiaire de l'interface ISPF APPC, comme cela est décrit dans le livre blanc. Ce livre blanc explique également comment configurer la transaction APPC afin de collecter des informations statistiques propres aux utilisateurs.
Le livre blanc APPC and WebSphere Developer for System z (SC23-5885-00) est disponible dans la bibliothèque Internet de Developer for System z, http://www-306.ibm.com/software/awdtools/rdz/library/.
// PARM='ISPSTART CMD(%FEKFRSRV TIMEOUT=60) NEWAPPL(ISR) NESTMACS'
Developer for System z prend en charge les options de configuration alternatives APPC et VTAM dont certaines sont décrites dans la présente section.
Le nom de transaction par défaut pour le service Commandes TSO est FEKFRSRV, comme décrit à la section (Facultatif) Transaction APPC pour le service Commandes TSO. Comme détaillé dans la section, ce nom peut être modifié lorsque vous définissez la transaction sur APPC.
Notez que la modification du nom de transaction dans APPC implique que le nouveau nom soit attribué à _FEKFSCMD_TP_NAME_ dans rsed.envvars, comme indiqué dans rsed.envvars - Fichier de configuration RSE.
APPC est un protocole de communication qui permet à un programme (le noeud partenaire) d'interagir avec un programme situé sur l'hôte (le noeud local). Avec Developer for System z, le noeud partenaire (serveur Commandes TSO) et le noeud local (serveur RSE) sont actifs dans le même système z/OS. Par défaut, ils utilisent la même définition d'unité logique (BASE) pour communiquer entre-eux.
Vous pouvez spécifier un nom d'unité logique partenaire alternatif pour le service Commandes TSO dans la directive _FEKFSCMD_PARTNER_LU_ de rsed.envvars (voir rsed.envvars - Fichier de configuration RSE). Notez que vous ne pouvez pas modifier l'unité logique locale qui doit toujours être une unité logique BASE valide (doit posséder les mots clés BASE et SCHED).
VTAM prend en charge une configuration APPC sécurisée dans laquelle la communication entre les unités logiques partenaire et locale doit être définie dans le logiciel de sécurité.
Vous l'activez en ajoutant VERIFY=REQUIRED à la définition VTAM de l'unité logique (BASE) locale. Les définitions de sécurité doivent être créées dans la classe APPCLU, tel que spécifié dans le document MVS Planning: APPC/MVS Management (SA22-7599).
Notez que lorsque cette configuration est active dans VTAM et que la configuration de votre logiciel de sécurité n'est pas achevée, l'initialisation de la communication avec le service Commandes TSO échouera et aucun message dans le journal système ne mentionnera le refus de VTAM de configurer la connexion. Le test du programme de vérification d'installation APPC (fekfivpa) échouera avec le message "Return code 1 - Allocate Failure no retry".
La présente annexe répertorie les conditions requises et les corequis liés à l'hôte correspondant à cette version de Developer for System z.
Voir Rational Developer for System z Prerequisites (SC23-7659) dans la bibliothèque en ligne de Developer for System z (http://www-01.ibm.com/software/awdtools/rdz/library/) pour obtenir une aide en ligne des conditions requises obligatoires et facultatives.
Les produits répertoriés dans la présente section sont disponibles à la date de publication du présent document. Consultez le site Web IBM Software Support Lifecycle à l'adresse http://www.ibm.com/software/support/lifecycle/ pour savoir si un produit sélectionné est toujours disponible au moment où vous souhaitez utiliser la fonction Developer for System z.
Pour utiliser Developer for System z, vous devez disposer de l'environnement ci-dessous avec les éléments prérequis appropriés :
L'un des niveaux suivants doit être installé sur le système hôte :
Numéro de programme | Nom | PTF ou niveaux de service requis |
---|---|---|
5694-A01 | z/OS v 1.11 |
ISPF :
TCP/IP :
|
5694-A01 | z/OS v 1.10 |
ISPF :
TCP/IP :
|
5694-A01 | z/OS v 1.9 |
ISPF :
TCP/IP :
|
5694-A01 | z/OS v 1.8 |
ISPF :
TCP/IP :
|
Le site Web du produit associé est :
Pour installer Developer for System z, l'un des niveaux suivants doit être installé :
Numéro de pro gramme | Nom | PTF ou niveaux de service requis |
---|---|---|
5655-G44 | IBM System Modification Program Extended (SMP/E) for z/OS v 3.5 | Aucune PTF ou aucun niveau de service requis |
5655-G44 | IBM System Modification Program Extended (SMP/E) for z/OS v 3.4 | Aucune PTF ou aucun niveau de service requis |
Le site Web du produit associé est :
Pour prendre en charge les applications qui utilisent Remote Systems Explorer (RSE), l'un des niveaux suivants doit être installé sur l'hôte :
Numéro de programme | Nom | PTF ou niveaux de service requis |
---|---|---|
5655-R32 | IBM 64-bit SDK for z/OS, Java 2 Technology Edition, v 6.0 | édition de service 7 |
5655-R31 | IBM 31-bit SDK for z/OS, Java 2 Technology Edition, v 6.0 | édition de service 7 |
5655-N99 | IBM 64-bit SDK for z/OS, Java 2 Technology Edition, v 5.0 | édition de service 11 |
5655-N98 | IBM 31-bit SDK for z/OS, Java 2 Technology Edition, v 5.0 | édition de service 11 |
Le site Web du produit associé est :
Les produits figurant dans la présente section et les logiciels suivants sont requis pour prendre en charge les composants spécifiques de Developer for System z. Le poste de travail client Developer for System z peut être installé sans ces logiciels. Pour pouvoir utiliser le composant, vous devez toutefois installer le logiciel hôte requis indiqué (qui doit être opérationnel à l'exécution) .
Numéro de programme | Nom | PTF ou niveaux de service requis |
---|---|---|
5694-A01 | z/OS v 1.11 |
HLASM Aucune PTF ou aucun niveau de service requis
XL C/C++ Aucune PTF ou aucun niveau de service requis
SCLM Aucune PTF ou aucun niveau de service requis
LE (PL/I) Aucune PTF ou aucun niveau de service requis
TN3270 Aucune PTF ou aucun niveau de service requis |
5694-A01 | z/OS v 1.10 |
HLASM Aucune PTF ou aucun niveau de service requis
XL C/C++ Aucune PTF ou aucun niveau de service requis
SCLM Aucune PTF ou aucun niveau de service requis
LE (PL/I) Aucune PTF ou aucun niveau de service requis
TN3270 Aucune PTF ou aucun niveau de service requis |
5694-A01 | z/OS v 1.9 |
HLASM Aucune PTF ou aucun niveau de service requis
XL C/C++ Aucune PTF ou aucun niveau de service requis
SCLM
LE (PL/I) Aucune PTF ou aucun niveau de service requis
TN3270 Aucune PTF ou aucun niveau de service requis |
5694-A01 | z/OS v 1.8 |
HLASM Aucune PTF ou aucun niveau de service requis
XL C/C++ Aucune PTF ou aucun niveau de service requis
SCLM
LE (PL/I)
TN3270 Aucune PTF ou aucun niveau de service requis |
Le site Web du produit associé est :
Le site Web du produit associé est :
Le site Web du produit associé est :
Le site Web du produit associé est :
Le site Web du produit associé est :
Le site Web du produit associé est :
Pour compiler les programmes COBOL développés ou édités dans Developer for System z, l'un des niveaux suivants doit être installé sur l'hôte :
Numéro de pro gramme | Nom | PTF ou niveaux de service requis |
---|---|---|
5655-S71 | IBM Enterprise COBOL for z/OS v 4.2 | Aucune PTF ou aucun niveau de service requis |
5655-S71 | IBM Enterprise COBOL for z/OS v 4.1 | Aucune PTF ou aucun niveau de service requis |
5535-G53 | IBM Enterprise COBOL for z/OS v 3.4 | Aucune PTF ou aucun niveau de service requis |
Le site Web du produit associé est :
Pour compiler les programmes PL/I développés ou édités dans Developer for System z, l'un des niveaux suivants doit être installé sur l'hôte :
Numéro de programme | Nom | PTF ou niveaux de service requis |
---|---|---|
5655-H31 | IBM Enterprise PL/I for z/OS v 3.9 | Aucune PTF ou aucun niveau de service requis |
5655-H31 | IBM Enterprise PL/I for z/OS v 3.8 | Aucune PTF ou aucun niveau de service requis |
5655-H31 | IBM Enterprise PL/I for z/OS v 3.7 | Aucune PTF ou aucun niveau de service requis |
5655-H31 | IBM Enterprise PL/I for z/OS v 3.6 | Aucune PTF ou aucun niveau de service requis |
Le site Web du produit associé est :
Pour prendre en charge le débogage à distance à partir de Developer for System z, l'un des niveaux suivants doit être installé sur l'hôte :
Numéro de pro gramme | Nom | Langage de programmation | APAR, PTF ou niveaux de service requis |
---|---|---|---|
5655-V50 | IBM Debug Tool for z/OS V10.1 | COBOL, PL/I, C/C++, assembleur et autres fonctions | Toute maintenance disponible |
5655-U27 | IBM Debug Tool for z/OS V9.1 | COBOL, PL/I, C/C++, assembleur et autres fonctions | Toute maintenance disponible |
5655-S16 | IBM Debug Tool Utilities and Advanced Functions for z/OS V8.1.0 | COBOL, PL/I, C/C++, assembleur et autres fonctions | Toute maintenance disponible |
5655-S17 | IBM Debug Tool for z/OS V8.1.0 | COBOL, PL/I, Assembleur, C/C++ | Toute maintenance disponible |
Le site Web du produit associé est :
Dès la version 9, Debug Tool for z/OS et Debug Tool Utilities and Advanced Functions ont été fusionnés en une seule offre.
Pour prendre en charge les applications avec des instructions CICS imbriquées, l'un des niveaux suivants doit être installé :
Numéro de programme | Nom | PTF ou niveaux de service requis |
---|---|---|
5655-S97 | IBM CICS Transaction Server for z/OS v 4.1 | Aucune PTF ou aucun niveau de service requis |
5697-E93 | IBM CICS Transaction Server for z/OS v 3.2 | UK34221 |
5697-E93 | IBM CICS Transaction Server for z/OS v 3.1 | UK15767, UK15764, UK11782, UK11294, UK12233, UK12521, UK15261, UK15271, UK34221, UK34078 |
Le site Web du produit associé est :
Pour obtenir la liste des exigences spécifiques d'exécution, reportez-vous à la documentation relative à Enterprise Service Tools dans le centre de documentation de IBM Rational Developer for System z, à l'adresse suivante : http://publib.boulder.ibm.com/infocenter/ratdevz/v7r6/.
Pour prendre en charge les applications utilisant la base de données et les transmissions de données IMS, l'un des niveaux suivants doit être installé sur l'hôte :
Numéro de programme | Nom | PTF ou niveaux de service requis |
---|---|---|
5635-A02 | IBM IMS v 11.1 | Aucune PTF ou aucun niveau de service requis |
5635-A01 | IBM IMS v 10.1 | Aucune PTF ou aucun niveau de service requis |
5655-J38 | IBM IMS v 9.1 | Aucune PTF ou aucun niveau de service requis |
Le site Web du produit associé est :
Pour prendre en charge DB2, l'un des niveaux suivants doit être installé sur l'hôte :
Numéro de programme | Nom | PTF ou niveaux de service requis |
---|---|---|
5635-DB2 | IBM DB2 for z/OS v 9.1 | Aucune PTF ou aucun niveau de service requis |
5625-DB2 | IBM DB2 Universal Database for z/OS v 8.1 | Aucune PTF ou aucun niveau de service requis |
Le site Web du produit associé est :
Pour le contrôle des sources Jazz utilisant les projets distants de Developer for System z, le niveau suivant doit être installé.
Numéro de pro gramme | Nom | PTF ou niveaux de service requis |
---|---|---|
5724-V82 | Rational Team Concert for System z Server v 2.0 |
Identificateur de modification de fonction HAHA200 - Serveur coopératif
Identificateur de modification de fonction HAHB200 - Kit d'outils
Identificateur de modification de fonction HAHC200 - Moniteur de travaux
Identificateur de modification de fonction HAHD200 - Agent BuildForge
|
Le site Web du produit associé est :
Pour prendre en charge l'intégration de File Manager, l'un des niveaux suivants doit être installé sur l'hôte :
Numéro de pro gramme | Nom | PTF ou niveaux de service requis |
---|---|---|
5655-U29 | IBM File Manager for z/OS v 10.1 |
|
Le site Web du produit associé est :
Pour prendre en charge l'intégration de Fault Analyzer, les niveaux suivants doivent être installés sur l'hôte :
Numéro de programme | Nom | PTF ou niveaux de service requis |
---|---|---|
5655-V51 | IBM Fault Analyzer v 10.1 | Aucune PTF ou aucun niveau de service requis |
5655-U28 | IBM Fault Analyzer v 9.1 | Aucune PTF ou aucun niveau de service requis |
5655-S15 | IBM Fault Analyzer v 8.1 | Aucune PTF ou aucun niveau de service requis |
Le site Web du produit associé est le suivant :
Pour utiliser SCLM Developer Toolkit, l'un des niveaux suivants doit être installé sur l'hôte :
Numéro de programme | Nom | PTF ou niveaux de service requis |
---|---|---|
5695-014 | Bibliothèque IBM pour REXX sous zSeries v 1.4 | Aucune PTF ou aucun niveau de service requis |
5695-014 | Bibliothèque IBM pour REXX sous zSeries - Alternate Library v 1.4.0 (FMIDs HWJ9143, JWJ9144) | Aucune PTF ou aucun niveau de service requis |
Une version de REXX/370 Alternate Library est disponible sur le site Web du produit :
IBM Ported Tools for z/OS doit être installé (sous z/OS UNIX) pour autoriser le déploiement sécurisé par le biais de sftp ou scp dans SCLM Developer Toolkit.
Une version d'IBM Ported Tools for z/OS est disponible sur le site Web du produit :
Apache Ant doit être installé (dans z/OS UNIX) pour procéder aux générations JAVA/J2EE dans SCLM Developer Toolkit.
Apache Ant est un outil de génération à source ouverte Java que vous pouvez télécharger à partir du site Web du produit :
Vous devez installer CA Endevor Software Change Manager Release 12 pour utiliser Developer for System z Interface for CA Endevor SCM.
CA Endevor SCM est un produit de CA. Le site Web du produit associé est :
http://www.ca.com/us/products/product.aspx?ID=259
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 |
---|---|---|---|
Java Diagnostic Guide | SC34-6650 | Java 5.0 | http://www.ibm.com/developerworks/java/jdk/diagnosis/ |
Java SDK and Runtime Environment User Guide | / | Java 5.0 | http://www-03.ibm.com/servers/eserver/zseries/software/java/ |
Program Directory for IBM Rational Developer for System z | GI11-7314 | Developer for System z | http://www-306.ibm.com/software/awdtools/rdz/library/ |
Rational Developer for System z Common Access Repository Manager Developer's Guide | SC23-7660 | Developer for System z | http://www-306.ibm.com/software/awdtools/rdz/library/ |
Rational Developer for System z Prerequisites | SC23-7659 | Developer for System z | http://www-306.ibm.com/software/awdtools/rdz/library/ |
Rational Developer for System z - Guide de démarrage rapide de configuration de l'hôte | GI11-7313 | Developer for System z | http://www-306.ibm.com/software/awdtools/rdz/library/ |
Rational Developer for System z - Guide de planification du système hôte | GI11-7244 | Developer for System z | http://www-306.ibm.com/software/awdtools/rdz/library/ |
SCLM Developer Toolkit - Guide d'administration | SC11-6464 | Developer for System z | http://www-306.ibm.com/software/awdtools/rdz/library/ |
APPC and WebSphere Developer for System z | SC23-5885 | Livre blanc | http://www-306.ibm.com/software/awdtools/rdz/library/ |
Communications Server IP Configuration Guide | SC31-8775 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP Configuration Reference | SC31-8776 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP Diagnosis Guide | GC31-8782 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP System Administrator's Commands | SC31-8781 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server SNA Network Implementation Guide | SC31-8777 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server SNA Operations | SC31-8779 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Cryptographic Services System SSL Programming | SC24-5901 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
DFSMS Macro Instructions for Data Sets | SC26-7408 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
DFSMS Using data sets | SC26-7410 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Language Environment Customization | SA22-7564 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Language Environment Debugging Guide | GA22-7560 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Initialization and Tuning Guide | SA22-7591 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Initialization and Tuning Reference | SA22-7592 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS JCL Reference | SA22-7597 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Planning APPC/MVS Management | SA22-7599 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Planning Workload Management | SA22-7602 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS System Commands | SA22-7627 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Security Server RACF Command Language Reference | SA22-7687 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Security Server RACF Security Administrator's Guide | SA22-7683 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
TSO/E Customization | SA22-7783 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
TSO/E REXX Reference | SA22-7790 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services Command Reference | SA22-7802 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services Planning | GA22-7800 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services User's Guide | SA22-7801 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Using REXX and z/OS UNIX System Services | SA22-7806 | z/OS 1.9 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
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 |
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 |
Language Reference | SC27-1408 | Enterprise COBOL for z/OS | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
Les sites Web suivants sont référencés dans le présent document :
Description | Site Web de référence |
---|---|
Centre de documentation de Developer for System z | http://publib.boulder.ibm.com/infocenter/ratdevz/v7r6/index.jsp |
Support de Developer for System z | http://www-306.ibm.com/software/awdtools/rdz/support/ |
Bibliothèque de Developer for System z | http://www-306.ibm.com/software/awdtools/rdz/library/ |
Page d'accueil de Developer for System z | http://www-306.ibm.com/software/awdtools/rdz/ |
Developer for System z - Service recommandé | 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/ |
Centre de documentation CICSTS | https://publib.boulder.ibm.com/infocenter/cicsts/v4r1/index.jsp |
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/ |
Les publications suivantes peuvent s'avérer utiles pour vous aider à comprendre les incidents de configuration pour les composants hôte requis :
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/ |
© Copyright IBM Corporation - 2010
U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
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 :
Le paragraphe suivant ne s'applique ni au Royaume-Uni, ni à 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 CONTREFAÇON 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. Ce document est mis à jour périodiquement. Chaque nouvelle édition inclut les mises à jour. IBM peut, à tout moment et sans préavis, modifier les produits et logiciels 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 à :
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 peut contenir 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 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 la plupart des juridictions du monde. 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.
Rational est une marque d'International Business Machines Corporation et de Rational Software Corporation aux Etats-Unis et/ou dans certains autres pays.
Intel® et Pentium® sont des marques d'Intel Corporation aux Etats-Unis et/ou dans certains autres pays.
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.