Avant d'utiliser le présent document et le produit associé, prenez connaissance des informations générales figurant à la section Remarques.
Certaines illustrations de ce manuel ne sont pas disponibles en français à la date d'édition.
LE PRESENT DOCUMENT EST LIVRE EN L'ETAT SANS AUCUNE GARANTIE EXPLICITE OU IMPLICITE. IBM DECLINE NOTAMMENT TOUTE RESPONSABILITE RELATIVE A CES INFORMATIONS EN CAS DE CONTREFACON AINSI QU'EN CAS DE DEFAUT D'APTITUDE A L'EXECUTION D'UN TRAVAIL DONNE.
Ce document est mis à jour périodiquement. Chaque nouvelle édition inclut les mises à jour. Les informations qui y sont fournies sont susceptibles d'être modifiées avant que les produits décrits ne deviennent eux-mêmes disponibles. En outre, il peut contenir des informations ou des références concernant certains produits, logiciels ou services non annoncés dans ce pays. Cela ne signifie cependant pas qu'ils y seront annoncés.
Pour plus de détails, pour toute demande d'ordre technique, ou pour obtenir des exemplaires de documents IBM, référez-vous aux documents d'annonce disponibles dans votre pays, ou adressez-vous à votre partenaire commercial.
Vous pouvez également consulter les serveurs Internet suivants :
Compagnie IBM France Direction Qualité Tour Descartes 92066 Paris-La Défense Cedex 50
(C) Copyright IBM France 2007. Tous droits réservés.
Le présent manuel décrit les fonctions d'IBM Rational Developer for System z. Il fournit les instructions permettant de configurer les serveurs IBM Rational Developer for System z 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 que IBM WebSphere Developer for System z, IBM WebSphere Developer for zSeries et WebSphere Studio Enterprise Developer, reprenez les informations du guide de configuration de l'hôte et des répertoires de programme de ces éditions.
Le présent manuel s'adresse aux programmeurs système qui souhaitent installer et configurer IBM Rational Developer for System z Version 7.1.1 sur leur système hôte z/OS. Avant d'utiliser le présent manuel, vous devez maîtriser les systèmes hôtes z/OS UNIX et MVS.
Les publications suivantes sont référencées dans ce document :
Titre de la publication | Référence de la com mande | Référence | Lien de la référence |
---|---|---|---|
Java Diagnostic Guide | SC34-6650 | Java 5.0 | http://www.ibm.com/developerworks/java/jdk/diagnosis/index.html |
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-8298-00 | RD/z | http://www-306.ibm.com/software/awdtools/rdz/library/index.html |
Program Directory for IBM Rational Developer for System z Common Access Repository Manager | GI11-8299-00 | RD/z | http://www-306.ibm.com/software/awdtools/rdz/library/index.html |
Program Directory for IBM Software Configuration and Library Manager (SCLM) Developer Toolkit | GI11-8306-00 | RD/z | http://www-306.ibm.com/software/awdtools/rdz/library/index.html |
Rational Developer for System z Application Deployment Manger User's Guide | SC23-7661 | RD/z | http://www-306.ibm.com/software/awdtools/rdz/library/index.html |
Rational Developer for System z Common Access Repository Manager Developer's Guide | SC23-7660 | RD/z | http://www-306.ibm.com/software/awdtools/rdz/library/index.html |
Rational Developer for System z Host Configuration Guide | SC23-7658 | RD/z | http://www-306.ibm.com/software/awdtools/rdz/library/index.html |
Rational Developer for System z Host Planning Guide | GI11-8296-00 | RD/z | http://www-306.ibm.com/software/awdtools/rdz/library/index.html |
SCLM Developer Toolkit Installation and Customization Guide | SC23-8504 | RD/z | http://www-306.ibm.com/software/awdtools/rdz/library/index.html |
ABCs of z/OS System Programming Volume 9 | SG24-6989 | Redbook | http://www.redbooks.ibm.com/ |
APPC and WebSphere Developer for System z | SC23-5885 | Livre blanc | http://www-306.ibm.com/software/awdtools/rdz/library/index.html |
Host Based Projects in WebSphere Developer for System z version 7.0 | Livre blanc | http://www-306.ibm.com/software/awdtools/rdz/library/index.html | |
Setting up SSL for RSE Communication | SC23-5816 | Livre blanc | http://www-306.ibm.com/software/awdtools/rdz/library/index.html |
Communications Server bookshelf | F1A1BK61 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP Configuration Guide | SC31-8775 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP Configuration Reference | SC31-8776 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP Diagnosis Guide | GC31-8782 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP System Administrator's Commands | SC31-8781 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server SNA Network Implementation Guide | SC31-8777 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Cryptographic Services System SSL Programming | SC24-5901 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Language Environment Customization | SA22-7564 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Language Environment Debugging Guide | GA22-7560 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS bookshelf | IEA2BK60 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Initialization and Tuning Guide | SA22-7591 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Initialization and Tuning Reference | SA22-7592 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS JCL Reference | SA22-7597 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Planning APPC/MVS Management | SA22-7599 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Planning Workload Management | SA22-7602 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS System Commands | SA22-7627 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Security Server RACF Command Language Reference | SA22-7687 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Security Server RACF Security Administrator's Guide | SA22-7683 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services Command Reference | SA22-7802 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services File System Interface Reference | SA22-7808 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services Planning | GA22-7800 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services User's Guide | SA22-7801 | z/OS 1.7 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Pour chacune des fonctions suivantes, installez les FMID requis. Pour de plus amples informations sur les différents FMID, veuillez vous reporter au répertoire du programme correspondant pour le FMID que vous installez.
Si vous avez besoin de cette fonction d'IBM Rational Developer for System z | Vous devez installer les FMID suivants | Vous trouverez des informations d'installation et de configuration dans les guides suivants |
---|---|---|
|
HHOP710, HSD3310* |
en option
|
|
HCMA710, HHOP710** |
en option
|
|
HSD3310 |
|
(*) Developer for System z nécessite une connexion au service Commandes TSO sur z/OS. Cette connexion est mise à disposition par l'un des éléments suivants :
(**) CARMA nécessite une interface basée sur l'hôte. HHOP710 met cette fonction à disposition, ou bien vous pouvez utiliser une interface personnalisée, basée sur l'hôte, et éviter l'installation de HHOP710
Les étapes de personnalisation de SCLMDT suivantes doivent être appliquées. Elles sont décrites dans SCLM Developer Toolkit Installation and Customization Guide (SC23-8504) :
Pour obtenir des instructions détaillées sur l'installation de SMP/E pour chaque FMID (identificateur de modification de fonction), voir le tableau 2.
Developer for System z a une liste de logiciels prérequis qui doivent être installés et opérationnels pour que le produit 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.
Consultez la liste des éléments prérequis et des éléments corequis pour votre version de Developer for System z dans Rational Developer for System z - Guide de planification de l'hôte (SC11-2412-02).
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.
Les étapes de personnalisation de SCLMDT suivantes doivent être appliquées. Elles sont décrites dans SCLM Developer Toolkit Installation and Customization Guide (SC23-8504) :
Vous pouvez tester votre configuration TCP/IP à l'aide de la commande TSO HOMETEST. Pour plus d'informations sur cette commande, consultez la section "TSO Commands" dans Communications Server IP System Administrator's Commands (SC31-8781).
Exemple de résultat de la commande HOMETEST :
Exécution du programme de test de la configuration TCP/IP IBM MVS TCP/IP CS V1R7 Le fichier de paramètre de configuration FTP utilisé est le "SYS1.TCPPARMS(FTPDATA)" Le nom d'hôte TCP est : CDFMVS08 Utilisation du serveur de noms pour une résolution CDFMVS08 Les adresses IP suivantes correspondent au nom d'hôte TCP : CDFMVS08 9.42.112.75 Les adresses IP suivantes correspondent aux adresses IP HOME définies dans PROFILE.TCPIP : 9.42.112.75 127.0.0.1 Toutes les adresses IP pour CDFMVS08 se trouvent dans la liste HOME ! Commande Hometest réussie - Tous les tests sont réussis !
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
Les services hôte suivants, et donc leurs ports, doivent être disponibles pour que client puisse s'y connecter. Tous les autres ports utilisés par Developer for System z présentent un trafic réservé à l'hôte. Cela signifie que, pour Developer for System z, seuls les ports indiqués sur la liste doivent être définis pour votre pare-feu qui protège l'hôte.
INETD est un processus serveur z/OS UNIX qui est nécessaire pour la configuration des connexions client-hôte de Developer for System z. 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.
Pour plus d'informations sur les droits INETD, voir Annexe D. Configuration d'INETD.
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.
La configuration de Developer for System z nécessite plus de droits que les droits classiques du programmeur système, par conséquent, un minimum d'entraide est à prévoir. La liste ci-dessous souligne les points les plus importants :
Developer for System z et Common Access Repository Manager (CARMA) prennent en charge le clonage d'une installation sur un système différent, ce qui épargne le besoin d'une installation SMP/E sur chaque système.
Les fichiers et répertoires suivants sont obligatoires pour le déploiement sur d'autres systèmes. Si vous avez copié un fichier à un emplacement différent pour vos besoins de personnalisations, ce fichier doit remplacer son équivalent dans la liste ci-après.
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. Pour de plus amples informations, consultez les sections liées dans ce manuel.
Avant d'installer Developer for System z version 7.1.1, si vous utilisiez la version précédente de Developer for System z, il est recommandé d'enregistrer les fichiers personnalisés associés. Voir Annexe A. Exécution de plusieurs instances de Developer for System z avant de lancer la personnalisation si vous envisagez d'exécuter plusieurs instances de Developer for System z.
Les tableau 3 et tableau 4 présentent les fichiers qui ont probablement été personnalisés pour Developer for System z et CARMA version 6.0.1 (et supérieure). Le tableau 5 classe les différentes personnalisations qui sont effectuées sur les fichiers et sur les logiciels et produits prérequis et corequis, au cours de l'installation de Developer for System z et CARMA version 6.0.1 (et supérieure).
Membre | Emplacement par défaut v 6.0.1 | Emplacement par défaut v 7.0/v7.1 | But |
---|---|---|---|
FEJJCNFG |
hlq.SFEJSAMP (hlq = FEJ) |
hlq.SFEKSAMP (hlq = FEK) |
Fichier de configuration pour le moniteur de travaux JES |
FEJJJCL |
hlq.SFEJSAMP (hlq = FEJ) |
hlq.SFEKSAMP (hlq = FEK) |
Langage JCL pour le moniteur de travaux JES |
FEJTSO |
hlq.SFEJSAMP (hlq = FEJ) |
hlq.SFEKSAMP (hlq = FEK) |
Langage JCL pour les soumissions TSO |
FEKAPPCC | N'existe pas |
hlq.SFEKSAMP (hlq = FEK) |
Le langage JCL doit créer une transaction APPC |
FEKAPPCL | N'existe pas |
hlq.SFEKSAMP (hlq = FEK) |
Le langage JCL doit afficher une transaction APPC |
FEKAPPCX | N'existe pas |
hlq.SFEKSAMP (hlq = FEK) |
Le langage JCL doit supprimer une transaction APPC |
FEKFRTAD |
hlq.SFEKSAMP (hlq = FEK) |
(nouveau nom de membre FEKAPPCC) | Le langage JCL doit créer une transaction APPC |
FEKFRDIS |
hlq.SFEKSAMP (hlq = FEK) |
(nouveau nom de membre FEKAPPCL) | Le langage JCL doit afficher une transaction APPC |
FEKFRDEL |
hlq.SFEKSAMP (hlq = FEK) |
(nouveau nom de membre FEKAPPLX) | Le langage JCL doit supprimer une transaction APPC |
ELAXF* |
hlq.SCCUSAMP (hlq = CCU) |
hlq.SFEKSAMP (hlq = FEK) |
Langage JCL pour les constructions de projets distants, etc. |
ELAXMSAM |
hlq.SCCUSAMP (hlq = CCU) |
hlq.SFEKSAMP (hlq = FEK) |
Procédure JCL de l'espace adresse WLM du compilateur de procédures mémorisées PL/I et COBOL. |
ELAXMJCL |
hlq.SCCUSAMP (hlq = CCU) |
hlq.SFEKSAMP (hlq = FEK) |
Langage JCL définissant le compilateur de procédures mémorisées PL/I et COBOL pour DB2 |
ADNVSAM | N'existe pas |
hlq.SFEKSAMP (hlq = FEK) |
Langage JCL définissant le référentiel ADM CRD |
ADNPCCSD | N'existe pas
|
hlq.SFEKSAMP (hlq = FEK) |
Langage JCL activant le serveur CRD dans la région CICS primaire |
ADNCMSGH | N'existe pas |
hlq.SFEKSAMP (hlq = FEK) (n'existe pas dans la version 7.0) |
Langage JCL compilant le gestionnaire de message de pipeline |
ADNSMSGH | N'existe pas |
hlq.SFEKSAMP (hlq = FEK) |
Exemple de code source pour le gestionnaire de message de pipeline |
ADNARCSD | N'existe pas |
hlq.SFEKSAMP (hlq = FEK) |
Langage JCL activant le serveur CRD dans les régions CICS non-primaires |
CRASUBMT |
hlq.SCRACLST (hlq = CRA) |
hlq.SCRACLST (aide = CRA) |
Liste de commandes CLIST pour la soumission du langage JCL à un serveur CARMA |
CRAMREPR |
hlq.SCRASAM (hlq = CRA) |
hlq.SCRASAMP (hlq = CRA) (nouveau nom de membre dans la version 7.1 CRA$VMSG) |
Le langage JCL doit créer la méthode d'accès VSAM au message du gestionnaire CARMA |
CRAREPR |
hlq.SCRASAM (hlq = CRA) |
hlq.SCRASAMP (hlq = CRA) (nouveau nom de membre dans la version 7.1 CRA$VDEF) |
Le langage JCL doit créer la méthode d'accès VSAM à la configuration du gestionnaire CARMA |
CRASREPR |
hlq.SCRASAM (hlq = CRA) |
hlq.SCRASAMP (hlq = CRA) (nouveau nom de membre dans la version 7.1 CRA$VSTR) |
Le langage JCL doit créer la méthode d'accès VSAM aux informations personnalisées du gestionnaire CARMA |
CRALREPR |
hlq.SCRASAM (hlq = CRA) |
hlq.SCRASAMP (hlq = CRA) (nouveau nom de membre dans la version 7.1 CRA#VSLM) |
Le langage JCL doit créer la méthode d'accès VSAM au message de la RAM du SCLM |
CRASALX |
hlq.SCRASAM (hlq = CRA) |
hlq.SCRASAMP (hlq = CRA) (nouveau nom de membre dans la version 7.1 CRA#ASLM) |
Le langage JCL doit créer les fichiers de la RAM du SCLM |
CRATREPR |
hlq.SCRASAM (hlq = CRA) |
hlq.SCRASAMP (hlq = CRA) (nouveau nom de membre dans la version 7.1 CRA#VPDS) |
Le langage JCL doit créer la méthode d'accès VSAM au message de la RAM du fichier partitionné |
Ficher | Emplacement par défaut v 6.0.1 | Emplacement par défaut version 7.0/version 7.1 | But |
---|---|---|---|
rsed.envvars | /usr/lpp/wd4z/rse/lib/ | /usr/lpp/wd4z/rse/lib/ | Fichier de configuration RSE |
rsecomm.properties | /usr/lpp/wd4z/rse/lib/ | /usr/lpp/wd4z/rse/lib/ | Fichier de configuration de trace RSE |
ssl.properties | /usr/lpp/wd4z/rse/lib/ | /usr/lpp/wd4z/rse/lib/ | Fichier de configuration SSL RSE |
setup.env.zseries | /usr/lpp/wd4z/rse/lib/ | (n'est plus personnalisé) | Exportation de variables d'environnement RSE |
projectcfg.properties | (N'existe pas) | /usr/lpp/wd4z/rse/lib/ | Fichier de configuration de projets hôte |
FMIEXT.properties | (N'existe pas) | /usr/lpp/wd4z/rse/lib/ (n'existe pas dans la version 7.0) | Fichier de configuration du gestionnaire de fichiers |
CRASRV.properties | /usr/lpp/wd4z/rse/lib/ | /usr/lpp/wd4z/rse/lib/ | Fichier de configuration du gestionnaire CARMA |
rexxsub | /usr/lpp/wd4z/rse/lib/ | (n'est plus personnalisé) | Le langage z/OS UNIX REXX du gestionnaire CARMA doit exécuter la liste de commandes CRASUBMT CLIST du système MVS |
Membre/Fichier | Emplacement par défaut | Personnalisation obligatoire |
---|---|---|
BPXPRMxx | SYS1.PARMLIB | Définissez MAXASSIZE sur 2147483647 ou plus |
PROGxx | SYS1.PARMLIB | L'APF autorise hlq.SFEKLOAD |
ASCHPMxx | SYS1.PARMLIB | Définissez une classe de transaction APPC du service Commandes TSO |
services | /etc/ | Définissez le démon RSE |
inetd.conf | /etc/ | Définissez le démon RSE |
ISPF.conf | /etc/SCLMDT/CONFIG/ | Définissez l'emplacement du serveur de commandes TSO |
/ | APPC | Définissez une transaction APPC du service Commandes TSO |
/ | WLM | Associez un programme transactionnel APPC à un groupe de performances TSO |
/ | WLM | Attribuez un environnement d'application à la procédure mémorisée DB2 |
Avant d'installer la version 7.1.1, si vous utilisiez la version précédente de Developer for System z, il est recommandé d'enregistrer la personnalisation associée comme décrit à la section Sauvegarde des fichiers déjà configurés.
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.
Les conditions de LINKLIST peuvent être ignorées en ajoutant une instruction STEPLIB à rsed.envvars, voir Personnalisation de rsed.envvars, le fichier de configuration de l'Explorateur de systèmes éloignés RSE.
MAXASSIZE définit la taille de la région de l'espace adresse (processus). Définissez MAXASSIZE dans SYS1.PARMLIB(BPXPRMxx) sur 2147483647 ou plus.
Cette valeur est vérifiable et définissable de manière dynamique (avant la procédure de chargement initial suivante) au moyen des commandes de la console suivantes, décrites dans le manuel MVS System Commands (SA22-7627).
1. DISPLAY OMVS,O 2. SETOMVS MAXASSIZE=2147483647
Vous trouverez de plus amples informations sur les autres emplacements au niveau desquels les tailles d'espace adresse peuvent être définies ou limitées dans la section Taille d'espace adresse.
Pour que le moniteur de travaux JES puisse accéder aux fichiers spoules JES, l'AFP doit autoriser le module FEJJMON de la bibliothèque de chargement hlq.SFEKLOAD.
Les autorisations de l'APF sont définies dans SYS1.PARMLIB(PROGxx), si votre site se conforme aux recommandations IBM. Pour plus d'informations sur la définition des autorisations APF, consultez le document MVS Initialization and Tuning Reference (SA22-7592).
A des fins de tests, les autorisations APF peuvent également être octroyées de manière dynamique. Elles seront en vigueur jusqu'à la procédure de chargement initial suivante du système. La commande requise de la console se présente comme suit :
SETPROG APF,ADD,DSN=hlq.SFEKLOAD,SMS
Pour plus d'informations sur la commande SETPROG, consultez le manuel MVS System Commands (SA22-7627).
Le moniteur de travaux JES est le composant de Developer for System z qui gère l'ensemble de la connectivité JES. Un fichier de configuration permet de personnaliser certains aspects afin de répondre aux normes de votre site.
Le modèle de fichier de configuration se trouve dans :
hlq.SFEKSAMP(FEJJCNFG)
Le fichier comporte un ensemble de définitions de variables d'environnement. Les lignes mises en commentaire commencent par un dièse (#). Le modèle de fichier de configuration est présenté dans la figure 1.
SERV_PORT=6715 CODEPAGE=UTF-8 HOST_CODEPAGE=IBM-1047 TZ=EST5EDT #LIMIT_VIEW=USERID LISTEN_QUEUE_LENGTH=5 MAX_DATASETS=32 MAX_THREADS=200 TIMEOUT_INTERVAL=1200 TIMEOUT=3600 AUTHMETHOD=RACF #_BPXK_SETIBMOPT_TRANSPORT=<tcpip stack name>
Les définitions suivantes sont requises :
Les définitions suivantes sont facultatives. Si vous les omettez, les valeurs par défaut seront utilisées comme indiqué ci-après :
Le moniteur de travaux JES est le composant de Developer for System z qui gère l'ensemble de la connectivité JES. Pour ce faire, un serveur doit être actif sur le système (que ce soit en travail utilisateur ou en programme STC). Suivez la procédure de personnalisation du langage JCL décrite dans hlq.SFEKSAMP(FEJJJCL) pour créer le serveur de moniteur de travaux JES en fonction des normes de votre site.
Si vous devez lancer la fonction de trace du moniteur de travaux JES pour un diagnostic, ajoutez "-TV" à la ligne PARM. La fonction de trace réduit les performances et ne doit être effectuée que sur indication du centre de support IBM.
//JMONITOR EXEC PGM=FEJJMON,TIME=1440,REGION=0M, // PARM=('POSIX(ON),ENVAR("_CEE_ENVFILE=DD:ENVIRON")/ -TV')
Le traçage est également contrôlable par les commandes de la console. Supposons que le nom de travail utilisé soit JMON, la première commande de la console répertoriée ci-dessous active le traçage et la seconde la désactive.
1. F JMON,APPL=-TV 2. F JMON,APPL=-TN
Le moniteur de travaux JES s'exécute comme un travail utilisateur ou une tâche lancée (STC). Les tâches suivantes doivent être implémentées pour définir JMON comme un programme STC :
//JMON PROC HLQ=FEK, // PRM= //* //* RD/Z JES JOB MONITOR //* //JMONITOR EXEC PGM=FEJJMON,TIME=1440,REGION=0M, // PARM=('POSIX(ON),ENVAR("_CEE_ENVFILE=DD:ENVIRON")/&PRM') //STEPLIB DD DISP=SHR,DSN=&HLQ..SFEKLOAD //ENVIRON DD DISP=SHR,DSN=&HLQ..SFEKSAMP(FEJJCNFG) //SYSPRINT DD SYSOUT=* //SYSABEND DD SYSOUT=* //SYSOUT DD SYSOUT=* //SYSIN DD DUMMY //*SYSTCPD DD DISP=SHR,DSN=SYS1.TCPIP.DATA
Pour plus de simplicité, il est recommandé que le nom de membre corresponde au nom de procédure (JMON dans l'exemple ci-dessus).
Utilisez l'exemple de commande ci-après pour créer un tel ID utilisateur, dans lequel userid est l'ID utilisateur en question, groupid est le groupe par défaut et uid est l'identificateur UNIX.
ADDUSER userid DFLTGRP(groupid) NOPASSWORD OMVS(UID(uid) HOME(/tmp) PROGRAM(/bin/sh))
a. SETROPTS GENERIC(STARTED) b. RDEFINE STARTED ** STDATA(USER(=MEMBER)) c. SETROPTS CLASSACT(STARTED) d. SETROPTS RACLIST(STARTED)
Pour ajouter le moniteur de travaux JES comme un programme STC, vous avez besoin des commandes RACF suivantes, où jmon désigne le nom de membre JCL et userid correspond à l'ID utilisateur qui dispose des droits qui seront utilisés.
a. RDEFINE STARTED jmon.* STDATA(USER(userid)) b. SETROPTS RACLIST(STARTED) REFRESH
Pour plus d'informations sur les tâches lancées et la sécurité, consultez Security Server RACF Security Administrator's Guide (SA22-7683).
L'opérateur système peut lancer les commandes suivantes sur la console (où JMON désigne le nom STC du moniteur de travaux JES) :
a. Start JMON b. stoP JMON c. Display A,JMON
Si vous avez les droits d'accès nécessaires, vous pouvez saisir ces commandes depuis l'utilitaire SDSF, en faisant précéder la commande d'une barre oblique ('/'). Pour plus d'informations sur les commandes de la console, consultez le document MVS System Commands (SA22-7627).
L'ID utilisateur assigné au moniteur de travaux JES doit avoir des droits d'accès READ à la bibliothèque de chargement Developer for System z, hlq.SFEKLOAD.
Démarrez le travail utilisateur ou la tâche lancée selon la procédure décrite ci-dessus. Si le travail s'arrête avec un code retour 66, cela signifie que l'APF n'autorise pas hlq.SFEKLOAD.
Pour être autorisés à exécuter des opérations via le moniteur de travaux JES, les utilisateurs doivent recevoir un droit d'accès à la classe OPERCMDS. Cette opération peut être effectuée de façon conditionnelle, afin que les droits d'accès des utilisateurs ne soient effectifs que lorsqu'ils utilisent le moniteur de travaux JES. Pour utiliser cette vérification d'accès conditionnelle, la classe CONSOLE doit être active et une console doit être définie avec le nom JMON (JMON est le seul nom valide).
Par exemple, votre administrateur de sécurité lancera les commandes RACF suivantes :
1. SETROPTS CLASSACT(CONSOLE) 2. RDEFINE CONSOLE JMON UACC(READ) 3. SETROPTS RACLIST(CONSOLE) REFRESH
Utilisez les commandes RACF suivantes pour autoriser les utilisateurs à émettre des commandes JES2 uniquement via le moniteur de travaux JES, dans lesquelles id est l'ID utilisateur ou l'ID groupe des utilisateurs de Developer for System z :
1. RDEFINE OPERCMDS JES2.** UACC(NONE) 2. PERMIT JES2.** CLASS(OPERCMDS) ID(id) ACCESS(CONTROL) WHEN(CONSOLE(JMON)) 3. SETROPTS RACLIST(OPERCMDS) REFRESH 4. SETROPTS GENERIC(OPERCMDS) REFRESH
Le moniteur de travaux JES ne met pas à disposition des utilisateurs de Developer for System z un accès complet au spoule JES. Seules les commandes figurant dans le tableau 6 sont disponibles. Les commandes sont émises 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 est encore limitée par les techniques décrites ci-après.
Commande | JES2 | JES3 |
---|---|---|
Mettre en attente | $Hjobid | *F,J=jobid,H |
Publier | $Ajobid | *F,J=jobid,R |
Annuler | $Cjobid | *F,J=jobid,C |
Purger | $Cjobid,P | *F,J=jobid,C |
Sans autorisation pour ces commandes de console, les utilisateurs peuvent toujours soumettre des travaux et lire les sorties de travaux, s'ils disposent d'autorisations d'accès aux fichiers spoule.
Pour restreindre les utilisateurs à leur propres travaux sur le spoule JES, définissez l'instruction "LIMIT_VIEW=USERID" dans le fichier de configuration du moniteur de travaux JES (FEJJCNFG). S'ils ont besoin d'accéder à davantage de travaux, mais pas à tous, utilisez les fonctions de protection du fichier spoule standard de votre produit de sécurité, telles que la classe JESSPOOL dans RACF.
Quand vous définissez d'autres protections, notez que le moniteur de travaux JES se sert de SAPI (interface de programme d'application SYSOUT) pour accéder au spoule. Par conséquent, l'utilisateur a besoin, au minimum, de droits d'accès de mise à jour des fichiers spoules, même pour des fonctionnalités de navigation. Cet élément prérequis ne s'applique pas si vous utilisez z/OS v 1.7 (z/OS 1.8 pour JES3) ou supérieure. Dans ce cas, les droits d'accès READ suffisent pour les fonctionnalités de navigation.
Pour plus d'informations sur la protection du fichier spoule JES, consultez le guide Security Server RACF Security Administrator's Guide (SA22-7683).
Developer for System z met à disposition des exemples de procédures de langage JCL qui peuvent être utilisés lors de la construction de langage 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, Assembleur et C/C++.
Ces procédures permettent aux installations d'appliquer leurs propres normes. Cela garantit également que les développeurs utilisent les mêmes procédures, options de compilateur et niveaux de compilateur.
SMP/E installe ces exemples de procédures JCL dans hlq.SFEKSAMP. Si vous prévoyez d'utiliser ces procédures, vous devez :
Les exemples de procédures à copier et personnaliser sont répertoriés dans le tableau 7.
Membre | But |
---|---|
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++. |
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 traduction 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. |
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. |
Le tableau 8 contient une liste de contrôle pour les différents qualificatifs de haut niveau utilisés dans les procédures ELAXF*.
Produit | Valeur par défaut HLQ | Valeur |
---|---|---|
RD/z | FEK | |
CICS | CICSTS31.CICS | |
DB2 | DSN810 | |
IMS | IMS | |
COBOL | IGY.V3R4M0 | |
PL/I | IBMZ.V3R6M0 | |
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, copiez-les dans une bibliothèque privée et 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 de travail du client. Ne personnalisez pas l'exemple de langage JCL dans le fichier d'installation, car les opérations de maintenance peuvent remplacer ces membres et annuler vos personnalisations.
//MYJOB JOB <paramètres du travail> //PROCS JCLLIB ORDER=(hlq.SFEKSAMP)
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. Si vous décidez de modifier le nom de la procédure ou le nom d'une étape de la procédure, le fichier des propriétés correspondantes du client doit également être modifié. Nous recommandons de ne pas modifier les noms de la procédure et de l'étape.
La définition de transaction APPC est devenue optionnelle dans la version 7.1. Developer for System z utilise maintenant par défaut SCLM Developer Toolkit pour fournir le service Commandes TSO. Cette configuration s'effectue dans rsed.envvars, voir Personnalisation de rsed.envvars, le fichier de configuration de l'Explorateur de systèmes éloignés RSE.
// PARM='ISPSTART CMD(%FEKFRSRV TIMEOUT=60) NEWAPPL(ISR) NESTMACS'
Le service Commandes TSO est mis en oeuvre comme un programme transactionnel APPC, FEKFRSRV et doit être actif pour que les connexions Developer for System z s'établissent entre l'hôte et le client. FEKFRSRV joue le rôle de serveur hôte pour exécuter les commandes TSO provenant du poste de travail via TCP/IP. Il n'est pas nécessaire d'installer APPC sur le poste de travail, car celui-ci communique avec FEKFRSRV via TCP/IP. Chaque poste de travail 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
Com pé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)
|
Pour plus d'informations sur la gestion WLM/SRM, consultez le manuel MVS Planning Workload Management (SA22-7602) . Pour plus d'informations sur les segments OMVS et les profils de protection de fichiers, consultez le guide Security Server RACF Security Administrator's Guide (SA22-7683).
Le programmeur système ou l'administrateur APPC doit effectuer les étapes suivantes pour configurer la fonction de commande :
CLASSADD CLASSNAME(A) MAX(20) MIN(1) MSGLIMIT(200)
La personnalisation suivante est nécessaire pour incorporer les modèles de procédures mémorisées DB2 (Compilateur de procédures mémorisées PL/I et COBOL) dans votre système. Vous aurez besoin de l'aide d'un administrateur WLM et d'un administrateur DB2 pour effectuer ces tâches.
Quand l'outil SMP/E s'applique, le modèle de bibliothèque hlq.SFEKSAMP et la bibliothèque de procédure hlq.SFEKPROC contiennent les membres de la procédure mémorisée DB2 classée dans le tableau 10.
Membre | But |
---|---|
hlq.SFEKSAMP(ELAXMJCL) | Modèle de langage JCL définissant le compilateur de procédures mémorisées PL/I et COBOL pour DB2. |
hlq.SFEKSAMP(ELAXMSAM) | Modèle de procédure JCL de l'espace adresse WLM du compilateur de procédures mémorisées PL/I et COBOL. |
hlq.SFEKPROC(ELAXMREX) | Code REXX du compilateur de procédures mémorisées PL/I et COBOL. |
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 :
Vous allez avoir besoin de l'aide de votre administrateur CICS pour effectuer les tâches suivantes :
Les transformations bidirectionnelles EST sont effectuées dans l'environnement d'exécution de flux de service (SFR) de CICS par le module FEJBDTRX. Le module FEJBDTRX est appelé lorsque les conversions bidirectionnelles sont nécessaires dans le code généré par EST (lorsque le mappage est généré dans des messages dont les attributs bidirectionnels sont différents).
Si l'installation automatique est définie sur autoINactive, définissez le programme FEJBDTRX sur CICS au moyen de la commande CEDA, par exemple :
CEDA DEF PROG(FEJBDTRX) LANG(LE) G(xxx)
De plus, le code généré par EST peut prendre en charge la transformation bidi dans d'autres environnements que SFR CICS (par exemple, des applications par lots). 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, hlq.SFEKLOAD.
Le Gestionnaire de déploiement d'application (ADM) propose une approche de déploiement et une interface de programmation d'application de déploiement communes pour tous les composants de Developer for System z.
De plus, ADM met à disposition un client et un serveur (basé sur l'hôte) de définition de ressource CICS (CRD), qui fournissent les fonctions suivantes :
Developer for System z met à disposition trois transactions qui sont utilisées par le serveur CRD lors de la définition et de la consultation des ressources CICS. Un exemple de langage COBOL est fourni afin de permettre une personnalisation en fonction du site.
Pour plus d'informations sur le gestionnaire de déploiement d'application, voir Rational Developer for System z Application Deployment Manger User's Guide (SC11-2793-00).
Les étapes de personnalisation ci-après sont nécessaires pour activer le serveur CRD.
Avant d'installer la version 7.1.1, si vous utilisiez la version précédente du serveur CRD, il est recommandé d'enregistrer la personnalisation associée comme décrit à la section Sauvegarde des fichiers déjà configurés.
Copiez les membres à personnaliser depuis le répertoire d'installation vers une bibliothèque personnelle et personnalisez les copies afin d'éviter de les écraser lors d'une opération de maintenance :
facultatif (gestionnaire de message de pipeline)
facultatif (mise à jour de correctif CSD pour les régions non-primaires)
Personnalisez et soumettez un travail ADNVSAM pour attribuer et initialiser le fichier de méthode d'accès VSAM du référentiel de serveur CRD. Pour obtenir des instructions de personnalisation, consultez la documentation qui se trouve dans ADNVSAM.
Il est conseillé de créer un référentiel séparé pour chaque région de connexion primaire CICS. Le partage de référentiel implique que toutes les régions CICS concernées utiliseront les mêmes valeurs stockées dans le référentiel, et que de multiples espaces adresse écriront dans la méthode d'accès VSAM, qui doit être configurée correctement pour cela.
Le serveur CRD doit être défini pour la région de connexion primaire. Il s'agit de la région qui traite les requêtes de service Web en provenance de Developer for System z.
CEDA INSTALL GROUP(ADNPCRGP)
Le gestionnaire de messages du pipeline (ADNSMSGH) 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. ADNSMSGH est référencé par le fichier de configuration du pipeline et doit donc être placé dans la concaténation RPL CICS. ADNSMSGH est également utilisé pour définir l'ID de transaction pour ADMD, ADMR ou ADMI selon l'opération demandée. Vous souhaiterez peut-être personnaliser ADNSMSGH pour utiliser des ID de transaction différents.
Utilisation des valeurs par défaut :
Personnalisation d'ADNSMSGH :
Le serveur CRD peut également être utilisé avec une ou plusieurs régions de connexion non primaire, qui sont généralement des régions gérant les applications (AOR).
CEDA INSTALL GROUP(ADNARRGP)
Avant d'installer la version 7.1.1, si vous utilisiez la version précédente de Developer for System z, il est recommandé d'enregistrer la personnalisation associée décrite dans la section Sauvegarde des fichiers déjà configurés.
Si vous n'êtes pas familiarisé avec le système z/OS UNIX, il est conseillé de demander l'aide d'un administrateur expérimenté dans z/OS UNIX ou un autre UNIX pour effectuer les tâches répertoriées dans ce chapitre.
Les commandes z/OS UNIX nécessaires pour effectuer ces tâches sont décrites brièvement pour votre convenance. Pour plus d'informations sur ces commandes, consultez l'ouvrage UNIX System Services Command Reference (SA22-7802), sauf indication contraire.
Les tâches décrites ci-après 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 exit pour pour retourner à TSO.
MVS permet de modifier les fichiers z/OS UNIX à l'aide de l'utilitaire ISPF par l'intermédiaire de la commande OEDIT. Cette commande s'utilise sous TSO et OMVS.
La plupart des fichiers z/OS UNIX présentent des droits d'accès en écriture restreints au propriétaire du fichier. Cette restriction peut être ignorée de plusieurs manières.
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.
Permet à l'utilisateur d'obtenir un UID 0 par l'intermédiaire de la commande su. Il s'agit de la configuration recommandée.
Permet à un utilisateur de lire/écrire dans tout fichier, et de lire ou de rechercher dans tout répertoire. Des droits d'accès CONTROL (ou plus) à ce profil de sécurité ajoutent l'écriture dans tout répertoire à la liste des autorisations.
Pour plus d'informations concernant la sécurité de z/OS UNIX, voir UNIX System Services Planning (GA22-7800).
Toutes les instructions de chemin d'accès /usr/lpp/wd4z/ que vous trouverez dans ce chapitre se rapportent au chemin utilisé au cours de l'installation de Developer for System z. Le chemin par défaut est /usr/lpp/wd4z/, mais il peut ne pas s'appliquer à votre site.
Vous pouvez tester votre configuration TCP/IP à l'aide de la commande TSO HOMETEST. Pour plus d'informations sur cette commande, voir Communications Server IP System Administrator's Commands (SC31-8781).
Les publications suivantes peuvent être utiles pour comprendre le système z/OS UNIX :
Il est recommandé de copier le fichier /usr/lpp/wd4z/rse/lib/rsed.envvars dans un nouveau répertoire (tel que /etc/wd4z/) et de personnaliser la copie afin d'éviter d'écraser votre personnalisation lors d'une opération de maintenance. Toutefois, lors de cette procédure, vous devez également copier les fichiers suivants, depuis le répertoire d'installation (/usr/lpp/wd4z/rse/lib/, par défaut) vers le nouvel emplacement :
Les fichiers dont la liste figure dans le tableau 11 doivent être également copiés si vous prévoyez d'utiliser les dispositifs en option dont ils font partie :
fichier | fonction |
---|---|
projectcfg.properties | Projets basés sur l'hôte
Voir (Facultatif) Personnalisation de projectcfg.properties, configuration de projets hôte |
FMIEXT.properties | Intégration du gestionnaire de fichiers
Voir (Facultatif) Personnalisation de FMIEXT.properties, intégration de File Manager |
CRASRV.properties | CARMA
Voir (Facultatif) Activation d'IBM Common Access Repository Manager (CARMA) |
Les différents exemples de commandes suivants,
créent un répertoire nommé /etc/rd4z et copient rsed.envvars à partir du répertoire actuel vers /etc/rd4z. Répétez la commande de copie pour le reste des fichiers.
Le résultat de la copie est vérifiable à l'aide de la commande ls /etc/wd4z, qui doit donner une sortie semblable à ceci ($ est l'invite de z/OS UNIX) :
$ ls /etc/wd4z /etc/wd4z rsecomm.properties server.zseries ssl.properties rsed.envvars setup.env.zseries
1. mkdir /usr/lpp/wd4z/rse/lib/cust 2. ln -s /usr/lpp/wd4z/rse/lib/cust /etc/wd4z
Toutes les méthodes de connexion au client Developer for System z utilisent les mêmes variables définies dans le fichier rsed.envvars, situé par défaut dans le répertoire d'installation, /usr/lpp/wd4z/rse/lib/, mais qui peut être copié dans un autre répertoire à l'étape précédente. Le modèle de fichier fourni comporte les instructions dont la liste est présentée dans la figure 4, où les lignes mises en commentaire commencent par un dièse (#).
#============================================================= # (1) required customizations JAVA_HOME=/usr/lpp/java/J1.4 RSE_HOME=/usr/lpp/wd4z TZ=EST5EDT LANG=C PATH=/bin:/usr/sbin:. _RSE_CLASS_OPTS="" _RSE_JAVAOPTS="" #_RSE_JAVAOPTS="$_RSE_JAVAOPTS -DTSO_SERVER=APPC" #============================================================= # (2) required customizations if SCLMDT is used _CMDSERV_BASE_HOME=/usr/lpp/SCLMDT _CMDSERV_BASE_LOAD=BWB.SBWBLOAD _CMDSERV_CONF_HOME=/etc/SCLMDT _CMDSERV_WORK_HOME=/var/SCLMDT STEPLIB=NONE #STEPLIB=$_CMDSERV_BASE_LOAD _RSE_CMDSERV_OPTS="" #============================================================= # (3) optional customizations #_RSE_PORTRANGE=8108-8118 #_FEKFLOCK_USERID_=user_id #_FEKFLOCK_JOBNAME_=job_name #_FEKFSCMD_TP_NAME_=tp_name #_FEKFSCMD_PARTNER_LU_=lu_name #============================================================= # (4) do not change unless directed by IBM support center RSE_LIB=$RSE_HOME/rse/lib ICU_LIB=$RSE_HOME/icuc/lib _CEE_RUNOPTS="ALL31(ON) HEAP(32M,32K,ANYWHERE,KEEP,,) TRAP(ON)" _CEE_DMPTARG=$HOME/.eclipse/RSE/$RSE_USER_ID _BPX_SHAREAS=YES _BPX_SPAWN_SCRIPT=YES PATH=$JAVA_HOME/bin:$RSE_LIB:$_CMDSERV_BASE_HOME/bin:$PATH LIBPATH=$JAVA_HOME/bin:$JAVA_HOME/bin/classic:$ICU_LIB:$RSE_LIB:. CLASSPATH=$RSE_LIB:$RSE_LIB/dstore_core.jar:$RSE_LIB/clientserver.jar CLASSPATH=$CLASSPATH:$RSE_LIB/dstore_extra_server.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-1.4.3.jar:$RSE_LIB/cdtparser.jar CLASSPATH=$CLASSPATH:$RSE_LIB/wdzBidi.jar:$RSE_LIB/fmiExtensions.jar CLASSPATH=.:$CLASSPATH _RSE_CMDSERV_OPTS="&SESSION=SPAWN$_RSE_CMDSERV_OPTS" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -DSCLMDT_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 -Dcom.ibm.cacheLocalHost=true" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -showversion" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Duser.home=$HOME" _RSE_JAVAOPTS="$_RSE_JAVAOPTS -Dclient.username=$RSE_USER_ID" _RSE_JAVAOPTS="$_RSE_JAVAOPTS $_RSE_CLASS_OPTS" _RSE_SERVER_CLASS=com.ibm.etools.systems.dstore.core.server.Server _RSE_SERVER_TIMEOUT=120000 #============================================================= # (5) additional environment variables
Les définitions suivantes sont requises :
Developer for System z utilise par défaut SCLM Developer Toolkit pour fournir le service Commandes TSO. APPC est utilisé 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 SCLM Developer Toolkit est utilisé, soit pour le service Commandes TSO, soit lorsque le module d'extension SCLMDT est installé dans le client Developer for System z.
Developer for System z utilise LINKLIST par défaut pour accéder à la bibliothèque de chargement de SCLM Developer Toolkit. STEPLIB est utilisé lorsque la directive STEPLIB suivante est retirée de la mise en commentaire :
STEPLIB=$_CMDSERV_BASE_LOAD
Les définitions suivantes sont facultatives. Si vous les omettez, les valeurs par défaut seront utilisées.
Les définitions suivantes sont nécessaires, et ne doivent pas être modifiées sans instruction du point service IBM.
STEPLIB=CEE.SCEERUN:CEE.SCEERUN2:CBC.SCLBDLL
STEPLIB=$STEPLIB:CEE.SCEERUN:CEE.SCEERUN2:CBC.SCLBDLL
Cette partie de la personnalisation de rsed.envvars spécifie les ports par lesquels le serveur RSE peut communiquer avec le client. Cette gamme de ports n'a aucune connexion avec les ports du démon RSE ou de REXEC/SSH.
Afin de mieux comprendre l'utilisation des ports, une brève description du processus de connexion RSE est incluse ci-après :
Pour spécifier la gamme de ports permettant au client de communiquer avec z/OS, supprimez la mise en commentaire et modifiez 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 la plage des ports de 8108 à 8117 qui sont utilisables). 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 met à disposition la possibilité de donner des paramètres supplémentaires à Java lors du démarrage du serveur RSE.
Les exemples d'options inclus dans rsed.envvars peuvent être activés en supprimant la mise en commentaire.
Developer for System z se repose sur le service INETD pour démarrer le serveur de l'Explorateur de systèmes éloignés (RSE) lorsqu'un client demande une connexion. INETD est un démon z/OS UNIX standard qui gère d'autres démons qui exécutent les tâches (dans ce cas, démarrer le serveur RSE). La configuration d'INETD ne fait pas partie de la personnalisation de Developer for System z, mais pour trouver des informations importantes, voir Annexe D. Configuration d'INETD.
Developer for System z prend en charge différentes façons de démarrer le serveur RSE.
Vous devez personnaliser au moins une de ces méthodes selon le fonctionnement prévu pour les utilisateurs.
Vous pouvez vérifier qu'INETD fonctionne à l'aide de la commande ps -e (lancée par un utilisateur autorisé). La sortie doit contenir une référence à INETD, par exemple (# est l'invite de z/OS UNIX) :
# ps -e PID TTY TIME CMD 7 ? 0:00 /usr/sbin/inetd
rse 4035/tcp #Developer for System z RSE
Le port doit correspondre à celui qui a été défini chez le client lors de la création d'une nouvelle connexion z/OS.
rse stream tcp nowait OMVSKERN /usr/lpp/wd4z/rse/lib/fekfrsed rsed -d /usr/lpp/wd4z/rse/lib -t 60
Tout ce qui se trouve après cet argument INETD sont des arguments de serveur, commençant par le nom de serveur.
rse stream tcp nowait OMVSKERN /usr/lpp/wd4z/rse/lib/fekfrsed rsed -d /etc/wd4z
Les définitions suivantes sont facultatives. Si vous les omettez, les valeurs par défaut seront utilisées.
a. # ps -e | grep inetd 50331687 ? 0:00 /usr/sbin/inetd b. # kill 50331687 c. # _BPX_JOBNAME='INETD' /usr/sbin/inetd d. # netstat | grep 4035 INETD4 00000B6A 0.0.0.0..4035 0.0.0.0..0 Listen
ICH408I USER(IBMUSER ) GROUP(SYS1 ) NAME(IBMUSER ) BPX.DAEMON CL(FACILITY) INSUFFICIENT ACCESS AUTHORITY ACCESS INTENT(READ ) ACCESS ALLOWED(NONE )
Aucune configuration propre à Developer for System z n'existe pour utiliser le serveur de commandes INETD REXEC (ou SSH). Toutefois, le client doit connaître 2 valeurs pour démarrer une connexion RSE par l'intermédiaire de REXEC/SSH :
Par défaut, ce répertoire d'installation est (/usr/lpp/wd4z/rse/lib/). Toutefois, server.zseries fait partie des fichiers qui doivent être également copiés si rsed.envvars est copié dans un répertoire différent, comme /etc/wd4z/.
Un port commun utilisé par REXEC est 512. Pour une vérification rapide du port, utilisez la commande NETSTAT, comme dans l'exemple ci-après ($ est l'invite de z/OS UNIX) :
$ netstat | grep 512 INETD4 0000002E 0.0.0.0..512 0.0.0.0..0 Listen
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. Son port commun est 22, et le nom de serveur est sshd.
Cette étape n'est obligatoire que dans le cas de l'utilisation de SCLM Developer Toolkit pour le service de Commandes TSO (cas par défaut). Elle n'est pas obligatoire dans le cas où APPC est utilisé pour le service de Commandes TSO.
SCLM Developer Toolkit nécessite que les définitions dans ISPF.conf créent un environnement valide pour exécuter les services ISPF. Le service Commandes TSO doit être ajouté à cet environnement ISPF.
ISPF.conf est créé lors de la personnalisation de SCLM Developer Toolkit, qui est décrite dans SCLM Developer Toolkit Installation and Customization Guide (SC23-8504). L'emplacement par défaut est /etc/SCLMDT/CONFIG, mais il peut ne pas s'appliquer à votre site.
Ajoutez les lignes ci-après à ISPF.conf, dans lesquelles hlq est identique au qualificatif de haut niveau utilisé pour installer Developer for System z (la valeur par défaut est FEK).
********************************************** * Developer for System z - TSO Commands server ********************************************** sysexec=hlq.SFEKPROC
Le résultat doit ressembler à l'exemple, voir la figure 5.
sysproc=ISP.SISPCLIB ispmlib=ISP.SISPMENU isptlib=ISP.SISPTENU ispplib=ISP.SISPPENU ispslib=ISP.SISPSLIB ispllib=BWB.SBWBLOAD ********************************************** * Developer for System z - TSO Commands server ********************************************** sysexec=FEK.SFEKPROC
L'installation de Developer for System z met à disposition plusieurs programmes de vérification de l'installation (IVP) pour le serveur RSE. Les scripts IVP se trouvent dans le répertoire d'installation, /usr/lpp/wd4z/rse/lib/ par défaut.
Tous les exemples de commandes de la présente section sous-entendent que les variables de l'environnement RSE sont configurées. De cette manière, les scripts IVP sont disponibles par l'intermédiaire de l'instruction PATH, et l'emplacement de rsed.envvars est connu. Utilisez les commandes pwd et cd pour vérifier votre répertoire de travail, et en changer pour le répertoire dans lequel rsed.envvars est personnalisé. Le script de shell setup.env.zseries peut alors être utilisé pour configurer les variables d'environnement RSE, comme dans l'exemple ci-après ($ est l'invite de z/OS UNIX) :
$ pwd /etc $ cd /etc/wd4z $ . ./setup.env.zseries
Le script de shell . ./setup.env.zseries, qui se trouve dans le même répertoire que rsed.envvars, exporte les variables d'environnement, de sorte que les autres processus peuvent les utiliser. Le premier "." (point) de . ./setup.env.zseries désigne une commande z/OS UNIX pour 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 avoir quitté ce dernier. Le second fait référence au répertoire de travail.
/usr/lpp/wd4z/rse/lib/fekfivpr 512 USERIDLa plupart des scripts fekfivp* demanderont également l'emplacement du rsed.envvars personnalisé si ./setup.env.zseries n'est pas exécuté en premier.
$ echo $STEPLIB none $ STEPLIB=TCPIP.SEZALOAD
ou
$ echo $STEPLIB SOME.STEPLIB.DATASET $ STEPLIB=$STEPLIB:TCPIP.SEZALOAD
Pour plus d'informations concernant le diagnostic des incidents de connexion RSE, voir l'Annexe B. 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/devzseries/support/.
La disponibilité des ports du moniteur de travaux JES, de REXEC, de SSH et du démon RSE peut être vérifiée en émettant la commande netstat. Le résultat doit présenter les ports utilisés par ces services, comme dans les exemples ci-après ($ est l'invite de z/OS UNIX) :
IPv4
$ netstat MVS TCP/IP NETSTAT CS V1R7 TCPIP Name: TCPIP 13:57:36 User Id Conn Local Socket Foreign Socket State ------- ---- ------------ -------------- ----- INETD4 00000014 0.0.0.0..22 0.0.0.0..0 Listen INETD4 00000030 0.0.0.0..512 0.0.0.0..0 Listen INETD4 0000004B 0.0.0.0..4035 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 V1R7 TCPIP Name: TCPIP 14:03:35 User Id Conn State ------- ---- ----- INETD4 00000018 Listen Local Socket: 0.0.0.0..22 Foreign Socket: 0.0.0.0..0 INETD4 00000046 Listen Local Socket: 0.0.0.0..512 Foreign Socket: 0.0.0.0..0 INETD4 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
Testez la connexion REXEC en exécutant la commande ci-après. 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: $ EZYRC01I Calling function rexec_af with the following: EZYRC02I Host: CDFMVS08, user USERID, cmd cd /etc/wd4z;export RSE_USER_ID=USERI D;./server.zseries -ivp, port 512 EZYRC19I Data socket = 4, Control socket = 6. expect to see time out messages after a successful IVP test 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 Server Started Successfully 1272 Server running on: CDFMVS08
$ java.net.SocketTimeoutException: Accept timed out at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384) at java.net.ServerSocket.implAccept(ServerSocket.java:471) at java.net.ServerSocket.accept(ServerSocket.java:442) at com.ibm.etools.systems.dstore.core.server. ConnectionEstablisher. ...
Ce test IVP peut être évité si le test précédent décrit dans Connexion REXEC, a été réussi.
Testez le script utilisé par la connexion REXEC et SSH en exécutant la commande ci-après :
fekfivps
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-après ($ est l'invite de z/OS UNIX) :
$ fekfivps $ java version "1.5.0" expect to see time out messages after a successful IVP test 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 Server Started Successfully 1751 Server running on: CDFMVS08$
$ java.net.SocketTimeoutException: Accept timed out at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384) at java.net.ServerSocket.implAccept(ServerSocket.java:471) at java.net.ServerSocket.accept(ServerSocket.java:442) at com.ibm.etools.systems.dstore.core.server.ConnectionEstablisher. ...
Testez la connexion du démon RSE en exécutant la commande ci-après. 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 à cet exemple ($ est l'invite de z/OS UNIX) :
$ fekfivpd 4035 USERID Password: SSL is disabled connected 8108 570655399 Succès
Testez la connexion du moniteur de travaux JES en exécutant la commande ci-après. 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-après ($ est l'invite de z/OS UNIX) :
$ fekfivpj 6715 Waiting for JES Job Monitor response... ACKNOWLEDGE01v03 Succès
Ce test IVP n'est nécessaire que dans le cas où vous utilisez SCLM Developer Toolkit, soit pour le service Commandes TSO soit pour le module d'extension client.
Testez la connexion au serveur Commandes TSO à l'aide de SCLM Developer en exécutant la commande ci-après.
fekfivpc
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 dans l'exemple suivant ($ est l'invite de z/OS UNIX ) :
$ fekfivpc ------------------------------------------------------------- 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/wd4z/rse/lib:/usr/lpp/SCLM DT/bin:/bin:/usr/sbin:. STEPLIB = BWB.SBWBLOAD _CMDSERV_BASE_HOME = /usr/lpp/SCLMDT _CMDSERV_CONF_HOME = /etc/SCLMDT _CMDSERV_WORK_HOME = /var/SCLMDT ------------------------------------------------------------- *** CHECK : HFS MODULES Checking install Directory : /usr/lpp/SCLMDT Checking for BWB modules in /bin directory 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 -------------------------------------------------------------
fekfivpc présente plusieurs paramètres facultatifs ne dépendant pas de la position :
N'exécutez pas cette procédure si vous n'avez pas configuré APPC pour le service Commandes TSO.
Testez la connexion au serveur Commandes TSO (en utilisant APPC) en exécutant la commande ci-après. 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 dans l'exemple ci-après ($ est l'invite de z/OS UNIX) :
$ fekfivpa USERID Enter password: 20070607 13:57:18.584060 /usr/lpp/wd4z/rse/lib/fekfscmd: version=Oct 2003 20070607 13:57:18.584326 Input parms: 1.2.3.4 * NOTRACE USERID ******** 20070607 13:57:18.585132 TP_name set via envvar: FEKFRSRV 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
Pour plus d'informations concernant le diagnostic des incidents de connexion RSE, voir l'Annexe B. 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/devzseries/support/.
Toutes les méthodes de connexion client de Developer for System z utilisent les variables de la couche SSL (Secure Socket Layer) définies dans le fichier ssl.properties, situé par défaut dans le répertoire d'installation, /usr/lpp/wd4z/rse/lib/. Toutefois, ssl.properties fait partie des fichiers qui doivent être également copiés si rsed.envvars est copié dans un répertoire différent, comme /etc/wd4z/. Le modèle de fichier fourni comporte les instructions dont la liste figure dans la figure 6, où les lignes mises en commentaire commencent par un dièse (#).
# Specify this property as true to enable SSL enable_ssl=false ################################### # Daemon Properties # The key database file and password need to be specified for # daemon to use. # The key label need to be specified if not default key. #daemon_keydb_file= #daemon_keydb_password= #daemon_key_label= ################################### # Server Properties # The keystore file and password need to be specified for the # server to use. #server_keystore_file= #server_keystore_password=
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 E. Configuration du protocole SSL.
Toutes les méthodes de connexion client de Developer for System z utilisent les variables définies dans le fichier rsecomm.properties, situé par défaut dans le répertoire d'installation, /usr/lpp/wd4z/rse/lib/. Toutefois, rsecomm.properties fait partie des fichiers qui doivent être également copiés si rsed.envvars est copié dans un répertoire différent, comme /etc/wd4z/. Le modèle de fichier fourni comporte les instructions dont la liste figure dans la figure 7, où les lignes mises en commentaire commencent par un dièse (#).
# 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 # 3 - Log error, warning, info and debug messages debug_level=1 # Log location # Log_To_StdOut # Log_To_File log_location=Log_To_File
Quand vous sélectionnez log_location=Log_To_File (fichier par défaut), les informations sont consignées dans home/.eclipse/RSE/USERID/rsecomm.log, où home désigne le chemin d'accès vers l'accueil défini dans le segment OMVS de l'utilisateur (ou le segment OMVS par défaut si l'utilisateur n'en possède pas) et USERID correspond à l'ID utilisateur de connexion (majuscule).
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 à l'exception 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 du projet est défini dans projectcfg.properties, situé par défaut dans le répertoire d'installation /usr/lpp/wd4z/rse/lib/ . Toutefois, projectcfg.properties fait partie des fichiers qui doivent être également copiés si rsed.envvars est copié dans un répertoire différent, comme /etc/wd4z/.
Le modèle de fichier fourni comporte les instructions dont la liste figure dans la figure 8, où les lignes mises en commentaire commencent par un dièse (#).
# # 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/wd4z/projects
La seule variable à modifier est PROJECT-HOME. Sa valeur, /var/wd4z/projects par défaut, correspond au répertoire principal des définitions du projet.
Pour plus d'informations sur les projets basés sur l'hôte, voir le livre blanc Host Based Projects in WebSphere Developer for System z version 7.0 dans la bibliothèque internet Developer for System z, http://www-306.ibm.com/software/awdtools/devzseries/library/
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 comprennent les fonctionnalités habituelles de visualisation, d'édition, de copie et d'impression que l'on trouve dans ISPF, étendues afin de répondre aux besoins des développeurs d'applications. La version en cours de Developer for System z prend en charge uniquement la visualisation/édition des fichiers MVS (dont VSAM KSDS et ESDS).
Veuillez noter que le produit IBM File Manager for z/OS doit être commandé, installé et configuré séparément. Consultez Rational Developer for System z - Guide de planification de l'hôte (SC11-2412-02) pour savoir quel niveau de File Manager est nécessaire 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.
Les définitions nécessaires à File Manager Developer for System z sont stockées dans FMIEXT.properties, qui se trouve par défaut dans le répertoire d'installation, /usr/lpp/wd4z/rse/lib/. Toutefois, FMIEXT.properties fait partie des fichiers qui doivent être également copiés si rsed.envvars est copié dans un répertoire différent, comme /etc/wd4z/.
L'exemple de fichier fourni comporte les instructions dont la liste figure dans la figure 9, où les lignes mises en commentaire commencent par un dièse (#).
# File Manager Integration (FMI) Extension properties # startup.script=/usr/lpp/wd4z/rse/lib/fmiSub startup.port=1957 startup.range=100 startup.fmload=FMN.SFMNMOD1 startup.jobcard1=//JOBCARD JOB <job parameters> startup.jobcard2=//* startup.jobcard3=//* startup.sysout=*
Le gestionnaire CARMA (Common Access Repository Manager) (FMID: HCMA710) représente un gain de productivité pour les développeurs qui créent des API pour les gestionnaires de configuration de logiciel (SCM). A leur tour, ces API peuvent être utilisées par les applications (Developer for System z par exemple) pour accéder aux SCM.
Avant d'installer la version 7.1.1, si vous utilisiez la version précédente du gestionnaire CARMA, il est recommandé d'enregistrer la personnalisation associée comme décrit à la section Sauvegarde des fichiers déjà configurés.
Après avoir installé CARMA, vous devez le configurer en procédant comme suit :
Voir le tableau 2 pour la liste des manuels qui proposent plus d'informations sur CARMA et son utilisation.
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 propriétés de la connexion CARMA du client. Les différents Niveaux de trace sont les suivants :
La valeur par défaut est
Journalisation des erreurs
Pour plus d'informations sur l'emplacement des fichiers journaux, voir l'Emplacement des fichiers journaux.
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 CARMA. L'installation par défaut est CRA, mais peut ne pas s'appliquer à votre site.
Pour configurer l'hôte MVS, procédez comme suit :
Si vous n'êtes pas familiarisé avec le système z/OS UNIX, il est conseillé de demander l'aide d'un administrateur z/OS UNIX ou autre UNIX expérimenté pour effectuer les tâches répertoriées dans cette section.
Les commandes z/OS UNIX nécessaires pour effectuer ces tâches sont décrites brièvement pour votre convenance. Pour plus d'informations sur ces commandes, consultez l'ouvrage UNIX System Services Command Reference (SA22-7802), sauf indication contraire.
Toutes les instructions de chemin d'accès /usr/lpp/wd4z/ que vous trouverez dans cette section se rapportent au chemin utilisé au cours de l'installation de Developer for System z, et non pas du gestionnaire CARMA. Le chemin par défaut est /usr/lpp/wd4z/, mais il peut ne pas s'appliquer à votre site.
Suivez les étapes ci-après pour configurer les composants z/OS UNIX CARMA ajoutés lors de l'installation d'IBM Rational Developer for System z (FMID: HHOP710) :
cp /usr/lpp/wd4z/rse/lib/CRASRV.properties /etc/wd4z
# CARMA configuration option # port.start=5227 port.range=100 startup.script.name=/usr/lpp/wd4z/rse/lib/rexxsub clist.dsname='hlq.SCRACLST(CRASUBMT)'
Les RAM (Repository Access Managers) sont des API écrites par l'utilisateur permettant d'interfacer avec les gestionnaires de configuration de logiciel z/OS. Pour activer les échantillons de RAM voulus, suivez les instructions des sections suivantes.
Pour plus d'informations sur les échantillons de RAM et les échantillons de code source fournis, voir Rational Developer for System z Common Access Repository Manager Developer's Guide (SC23-7660).
IBM Software Configuration and Library Manager (SCLM) Developer Toolkit (FMID: HSD3310) permet d'étendre les fonctions de SCLM au client. SCLM est lui-même un gestionnaire de code source hôte livré comme partie intégrante d'ISPF.
SCLM Developer Toolkit, qui est livré avec Developer for System z, est un module d'extension basé sur Eclipse qui procure une interface avec SCLM et permet d'accéder à tous les processus SCLM de développement du code existant et prend en charge le développement de Java et de J2EE complets sur le poste de travail avec la synchronisation à SCLM sur le grand système y compris la construction, l'assemblage et le déploiement du code J2EE du grand système.
Voir le tableau 2 pour la liste des manuels qui proposent plus d'informations sur SCLM Developer Toolkit et son installation, son utilisation et sa personnalisation.
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 la liste de contrôle qui se trouve dans le tableau 12 pour rassembler les informations nécessaires.
Personnalisation | Valeur |
---|---|
Numéro de port de serveur du moniteur de travaux JES
(par défaut 6715) :
Voir SERV_PORT dans Personnalisation de FEJJCNFG, le fichier de configuration du moniteur de travaux JES . |
|
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 Personnalisation ELAXF*, procédure de construction à distance. |
|
Procédure et/ou noms des étapes des procédures ELAXF* si
elles ont été modifiées.
Voir les annotations sur leur modification dans Personnalisation ELAXF*, procédure de construction à distance. |
|
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 l'Annexe A. Exécution de plusieurs instances de Developer for System z. |
|
Emplacement de la
procédure mémorisée DB2 si elle ne se trouve pas dans une bibliothèque de
procédure système :
Voir (Facultatif) Personnalisation ELAXM*, membres de procédure mémorisée DB2. |
|
Utilisation de la méthode de connexion DAEMON, REXEC ou SSH pour RSE : | |
Numéro de port TCP/IP du démon RSE (4035 par défaut) : | |
Chemin d'accès au script de shell server.zseries pour REXEC/SSH (/usr/lpp/wd4z/rse/lib par défaut, /etc/wd4z conseillé) : | |
Numéro de port REXEC ou SSH (512 ou 22 par défaut, respectivement) :
Voir Configuration de INETD REXEC (ou SSH). Remarque :
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. |
|
Emplacement du langage JCL CRA#ASLM pour les allocations de fichiers
RAM SCLM CARMA :
Voir les annotations concernant CRA#ASLM dans Activation de la RAM SCLM. |
z/OS est un système d'exploitation fortement 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, voirMVS Initialization and Tuning Guide (SA22-7591) et UNIX System Services Planning (GA22-7800).
zFS (zSeries File System) et HFS (Hierarchical File System) sont tous deux des systèmes de fichiers UNIX pouvant être utilisés dans un environnement UNIX z/OS UNIX. Cependant, zFS fournit les fonctions et avantages suivants :
Pour plus d'informations concernant zFS, voir UNIX System Services Planning (GA22-7800).
Chaque processus z/OS UNIX qui présente un STEPLIB qui est propagé de parent à enfant ou à travers une commande exec consomme environs 200 octets de zone de mémoire commune étendue ECSA. Dans le cas où aucune variable d'environnement STEPLIB n'est définie, ou dans le cas où 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(). Le serveur RSE lance plusieurs processus, et chaque connexion client dispose d'un serveur RSE privé. De ce fait, le nombre peut augmenter rapidement.
Developer for System z présente une valeur par défaut STEPLIB=NONE codée dans rsed.envvars, comme décrit dans Personnalisation de rsed.envvars, le fichier de configuration de l'Explorateur de systèmes éloignés RSE. 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.
Si vous utilisez effectivement l'instruction STEPLIB, vous devez vérifier le contenu de rsed.envvars pour voir si votre instruction STEPLIB est oui ou non la première.
STEPLIB=first.steplib.dataset:second.steplib.dataset
STEPLIB=$STEPLIB:first.steplib.dataset:second.steplib.dataset
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, comme par leur ajout à la zone permanente de programme (LPA), 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 MVS Initialization and Tuning Reference (SA22-7592).
Lorsque des programmes C (y compris le shellz/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.
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 Personnalisation de rsed.envvars, le fichier de configuration de l'Explorateur de systèmes éloignés RSE. 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 pour le 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 mettez l'éditeur de liens sur LPA dynamique, en ajoutant les lignes ci-après à 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. Pour plus d'informations concernant l'insertion de modules de chargement LE dans le LPA dynamique, voir Language Environment Customization (SA22-7564). Pour plus d'informations sur l'insertion de modules de chargement de compilateur C/C++ dans le LPA dynamique, voir 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 gamme 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).
IBM Java Virtual Machine (JVM) version 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 Java SDK and Runtime Environment User Guide.
Pour activer le partage de classe pour le serveur RSE, supprimez la mise en commentaire de l'instruction suivante, dans rsed.envvars, comme il est indiqué dans (Facultatif) Définition des paramètres de démarrage Java supplémentaires avec _RSE_*OPTS. 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).
_RSE_CLASS_OPTS=-Xshareclasses:name=RSE,groupAccess,nonFatal #_RSE_CLASS_OPTS="$_RSE_CLASS_OPTS -Xscmx6m
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 lors de l'utilisation de Java SecurityManager, voir 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 plus d'informations concernant les implications en termes de performances et d'utilisation de ces paramètres, voir 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 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.
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 concernant les tailles de pile et la récupération de place, voir 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 établies avec les options de commandes Java -Xms (initiale) et -Xmx (maximale).
Dans Developer for System z, les options de ligne de commande Java sont définies dans la directive _RSE_JAVAOPTS de rsed.envvars, comme décrit dans (Facultatif) Définition des paramètres de démarrage Java supplémentaires avec _RSE_*OPTS.
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Xms128m -Xmx128m"
Chaque site présente 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 satisfaire ces besoins. Avec la gestion de charge de travail, vous pouvez définir des objectifs de performances et assigner une importance à chaque but. 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-après.
Pour plus d'informations sur le sujet, voir MVS Planning Workload Management (SA22-7602).
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 telles que les ports TCP/IP 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 2 instances (ou plus), il est recommandé de NE PAS le faire, sauf si leurs niveaux de logiciel sont identiques et que les seules modifications se trouvent dans les membres de configuration. Developer for System z offre suffisamment de possibilités de personnalisation pour que plusieurs instances ne se chevauchent pas et nous vous recommandons vivement d'utiliser ces fonctions.
Dans un nombre limité de circonstances, vous pouvez partager tout sauf (certains) des composants personnalisables. La mise à disposition d'un accès non-SSL pour un utilisation sur site, et d'une communication encodée SSL pour une utilisation hors site est un exemple.
Pour configurer une autre instante d'une installation active de Developer for System z, suivez à nouveau les étapes de personnalisation pour les composants qui sont différents, en utilisant d'autres fichiers/répertoires/ports afin d'éviter un chevauchement avec la configuration en cours.
Dans l'exemple SSL mentionné ci-avant, les personnalisations du serveur RSE en cours peuvent être clonées, après quoi le clone de ssl.properties peut être 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 suivrait les actions ci-après :
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 conseillé 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-après décrit brièvement les éléments qui doivent (cela est fortement recommandé) être différents entre les instances de Developer for System z :
Vous trouverez ci-après 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; //
Cette annexe vous aide à résoudre certains incidents fréquents qui peuvent survenir lors de la configuration de Developer for System z.
Pour plus d'informations, consultez la section Support du site Developer for System z (http://www-306.ibm.com/software/awdtools/devzseries/support/) où vous trouverez des fiches techniques pour bénéficier des plus récentes informations produites par notre équipe de support.
Dans la section Bibliothèque du site Web, vous pouvez également consulter la dernière version de la documentation de Developer for System z, notamment les livres blancs.
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/
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 suivante présente les fichiers journaux que vous pouvez créer. Après ces journaux qui sont propres 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 :
La plupart des fichiers journaux sont situés dans home/.eclipse/RSE/USERID/, où home désigne le chemin d'accès à l'accueil défini dans le segment OMVS de l'utilisateur (ou le segment OMVS par défaut si l'utilisateur n'en possède pas) et USERID correspond à l'ID utilisateur de connexion (majuscule).
/tmp/ contient les fichiers journaux créés avant la vérification de l'ID utilisateur.
Journalisation des opérations classiques. La valeur par défaut du modèle JCL hlq.SFEKSAMP(FEJJJCL) est définie par SYSOUT=*.
Journalisation de trace. La valeur par défaut du modèle JCL hlq.SFEKSAMP(FEJJJCL) est définie par SYSOUT=*. La fonction de trace est activée à l'aide du paramètre -TV, voir Personnalisation du Langage JCL d'initialisation du moniteur de travaux JES pour des informations détaillées.
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 hlq.SFEKSAMP(FEKAPPCC) est définie par 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 hlq.SFEKSAMP(FEKAPPCC) est définie par &SYSUID.FEKFRSRV.&TPDATE.&TPTIME.LOG. Pour plus d'informations, voir MVS Planning APPC/MVS Management (SA22-7599).
Plusieurs fichiers journaux créés par les composants associés à RSE existent. La plupart sont situés dans home/.eclipse/RSE/USERID/, où home désigne le chemin d'accès à l'accueil défini dans le segment OMVS de l'utilisateur (ou le segment OMVS par défaut si l'utilisateur n'en possède pas) et USERID correspond à l'ID utilisateur de connexion (majuscule).
Le volume des données écrites dans ffs*.log, lock.log et rsecomm.log est contrôlé par le paramètre debug_level dans rsecomm.properties. Pour plus d'informations, voir (Facultatif) Personnalisation de rsecomm.properties, configuration de la fonction de trace RSE.
Ce fichier contient un journal du démon avant la journalisation.
Sortie de la commande fekfivpc -file (test du programme IVP associé à SCLM Developer Toolkit), où home désigne le chemin d'accès à l'accueil défini dans le segment OMVS de l'utilisateur (ou le segment OMVS par défaut si l'utilisateur n'en possède pas) et USERID correspond à l'ID utilisateur de connexion (majuscule).
Pour plus d'informations, voir Connexion du service Commandes TSO (avec SCLMDT).
Journal d'intégration de Fault Analyzer, où home désigne le chemin d'accès à l'accueil défini dans le segment OMVS de l'utilisateur (ou le segment OMVS par défaut si l'utilisateur n'en possède pas) et USERID correspond à l'ID utilisateur de connexion (majuscule).
A l'ouverture d'une connexion avec File Manager, un travail de serveur est lancé, avec l'ID utilisateur de l'utilisateur comme propriétaire. Son nom est FEKport, où port désigne le port TCP/IP utilisé.
Le SYSPRINT du travail de serveur contient le journal du serveur FMI.
Journal de communication de FMI, où home désigne le chemin d'accès à l'accueil défini dans le segment OMVS de l'utilisateur (ou le segment OMVS par défaut si l'utilisateur n'en possède pas) et USERID correspond à l'ID utilisateur de connexion (majuscule).
Le volume des données écrites dans ce fichier est contrôlé par le paramètre debug_level dans rsecomm.properties. Pour plus d'informations, voir (Facultatif) Personnalisation de rsecomm.properties, configuration de la fonction de trace RSE.
Quand vous ouvrez une connexion avec CARMA, hlq.SCRACLST(SCRASUBMT) démarre un travail de serveur (avec les ID des utilisateurs en tant que propriétaires) appelé CRAport, où port désigne le port TCP/IP utilisé.
Si l'instruction de définition de données CARMALOG est indiquée dans hlq.SCRACLST(SCRASUBMT), 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 volume de consignation du journal est commandé par le réglage Niveau de trace sur le client. Pour plus d'informations sur la configuration du paramètre Niveau de trace, voir (Facultatif) Activation d'IBM Common Access Repository Manager (CARMA).
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.
Journal de communication de CARMA, où home désigne le chemin d'accès à l'accueil défini dans le segment OMVS de l'utilisateur (ou le segment OMVS par défaut si l'utilisateur n'en possède pas) et USERID correspond à l'ID utilisateur de connexion (majuscule).
Le volume des données écrites dans ce fichier est contrôlé par le paramètre debug_level dans rsecomm.properties. Pour plus d'informations, voir (Facultatif) Personnalisation de rsecomm.properties, configuration de la fonction de trace RSE.
Quand un produit se termine par 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 beaucoup 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, les 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 inscrit dans un fichier séquentiel MVS, avec un nom par défaut au format &idutilisateur.JVM.TDUMP.&nomdetravail.D&date.H&heure, 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.
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 de vidage de 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 de vidage de 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 de vidage de z/OS UNIX.
Pour plus d'informations sur les vidages de la JVM, voir Java Diagnostics Guide (SC34-6650), et pour les informations spécifiques à LE, 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. Veuillez noter que vous devez disposer d'un espace disque suffisant pour que le fichier de vidage soit écrit correctement.
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.
Le bit de contrôle du programme est défini pendant l'installation SMP/E au besoin.
Le résultat est vérifiable à l'aide de la commande ls -lE fekf* qui donne une sortie semblable à ceci ($ est l'invite de z/OS UNIX) :
$ ls -lE /usr/lpp/wd4z/rse/lib/fekf* -rwxr-xr-x -ps- 2 user group 94208 Jun 12 16:21 /usr/lpp/wd4z/rse/lib/ fekfdir.dll -rwxr-xr-x -ps- 2 user group 143360 Jun 12 16:21 /usr/lpp/wd4z/rse/lib/fekfdivp -rwxr-xr-x --s- 2 user group 480 Jun 12 16:21 /usr/lpp/wd4z/rse/lib/fekfivpa -rwxr-xr-x --s- 2 user group 342 Jun 12 16:21 /usr/lpp/wd4z/rse/lib/fekfivpc -rwxr-xr-x --s- 2 user group 445 Jun 12 16:21 /usr/lpp/wd4z/rse/lib/fekfivpd -rwxr-xr-x --s- 2 user group 1491 Jun 12 16:21 /usr/lpp/wd4z/rse/lib/fekfivpj -rwxr-xr-x --s- 2 user group 883 Jun 12 16:21 /usr/lpp/wd4z/rse/lib/fekfivpr -rwxr-xr-x --s- 2 user group 307 Jun 12 16:21 /usr/lpp/wd4z/rse/lib/fekfivps -rwxr-xr-x -ps- 2 user group 139264 Jun 12 16:21 /usr/lpp/wd4z/rse/lib/fekflock -rwxr-xr-x -ps- 2 user group 196608 Jun 12 16:21 /usr/lpp/wd4z/rse/lib/fekfrsed -rwxr-xr-x --s- 2 user group 42443 Jun 12 16:21 /usr/lpp/wd4z/rse/lib/fekfscmd
Exécutez les commandes suivantes si le bit de contrôle du programme a besoin d'être défini manuellement, en supposant que le répertoire d'installation par défaut (/usr/lpp/wd4z/rse/lib/) est utilisé :
1. cd /usr/lpp/wd4z/rse/lib 2. extattr +p fekfdir.dll fekfivp fekflock fekfrsed
A l'aide de la commande NETSTAT (TSO ou z/OS UNIX), vous pouvez connaître les ports actuellement en service. Le résultat de cette commande ressemblera aux exemples ci-dessous. Les ports utilisés sont le dernier chiffre (derrière les deux points '..') dans la colonne/ligne "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 V1R7 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 INETD4 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 V1R7 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 INETD4 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).
Ces ports réservés sont répertoriés à l'aide de la commande NETSTAT PORTL (TSO ou z/OS UNIX), qui crée un résultat semblable à l'exemple ci-dessous :
MVS TCP/IP NETSTAT CS V1R7 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, consultez le document Communications Server IP System Administrator's Commands (SC31-8781).
Le serveur RSE, qui est un processus Java UNIX, nécessite une grande taille de région pour exécuter ses fonctions. Il est ainsi important de définir de grandes limites de mémoire pour les espaces d'adresse OMVS.
Un serveur RSE est démarré par INETD lorsqu'un client se connecte au port du démon RSE ou quand le client émet le script de démarrage avec REXEC/SSH. Ceci est exécuté avec les limites mémoire d'INETD, qui doivent donc être suffisamment grandes.
Configurez MAXASSIZE dans SYS1.PARMLIB(BPXPRMxx), qui définit la taille de région de l'espace adresse (processus) OMVS par défaut, sur 2147483647 ou plus.
Cette valeur est vérifiable et définissable de manière dynamique (avant la procédure de chargement initial suivante) au moyen des commandes de la console suivantes, décrites dans le manuel MVS System Commands (SA22-7627) :
Vérifiez ASSIZEMAX dans le segment OMVS de l'ID utilisateur, 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 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 MVS System Commands (SA22-7627) :
La procédure suivante permet de rassembler les informations nécessaires pour diagnostiquer les 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.SF1.Z682746.XML 23 //COBOL.WSEDSF2 DD DISP=MOD, // DSN=uid.ERRCOB.member.SF1.Z682747.XML
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) Définition d'une 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.
Les fiches techniques disponibles à la section Support du site Web (http://www-306.ibm.com/software/awdtools/devzseries/support/) sont répertoriées ci-dessous. Pour plus d'informations, consultez le support du site Web :
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 console SETOMVS et SET OMVS.
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 (quand 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.
La lecture et l'écriture d'un fichier MVS nécessite 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(200) TYPE(UDS)
Lors de l'utilisation de VIPA (adresses IP virtuelles) dynamiques au niveau de plusieurs piles TCPIP, une coordination au niveau de sysplex de l'affectation des port éphémères est nécessaire de façon à ce que le 4-uplet (combinaison de ports et d'adresses IP source et destination) reste unique pour chaque connexion. Cela peut être fait par l'ajout du paramètre facultatif SYSPLEXPORTS à la première instruction VIPADISTRIBUTE, voir Communications IP Configuration Guide (SC31-8775).
Lors de l'emploi de cette technique, assurez-vous que la structure de l'unité de couplage EZBEPORT (qui contient les informations d'affectation de port sysplex) a été définie. Pour plus d'informations sur le sujet, voir Communications Server SNA Network Implementation Guide (SC31-8777).
Si les incidents ne sont pas résolus après la lecture du présent manuel et la consultation du site Web de support (http://www-306.ibm.com/software/awdtools/devzseries/support/), et que vous avez besoin de l'aide du support IBM, veuillez réunir les informations suivantes et ouvrir un enregistrement d'incident auprès d'IBM :
Les informations suivantes sont utiles pour résoudre les incidents de connexion :
Si vous utilisez SCLM Developer Toolkit pour le service Commandes TSO (cas par défaut)
Si vous utilisez APPC pour le service Commandes TSO
Mettez à disposition toutes les informations qui semblent importantes pour les incidents de fonctionnement comme
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 et/ou de la modification d'une configuration existante.
Pour plus d'informations sur la configuration TCP/IP, consultez les ouvrages Communications Server: IP Configuration Guide (SC31-8775) et Communications Server IP Configuration Reference (SC31-8776).
Developer for System z requiert que le protocole TCP/IP dispose du nom d'hôte correct lors de son initialisation. 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 de la commande TSO HOMETEST. Pour plus d'informations sur la commande HOMETEST, consultez le document Communications Server IP System Administrator's Commands (SC31-8781).
Exemple de résultat de la commande HOMETEST :
Exécution du programme de test de la configuration TCP/IP IBM MVS TCP/IP CS V1R7 Le fichier de paramètre de configuration FTP utilisé est le "SYS1.TCPPARMS(FTPDATA)" Le nom d'hôte TCP est : CDFMVS08 Utilisation du serveur de noms pour une résolution CDFMVS08 Les adresses IP suivantes correspondent au nom d'hôte TCP : CDFMVS08 9.42.112.75 Les adresses IP suivantes correspondent aux adresses IP HOME définies dans PROFILE.TCPIP : 9.42.112.75 127.0.0.1 Toutes les adresses IP pour CDFMVS08 se trouvent dans la liste HOME ! Commande Hometest réussie - Tous les tests sont réussis !
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. L'ordre de recherche de l'environnement UNIX z/OS permet d'obtenir sa valeur.
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 du programme 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 UNIX sous z/OS, un processus enfant n'a pas accès au 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 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.
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 du programme 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 plus d'informations sur les instructions TCPIP.DATA, consultez l'ouvrage 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 mentionné précédemment, 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.
L'exemple ci-dessous présente certaines tâches de la configuration de TCP/IP et du programme de résolution. Il ne couvre pas l'ensemble de la configuration, 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 UNIX sous z/OS, 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 avons défini cdfmvs08 et cdfmvs08.raleigh.ibm.com comme un nom valide pour l'adresse IP de notre 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, nous vous recommandons 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
|
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 et/ou de la modification d'une configuration existante.
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 (comme écho). 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 UNIX ou MVS natif.
La syntaxe suivante s'applique à la spécification d'informations de maintenance :
Chaque entrée se compose de 4 champs à position fixe, selon le format :
service_name port_number/protocol aliases
L'ordre de recherche permettant d'accéder à ETC.SERVICES dans z/OS UNIX est le suivant. 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 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.
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 voir 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 produit 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 conseillé d'utiliser le nom de la procédure JCL qui est démarrée pour l'espace d'adresse de noyau z/OS UNIX afin de permettre à presque tout 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 une 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 d'empêcher d'avoir plus de 1 processus INETD actif.
La mise en oeuvre z/OS UNIX d'INETD est située par défaut dans /usr/sbin/inetd et prend en charge deux paramètre de démarrage facultatif et ne dépendant pas de la position :
/usr/sbin/inetd [-d] [inetd.conf]
Il est conseillé 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 de 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 autorise la définition du paramètre respawn, qui redémarre automatiquement le processus lorsqu'il se termine (un WTOR est envoyé à l'opérateur pour un second 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 travaux des utilisateurs et du programme STC. 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 de la liste de la figure 11 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, // PARM='SH ps -e | grep inetd | cut -c 1-10 | xargs -n 1 kill' //* //INETD EXEC PGM=BPXBATCH,TIME=NOLIMIT,REGION=0M, // PARM='PGM /usr/sbin/inetd &PRM' //STDERR DD PATH='/tmp/bpxbatch.start.inetd.stderr', // PATHOPTS=(OWRONLY,OCREAT,OTRUNC), // PATHMODE=SIRWXU //* STDIN, STDOUT and STDENV are defaulted to /dev/null //* INETD daemon output can be controlled by syslogd settings //*
// 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 commandes suivants peuvent être utilisés (par quelqu'un disposant des droits d'accès nécessaires) pour arrêter et démarrer INETD (# désigne l'invite z/OS UNIX) :
1. # ps -e | grep inetd 7 ? 0:00 /usr/sbin/inetd 2. # kill 7 3. # _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 comme setuid(). 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 rendre un module chargeable MVS 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.
Pour plus d'informations sur les commandes extattr et su, voir UNIX System Services Command Reference (SA22-7802). Pour plus d'informations concernant la classe UNIXPRIV et les profils BPX.* dans la classe FACILITY, voir UNIX System Services Planning (GA22-7800). Pour plus d'informations sur les définitions de segments OMVS et la classe PROGRAM, voir Security Server RACF Security Administrator's Guide (SA22-7683).
Developer for System z dépend d'INETD pour la configuration de la connexion client-hôte. Il impose des exigences supplémentaires à la configuration d'INETD décrite ci-avant.
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 RSE qui est démarré par INETD lorsqu'un client se connecte au port 4035 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 RSE (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 du protocole SSL (Secure Socket Layer), ou au cours de la vérification et/ou de la modification d'une configuration existante.
Une communication sécurisé vous assure que votre partenaire de communication est bien qui 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. Pour plus d'informations sur les certificats numériques et le protocole à clé publique utilisés par SSL, voir Security Server RACF Security Administrator's Guide (SA22-7683).
Les actions nécessaires pour la configuration des communications SSL pour Developer for System z varient largement d'un site à l'autre, selon les besoins exacts, 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 qui utilisera le protocole SSL. Les méthodes de connexion REXEC et par démon seront toutes les deux configurées pour 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. Tout cela s'effectue selon les étapes suivantes :
Une convention d'attribution de nom uniforme est utilisée dans cette annexe :
La plupart 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 pour retourner à TSO.
Dans cette étape, une nouvelle instance du serveur RSE et du démon RSE est créée pour être exécutée en parallèle avec celle(s) qui existe(nt) déjà. De cette façon, les tests du protocole SSL ne perturberont pas les opérations normales. Comme il est conseillé dans l'Enregistrement du fichier de configuration rsed.envvars dans un autre répertoire, les exemples de commandes ci-dessous supposent que les fichiers de configuration se trouvent dans /etc/wd4z/
$ cd /etc/wd4z $ mkdir ssl $ cp * ssl cp: FSUM6254 "ssl" is a directory (not copied) $ ls ssl rsecomm.properties server.zseries ssl.properties rsed.envvars setup.env.zseries $ cd ssl $ su # oedit /etc/services rsessl 4047/tcp #Developer for System z RSE using SSL
ajout d'un service rsessl, en utilisant le port 4047
# oedit /etc/inetd.conf rsessl stream tcp nowait OMVSKERN /usr/lpp/wd4z/rse/lib/fekfrsed rsed -d /etc/wd4z/ssl
ajout d'un démon rsessl, en utilisant le répertoire de configuration /etc/wd4z/ssl
# ps -e | grep inetd 7 ? 0:00 /usr/sbin/inetd # kill 7 # _BPX_JOBNAME='INETD' /usr/sbin/inetd # exit $ netstat | grep 4047 INETD4 00016619 0.0.0.0..4047 0.0.0.0..0 Listen
Les commandes indiquées ci-dessus créent un sous-répertoire appelé ssl et le remplissent avec les fichiers de configuration obligatoires. Il n'y a pas (encore) besoin de procéder à des modifications de la configuration. Il est possible de partager le répertoire d'installation et les composants MVS dans la mesure où ils ne sont pas spécifiques au protocole SSL. Toutefois, un nouveau démon (rsessl) doit être défini, qui utilise les nouveaux fichiers de configuration. Le port 4047 est affecté au nouveau démon.
Pour plus d'informations concernant les actions présentées ci-avant, voir le Activation des composants de Developer for System z z/OS UNIX.
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.
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é (RACF par exemple). Le serveur RSE (qui est démarré par le démon ou par REXEC) est une application Java SSL, qui utilise un fichier de stock de clés créé par keytool. A l'heure actuelle, RACF ne présente pas de prise en charge prête à l'emploi pour Java SSL.
Ainsi, pour procéder à une connexion par l'intermédiaire de REXEC, nous avons uniquement besoin du fichier de stock de clés :
Pour réaliser la connexion par l'intermédiaire du démon, nous avons besoin à la fois du stock de clés et du fichier de la base de données de clés :
Pour plus d'informations sur RACF et sur les certificats numériques, voir Security Server RACF Security Administrator's Guide (SA22-7683). Pour la documentation gskkyman, voir Cryptographic System SSL Programming (SC24-5901). La documentation de keytool est disponible à l'adresse suivante : http://java.sun.com/j2se/1.4.2/docs/tooldocs/solaris/keytool.html.
"keytool -genkey" génère un paire de clés (une clé publique et une clé privée associée). La clé publique est ensuite incorporée dans un certificat d'auto-signature X.509 v1, qui est stocké comme une chaîne de certificats à un seul élément. Cette chaîne de certificats ainsi que la clé privée sont stockées comme une entrée (identifiée par un alias) dans un (nouveau) fichier de stock de clés.
Toutes les informations peuvent être passées comme paramètres, mais en raison des limitations de longueur de la ligne de commande, une certaine interactivité est nécessaire.
$ keytool -genkey -alias wd4zrse -validity 3650 -keystore wd4zssl.jks -storepass rsessl -keypass rsessl What is your first and last name? [Unknown]: wd4z rse ssl What is the name of your organizational unit? [Unknown]: wd4z 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=wd4z rse ssl, OU=wd4z, O=IBM, L=Raleigh, ST=NC, C=US correct? (type "yes" or "no") [no]: yes $ ls rsecomm.properties server.zseries ssl.properties rsed.envvars setup.env.zseries wd4zssl.jks
Le certificat d'auto-signature créé ci-avant est valide pendant environs 10 ans (sans compter les jours intercalaires des années bissextiles). Il est stocké dans /etc/wd4z/ssl/wd4zssl.jks avec l'alias wd4zrse. Son mot de passe (rsessl) est identique au mot de passe du stock 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 wd4zrse -keystore wd4zssl.jks -storepass rsessl -v Alias name: wd4zrse Creation date: May 24, 2007 Entry type: keyEntry Certificate chain length: 1 Certificate 1¨: Owner: CN=wd4z rse ssl, OU=wd4z, O=IBM, L=Raleigh, ST=NC, C=US Issuer: CN=wd4z rse ssl, OU=wd4z, 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
Comme il a été mentionné plus tôt, le démon est une application du système SSL, qui utilise un fichier de base de données de clés. Il peut s'agir soit d'un fichier physique créé par gskkyman soit d'un jeu de clés RACF. Les jeux de clés RACF sont la méthode favorite de gestion des clés privées et des certificats pour le système SSL.
Ne suivez pas cette étape si vous utilisez gskkyman pour le système SSL.
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 jeux de clés.
Pour plus de détails concernant la commande RACDCERT, voir 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(omvskern) PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ACCESS(READ) ID(omvskern) SETROPTS RACLIST(FACILITY) REFRESH RACDCERT ID(omvskern) GENCERT SUBJECTSDN(CN('wd4z rse ssl') + OU('wd4z') O('IBM') L('Raleigh') SP('NC') C('US')) + NOTAFTER(DATE(2017-05-21)) WITHLABEL('wd4zrse') KEYUSAGE(HANDSHAKE) RACDCERT ID(omvskern) ADDRING(wd4zssl.racf) RACDCERT ID(omvskern) CONNECT(LABEL('wd4zrse') RING(wd4zssl.racf) + DEFAULT USAGE(PERSONAL))
L'exemple ci-avant commence par la création des profils nécessaires et par l'autorisation d'accès de l'ID utilisateur OMVSKERN aux jeux de clés. L'ID utilisateur utilisé doit correspondre à celui codé dans /etc/inetd.conf pour le démon RSE du protocole SSL. L'étape suivante est la création d'un nouveau certificat auto-signé avec l'intitulé wd4zrse. Aucun mot de passe n'est nécessaire. Ce certificat est alors ajouté au jeu de clés nouvellement créé (wd4zssl.racf). Exactement comme avec le certificat, aucun mot de passe n'est nécessaire pour le jeu de clés. La durée de vie du certificat correspond à celle créé avec keytool.
Le résultat peut être vérifié par l'intermédiaire de l'option list :
RACDCERT ID(omvskern) LIST Digital certificate information for user OMVSKERN: Label: wd4zrse 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=wd4z rse ssl.OU=wd4z.O=IBM.L=Raleigh.SP=NC.C=US< Subject's Name: >CN=wd4z rse ssl.OU=wd4z.O=IBM.L=Raleigh.SP=NC.C=US< Private Key Type: Non-ICSF Private Key Size: 1024 Ring Associations: Ring Owner: OMVSKERN Ring: >wd4zssl.racf<
Ne suivez pas cette étape si vous utilisez RACF pour le système SSL.
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 certiticats 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
$ gskkyman Database Menu 1 - Create new database 2 - Open database 3 - Change database password 4 - Change database record length 5 - Delete database 6 - Create key parameter file 0 - Exit program Enter option number: 1 Enter key database name (press ENTER to return to menu): wd4zssl.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/wd4z/ssl/wd4zssl.kdb created. Press ENTER to continue. Key Management Menu Database: /etc/wd4z/ssl/wd4zssl.kdb 1 - Manage keys and certificates 2 - Manage certificates 3 - Manage certificate requests 4 - Create new certificate request 5 - Receive requested certificate or a renewal certificate 6 - Create a self-signed certificate 7 - Import a certificate 8 - Import a certificate and a private key 9 - Show the default key 10 - Store database password 11 - Show database record length 0 - Exit program Enter option number (press ENTER to return to previous menu): 6 Certificate Type 1 - CA certificate with 1024-bit RSA key 2 - CA certificate with 2048-bit RSA key 3 - CA certificate with 4096-bit RSA key 4 - CA certificate with 1024-bit DSA key 5 - User or server certificate with 1024-bit RSA key 6 - User or server certificate with 2048-bit RSA key 7 - User or server certificate with 4096-bit RSA key 8 - User or server certificate with 1024-bit DSA key Select certificate type (press ENTER to return to menu): 5 Enter label (press ENTER to return to menu): wd4zrse Enter subject name for certificate Common name (required): wd4z rse ssl Organizational unit (optional): wd4z 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 Database: /etc/wd4z/ssl/wd4zssl.kdb 1 - Manage keys and certificates 2 - Manage certificates 3 - Manage certificate requests 4 - Create new certificate request 5 - Receive requested certificate or a renewal certificate 6 - Create a self-signed certificate 7 - Import a certificate 8 - Import a certificate and a private key 9 - Show the default key 10 - Store database password 11 - Show database record length 0 - Exit program Enter option number (press ENTER to return to previous menu): 0 $ ls -l total 152 -rwxr-xr-x 1 IBMUSER SYS1 333 May 24 13:52 rsecomm.properties -rwxr-xr-x 1 IBMUSER SYS1 6067 May 24 13:52 rsed.envvars -rwxr-xr-x 1 IBMUSER SYS1 332 May 24 13:52 server.zseries -rwxr-xr-x 1 IBMUSER SYS1 645 May 24 13:52 setup.env.zseries -rwxr-xr-x 1 IBMUSER SYS1 638 May 24 13:52 ssl.properties -rw-r--r-- 1 IBMUSER SYS1 1224 May 24 14:17 wd4zssl.jks -rw------- 1 IBMUSER SYS1 35080 May 24 14:24 wd4zssl.kdb -rw------- 1 IBMUSER SYS1 80 May 24 14:24 wd4zssl.rdb $ chmod 644 wd4zssl.kdb $ chmod 644 wd4zssl.rdb $ ls -l total 152 -rwxr-xr-x 1 IBMUSER SYS1 333 May 24 13:52 rsecomm.properties -rwxr-xr-x 1 IBMUSER SYS1 6067 May 24 13:52 rsed.envvars -rwxr-xr-x 1 IBMUSER SYS1 332 May 24 13:52 server.zseries -rwxr-xr-x 1 IBMUSER SYS1 645 May 24 13:52 setup.env.zseries -rwxr-xr-x 1 IBMUSER SYS1 638 May 24 13:52 ssl.properties -rw-r--r-- 1 IBMUSER SYS1 1224 May 24 14:17 wd4zssl.jks -rw-r--r-- 1 IBMUSER SYS1 35080 May 24 14:24 wd4zssl.kdb -rw-r--r-- 1 IBMUSER SYS1 80 May 24 14:24 wd4zssl.rdb
L'exemple ci-avant commence par la création d'une base de données de clés appelée wd4zssl.kdb avec le mot de passe rsessl. Une fois que la base de données existe, elle est remplie par la création d'un nouveau certificat, auto-signé, stocké sous le l'intitulé wd4zrse et avec le même 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 contrôle des données de droits (très sûr) de 600 (seul le propriétaire a accès) à 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 droits doivent être définis d'une manière moins restrictive. Les masques 640 (le propriétaire a des droits d'accès en lecture/écriture, le groupe du propriétaire a des droits d'accès en lecture) ou 644 (le propriétaire a des droits d'accès en lecture/écriture, tout le monde a des droits d'accès en lecture) sont utilisables 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 1 - Create new database 2 - Open database 3 - Change database password 4 - Change database record length 5 - Delete database 6 - Create key parameter file 0 - Exit program Enter option number: 2 Enter key database name (press ENTER to return to menu): wd4zssl.kdb Enter database password (press ENTER to return to menu): rsessl Key Management Menu Database: /etc/wd4z/ssl/wd4zssl.kdb 1 - Manage keys and certificates 2 - Manage certificates 3 - Manage certificate requests 4 - Create new certificate request 5 - Receive requested certificate or a renewal certificate 6 - Create a self-signed certificate 7 - Import a certificate 8 - Import a certificate and a private key 9 - Show the default key 10 - Store database password 11 - Show database record length 0 - Exit program Enter option number (press ENTER to return to previous menu): 1 Key and Certificate List Database: /etc/wd4z/ssl/wd4zssl.kdb 1 - wd4zrse 0 - Return to selection menu Enter label number (ENTER to return to selection menu, p for previous list): 1 Key and Certificate Menu Label: wd4zrse 1 - Show certificate information 2 - Show key information 3 - Set key as default 4 - Set certificate trust status 5 - Copy certificate and key to another database 6 - Export certificate to a file 7 - Export certificate and key to a file 8 - Delete certificate and key 9 - Change label 10 - Create a signed certificate and key 11 - Create a certificate renewal request 0 - Exit program Enter option number (press ENTER to return to previous menu): 1 Certificate Information Label: wd4zrse Record ID: 14 Issuer Record ID: 14 Trusted: Yes Version: 3 Serial number: 45356379000ac997 Issuer name: wd4z rse ssl wd4z IBM Raleigh NC US Subject name: wd4z rse ssl wd4z 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 Label: wd4zrse 1 - Show certificate information 2 - Show key information 3 - Set key as default 4 - Set certificate trust status 5 - Copy certificate and key to another database 6 - Export certificate to a file 7 - Export certificate and key to a file 8 - Delete certificate and key 9 - Change label 10 - Create a signed certificate and key 11 - Create a certificate renewal request 0 - Exit program Enter option number (press ENTER to return to previous menu): 0
Maintenant que les certificats sont en place, RSE peut commencer à utiliser le protocole SSL. En fonction des définitions choisies lors des étapes précédentes, différentes valeurs doivent être fournies dans ssl.properties.
$ oedit ssl.properties
La configuration de l'hôte SSL est maintenant terminée, et peut être testée par la connexion au client Developer for System z. Dans la mesure où nous avons créé une nouvelle configuration pour l'utilisation avec SSL (par clonage d'une configuration existante), une nouvelle connexion doit être définie, à l'aide des caractéristiques suivantes :
STEPLIB=SYS1.SIEALNKE
STEPLIB=$STEPLIB:SYS1.SIEALNKE
A la connexion, l'hôte et le client démarrent avec un protocole d'établissement de liaison afin de 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, il demande à l'utilisateur si le 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, ce dialogue n'est plus affiché. 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. Plus d'informations sont disponibles dans les différents fichiers journaux (home/.eclipse/RSE/USERID/* et /tmp/rsedaemon.log), comme il est indiqué dans Journalisation du serveur RSE.
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 et/ou de la modification d'une configuration existante.
Pour plus d'informations sur la gestion des APPC et sur les membres parmlib étudiés ci-dessous, consultez les ouvrages MVS Planning APPC/MVS Management (SA22-7599) et MVS Initialization and Tuning Reference (SA22-7592).
Veuillez noter 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 des membres SYS1.PARMLIB 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.
L'exemple de travail présenté dans la figure 14 est une concaténation des exemples de membres 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 <job parameters> //* //* 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 gamme de composants SNA physiques et logiques, comme l'unité logique (LU). 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 à 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
Pour plus d'informations concernant la configuration de VTAM, voir Communications Server bookshelf (F1A1BK61 for z/OS 1.7).
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.
La figure 16 est un exemple du 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 de 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 Personnalisation de rsed.envvars, le fichier de configuration de l'Explorateur de systèmes éloignés 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 aux sections OPTIONS et TPDEFAULT.
La figure 17 est un exemple du 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 ci-avant 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 console D APPC et D ASCH peuvent être employées pour vérifier la configuration d'APPC. Pour plus d'informations sur les commandes mentionnées, voir MVS System Commands (SA22-7627).
Une fois qu'APPC/MVS est actif, le service Commandes TSO de Developer for System z peut être défini, voir (Facultatif) Définition d'une transaction APPC pour le service Commandes TSO.
La façon de définir la transaction APPC décrite est par personnalisation et soumission de hlq.SFEKSAMP(FEKAPPCC), où hlq est identique au qualificatif de haut niveau utilisé lors de l'installation de Developer for System z (la valeur par défaut est FEK).
La transaction APPC peut également être définie en mode interactif par l'intermédiaire de l'interface ISPF APPC, qui est décrit dans le livre blanc. Ce livre blanc décrit également comment configurer la transaction APPC afin de collecter des informations statistiques spécifiques des utilisateurs.
Le livre blanc APPC and WebSphere Developer for System z (SC23-5885) est disponible auprès de la bibliothèque internet de Developer for System z, http://www-306.ibm.com/software/awdtools/devzseries/library/
// PARM='ISPSTART CMD(%FEKFRSRV TIMEOUT=60) NEWAPPL(ISR) NESTMACS'
La présente documentation a été rédigée pour des produits et services proposés aux Etats-Unis.
IBM peut ne pas offrir les produits, services, ou fonctions traités dans ce document dans d'autres pays. Pour plus de détails, référez-vous aux documents d'annonce disponibles dans votre pays, ou adressez-vous à votre partenaire commercial IBM. Toute référence à un produit, logiciel ou service IBM n'implique pas que seul ce produit, logiciel ou service IBM puisse être utilisé. Tout autre élément fonctionnellement équivalent peut être utilisé, s'il n'enfreint aucun droit d'IBM. Toutefois, il appartient à l'utilisateur d'évaluer et de vérifier le fonctionnement de produits, logiciels ou services non expressément référencés par IBM.
IBM peut détenir des brevets ou des demandes de brevet couvrant les produits mentionnés dans la présente documentation. La remise de ce document ne vous donne aucun droit de licence sur ces brevets ou demandes de brevet. Si vous désirez recevoir des informations concernant l'acquisition de licences, veuillez en faire la demande par écrit à l'adresse suivante :
IBM Director of Licensing IBM Corporation North Castle Drive Armonk, NY 10504-1785 U.S.A.
Les informations sur les licences concernant les produits utilisant un jeu de caractères double octet peuvent être obtenues 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 CONTREFACON AINSI QU'EN CAS DE DEFAUT D'APTITUDE A L'EXECUTION D'UN TRAVAIL DONNE. Certaines juridictions n'autorisent pas l'exclusion des garanties implicites, auquel cas l'exclusion ci-dessus ne vous sera pas applicable.
Le présent document peut contenir des inexactitudes ou des coquilles. 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 parIBM 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 n'accepte 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.
LICENCE DE COPYRIGHT :
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 interface 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. 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 IBM.
Toute copie totale ou partielle de ces programmes exemples et des oeuvres qui en sont dérivées doit comprendre une notice de copyright libellée comme suit :
(C) (nom de votre société) (année). Les segments de code sont dérivés des Programmes exemples d'IBM Corp. (C) Copyright IBM Corp. _Saisissez l'année ou les années_. All rights reserved.
Les termes qui suivent sont des marques d'International Business Machines Corporation aux Etats-Unis et/ou dans certains autres pays :
Java ainsi que toutes les marques et logos incluant Java sont des marques de Sun Microsystems, Inc. aux Etats-Unis et/ou dans certains autres pays.
Microsoft, Windows, Windows NT, et le logo Windows sont des marques de Microsoft 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.
Les autres noms de sociétés, de produits et de services peuvent appartenir à des tiers.