Avant d'utiliser cette documentation, reportez-vous aux informations générales sous Remarques sur la documentation pour IBM Rational Developer for System z.
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
© Copyright IBM France 2009. Tous droits réservés.
Le présent document aborde la configuration d'IBM® Software Configuration and Library Manager (SCLM) requise pour la fonction SCLM Developer Toolkit d'IBM Rational Developer for System z.
A partir de maintenant, les noms suivants sont utilisés dans le présent ouvrage :
Le présent document contient des informations destinées à l'administrateur de projets SCLM qui seront utilisées avec SCLM Developer Toolkit. Cela comprend les projets qui utilisent les langages des composants Java™ et z/OS UNIX® System Services, ainsi que les projets SCLM traditionnels.
Ces administrateurs doivent connaître z/OS UNIX System Services, le script REXX, le compilateur Java et les définitions de langage et de projet SCLM.
Le présent document ne couvre pas l'implémentation et le chargement du produit SCLM, qui est livré avec le système d'exploitation z/OS. Il n'aborde pas non plus l'installation et la configuration de SCLM Developer Toolkit, qui est une fonction de Rational Developer for System z.
Pour plus d'informations sur ces tâches, voir ISPF Software Configuration and Library Manager Project Manager's and Developer's Guide (SC34-4817) et Rational Developer for System z - Guide de configuration de l'hôte (SC11-6285).
Pour effectuer les tâches de personnalisation et de définition de projet, l'administrateur SCLM doit connaître un certain nombre de valeurs Developer for System z personnalisables, comme indiqué dans le tableau 1. Pour plus d'informations, adressez-vous au programmeur système z/OS chargé d'installer et de personnaliser Developer for System z.
Description | Valeur par défaut | Emplacement de la réponse | Valeur |
---|---|---|---|
Exemple de bibliothèque Developer for System z | FEK.SFEKSAMP | Installation SMP/E | |
Exemple de répertoire Developer for System z | /usr/lpp/rdz/samples | Installation SMP/E | |
Répertoire bin Java | /usr/lpp/java/J5.0/bin | rsed.envvars - $JAVA_HOME/bin | |
Répertoire bin Ant | /usr/lpp/Ant/apache-ant-1.7.1/bin | rsed.envvars - $ANT_HOME/bin | |
Répertoire de base WORKAREA | /var/rdz | rsed.envvars - $_CMDSERV_CONF_HOME | |
Répertoire de base de la configuration des projets SCLMDT | /etc/rdz/sclmdt | rsed.envvars | |
VSAM de traduction des noms longs/abrégés | FEK.#CUST.LSTRANS.FILE | rsed.envvars - $_SCLMDT_TRANTABLE |
Ce chapitre explique comment l'administrateur SCLM peut personnaliser SCLM pour une utilisation par SCLM Developer Toolkit.
Voici un résumé de la procédure effectuée pour les générations Java et J2EE à l'aide des traducteurs fournis.
L'ARCHDEF contient les membres qui constituent le projet JAVA/J2EE et qui correspondent à une représentation abrégée de la manière dont le projet existe dans un espace de travail Eclipse.
L'ARCHDEF elle-même est générée, ce qui appelle un traducteur de langage de vérification de pré-génération (J2EEANT). Le traducteur lit le script de génération J2EE, qui est représenté dans l'ARCHDEF par le mot clé SINC et remplace les propriétés spécifiées dans le squelette XML Ant référencé par les propriétés XML SCLM-ANTXML (A). Le script de génération, lorsqu'il est généré par SCLM Developer Toolkit, est stocké dans SCLM avec le langage J2EEANT (1).
Une ARCHDEF génère les classes Java de la source Java identifiée avec le mot clé INCLD dans l'ARCHDEF (2) et chaque ARCHDEF peut également générer un fichier d'archive J2EE, tel qu'un fichier JAR, WAR ou EAR. L'objet J2EE créé dépend du script de génération correspondant référencé et de l'utilisation du mot clé d'ARCHDEF OUT1 (3), (B).
Lorsque l'ARCHDEF est générée, le traducteur de langage de vérification de pré-génération associé au script de génération (dans le type SCLM J2EEBLD) s'exécute. Il détermine quels composants de l'ARCHDEF doivent être à nouveau générés (y compris les ARCHDEF imbriquées (4) identifiées via l'utilisation du mot clé INCL dans l'ARCHDEF). Ces composants sont ensuite copiés dans le répertoire du système de fichiers z/OS UNIX System Services et le script Ant compile, puis génère les objets JAVA/J2EE indiqués par le script de génération et l'ARCHDEF. Les références à des fichiers jar ou des classes externes que votre projet IDE doit résoudre sont résolus à partir du chemin d'accès défini dans la propriété CLASSPATH_JARS (C).
SCLM traite ensuite chaque composant ARCHDEF en exécutant chaque traducteur de langage associé au composant. Le traducteur de langage Java, associé au code source Java, copie les fichiers de classe créés dans SCLM.
Enfin, le traducteur d'ARCHDEF détermine quels objets J2EE ont été générés (JAR, WAR, EAR) et les recopie dans SCLM.
Il est essentiel de créer une ARCHDEF séparée pour chaque composant d'application qui peut constituer une application d'entreprise (EAR). En d'autres termes, un fichier EAR contenant un fichier WAR, qui contient à son tour un EJB JAR, doit disposer d'une ARCHDEF JAR, d'une archdef WAR avec une inclusion de l'ARCHDEF EJB JAR. L'ARCHDEF EAR doit ensuite inclure une instruction INCL de l'ARCHDEF WAR.
L'exemple suivant montre le code JAR :
* * Initially generated on 10/05/2006 by SCLM DT V2 * LKED J2EEOBJ * J2EE Build translator * * Source to include in build * INCLD AN000002 V2TEST * com/Angelina.java * INCLD V2000002 V2TEST * com/V2Java1.java (2) * INCLD V2000003 V2TEST * V2InnerClass.java * * * Nested SCLM controlled jars to include * * INCL V2JART1 ARCHDEF * DateService.jar (4) * * * Build script and generated outputs * SINC V2JARB1(1) J2EEBLD * J2EE JAR Build script * OUT1 * J2EEJAR * V2TEST.jar (3) * LIST * J2EELIST
L'exemple suivant montre le script JAR correspondant.
<ANTXML> <project name="JAVA Project" default="jar" basedir="."> <property name="env" environment="env" value="env"/> <property name="SCLM_ARCHDEF" value="V2JAR1"/> <property name="SCLM_ANTXML" value="BWBJAVAA"/> (A) <property name="SCLM_BLDMAP" value="YES"/> <property name="JAR_FILE_NAME" value="V2TEST.jar"/> (B) <property name="CLASSPATH_JARS" value="/var/SCLMDT/CLASSPATH"/> (C) <property name="ENCODING" value="IBM-1047"/> </ANTXML>
Les objets suivants sont générés :
SCLM Developer Toolkit requiert de nouveaux traducteurs de langage définis dans SCLM pour le support JAVA/J2EE. Ces traducteurs de langage sont fournis dans les membres FEK.SFEKSAMV, comme indiqué ci-dessous :
Traducteur | Description |
---|---|
BWBTRANJ | Exemple de traducteur de membre par défaut. Pas d'analyse syntaxique. Similaire à SCLM FLM@TEXT. Ce traducteur peut être personnalisé pour créer les définitions de langage J2EEPART, J2EEBIN, BINARY et TEXT. |
BWBTRANS | Exemple de traducteur de langage SQLJ. LANG=SQLJ |
BWBTRAN1 | Exemple de traducteur de langage Java. LANG=JAVA |
BWBTRAN2 | Exemples de traducteur de langage JAVA/J2EE incorporant Ant (pour plusieurs compilations Java et générations JAR, WAR et EAR) |
BWBTRAN3 | Exemple de traducteur de langage J2EE pour le support SCLM ARCHDEF J2EE. LANG=J2EEOBJ |
L'administrateur SCLM doit copier ces exemples, les renommer si nécessaire, puis les générer dans la bibliothèque PROJDEFS.LOAD de chaque projet SCLM nécessitant le support Java. Ces traducteurs doivent être ajoutés ou compilés dans la définition de projet.
Un exemple de définition de projet pour les projets JAVA/J2EE et les composants hôte est fourni dans l'exemple BWBSCLM.
Les exemples de traducteur définissent les langages suivants :
Ce traducteur de vérification détermine quels composants doivent être générés (y compris les ARCHDEF imbriquées) et, suivant les modes de génération, copie ces composants dans le répertoire WORKAREA du système de fichiers z/OS UNIX System Services. Un squelette XML Ant est personnalisé de manière dynamique en fonction du script de génération et les composants générés dans la zone de travail à l'aide de l'utilitaire Ant. Les fichiers classe sont transmis aux traducteurs de langage JAVA/JAVABIN pour enregistrer à nouveau les fichiers dans SCLM. Les objets J2EE générés, tels que JAR, WAR ou EAR, sont transmis au traducteur de langage ARCHDEF (J2EEOBJ) pour être à nouveau enregistrés dans SCLM.
Le traducteur Java compile la source en classes de sortie. La classe est stockée dans SCLM sous le type JAVACLAS. La sortie de compilation Java est stockée dans le type JAVALIST.
Les dépendances des chemins d'accès aux classes peuvent être satisfaites en stockant des fichiers JAR dépendants dans le répertoire des chemins d'accès aux classes spécifié dans le paramètre CLASSPATH_JARS du membre $GLOBAL . Pour plus d'informations, voir $GLOBAL.
Il est recommandé de créer des fichiers source SCLM cible de RECFM=VB, LRECL=1024 pour toute source JAVA/J2EE à stocker dans SCLM à partir du client Toolkit afin d'autoriser les enregistrements de type long.
Les éditeurs du client Eclipse créent des fichiers de longueur d'enregistrement variable et, pour conserver l'intégrité, les fichiers cible de l'hôte dans SCLM doivent également être au format RECFM=VB. Avec l'utilisation de fichiers de longueur d'enregistrement fixe (RECFM=FB), les membres importés contiennent des espaces à la fin de l'enregistrement.
Un certain nombres de types SCLM doivent être créés pour le support JAVA/J2EE. Certains de ces types sont obligatoires et doivent être créés pour que le support JAVA/J2EE fonctionne.
Les attributs de fichier par défaut DSORG=PO TRACKS(1,5) DIR=50 BLKSIZE=0 (déterminés par le système) sont recommandés pour les TYPES SCLM ci-après.
En outre, le format d'enregistrement et les attributs de longueur d'enregistrement suivants sont recommandés :
Type SCLM | RECFM | LRECL |
---|---|---|
ARCHDEF | FB | 80 |
J2EEBLD | FB | 256 |
JAVALIST | VB | 255 |
J2EELIST | VB | 255 |
DBRMLIB | VB | 256 |
JAVACLAS | VB | 256 |
J2EEEAR | VB | 256 |
J2EEJAR | VB | 256 |
J2EEWAR | VB | 256 |
SQLJSER | VB | 256 |
Autres types de fichier source pour Java/J2EE | VB | 1024 |
Les parties correspondant au nom long de chaque membre ARCHDEF définissent la structure des projets JAVA/J2EE. L'ARCHDEF d'un projet donné peut être créé de manière dynamique à partir du client lors de la migration vers de nouveaux projets ou mis à jour lors de l'ajout de nouveaux composants à un projet existant.
L'ARCHDEF SCLM est le fichier SCLM principal pour la définition des éléments d'un projet JAVA/J2EE. Dans le cas des applications JAVA/J2EE, l'ARCHDEF représente la manière dont l'application J2EE est structurée dans l'espace de travail du projet IDE client.
La structure des fichiers de projet de l'application est répliquée dans l'ARCHDEF (à l'aide du nom abrégé de l'hôte SCLM pour mapper la structure du nom long). D'autres mots clés dans l'ARCHDEF, tels que LINK, SINC et OUT1 indiquent à SCLM la nature J2EE de ce projet et le code source inclut un script de génération JAVA/J2EE pour simplifier le traitement de la génération de ce projet.
DBRMLIB est requis pour le support SQLJ et stocke les modules d'interrogation de base de données.
Un type SCLM différent est requis pour chaque projet JAVA/J2EE à enregistrer dans SCLM. Ceci permet d'éviter que des conflits de fichiers portant le même nom se produisent avec les projets JAVA/J2EE. Pour plus d'informations, voir Mappage de projets J2EE à SCLM.
Cette section décrit les formats des membres SCLM.
Le format $GLOBAL est de type J2EEBLD et possède le langage J2EEPART. Il doit utiliser le nom $GLOBAL et les variables sont définies dans un format de langage balisé.
$GLOBAL spécifie les propriétés par défaut du projet SCLM pour le processus de génération JAVA/J2EE. Il doit être stocké dans le type SCLM J2EEBLD.
Pour une description détaillée des paramètres des membres $GLOBAL, voir $GLOBAL.
Reportez-vous à l'exemple de code suivant :
<property name="ANT_BIN" value="/usr/lpp/Ant/apache-Ant-1.6.0/bin/Ant"/> <property name="JAVA_BIN" value="/usr/lpp/java/IBM/J1.4/bin"/> <property name="_SCLMDT_CONF_HOME" value="/etc/rdz/sclmdt/CONFIG"/> <property name="_SCLMDT_WORK_HOME" value="/var/rdz/WORKAREA"/> <property name="CLASSPATH_JARS" value="/var/rdz/CLASSPATH"/>
Le format d'ARCHDEF J2EE a le type ARCHDEF et le langage ARCHDEF.
L'ARCHDEF utilise les mots clés d'architecture SCLM standard pour indiquer à SCLM comment traiter la génération de l'ARCHDEF.
L'exemple suivant montre le code JAR :
* * Initially generated on 10/05/2006 by SCLM DT V2 * LKED J2EEOBJ * J2EE Build translator * * Source to include in build * INCLD AN000002 V2TEST * com/Angelina.java * INCLD V2000002 V2TEST * com/V2Java1.java * INCLD V2000003 V2TEST * V2InnerClass.java * * * Build script and generated outputs * SINC V2JARB1 J2EEBLD * J2EE JAR Build script * OUT1 * J2EEJAR * V2TEST.jar * LIST * J2EELIST
L'exemple suivant montre le code WAR :
* * Initially generated on 5 Sep 2006 by SCLM DT V2 * LKED J2EEOBJ * J2EE Build translator * * Source to include in build * INCLD DA000026 SAMPLE5 * JavaSource/service/dateController.java * INCLD XX000001 SAMPLE5 * .classpath * INCLD XX000002 SAMPLE5 * .project * INCLD XX000003 SAMPLE5 * .websettings * INCLD XX000004 SAMPLE5 * .website-config * INCLD OP000002 SAMPLE5 * WebContent/operations.html * INCLD MA000001 SAMPLE5 * WebContent/META-INF/MANIFEST.MF * INCLD IB000001 SAMPLE5 * WebContent/WEB-INF/ibm-web-bnd.xmi * INCLD IB000002 SAMPLE5 * WebContent/WEB-INF/ibm-web-ext.xmi * INCLD WE000001 SAMPLE5 * WebContent/WEB-INF/web.xml * INCLD MA000002 SAMPLE5 * WebContent/theme/Master.css * INCLD BL000001 SAMPLE5 * WebContent/theme/blue.css * INCLD BL000002 SAMPLE5 * WebContent/theme/blue.htpl * INCLD LO000013 SAMPLE5 * WebContent/theme/logo_blue.gif * * * Build script and generated outputs * SINC SAMPLE5 J2EEBLD * J2EE WAR Build script * OUT1 * J2EEWAR * Sample5.war * LIST * J2EELIST
L'exemple suivant montre le code EJB :
LKED J2EEOBJ * INCLD XX000001 SAMPLE3 * .classpath * INCLD XX000002 SAMPLE3 * .project * INCLD MA000004 SAMPLE3 * ejbModule/META-INF/MANIFEST.MF * INCLD EJ000004 SAMPLE3 * ejbModule/META-INF/ejb-jar.xml * INCLD IB000003 SAMPLE3 * ejbModule/META-INF/ibm-ejb-jar-bnd.xmi * INCLD XX000008 SAMPLE3 * ejbModule/com/ibm/ejs/container/_EJSWrapper * * _Stub.java * INCLD XX000009 SAMPLE3 * ejbModule/com/ibm/ejs/container/_EJSWrapper * * _Tie.java * INCLD XX000010 SAMPLE3 * ejbModule/com/ibm/websphere/csi/_CSIServant * * _Stub.java * INCLD XX000011 SAMPLE3 * ejbModule/com/ibm/websphere/csi/_Transactio * * nalObject_Stub.java * INCLD DA000005 SAMPLE3 * ejbModule/myEJB/DateBean.java * INCLD DA000006 SAMPLE3 * ejbModule/myEJB/DateBeanBean.java * INCLD DA000007 SAMPLE3 * ejbModule/myEJB/DateBeanHome.java * INCLD EJ000001 SAMPLE3 * ejbModule/myEJB/EJSRemoteStatelessDateBeanH * * ome_1a4c4c85.java * INCLD EJ000002 SAMPLE3 * ejbModule/myEJB/EJSRemoteStatelessDateBean_ * * _1a4c4c85.java * INCLD EJ000003 SAMPLE3 * ejbModule/myEJB/EJSStatelessDateBeanHomeBea * * nHomeBean_1a4c4c85.java * INCLD XX000012 SAMPLE3 * ejbModule/myEJB/_DateBeanHome_Stub.java * INCLD XX000013 SAMPLE3 * ejbModule/myEJB/_DateBean_Stub.java * INCLD XX000014 SAMPLE3 * ejbModule/myEJB/_EJSRemoteStatelessDateBean * * Home_1a4c4c85_Tie.java * INCLD XX000015 SAMPLE3 * ejbModule/myEJB/_EJSRemoteStatelessDateBean * * _1a4c4c85_Tie.java * INCLD XX000016 SAMPLE3 * ejbModule/org/omg/stub/javax/ejb/_EJBHome_S * * ub.java * INCLD XX000017 SAMPLE3 * ejbModule/org/omg/stub/javax/ejb/_EJBObject * * _Stub.java * INCLD XX000018 SAMPLE3 * ejbModule/org/omg/stub/javax/ejb/_Handle_St * * ub.java * INCLD XX000019 SAMPLE3 * ejbModule/org/omg/stub/javax/ejb/_HomeHandl * * e_Stub.java * INCLD DA000008 SAMPLE3 * ejbModule/services/DateBeanServices.java * INCLD XX000020 SAMPLE3 * ejbModule/services/_DateBeanServices_Stub.j * * ava * * SINC SAMPLE3 J2EEBLD * J2EE EJB JAR Build script * OUT1 * J2EEJAR * DateService.jar * LIST * J2EELIST
L'exemple suivant montre le code EAR :
LKED J2EEOBJ * INCLD XX000001 SAMPLE6 * .classpath * INCLD XX000002 SAMPLE6 * .project * INCLD AP000001 SAMPLE6 * META-INF/application.xml * INCL SAMPLE3 ARCHDEF * DateService.jar * INCL SAMPLE5 ARCHDEF * Sample5.war * * SINC SAMPLE6 J2EEBLD * J2EE EAR Build script * OUT1 * J2EEEAR * Sample6.ear * LIST * J2EELIST
Le format du script de génération Ant J2EE a le type J2EEBLD et le langage J2EEANT. Il peut s'agir d'un nom comportant jusqu'à huit caractères dont les variables sont définies dans un format de langage balisé. Les scripts de génération des fichiers JAR, WAR et EAR sont très similaires. Un exemple de syntaxe de script de génération WAR est indiqué ci-dessous. Pour les fichiers JAR et EAR, les scripts de génération, les variables sont identiques, à l'exception de WAR_NAME que vous devez remplacer par JAR_NAME et WAR_NAME.
Reportez-vous à l'exemple de script de génération suivant :
<ANTXML> <project name="J2EE Project type" default="web-war" basedir="."> <property name="env" environment="env" value="env"/> <property name="SCLM_ARCHDEF" value="ARCHDEF name"/> <property name="SCLM_ANTXML" value="ANTXML name"/> <property name="SCLM_BLDMAP" value="Include Buildmap"/> <property name="JAVA_SOURCE" value="Include Java Source"/> <property name="J2EE_HOME" value="${env.J2EE_HOME}"/> <property name="JAVA_HOME" value="${env.JAVA_HOME}"/> <property name="CLASSPATH_JARS" value="Classpath Directory location"/> <property name="CLASSPATH_JARS_FILES" value="Jar/class filenames"/> <property name="ENCODING" value="Codepage"/> <property name="DEBUG_MODE" value="debug_mode"/> <!-- WAR file name to be created by this build process --> <!-- include suffix of .war --> <property name="WAR_NAME" value="War name" /> <path id="build.class.path"> <pathelement location="."/> <pathelement location="${J2EE_HOME}/lib/j2ee.jar"/> <pathelement location="${CLASSPATH_JARS}/jdom.jar"/> <fileset dir="." includes="**/*.jar"/> <fileset dir="${CLASSPATH_JARS}" includes="**/*.jar, **/*.zip"/> </path> </ANTXML>
Les scripts de génération SCLM remplacent les variables définies par le client de manière dynamique lors de l'exécution du script de génération Ant. Ces variables possèdent les valeurs indiquées dans le tableau 3.
Variable | Description |
---|---|
Nom du projet J2EE | Type de projet Java/J2EE généré. Ce nom de projet temporaire est
défini dans le script de génération pour que l'utilitaire Ant puisse l'utiliser pendant
la génération. Les valeurs suivantes seront définies :
|
SCLM_ARCHDEF | Nom de l'ARCHDEF ou de l'ARCHDEF générée |
SCLM_ANTXML | Nom du squelette XML Ant à utiliser pour la génération |
SCLM_BLDMAP | Valeur Oui ou Non. Si Oui, inclure la mappe de génération SCLM dans le répertoire MANIFEST dans JAR, WAR ou EAR. Fournit l'audit et la mappe de génération des composants inclus. |
JAVA_SOURCE | Valeur : Yes ou No. Si la valeur est Yes, incluez la source Java dans JAR, WAR ou EAR. |
CLASSPATH_JARS | Répertoire de chemin de classes z/OS UNIX System Services utilisé pour résoudre les dépendances de chemin de classes lors de la génération. Tous les fichiers jar situés dans ce répertoire seront utilisés dans le chemin de classe. |
CLASSPATH_JARS_FILES | Noms des fichiers classe et JAR à inclure individuellement dans la génération. Il peut s'agir d'une liste, comme dans l'exemple suivant : <property name="CLASSPATH_JARS_FILES" value="V2J4.jar,V2J3.jar" /> |
ENCODING | Page de codes ASCII ou EBCDIC pour JAVA. Il s'agit de la source
JAVA de la page de codes enregistrée sur l'hôte z/OS. Par exemple :
|
JAR_FILE_NAME EJB_NAME WAR_NAME EAR_NAME |
Nom du fichier JAR, EJB JAR, WAR ou EAR. |
DEBUG_MODE | Spécifiez 'on' pour forcer Developer Toolkit à ne pas supprimer les fichiers de génération du répertoire WORKAREA. Cela est utile si vous devez vérifier la structure d'une Java/J2EE générée. |
La source Java d'une ARCHDEF peut comporter des dépendances de chemin de classes sur d'autres bibliothèques ou fichiers classe Java. Si ces dépendances sont situées sur des composants Java contenus dans la même structure d'ARCHDEF, elles sont résolues lors de la génération d'ARCHDEF (en mode conditionnel ou forcé).
Toutefois, un composant d'ARCHDEF J2EE peut comporter des dépendances de chemin de classe sur des fichiers JAR externes ou des membres contenus dans d'autres ARCHDEF. Dans ce cas, le script de génération J2EE associé à l'ARCHDEF peut contrôler les dépendances de chemin de classes à l'aide des mots clés suivants :
Ce répertoire peut être mis à jour avec les fichiers CLASSPATH via la fonction d'équipe client Charger les fichiers JAR qui permet de copier les fichiers JAR du client dans le répertoire classpath. La fonction Copier le fichier de SCLM vers le classpath qui permet de copier les fichiers JAR enregistrés dans SCLM dans le répertoire classpath est également disponible.
L'exemple suivant montre le script JAR :
<ANTXML> <project name="JAVA Project" default="jar" basedir="."> <property name="env" environment="env" value="env"/> <property name="SCLM_ARCHDEF" value="V2JAR1"/> <property name="SCLM_ANTXML" value="BWBJAVAA"/> <property name="SCLM_BLDMAP" value="YES"/> <property name="JAR_FILE_NAME" value="V2TEST.jar"/> <property name="CLASSPATH_JARS" value="/var/rdz/CLASSPATH"/> <property name="ENCODING" value="IBM-1047"/> </ANTXML>
L'exemple suivant montre le script WAR :
<ANTXML> <project name="J2EE WAR Project" default="web-war" basedir="."> <property name="env" environment="env" value="env"/> <property name="SCLM_ARCHDEF" value="SAMPLE5"/> <property name="SCLM_ANTXML" value="BWBWEBA"/> <property name="SCLM_BLDMAP" value="YES"/> <property name="JAVA SOURCE" value="YES"/> <property name="J2EE_HOME" value="${env.J2EE_HOME}"/> <property name="JAVA_HOME" value="${env.JAVA_HOME}"/> <property name="CLASSPATH_JARS" value="/var/rdz/CLASSPATH"/> <property name="ENCODING" value="IBM-1047"/> <!-- WAR file name to be created by this build process --> <property name="WAR_NAME" value="Sample5.war" /> <path id="build.class.path"> <pathelement location="."/> <pathelement location="${J2EE_HOME}/lib/j2ee.jar"/> <pathelement location="${CLASSPATH_JARS}/jdom.jar"/> <fileset dir="${CLASSPATH_JARS}" includes="**/*.jar, **/*.zip"/> </path> </ANTXML>
L'exemple suivant montre le script EJB :
<ANTXML> <project name="J2EE EJB Project" default="EJBBuild" basedir="."> <property name="env" environment="env" value="env"/> <property name="SCLM_ARCHDEF" value="SAMPLE3"/> <property name="SCLM_ANTXML" value="BWBEJBA"/> <property name="SCLM_BLDMAP" value="NO"/> <property name="J2EE_HOME" value="${env.J2EE_HOME}"/> <property name="JAVA_HOME" value="${env.JAVA_HOME}"/> <property name="CLASSPATH_JARS" value="/var/rdz/CLASSPATH"/> <property name="ENCODING" value="IBM-1047"/> <property name="EJB_NAME" value="DateService.jar"/> <path id="build.class.path"> <pathelement location="."/> <pathelement location="${J2EE_HOME}/lib/j2ee.jar"/> <pathelement location="${CLASSPATH_JARS}/jdom.jar"/> <fileset dir="${CLASSPATH_JARS}" includes="**/*.jar, **/*.zip"/> </path> </ANTXML>
L'exemple suivant montre le script EAR :
<ANTXML> <project name="J2EE EAR Project" default="j2ee-ear" basedir="."> <property name="env" environment="env" value="env"/> <property name="SCLM_ARCHDEF" value="SAMPLE6"/> <property name="EAR_NAME" value="Sample6.ear"/> <property name="SCLM_ANTXML" value="BWBEARA"/> <property name="SCLM_BLDMAP" value="NO"/> <property name="J2EE_HOME" value="${env.J2EE_HOME}"/> <property name="JAVA_HOME" value="${env.JAVA_HOME}"/> <property name="CLASSPATH_JARS" value="/var/rdz/CLASSPATH"/> <path id="build.class.path"> <pathelement location="."/> <pathelement location="${J2EE_HOME}/lib/j2ee.jar"/> <pathelement location="${CLASSPATH_JARS}/jdom.jar"/> <fileset dir="${CLASSPATH_JARS}" includes="**/*.jar, **/*.zip"/> </path> <target name="common"> <echo message="BuildName: ${Ant.project.name}" /> <echo message="BuildHome: ${basedir}" /> <echo message="BuildFile: ${Ant.file}" /> <echo message="BuildJVM: ${Ant.java.version}" /> </target> </ANTXML>
Cette section répertorie les exemples de squelette de génération Ant fournis dans la bibliothèque FEK.SFEKSAMV. Ces exemples de membre peuvent être copiés dans le type SCLM J2EEBLD de la hiérarchie SCLM pour être référencé et utilisé par les scripts de génération JAVA/J2EE. Ces scripts sont des fichiers de variable de propriétés qui écrasent les fichiers de squelette XML Ant.
Les exemples de squelette de génération J2EE fournis pour générer un simple fichier JAR, un projet SQLJ, un JAR d'EJB, un WAR ou un EAR ou pour le déploiement peuvent généralement être utilisés tels quels, sans personnalisation par l'utilisateur. Sachez toutefois que certains projets J2EE peuvent ne pas s'appliquer au modèle standard, auquel cas les squelettes XML Ant fournis risquent de devoir être personnalisés.
Une description détaillée des scripts de génération, des squelettes Ant et des exemples de traitement de génération JAVA/J2EE sont fournis dans le Guide d'utilisation de SCLM Developer Toolkit livré avec le plug-in du client.
Exemple de squelette de génération JAVA XML Ant
Ce squelette Ant est utilisé par un script de génération Java pour compiler plusieurs programmes Java et éventuellement créer un fichier JAR (Java Archive) qui possède une structure déterminée par une ARCHDEF indiquée.
Exemple de squelette de génération d'EJB J2EE XML Ant
Ce squelette Ant est utilisé par un script de génération J2EE pour compiler ou générer un projet EJB qui crée généralement un JAR EJB qui possède une structure déterminée par une ARCHDEF spécifiée.
Exemple de squelette de génération WEB J2EE XML Ant
Ce squelette est utilisé par un script de génération J2EE pour compiler ou générer un projet WEB qui crée généralement un fichier d'archive WEB (WAR).
Exemple de squelette d'assemblage d'EAR J2EE XML Ant
Ce squelette est utilisé par un script de génération J2EE comme processus d'assemblage en préparation du déploiement d'applications J2EE. Ce processus génère des fichiers EAR (Enterprise Archive) qui peuvent être déployés sur un serveur d'applications Web, tel qu'un serveur d'applications WebSphere.
Exemple de script de génération Java/SQLJ
Ce squelette est utilisé par un script de génération J2EE pour compiler ou générer un projet JAR qui utilise SQLJ.
Exemple de script de génération EJB/SQLJ
Ce squelette est utilisé par un script de génération J2EE pour compiler ou générer un projet EJB qui utilise SQLJ.
Exemple de conversion de Cloud 9 vers SCLM DT.
Exemple de mise à jour de fichiers .ser SQLJ au sein d'un fichier JAR lors du déploiement à l'aide de db2sqljcustomize.
Exemple conçu pour db2sqljcustomize dans lequel la propriété longname copie le fichier JAR indiqué du groupe spécifié et les emplacements de types de SCLM dans le répertoire de destination défini par "dest".
Cet exemple de routine personnalise les fichiers .ser stockés dans les fichiers JAR sélectionnés pour un déploiement à l'aide de db2sqljcustomize.
Exemple de convertisseur de génération SCLM pour les messages d'erreur de génération SYSXML pour COBOL.
IBM SCLM Developer Toolkit permet de gérer, de générer et de déployer des projets dans SCLM. Cette section explique comment configurer la structure de projets SCLM pour prendre en charge le développement d'applications distribuées, tel que JAVA/J2EE.
De nombreux projets JAVA/J2EE entraînent la création d'un fichier EAR exécutable. Cette application est un assemblage de projets, généralement des EJB et des applications et, dans les environnements IDE, ces projets sont généralement développés comme structures de projets individuelles associées à un projet EAR.
Cette forme de structures de projets multiples ne se mappe pas directement à SCLM. En effet, un projet SCLM ne peut pas être associé à un autre projet SCLM pour fournir une forme de structure de projets agrégée. Toutefois, SCLM offre un moyen permettant de prendre en charge cette structure IDE à projets multiples dans un même projet SCLM, à l'aide des types.
Les projets SCLM peuvent être définis avec plusieurs types de source. Chaque type peut contenir un seul projet IDE. Si nous tentions d'enregistrer plusieurs projets IDE Eclipse dans SCLM sans une certaine forme de séparation, chaque fichier .classpath et .project du projet serait remplacé car chaque fichier a été ajouté à SCLM. L'utilisation de différents types de source permet à ces fichiers et à tous les autres fichiers associés au projet, d'être enregistrés dans SCLM en toute sécurité.
Avec ce mappage, les projets IDE seraient enregistrés indépendamment dans SCLM avec le type comme principal élément de différentiation. Par exemple : EJB1 est enregistré dans le projet SCLM SCLMPRJ1 sous le type EJB1. En utilisant cette structure, il est possible de mapper la structure de projets IDE à des types indépendants dans le projet SCLM.
Il est donc important que la structure de projet SCLM soit conçue pour permettre le mappage de différents projets IDE dans sa structure. En effet, dans les grands projets SCLM, il peut s'avérer utile d'ajouter des types de projet supplémentaires dans la mesure où cette opération requiert une modification de la définition du projet SCLM, une régénération de la définition de projet SCLM et l'allocation de fichiers pour les nouveaux types.
Cette structure ne se limite pas aux projets de style J2EE, mais peut s'appliquer à toutes les situations dans lesquelles plusieurs projets sont développés, procurant une certaine forme de dépendance entre eux.
La liste suivante offre des recommandations permettant de mapper des projets J2EE (et autres) à SCLM :
L'utilisation de plusieurs types SCLM pour enregistrer des projets IDE est également liée à l'opération de la structure ARCHDEF pour la génération de ces projets IDE.
Le fichier ARCHDEF contient la liste des membres qui constituent une génération. Dans un contexte J2EE, une génération peut entraîner la constitution de plusieurs fichiers WAR et JAR dans un fichier EAR. Cette séparation de projets est similaire à la structure de type qui définit le projet dans SCLM. En disposant d'une ARCHDEF de haut niveau qui fait référence aux composants qui constituent la génération, il est possible d'obtenir un environnement de génération structuré. Ceci dépend de la définition réelle de la structure de projet lorsque vous définissez les types dans SCLM.
La définition du projet d'une manière structurée permet également :
Lors de la génération d'autres applications ayant des références ou des dépendances sur d'autres objets de génération, comme des fichiers JAR, d'autres projets ou d'autres classes, plusieurs approches sont possibles :
SCLM Developer Toolkit offre plusieurs fonctions de déploiement. Vous pouvez déployer des fichiers d'archive d'entreprise (EAR) dans un serveur WebSphere Application Server (WAS). D'autre part, tous les composants générés ou contrôlés par SCLM Developer Toolkit peuvent être distribués à l'aide d'un script de déploiement personnalisable. Des exemples de script permettant de copier un fichier EAR vers un hôte distant à l'aide des commandes secure copy (SCP) et secure FTP (SFTP) sont fournis.
Il existe principalement deux scripts au coeur du déploiement ; le premier type de script, celui modifié par l'utilisateur, est le script des propriétés, qui contient une liste de paramètres pour l'opération de déploiement. Le second est le script d'action contenant les étapes requises pour exécuter l'opération de déploiement.
Le déploiement est lancé à partir du plug-in client de SCLM Developer Toolkit et le type de déploiement est choisi en appuyant sur le bouton approprié de l'écran de déploiement. Le choix de l'action de déploiement a un impact sur le contenu du script des propriétés. La plupart des scripts incluent la propriété SCLM_ANTXML, qui contient le nom de membre du script d'action correspondant. Developer Toolkit sélectionne le script de propriétés généré et le superpose au script d'action, avant d'appeler le script d'action résultant.
Vous trouverez ci-après une liste d'exemples de script d'action de déploiement Ant qui sont fournis dans la bibliothèque FEK.SFEKSAMV. Ces exemples de membre peuvent être copiés dans le type SCLM J2EEBLD de la hiérarchie SCLM pour être référencé et utilisé par les scripts de propriétés générés. Ces scripts sont des fichiers de variable de propriétés qui écrasent les scripts d'action de déploiement XML Ant référencés ci-après. Ces scripts doivent être stockés avec un langage de type texte, tel que TEXT ou J2EEPART.
Membre | Description |
---|---|
BWBDEPLA | Déploiement EAR WAS. |
BWBRDEPL | Déploiement EAR WAS distant. |
BWBSCOPY | Déploiement Secure copy. Copie un objet de génération d'un hôte vers un autre à l'aide de SCP. |
BWBSFTP | Déploiement Secure FTP. Copie un objet de génération d'un hôte vers un autre à l'aide de SFTP. |
Pour que ces scripts de génération puissent être utilisables à partir de plusieurs groupes, l'administrateur doit générer les scripts et et les promouvoir au niveau de groupe le plus élevé disponible dans le projet.
Le traitement diffère légèrement suivant les types de script générés.
Pour le déploiement de WebSphere Application Server (WAS) la propriété SCLM_ANTXML ne fait pas référence à un script d'action Ant, mais à un script d'action JACL. Vous pouvez également utiliser l'outil wsadmin fourni avec WAS sous z/OS.
Cet outil requiert un script JACL pour assister la procédure de déploiement. Si cette méthode de déploiement est utilisée, le script JACL doit être créé sous la forme d'un fichier ASCII dans un répertoire z/OS UNIX pour que la procédure de déploiement puisse être appelée.
La personnalisation de Developer for System z fournit l'exemple de script JACL (ASCII) /etc/rdz/sclmdt/CONFIG/scripts/deploy.jacl (/etc/SCLMDT représentant le répertoire etc par défaut de SCLM Developer Toolkit).
Vous trouverez des exemples JACL supplémentaires dans la documentation de WebSphere Application Server (WAS).
Les emplacements de répertoire de l'outil wsadmin (wsadmin.sh) et du script JACL (deploy.jacl) peuvent être configurés dans la page des préférences, sous Equipe > Préférences du SCLM > Options de script de génération. Le client SCLMDT permet de générer un script de déploiement qui peut ensuite servir de base de génération. (La procédure de déploiement est déclenchée par une demande de fonction de déploiement au script de déploiement qui est stocké dans le type SCLM J2EEBLD).
Les exemples de script d'action à stocker dans le type SCLM J2EEBLD pour le déploiement de WAS ou le déploiement à distance de WAS sont BWBDEPLA et BWBRDEPL.
SCLM Developer Toolkit offre un moyen de déployer les fichiers stockés dans le référentiel SCLM sur le système de fichiers z/OS UNIX System Services de la même partition logique. Il est ainsi facile de déployer un objet généré par SCLM dans un environnement où il peut être exécuté ou même déployé sur un hôte éloigné à l'aide du déploiement sécurisé décrit ci-après.
Il n'existe pas de script d'action pour cette action. Sélectionnez les membres de SCLM et générez le script de propriétés requis à l'aide du bouton Inclure les membres SCLM. Les fichiers sont copiés de l'emplacement SCLM sélectionné vers un répertoire spécifié sur le système de fichiers z/OS UNIX System Services. Si ce répertoire n'existe pas, une erreur se produit.
Cette option permet de copier des objets déployables sur un hôte éloigné à l'aide des commandes secure copy (SCP) et secure FTP (SFTP). En combinant le script des propriétés de déploiement sécurisé et l'inclusion des membres SCLM, les fichiers requis peuvent être sélectionnés dans la hiérarchie SCLM, copiés dans un emplacement du système de fichiers z/OS UNIX System Services, puis copiés sur la machine de destination à partir de cet emplacement du système de fichiers z/OS UNIX System Services à l'aide des commandes SCP (copie sécurisée) et SFTP (FTP sécurisé).
Les exemples de script d'action à stocker dans le type SCLM J2EEBLD pour le déploiement sécurisé sont BWBSCOPY et BWBSFTP.
IBM Ported Tools for z/OS fournit les protocoles suivants :
L'authentification de la clé publique remplace la connexion interactive et peut être automatisée dans le cadre de l'opération de déploiement sécurisé de Developer Toolkit.
Pour que l'authentification de la clé publique fonctionne comme prévu, vous pouvez utiliser un ID utilisateur de substitution pour le déploiement ou configurer chaque utilisateur que vous souhaitez autoriser à effectuer des opérations de déploiement.
Pour obtenir des instructions de configuration de l'authentification basée sur des clés via ssh-agent et de ssh-add, reportez-vous au document IBM Ported Tools for z/OS User's Guide. Pour plus d'informations sur l'utilisation des ID utilisateur de substitution, voir Sécurité SCLM.
Il est également possible de créer des scripts Ant pour effectuer le déploiement, de différentes manières. Dans vos scripts, vous pouvez utiliser la balise Ant <exec> pour appeler un programme disponible dans le système de fichiers z/OS UNIX System Services. A l'aide de cette méthode, les scripts de génération peuvent appeler d'autres programmes, tels que FTP, pour effectuer le déploiement. Pour plus d'informations sur la création de scripts Ant, reportez-vous à la documentation Ant en ligne, à l'adresse suivante : http://ant.apache.org/.
Les fichiers source transférés à partir du plug-in SCLM Developer Toolkit peuvent être stockés dans SCLM au format ASCII ou EBCDIC.
Généralement, toutes les sources de SCLM sont stockées au format EBCDIC afin de pouvoir être affichées et modifiées directement à partir d'ISPF/SCLM sous z/OS. Si vous ne souhaitez pas parcourir ou modifier le code directement à partir de l'hôte, vous pouvez le stocker directement (le transférer en binaire) là où la source sera stockée dans SCLM, en utilisant la page de codes ASCII/UNICODE d'origine du client. Cette méthode a l'avantage d'améliorer les performances pour les projets de grande taille stockés et importés à partir de SCLM et pour les générations JAVA/J2EE car aucune conversion d'ASCII en EBCDIC n'est effectuée.
SCLM Developer Toolkit détermine si un fichier est transféré en binaire ou si une conversion d'ASCII en EBCDIC est effectuée, en vérifiant le langage SCLM associé à chaque fichier ou membre. SCLM Developer Toolkit vérifie ensuite que le langage SCLM contient une entrée dans le fichier TRANSLATE.conf avec un mot clé TRANLANG.
Traducteur de langage SCLM | Description |
---|---|
JAVA | Membres de source Java stockés au format EBCDIC. Créés à l'aide de l'exemple BWBTRAN1. |
SQLJ | Membres SQLJ stockés au format EBCDIC. Créés à l'aide de l'exemple (BWBTRANS). |
JAVABIN | Membres de source Java stockés au format ASCII. Créés à l'aide de l'exemple BWBTRAN1. |
J2EEPART | Fichiers J2EE pour lesquels aucune analyse syntaxique n'est requise, stockés au format EBCDIC. Créés à l'aide de l'exemple BWBTRAN1. |
J2EEBIN | Fichiers J2EE pour lesquels aucune analyse syntaxique n'est requise, stockés comme fichiers ASCII ou binaires. Créés à l'aide de l'exemple BWBTRAN1. |
SQLJ | Membres de source SQLJ stockés au format EBCDIC. Créés à l'aide de l'exemple BWBTRANS. |
SQLJBIN | Membres de source SQLJ stockés au format ASCII. Créés à l'aide de l'exemple BWBTRANS. |
TEXT | Traducteur de texte par défaut pour lesquels aucune analyse syntaxique n'est requise, stockés au format EBCDIC. Créés à l'aide de l'exemple BWBTRAN1. |
BINARY | Traducteur de langage binaire par défaut pour lequel aucune analyse syntaxique n'est requise. Créés à l'aide de l'exemple BWBTRAN1. |
Par défaut, une conversion ASCII/EBCDIC est effectuée. Cela signifie que les fichiers consultés et modifiés dans le plug-in Eclipse peuvent également l'être directement sur l'hôte à partir d'ISPF/SCLM.
Il est recommandé d'utiliser le format ASCII (transfert en binaire) pour les performances de génération et de migration ou d'importation de projets, car les fichiers n'ont pas besoin d'être convertis. Cette méthode ne convient que si l'édition dans ISPF/SCLM n'est pas requise.
Suivant le traducteur de langage SCLM utilisé, le source peut être généré en ASCII ou EBCDIC.
Pour les possibilités d'utilisation entre des plateformes différentes, tous les fichiers déployables, tels que les fichiers JAR, WAR et EAR, sont générés afin que tous les objets contenus soient de type ASCII, que le source soit stocké au format EBCDIC ou non.
Remarque sur la génération JAVA/J2EE : Si la source Java est stockée en ASCII, le script de génération doit spécifier la page de codes ASCII à l'aide de la variable de propriété ENCODING pour compiler correctement la source Java.
Par exemple :
<property name="ENCODING" value="ISO8859-1"/>
Le script Ant appelé utilise la commande Java avec le paramètre ENCODING=ISO8859-1 pour compiler le source ASCII. La page de codes ENCODING par défaut est la page de codes EBCDIC IBM-1047.
Dans le cadre du processus de génération JAVA/J2EE, des informations supplémentaires sont nécessaires pour exécuter les générations. Etant donné que les générations sont effectuées dans le système z/OS UNIX System Services, des informations, telles que l'emplacement du produit Java, l'emplacement du produit Ant et l'emplacement des fichiers de configuration SCLM Developer Toolkit et la zone de travail sont requises.
Vous pouvez également être amené à utiliser des versions différentes d'Ant ou de Java pour différents groupes de développement SCLM. C'est pourquoi le membre $GLOBAL peut être propre à un groupe. Les variables d'environnement définies dans le membre $GLOBAL peuvent être remplacées par des paramètres de variable de script de génération spécifiques.
Un exemple de membre BWBGLOB est fourni dans la bibliothèque FEK.SFEKSAMV. Cet exemple de membre doit être copié dans le type SCLM J2EEBLD de la hiérarchie SCLM comme membre $GLOBAL et sauvegardé avec un langage sans analyse valide, tel que TEXT (comme spécifié dans le traducteur de langage FLM@TEXT de la bibliothèque SISPMACS).
Le membre $GLOBAL fournit les informations suivantes aux procédures de génération JAVA/J2EE :
Variable | Description |
---|---|
ANT_BIN | Chemin d'accès du répertoire du système de fichiers z/OS UNIX System Services de l'environnement d'exécution Ant
Exemple : <property name="ANT_BIN" value="/usr/lpp/apache-Ant-1.6.0/bin/Ant"/> |
JAVA_BIN | Chemin d'accès du répertoire du système de fichiers z/OS UNIX System Services de l'environnement de compilation/exécution
Java
Exemple : <property name="JAVA_BIN" value="/usr/lpp/java/5.0/bin"/> |
_SCLMDT_WORK_HOME | Emplacement du répertoire de zone de travail SCLM
Developer Toolkit
Exemple : <property name="_SCLMDT_WORK_HOME" value="/var/rdz"/> |
_SCLMDT_CONF_HOME | Emplacement du répertoire de configuration de SCLM
Developer Toolkit
Exemple : <property name="_SCLMDT_CONF_HOME" value="/etc/rdz/sclmdt"/> |
CLASSPATH_JARS | Répertoire de chemin de classes du système de fichiers z/OS UNIX System Services utilisé pour les compilations JAVA. Tous les fichiers jar situés dans ce répertoire seront utilisés dans le chemin de classe.
Exemple : <property name="CLASSPATH_JARS" value="/var/rdz/CLASSPATH"/> |
TRANTABLE | Fichier VSAM contenant les conversions de nom long/abrégé
Exemple : <property name="TRANTABLE" value="FEK.#CUST.LSTRANS.FILE"/> |
DEBUG_MODE | Spécifiez "on" si vous souhaitez que Developer Toolkit ne supprime
pas les fichiers de génération Java/J2EE du système de fichiers z/OS UNIX System
Services.
Cela est utile si vous souhaitez que la structure de la génération apparaisse dans le système de fichiers USS à des fins de débogage. |
Si ces variables doivent être définies pour tous les niveaux du groupe dans le projet SCLM, il peut s'avérer judicieux de créer un membre $GLOBAL unique au niveau le plus élevé de la hiérarchie. Lorsque le traducteur de génération JAVA/J2EE s'exécute, il parcoure la hiérarchie à partir du niveau effectuant la génération et utilise le premier membre $GLOBAL qu'il trouve dans le type J2EEBLD.
Si différents paramètres sont requis, par exemple, au niveau de différents groupes de développement, un membre $GLOBAL peut être créé dans chacun des groupes de développement.
Le fichier TRANSLATE.conf fournit des mots clés permettant de déterminer le mode d'enregistrement du code dans SCLM. Le fichier de configuration contient des mots clés qui déterminent le mode de transfert des fichiers vers le système hôte, selon leur définition de langage. Des mots clés spécifiques déterminent si les fichiers dans un certain type de langage sont binaires, transférés et enregistrés, ou si le source de type texte reste au format ASCII et n'est pas converti par défaut d'ASCII en EBCDIC.
De plus, les définitions de langage SCLM déterminent si les noms de fichiers longs sont convertis en noms d'hôte abrégés valides pour l'enregistrement dans SCLM. Ce mappage de noms longs sur des noms abrégés est contrôlé par la fonction VSAM de conversion de nom long/abrégé SCLM.
TRANSLATE.conf se trouve dans /etc/rdz/sclmdt/CONFIG. Vous pouvez modifier le fichier à l'aide de la commande TSO OEDIT.
L'exemple ci-après illustre le code TRANSLATE.conf, qui doit être personnalisé pour correspondre à votre environnement système. Les lignes mises en commentaire commencent par un astérisque (*).
*============================================================= * cross system sharing TRANVRLS = NO *============================================================= * codepage CODEPAGE ASCII = ISO8859-1 CODEPAGE EBCDIC = IBM-1047 *============================================================= * ascii/ebcdic translation TRANLANG JAVABIN TRANLANG J2EEBIN TRANLANG J2EEOBJ TRANLANG TEXTBIN TRANLANG BINARY TRANLANG DOC TRANLANG XLS *============================================================= * long/short name translation LONGLANG JAVA LONGLANG SQLJ LONGLANG J2EEPART LONGLANG JAVABIN LONGLANG J2EEBIN LONGLANG J2EEOBJ LONGLANG DOC LONGLANG XLS
Les mots clés suivants sont valides dans le fichier TRANSLATE.conf :
Une directive de page de codes doit exister pour ASCII et pour EBCDIC afin que SCLM Developer Toolkit puisse déterminer comment convertir les fichiers transférés.
Une directive de page de codes doit exister pour ASCII et pour EBCDIC afin que SCLM Developer Toolkit puisse déterminer comment convertir les fichiers transférés.
SCLM utilise la méthode de partage de niveau enregistrement (RLS-Record Level Sharing) VSAM pour permettre le partage du fichier VSAM et conserver l'intégrité dans un environnement partagé. Les fichiers VSAM doivent être définis avec la classe STORAGECLASS appropriée pour l'utilisation de RLS. Pour plus d'informations sur RLS, voir le document DFSMS Using Data Sets (SC26-7410).
Notez que cette directive ne contient pas de signe égal (=) pour séparer le mot clé TRANLANG et le nom du traducteur de langage (factice).
Si le langage SCLM n'est pas indiqué dans le mot clé LONGLANG, le fichier client est considéré comme étant déjà au format de nom d'hôte abrégé (8 caractères ou moins) et est enregistré en tant que tel.
Notez que cette directive ne contient pas de signe égal (=) pour séparer le mot clé LONGLANG et le nom du langage SCLM.
Un utilitaire a été fourni pour permettre la création de certains paramètres à un niveau d'installation SITE ou au niveau d'un projet SCLM spécifique. Les options pouvant être actuellement configurées sont les suivantes :
Vous pouvez définir toutes ces options ou aucune d'elles. Si elles ne sont pas définies, leur valeur par défaut est utilisée dans les programmes. Certaines de ces options peuvent être définies dans le fichier SITE.conf tandis que d'autres peuvent l'être au niveau d'un certain projet SCLM. Il se peut également qu'il n'existe aucun fichier SITE spécifique, auquel cas, les options ne peuvent être définies qu'au niveau d'un projet SCLM. Vous pouvez remplacer les informations des cartes de travail par vos propres cartes de travail entrées via l'interface IDE.
Cet outil est activé en créant le fichier SITE.conf dans le répertoire z/OS UNIX /etc/rdz/sclmdt/CONFIG/PROJECT/ (où /etc/rdz/sclmdt est le répertoire etc par défaut de SCLM Developer Toolkit). Ce répertoire est créé lors de la personnalisation de Developer for System z.
Un exemple de fichier SITE.conf est fourni dans le répertoire /usr/lpp/rdz/samples/. Copiez ce répertoire et les instructions en fonction de vos besoins. Vous pouvez modifier le fichier à l'aide de la commande TSO OEDIT. L'exemple ci-après illustre le fichier de configuration SITE.conf.
* SCLM Developer Toolkit Site Specific option * * SCM Approver processing applies to this project? BUILDAPPROVER=NONE PROMOTEAPPROVER=NONE * * Change Code entry on check-in is mandatory? CCODE=N * * * To allow promotion by architecture definition only, * set the value of PROMOTEONLYFROMARCHDEF to Y PROMOTEONLYFROMARCHDEF=N * * Foreground or On-line builds/promotes allowed for this project? FOREGROUNDBUILD=Y FOREGROUNDPROMOTE=Y * * Batch Build default jobcard BATCHBUILD1=//SCLMBILD JOB (#ACCT),'SCLM BUILD',CLASS=A,MSGCLASS=X, BATCHBUILD2=// NOTIFY=&SYSUID,REGION=512M BATCHBUILD3=//* BATCHBUILD4=//* * * Batch Promote default jobcard BATCHPROMOTE1=//SCLMPROM JOB (#ACCT),'SCLM PROMOTE',CLASS=A,MSGCLASS=X, BATCHPROMOTE2=// NOTIFY=&SYSUID,REGION=128M BATCHPROMOTE3=//* BATCHPROMOTE4=//* * * Batch Migrate default jobcard BATCHMIGRATE1=//SCLMMIGR JOB (#ACCT),'SCLM MIGRATE',CLASS=A,MSGCLASS=X, BATCHMIGRATE2=// NOTIFY=&SYSUID,REGION=128M BATCHMIGRATE3=//* BATCHMIGRATE4=//* * * Batch Deployment default jobcard BATCHDEPLOY1=//SCLMDPLY JOB (#ACCT),'SCLM DEPLOY',CLASS=A,MSGCLASS=X, BATCHDEPLOY2=// NOTIFY=&SYSUID,REGION=128M BATCHDEPLOY3=//* BATCHDEPLOY4=//* * * BUILD Security flag for SAF/RACF security call and possible Surrogate * ID switch BUILDSECURITY=N * * Project list flag if set to N will stop users selecting * as project * filter. This may avoid long catalog searches for all SCLM projects. * PROJECTLISTALL=Y
Des paramètres de configuration peuvent également être spécifiques au projet pour configurer un projet SCLM. Ces paramètres remplacent les valeurs spécifiques au SITE s'il existe un fichier SITE.conf. Si vous souhaitez définir des valeurs spécifiques au projet, vous devez créer un fichier <project.conf dans le répertoire /PROJECT, <project> correspondant au nom du projet SCLM (Maj./min. non différenciées).
Un exemple de fichier de configuration de projet est fourni dans le répertoire /usr/lpp/rdz/samples/ (SCLMproject.conf). Copiez cet exemple dans le répertoire PROJECT en utilisant le nom de cible approprié et personnalisez les instructions conformément à vos besoins.
Vous pouvez modifier le fichier à l'aide de la commande TSO OEDIT. L'exemple ci-après illustre le code de configuration du projet.
* SCLM Developer Toolkit Project Specific option * * SCM Approver processing applies to this project? BUILDAPPROVER=BREEZE PROMOTEAPPROVER=BREEZE * * Change Code entry on check-in is mandatory? CCODE=Y * * Foreground or On-line builds/promotes allowed for this project? FOREGROUNDBUILD=N FOREGROUNDPROMOTE=N * * Batch Build default jobcard BATCHBUILD1=//SCLMBILD JOB (#ACCT),'SCLM BUILD',CLASS=A,MSGCLASS=X, BATCHBUILD2=// NOTIFY=&SYSUID,REGION=512M BATCHBUILD3=//* BATCHBUILD4=//* * * Batch Promote default jobcard BATCHPROMOTE1=//SCLMPROM JOB (#ACCT),'SCLM PROMOTE',CLASS=A,MSGCLASS=X, BATCHPROMOTE2=// NOTIFY=&SYSUID,REGION=128M BATCHPROMOTE3=//* BATCHPROMOTE4=//* * * BUILD Security flag for SAF/RACF security call and possible Surrogate * ID switch BUILDSECURITY=N * PROMOTE Security flag for SAF/RACF security call and possible * Surrogate ID switch PROMOTESECURITY=N * J2EE DEPLOY security flag for SAF/RACF security call and possible * Surrogate ID switch DEPLOYSECURITY=N
Toutes les options répertoriées sont facultatives. Les valeurs par défaut sont utilisées si rien n'est spécifié dans le fichier SITE.conf ou project.conf.
BUILDAPPROVER=produit de validation/NONE | Spécifiez le nom du produit de validation utilisé pour la procédure de génération. Actuellement, le seul produit pris en charge est IBM Breeze for SCLM, qui est sélectionné à l'aide du mot clé BREEZE. La valeur par défaut est NONE. |
PROMOTEAPPROVER=produit de validation/NONE | Spécifiez le nom du produit de validation utilisé pour la procédure de promotion. Actuellement, le seul produit pris en charge est IBM Breeze for SCLM. Si PROMOTEAPPROVER a la valeur BREEZE, les zones spécifiques à Breeze sont affichées lors d'une promotion. La valeur par défaut est NONE. |
CCODE=N/Y | Spécifiez Y pour que l'entrée du code de modification soit obligatoire lors d'une restitution. La valeur par défaut est N ; l'entrée du code de modification n'est pas obligatoire. |
FOREGROUNDBUILD=Y/N | Spécifiez N pour restreindre les générations en avant-plan. La valeur par défaut est Y ; les générations en avant-plan sont autorisées. |
FOREGROUNDPROMOTE=Y/N | Spécifiez N pour restreindre les promotions en avant-plan. La valeur par défaut est Y ; les promotions en avant-plan sont autorisées. |
BATCHBUILD1=Carte de travail 1 BATCHBUILD2=Carte de travail 2 BATCHBUILD3=Carte de travail 3 BATCHBUILD4=Carte de travail 4 |
Définissez une carte de travail par lots par défaut pour la procédure de génération. Des projets différents peuvent utiliser des classes de travaux ou des codes de compte différents pour que l'option de spécification de cartes de travaux spécifiques à un projet permette ce scénario. |
BATCHPROMOTE1=Carte de travail 1 BATCHPROMOTE2=Carte de travail 2 BATCHPROMOTE3=Carte de travail 3 BATCHPROMOTE4=Carte de travail 4 |
Définissez un travail par lots par défaut pour la procédure de promotion. Des projets différents peuvent utiliser des classes de travaux ou des codes de compte différents pour que l'option de spécification de cartes de travaux spécifiques à un projet permette ce scénario. |
BATCHMIGRATE1=Carte de travail 1 BATCHMIGRATE2=Job card 2 BATCHMIGRATE3=Job card 3 BATCHMIGRATE4=Job card 4 |
Définissez un travail par lots par défaut pour la procédure de migration. Des projets différents peuvent utiliser des classes de travaux ou des codes de compte différents pour que l'option de spécification de cartes de travaux spécifiques à un projet permette ce scénario. |
BUILDSECURITY=Y/N | Spécifiez Y afin d'appeler l'appel de sécurité SAF/RACF pour l'étape de génération et effectuez éventuellement une commutation d'ID de substitution. Pour plus d'informations, voir Sécurité SCLM. |
PROMOTESECURITY=Y/N | Spécifiez Y afin d'appeler l'appel de sécurité SAF/RACF pour l'étape de promotion et effectuez éventuellement une commutation d'ID de substitution. Pour plus d'informations, voir Sécurité SCLM. |
DEPLOYSECURITY=Y/N | Spécifiez Y afin d'appeler l'appel de sécurité SAF/RACF pour l'étape de déploiement et effectuez éventuellement une commutation d'ID de substitution. Pour plus d'informations, voir Sécurité SCLM. |
ASCII=page de codes ASCII | Spécifiez la page de codes ASCII devant remplacer celle qui est spécifiée dans TRANSLATE.conf. Par exemple :
ASCII=UTF-8 |
EBCDIC=page de codes EBCDIC | Spécifiez la page de codes EBCDIC devant remplacer celle qui est spécifiée dans TRANSLATE.conf. Par exemple :
EBCDIC=IBM-420 |
TRANLANG=Langage SCLM | Spécifiez un paramètre TRANLANG à ajouter à la liste des
paramètres TRANLANG spécifiés dans le fichier TRANSLATE.conf.
Par exemple :
TRANLANG=DOC |
NOTRANLANG=Langage SCLM | Utilisez le mot clé NOTRANLANG pour supprimer un mot clé
TRANLANG déjà spécifié de la liste des mots clés autorisés pour ce projet SCLM, conformément au
fichier TRANSLATE.conf. Par exemple :
NOTRANLANG=JAVA |
LONGLANG=Langage SCLM | Spécifiez un paramètre LONGLANG à ajouter à la liste des
paramètres LONGLANG spécifiés dans le fichier TRANSLATE.conf .
Par exemple :
LONGLANG=DOC |
NOLONGLANG=Langage SCLM | Utilisez le mot clé NOLONGLANG pour supprimer un mot clé
LONGLANG déjà spécifié de la liste des mots clés autorisés pour ce projet
SCLM, conformément au fichier TRANSLATE.conf. Par exemple :
NOLONGLANG=COBOL |
BIDIPROP=LANG=SCLM Language/* TextOrient=LTR/RTL TextType=Visual/Logical SymetricSwap=On/Off NumericSwap=On/Off |
Utilisez le mot clé BIDIPROP pour affecter les langages SCLM comme langages bidirectionnels par défaut. Le paramètre LANG= peut correspondre à tous les langages SCLM à des langages SCLM spécifiques. Le support bidirectionnel n'est pris en charge que sous Developer for System z. |
PROJECTLISTALL=Y | Si l'option de liste de projets a la valeur N, les utilisateurs ne pourront plus sélectionner * comme filtre de projets. Cela peut éviter les longues recherches dans les catalogues utilisateur pour tous les projets SCLM. |
Le fichier TRANSLATE.conf définit les paramètres par défaut de la prise en charge des pages de codes et le support de langage SCLM par défaut à appliquer dans SCLM Developer Toolkit. Dans cet exemple, TRANSLATE.conf possède les valeurs répertoriées ci-après.
CODEPAGE ASCII = ISO8859-1 CODEPAGE EBCDIC = IBM-1047 * TRANLANG JAVABIN TRANLANG J2EEBIN TRANLANG J2EEOBJ TRANLANG TEXTBIN TRANLANG BINARY TRANLANG DOC TRANLANG XLS * LONGLANG JAVA LONGLANG SQLJ LONGLANG DOC LONGLANG XLS LONGLANG J2EEPART LONGLANG JAVABIN LONGLANG J2EEBIN LONGLANG J2EEOBJ
Il est possible pour des projets SCLM différents qui stockent des types de données différents, éventuellement dans d'autres langues, de remplacer ces paramètres par défaut. Le fichier de configuration du projet SCLM SCLMPRJ1.conf peut donc contenir les paramètres de substitution suivants :
* Arabic Codepage overrides * ASCII=UTF-8 EBCDIC=IBM-420 * * Project specific TRANLANG and LONGLANG entries * TRANLANG=DOC LONGLANG=DOC
Cela affecte aux pages de codes des traductions source la paire de pages de codes arabes. De plus, le langage SCLM DOC est ajouté aux valeurs par défaut du fichier TRANSLATE.conf.
Le projet SCLM SCLMPRJ2 peut contenir des paramètres de remplacement différents dans le fichier SCLMPRJ2.conf :
* Hebrew Codepage overrides * ASCII=UTF-8 EBCDIC=IBM-424 * * Project specific TRANLANG and LONGLANG entries * TRANLANG=DOC TRANLANG=XLS NOTRANLANG=JAVABIN NOTRANLANG=J2EEBIN NOTRANLANG=J2EEOBJ LONGLANG=DOC LONGLANG=XLS NOLONGLANG=COBOL NOLONGLANG=J2EEPART NOLONGLANG=JAVABIN NOLONGLANG=J2EEBIN NOLONGLANG=J2EEOBJ
Cela affecte aux pages de codes des traductions source la paire de pages de codes hébreux. De plus, les langages SCLM DOC et XLS sont ajoutés aux valeurs par défaut du fichier TRANSLATE.conf. Dans ce cas, toutefois, les valeurs par défaut définies dans le fichier TRANSLATE.conf sont ensuite supprimées. Cela n'est pas vraiment nécessaire car la présence de paramètres supplémentaires ne pose pas de difficultés, mais cela montre comment un projet peut être configuré de sorte à ne contenir que les langages SCLM requis pour un projet SCLM spécifique.
Les valeurs BIDIPROP spécifiées dans le fichier SITE.conf peuvent être remplacées par les valeurs BIDIPROP spécifiées dans les fichiers SCLM <project>.conf spécifiques aux projets. Par exemple, les valeurs suivantes sont définies dans le fichier SITE.conf :
* * ---------------- SITE SPECIFIC BIDI OPTIONS ------------------ * * * BiDi Language default properties * BIDIPROP=LANG=* TextOrient=LTR TextType=Visual SymetricSwap=Off NumericSwap=Off
Cela affecte à tous les langages SCLM les paramètres spécifiés. Il est maintenant possible de spécifier les valeurs suivantes dans le fichier ADMIN10.conf :
* * BiDi Language default properties BIDIPROP=LANG=JAVA TextOrient=RTL TextType=Visual SymetricSwap=On NumericSwap=Off BIDIPROP=LANG=COBOL TextOrient=RTL TextType=Logical SymetricSwap=Off NumericSwap=Off
Ces paramètres remplacent ceux du fichier SITE.conf pour les définitions de langage JAVA et COBOL. Tous les autres langages possèdent les paramètres par défaut, comme spécifié dans SITE.conf.
SQLJ est une extension de langage pour Java. Il s'agit de l'une des technologies qui permettent aux programmeurs Java d'inclure des communications de base de données dans leurs programmes. SQLJ permet de générer du code SQL imbriqué, statique, qui s'avère généralement plus performant que ses équivalents dynamiques, tels que JDBC.
SCLM Developer Toolkit est livré avec des scripts exemple vous permettant de générer des programmes Java activés par SQLJ à l'aide de DB2.
Après la lecture de ce chapitre, vous devriez comprendre le fonctionnement de base de SQLJ et savoir comment appliquer ces connaissances lors de l'utilisation de SCLM Developer Toolkit.
SQL est l'acronyme de Structured Query Language. Il s'agit d'un langage ouvert permettant d'interroger, d'ajouter, de supprimer et de modifier des données dans un système RDMS (Relational Database Management System).
La première implémentation de ce langage a été effectuée dans un produit de base de données IBM pionnier dans les années 1970 : System R. Depuis, SQL s'est développé, a été standardisé (par ANSI et ISO) et a pris plusieurs formes sur un grand nombre de systèmes de base de données.
DB2 est un système de base de données populaire, utilisé à l'origine pour la plateforme de l'ordinateur principal, mais qui depuis a été étendu à de nombreuses autres plateformes. Il s'agit de la norme pour les systèmes de gestion de base de données relationnelle sous z/OS.
DB2 UDB Version 8 correspond à la version utilisée par les scripts de génération SCLM Developer Toolkit. Dans le présent chapitre, toute référence à DB2 s'applique spécifiquement à DB2 UDB Version 8.
JDBC signifie Java Database Connectivity. En développement Java, cette technologie est bien connue et couramment utilisée pour implémenter l'interaction des bases de données. JDBC est une API au niveau appel, ce qui signifie que les instructions SQL sont transmises sous forme de chaînes à l'API, qui les exécute ensuite sur le système RDMS. Par conséquent, la valeur de ces chaînes peut être modifiée lors de l'exécution et rendre ainsi JDBC dynamique.
Les programmes JDBC sont exécutés plus lentement que leurs équivalents SQLJ, mais ils bénéficient du concept "Write once, call anywhere". Comme aucune interaction n'est requise lors de la phase d'exécution, un programme JDBC est donc particulièrement transférable et peut passer d'un système à un autre pour un coût minimal.
SQLJ est une extension de langage utilisée pour les transactions de base de données dans les applications Java. Il génère un SQLJ imbriqué, statique. Ce terme se compose du sigle SQL ( Structured Query Language) suivi de la lettre J, pour Java.
SQLJ est statique car les instructions SQL qui seront exécutées sont connues lors de l'assemblage du programme, contrairement à JDBC où les requêtes qui sont exécutées peuvent être modifiées à tout moment.
SQLJ est imbriqué car, lors de la liaison, une forme sérialisée des instructions SQL des programmes est fournie à la base de données. Cette dernière utilise ces données sérialisées pour déterminer les chemins d'accès optimisés aux tables qui y sont référencées. Dans JDBC, la base de données n'a pas moyen de déterminer quelles instructions seront exécutées, jusqu'à ce qu'elle les reçoit de l'application lors de la phase d'exécution. Par conséquent, il doit déterminer les chemins d'accès lors de la phase d'exécution. Le temps système est alors augmenté. Vous pouvez éviter cette situation en utilisant SQLJ.
Cette table se base sur les informations de la section 5.2 du Redbook DB2 UDB for z/OS Version 8: Everything You Ever Wanted to Know, ... and More.
SQLJ (statique) | JDBC (dynamique) | |
---|---|---|
PERFORMANCES | La plupart du temps, le SQL statique est plus rapide que le SQL dynamique car lors de la phase d'exécution, seules les autorisations des packages et des plans doivent être vérifiées avant l'exécution du programme. | Les instructions SQL dynamiques doivent être analysées, les autorisations des tables/vues doivent être vérifiées et le chemin d'optimisation doit être déterminé. |
AUTORISATION | Avec SQLJ, le propriétaire de l'application octroie les droits d'exécution (EXECUTE) sur le plan ou le package et le destinataire de ces droits doivent exécuter l'application, tel que c'est spécifié. | Avec JDBC, le propriétaire de l'application octroie des droits sur toutes les tables sous-jacentes utilisées par l'application. Le destinataire de ces droits peut effectuer toute opération autorisée par ces droits. Par exemple, les utiliser en dehors de l'application pour laquelle ces droits ont été octroyés à l'origine. L'application ne peut pas contrôler quelles opérations l'utilisateur peut effectuer. |
DEBOGAGE | SQLJ n'est pas une API, mais une extension de langage. Cela signifie que les outils SQLJ ont connaissance des instructions SQL dans votre programme et qu'ils vérifient si leur autorisation et leur syntaxe sont correctes lors de la procédure de développement du programme. | JDBC est une pure API au niveau appel. Autrement dit, le compilateur Java ne prend pas en compte les instructions SQL. Elles apparaissent uniquement en tant qu'arguments d'appels de méthode. Si l'une de vos instructions est erronée, vous ne détecterez pas cette erreur jusqu'à ce que la base de données affiche une erreur. |
SURVEILLANCE | Avec SQLJ, la surveillance du système et les rapports de performances sont bien meilleurs. Les packages SQL statiques vous indiquent les noms des programmes exécutés à un moment donné. Ces packages sont utiles pour l'étude de l'utilisation de l'unité centrale par les différentes applications, le verrouillage de certains éléments (blocage ou délai, par exemple), etc. | Alors que dans SQLJ, vous pouvez déterminer le nom du programme en cours d'exécution, avec JDBC, toutes les transactions sont effectuées via le même programme. Cela rend la surveillance et l'identification des zones d'incident plus difficiles. |
PROLIXITE | Les instructions SQLJ étant codées dans une syntaxe purement SQL, sans qu'il ne soit nécessaire de les encapsuler dans une méthode Java, les programmes sont plus faciles à lire et donc à gérer. En outre, comme une partie du code standard codé explicitement en JDBC est généré automatiquement en SQLJ, les programmes écrits en SQLJ ont tendance à être plus courts que les programmes JDBC équivalents. | Avec JDBC, toutes les instructions SQL doivent être encapsulées dans des appels d'API, ce qui donne généralement un code peu clair et prolixe. |
Un profil sérialisé est un code écrit en SQLJ est placé dans un fichier ayant l'extension .sqlj. Dans la première étape de préparation de programme (qui sera décrit en détails ultérieurement), le fichier .sqlj est transmis au traducteur SQLJ.
Ce traducteur génère deux types de sortie. La première est le code source Java (.java). Ce code source correspond à l'implémentation Java du code dans le fichier .sqlj.
Le deuxième type de sortie est un profil sérialisé (.ser). Ce fichier contient toutes les instructions SQL provenant du fichier .sqlj à un format sérialisé. Ce profil doit être disponible lors de l'exécution pour le programme. Il peut également être utilisé pour la liaison au système de gestion de base de données relationnelle.
DBRM signifie module d'interrogation de base de données. Il s'agit de la représentation sérialisée DB2 standard des instructions SQL dans un programme. Par exemple, un programme peut être écrit en COBOL. Ce programme sera prétraité par DB2 pour générer un module DBRM permettant d'accéder à un sous-système DB2 particulier.
Avec SQLJ, la procédure est légèrement différente et est appelée, dans la terminologie DB2 UDB Version 8, mode de compatibilité. L'utilitaire db2sqljcustomize peut être fourni avec des arguments de ligne de commande facultatifs qui entraînent la génération d'un module DBRM. Ce module DBRM peut ensuite être associé à DB2 à l'aide de moyens traditionnels, tel qu'un script REXX appelé par un exit utilisateur SCLM.
Avant d'aborder l'utilisation de SCLM Developer Toolkit pour générer des programmes SQLJ, examinons d'abord la procédure manuelle. Cette procédure concerne l'implémentation DB2 de SQLJ et se compose de trois commandes appelées sqlj, db2sqljcustomize et db2bind. Notez que l'étape de liaison pouvant être éventuellement effectuée dans db2sqljcustomize, db2bind n'est pas toujours nécessaire.
Le traducteur SQLJ (à ne pas confondre avec le traducteur de langage SCLM) utilise les fichiers source SQLJ en tant qu'entrée et génère du code source Java (fichiers .java) et des profils sérialisés (fichiers .ser).
Le langage SQLJ lui-même n'est pas abordé dans le présent document. Pour obtenir des références sur le développement de code SQLJ, consultez le site http://www.sql.org.
Le nombre de profils sérialisés générés par fichier .sqlj dépend du nombre de classes de contexte de connexion référencées dans le code SQLJ. Un profil sérialisé sera généré pour chacune d'entre elles.
De nombreux fichiers source SQLJ ne font référence qu'à une seule classe de contexte de connexion et ne génèrent donc qu'un seul profil sérialisé. Les profils sérialisés sont nommés en fonction de l'ordre dans lequel ils sont référencés dans le fichier source. Le nom se présente au format suivant :
nomprog_SJProfileX.ser
Où :
Exemple :
Entrée : Customer.sqlj (fait référence à une classe de contexte de connexion) Sortie : Customer.java Customer_SJProfile0.ser Et éventuellement, si l'argument -compile=true est fourni à sqlj : Customer.class
Une fois que les profils sérialisés sont générés, nous devons les personnaliser. La commande permettant d'effectuer cette action dans DB2 version 8 est db2sqljcustomize. Dans les versions précédentes, la commande était db2profc. Chaque appel du personnaliseur doit correspondre à un appel du traducteur SQLJ. Autrement dit, si un simple appel du traducteur a généré cinq profils, ces cinq profils doivent être transmis en tant qu'entrée à un appel unique du personnaliseur de profil. Il est également possible d'associer chaque nom de programme à un appel de chacun des utilitaires. N'oubliez pas que le nom du programme est identique au nom de fichier source en entrée, sans l'extension .sqlj.
La personnalisation ajoute des informations propres à DB2 au profil sérialisé utilisé lors de l'exécution. D'autres options, telles la liaison automatique, peuvent être configurées à l'aide d'options de ligne de commande. Si vous utilisez une version existante de DB2 ou que vous spécifiez les options gendbrm et dbrmdir pour db2sqljcustomize, un fichier de module DBRM est généré. Ce fichier est utilisé par la suite pour accéder à la base de données. A l'aide du pilote universel de DB2 UDB 8+, vous pouvez ignorer la génération d'un module d'interrogation de base de données à l'aide des profils sérialisés générés par le traducteur SQLJ.
La liaison est la dernière étape de la procédure de préparation du programme SQLJ. Dans DB2 version 8, la commande de liaison est db2sqljbind ou, pour une liaison automatique, db2sqljcustomize. La liaison constitue l'étape qui génère un chemin d'accès aux tables DB2 pour vos instructions SQL sérialisées. Ces instructions sont disponibles sous forme de module DBRM ou de profil sérialisé.
Par défaut, quatre packages sont créés ; un pour chaque niveau d'isolement. Vous pouvez effectuer la liaison à l'aide de la méthode traditionnelle lorsqu'un module d'interrogation est utilisé ou de la nouvelle méthode Universal lorsque les profils sérialisés sont utilisés à la place.
Avant d'aborder les traducteurs et les types SCLM, il est important de faire la distinction entre un traducteur de langage SCLM ou, plus simplement, un traducteur SCLM et le traducteur SQLJ sqlj fourni avec DB2.
Dans SCLM, tout langage défini doit posséder un traducteur pour que le système sache comment traiter ce langage. Ce traducteur est différent du traducteur SQLJ, sqlj, un utilitaire de ligne de commande qui génère des profils sérialisés et un code source Java à partir d'un fichier source SQLJ.
Une fois cette distinction établie, nous étudierons les types SCLM et les traducteurs SCLM associés à la procédure de génération SQLJ, de la manière suivante :
Un traducteur SCLM pour SQLJ est fourni et doit être affecté comme type de langage de tout le code source SQLJ stocké dans SCLM. Ce nouveau traducteur requiert la définition de types SCLM supplémentaires. Le traducteur SCLM de SQLJ est similaire au traducteur JAVA, mais il contient des définitions IOTYPE supplémentaires pour les types de sortie SCLM SQLJSER et DBRMLIB. Si vous ne souhaitez pas générer de fichier de module d'interrogation de base de données comme partie de l'étape de personnalisation, cet élément DBRMLIB IOTYPE peut être retiré de la définition de langage SQLJ.
Dans la définition de projet, un administrateur doit définir et générer le traducteur SCLM et les types supplémentaires.
SQLJSER | Requis pour stocker les fichiers de profil sérialisé générés (fichiers .ser) créés ou personnalisés dans les étapes de traduction et de personnalisation. Il est recommandé de définir ce fichier de type SCLM au format recfm=VB, lrecl=256. |
DBRMLIB | Type devant contenir les fichiers DBRM générés créés dans l'étape de personnalisation. Ce type est requis uniquement pour les clients utilisant les fichiers de modules d'interrogation de base de données générés dans le cadre du traitement de liaison DB2. |
Pour conserver une flexibilité maximale, la procédure de génération SQLJ peut être très personnalisée, pour répondre aux besoins de différentes configurations de site et de toute combinaison de paramètres à transmettre à sqlj et db2sqljcustomize.
Cette section décrit les concepts liés à l'implémentation SQLJ de SCLM Developer Toolkit. Après la lecture de cette section, vous devriez pouvoir personnaliser le processus de génération afin qu'il réponde aux exigences de votre site.
Lors de la traduction SQLJ et de la personnalisation des profils, SCLM Developer Toolkit appelle directement les mêmes classes Java utilisées par les commandes sqlj et db2sqljcustomize. Sachez que les arguments fournis aux procédures de traduction et de personnalisation SCLM DT sont identiques. Pour obtenir une description détaillée de tous les arguments de ligne de commande pour chaque commande, consultez le document DB2 Universal Database User Guide.
En supposant que vous ayez utilisé l'assistant Ajouter à SCLM, le script de génération de votre programme SQLJ reçoit le même nom de membre que l'Archdef. Par exemple, si la définition d'archive de votre projet sqlj est SCLM10.DEV1.ARCHDEF(SQLJ01), vous trouverez le script de génération dans SCLM10.DEV1.J2EEBLD(SQLJ01).
Ce script de génération contient une référence au script de génération maître. Cet élément est disponible dans la propriété. La configuration répertoriée pour les étapes de traduction et de personnalisation se poursuit dans ce fichier.
Chaque propriété répertoriée dans le tableau 9 apparaît dans le script de génération BWBSQLB. Ces propriétés sont au format XML, comme cela est présenté ci-dessous :
La configuration du script implique la modification de la valeur pour toute propriété appropriée.
Nom | Valeur | Description |
---|---|---|
sqlj.exec | usr/lpp/rdz/bin/bwbsqlc.rex | Spécifie l'emplacement de la routine d'exécution sqlj & db2sqljcustomize bwbsqlc.rex, qui se trouve dans le répertoire d'installation de Developer for System z. |
sqlj.class | sqlj.tools.Sqlj | Spécifie le nom de la classe sqlj. Il s'agit du nom de la classe appelée par l'utilitaire sqlj. Il est peut probable que vous deviez modifier cette valeur. |
sqlj.bin | /db2path/bin | Spécifiez le répertoire db2 sqlj bin dans lequel se trouve le script sqlj. |
sqlj.cp | /db2path/jcc/classes/sqlj.zip | Spécifie l'emplacement du fichier sqlj.zip à inclure dans le chemin d'accès aux classes. |
sqlj.arg | -compile=false status linemap=NO db2optimize | Spécifie les arguments de propriété globaux ci-après pour le traitement sqlj. |
Chaque propriété répertoriée dans le tableau 10 apparaît dans le script de génération BWBSQLB. Ces propriétés sont au format XML, comme cela est présenté ci-dessous :
<property name= NOM value= VALEUR />
La configuration du script implique la modification de la valeur pour toute propriété appropriée.
Nom | Valeur | Description |
---|---|---|
sqljdb2cust.class | com.ibm.db2.jcc.sqlj.Customizer | Spécifie le nom de la classe de personnalisation sqlj db2. Il est peut probable que vous deviez modifier cette valeur. |
db2sqljcust.cp |
/db2path/jcc/classes/db2jcc.jar: ./SRC: /db2path/jcc/classes/db2jcc_license_cisuz.jar |
Paramètres du chemin d'accès aux classes pour l'utilitaire de personnalisation. Les noms de chemin complets doivent être fournis en XML. |
db2sqljcust.arg | -automaticbind NO -onlinecheck YES -staticpositioned YES -bindoptions â ISOLATION(CS)â -genDBRM | Arguments généraux à fournir à l'utilitaire de personnalisation. |
db2sqljcust.propfile | user.properties | Nom du fichier de propriétés temporaire à transmettre à un script de détermination des propriétés utilisateur pour les valeurs de propriétés dynamiques. Conservez la valeur par défaut. |
db2sqljcust.userpgm | AUCUN si vous souhaitez ignorer le script. Sinon, spécifiez le nom de fichier et le chemin d'accès complet du script utilisateur. | Ce script est exécuté immédiatement avant l'utilitaire de personnalisation. Il met à jour de manière dynamique un fichier de propriétés utilisé en entrée dans l'utilitaire de personnalisation. |
Le script de génération SQLJ fourni par SCLM Developer Toolkit est conçu pour fonctionner en mode de compatibilité DB2 UDB v8. Ce mode prend en charge le concept DB2 des modules d'interrogation de base de données et non la liaison via les profils sérialisés. Pour utiliser les profils sérialisés, vous devez modifier le script BWBSQLB. Cette opération est abordée dans la sous-rubrique Liaison [Profil sérialisé].
La méthodologie de liaison à part, pour faire correspondre la procédure de génération à votre site, vous devrez probablement personnaliser les arguments de sqlj et db2sqljcustomize en fonction de votre environnement de base de données, de vos règles d'isolement et d'autres facteurs. Vous pouvez également transmettre vos propres scripts afin de déterminer les propriétés dynamiques pour ces arguments. Par exemple, vous pouvez vouloir créer un nom de package lié au nom du fichier d'entrée.
SCLM Developer Toolkit vous le permet ; vous n'avez qu'à spécifier votre propre script de personnalisation. L'intégralité de la procédure de création XML ANT repose sur le concept des "propriétés", les éléments XML Property spécifiant une paire de noms ou de valeurs. Par exemple, dans l'étape db2sqljcustomize du script de génération BWBSQLB, les arguments de ligne de commande globaux à fournir à db2sqljcustomize sont définis dans un élément de propriété appelé db2sqljcust.arg et dont la valeur par défaut est -automaticbind NO -onlinecheck YES -staticpositioned YES -bindoptions "ISOLATION(CS)" genDBRM lang=EN-AU.
Si vous souhaitez modifier les arguments fournis, vous pouvez éditer le script de génération fourni pour modifier la valeur de la propriété, ce qui modifie les paramètres de manière globale, ou ancrer votre propre script de personnalisation dans la procédure.
Pour intégrer votre propre script de propriété personnalisé, indiquez le nom du script dans db2sqljcust.userpgm et le nom du fichier de propriétés à placer dans db2sqljcust.propfile.
Le script spécifié dans db2sqljcust.userpgm est exécuté immédiatement avant le processus db2sqljcustomize. Votre script met à jour dynamiquement le fichier de propriétés spécifié dans db2sqljcust.userpgm. Ce fichier de propriétés est utilisé en entrée du processus db2sqljcustomize car la procédure de génération concatène les deux propriétés dans le fichier de propriétés mis à jour de manière dynamique et les propriétés déjà définies dans le script de génération.
Le script spécifié dans db2sqljcust.userpgm sera fourni par les arguments suivants lors de l'exécution :
Les propriétés doivent être définies dans le fichier au format suivant, avec une déclaration de propriété par ligne :
argument=value ex. singlepkgname= pkgname
Exemple :
pkgversion=1 url=jdbc:db2://site1.com:80/MVS01 qualifier=DBT singlepkgname= SQLJ986
La routine de personnalisation est appelée une fois par fichier. Enfin, les propriétés des arguments sont utilisées pour générer la chaîne d'arguments requise pour l'appel db2sqljcustomize. Exemple :
db2sqljcustomize -automaticbind NO -collection ${db2.collid} -url ${db2.url} -user ${db2.user} -password ???????? -onlinecheck YES -qualifier ${db2.qual} -staticpositioned YES -pkgversion ${db2.packversion} -bindoptions "ISOLATION (CS)" -genDBRM -DBRMDir DBRMLIB -singlepkgname ${db2.pack}
DB2 utilise généralement un a module d'interrogation de base de données (ou module DBRM) pour la liaison. Le module DBRM est généré par la commande db2sqljcustomize lorsque l'option gendbrm est fournie. Sans cette option, la commande suppose que vous souhaitez effectuer la liaison via des profils sérialisés et ne génère pas de module DBRM.
Si vous indiquez ce paramètre, SCLM Developer Toolkit utilise les modules d'interrogation de base de données et les enregistre dans SCLM pour une utilisation future. Cette technique présente l'avantage de pouvoir facilement effectuer une liaison DB2 dans un exit utilisateur SCLM, tel que l'exit de génération/copie.
Etant donné qu'une liste d'objets mis à jour est automatiquement fournie pour un exit de génération/copie, vous pouvez lier à nouveau de manière sélective uniquement les modules qui ont été modifiés, ce qui évite l'inefficacité via la liaison redondante.
Quatre étapes sont requises pour la configuration de la liaison des systèmes de gestion de bases de données relationnelle :
<!-- specify global property arguments below for sqlj processing --> <property name="sqlj.arg" value="-compile=false -status -linemap=no"/>
Argument | Description |
---|---|
compile=false | Si cette option a la valeur false, le traducteur sqlj ne peut pas compiler automatiquement la source Java qu'il génère. SCLM Developer Toolkit utilisant le source généré dans sa propre procédure de génération, il est recommandé de toujours spécifier la valeur false. |
linemap=no | Spécifie si les numéros de ligne des exceptions Java correspondent aux numéros de ligne des fichiers source SQLJ (fichier .sqlj) ou du fichier source Java généré par les fichiers du traducteur SQLJ (fichier .java). Un fichier .class étant pour cela requis, cette option doit avoir la valeur no lorsqu'elle est utilisée avec compile=false. |
status | Imprime l'écran d'état immédiat du traitement SQLJ. |
<property name="db2sqljcust.arg" Value='-automaticbind NO -onlinecheck YES -bindoptions "ISOLATION(CS)" -gendbrm'/>
Argument | Description |
---|---|
automaticbind no | Si cette option a la valeur no, le personnaliseur n'effectue pas de liaison une fois la personnalisation terminée. |
onlinecheck yes | Effectue une vérification en ligne sur le système spécifié par le paramètre url. La valeur par défaut est yes si url est fourni et no dans le cas contraire. |
Bindoptions ISOLATION(CS) | Demande au programme de liaison de créer un seul package (lecture non reproductible). Option utilisée avec singlepkgname (défini de manière dynamique). |
gendbrm | Demande au personnaliseur de générer des fichiers DBRM. |
Définissez l'emplacement de votre programme utilisateur dans BWBSQLB. Indique au processus de génération où trouver le script rex permettant de calculer les propriétés dynamiques.
La propriété importante que nous souhaitons configurer de manière dynamique est singlepkgname. Il s'agit du nom du package cible de la liaison. Chaque programme possède son propre nom de package unique qui, dans cet exemple simple, correspond aux huit premières lettres du nom du programme.
Comme nous utilisons singlepkgname dans l'étape de personnalisation, le nom du package est identique au nom du module DBRM.
La nouvelle approche recommandée pour la liaison des programmes SQLJ consiste à utiliser les profils sérialisés (fichiers .ser) pour effectuer la liaison. Cela était inévitable car le profil sérialisé effectue la même fonction que le module DBRM : fournir une image sérialisée des instructions du programme.
En modifiant légèrement le script de génération BWBSQLB, vous pouvez configurer SCLM Developer Toolkit pour qu'il utilise cette méthode à la place. Il s'agit simplement d'une question de modification des arguments fournis à db2sqljcustomize pour supprimer le commutateur de ligne de commande gendbrm et affecter à automaticbind la valeur YES.
Trois étapes sont requises pour la configuration de la liaison des profils sérialisés :
Il n'existe pas d'arguments de ligne de commande pour le traducteur sqlj qui sont réservés à la liaison des profils sérialisés. Toutefois, les arguments définis pour cet exemple particulier sont illustrés.
<!-- specify global property arguments below for sqlj processing --> <property name="sqlj.arg" value="-compile=false -status -linemap=no"/>
Argument | Description |
---|---|
compile=false | Si cette option a la valeur false, le traducteur sqlj ne peut pas compiler automatiquement la source Java qu'il génère. SCLM Developer Toolkit utilisant le source généré dans sa propre procédure de génération, il est recommandé de toujours spécifier la valeur false. |
linemap=no | Spécifie si les numéros de ligne des exceptions Java correspondent aux numéros de ligne des fichiers source SQLJ (fichier .sqlj) ou du fichier source Java généré par les fichiers du traducteur SQLJ (fichier .java). Un fichier .class étant pour cela requis, cette option doit avoir la valeur no lorsqu'elle est utilisée avec compile=false. |
status | Imprime l'écran d'état immédiat du traitement SQLJ. |
<property name="db2sqljcust.arg" Value='-automaticbind YES -onlinecheck YES'/>
Argument | Description |
---|---|
automaticbind yes | Si cette option a la valeur yes, le personnaliseur effectue également la liaison une fois la personnalisation terminée. Si elle a la valeur no, la liaison doit être effectuée de manière distincte, à l'aide de la commande db2bind. |
onlinecheck yes | Effectue une vérification en ligne sur le système spécifié par le paramètre url. La valeur par défaut est yes si url est fourni et no dans le cas contraire. |
Définissez l'emplacement de votre programme utilisateur dans BWBSQLB. Indique au processus de génération où trouver le script rex permettant de calculer les propriétés dynamiques.
<property name="db2sqljcust.userpgm" value="/u/dba/sqljcust.rex"/>
SCLM Developer Toolkit offre des fonctionnalités de sécurité facultatives pour les fonctions de génération, de promotion et de déploiement.
Vous pouvez définir une option de sécurité de génération, de promotion ou de déploiement dans les fichiers de configuration du SITE/PROJET. Pour en savoir plus sur les fichiers de configuration du SITE/PROJET, voir Options spécifiques au projet et SITE. Les instructions suivantes contrôlent l'option de sécurité des fonctions de génération, promotion et déploiement, respectivement :
La sécurité des fonctions de génération, de promotion et de déploiement SCLM utilise l'interface de sécurité SAF/RACROUTE, qui est prise en charge par tous les principaux produits de sécurité.
Les exemples de commande répertoriés concernent RACF. Si vous utilisez un autre produit, reportez-vous à la documentation de votre produit de sécurité.
L'administrateur de la sécurité définit les profils requis dans la classe XFACILIT à l'aide de la commande RDEFINE et en permet l'accès à l'aide de la commande PERMIT. Pour savoir quels profils doivent être définis, voir tableau 11.
Fonction | Profil XFACILIT | Droit d'accès requis |
---|---|---|
Génération | SCLM.BUILD.project.projdef.group.type.member | READ |
Promotion | SCLM.PROMOTE.project.projdef.group.type.member | READ |
Déploiement | SCLM.DEPLOY.server.application.node.cell.project.projdef.group.type | READ |
La liste ci-après décrit la signification des différents noms de section de profil :
SCLM | Constante ; indique un profil de fonction SCLM |
GENERER | Constante ; indique la fonction GENERER |
REMONTER | Constante ; indique la fonction REMONTER |
DEPLOYER | Constante ; indique la fonction DEPLOYER |
projet | Nom du projet SCLM ou * pour tous les projets |
définition de projet | Autre nom de projet (correspond au nom de projet par défaut) ou * pour tous les autres projets |
Groupe | Groupe SCLM à générer/promouvoir/déployer ou * pour tous les groupes |
Type | Type SCLM ou * pour tous les types |
Membre | Membre SCLM à générer/promouvoir ou * pour tous les membres |
Serveur | Serveur de déploiement cible (SERVER_NAME dans le script de déploiement Ant) ou * pour tous les serveurs |
Application | Nom de l'application WAS cible (APPLICATION_NAME dans le script de déploiement Ant) ou * pour toutes les applications |
Noeud | Nom du noeud WAS cible (NODE_NAME dans le script de déploiement Ant) ou * pour tous les noeuds |
Cellule | Nom de la cellule WAS cible (CELL_NAME dans le script de déploiement Ant) ou * pour toutes les cellules |
Les fonctions de génération, promotion et déploiement prennent en charge l'utilisation d'un ID utilisateur de substitution pour exécuter la fonction. S'il est activé, tous les appels autorisés vers la fonction entraîneront l'exécution de cette dernière avec les droits de l'ID utilisateur de substitution et non de l'ID utilisateur demandeur.
L'activation de l'ID utilisateur de substitution est spécifique au profil et contrôlée par la chaîne "SUID=userid" dans la zone APPLDATA du profil de sécurité, userid correspondant à l'ID utilisateur de substitution. Si cette chaîne est présente, l'ID utilisateur de substitution est utilisé ; si elle n'est pas présente, l'ID utilisateur du demandeur est utilisé.
Cet exemple répertorie les définitions de produit de sécurité requises pour protéger la fonction de génération d'un projet donné. Le même exemple peut être utilisé pour sécuriser la fonction de promotion, en remplaçant la règle SCLM.BUILD.* par la règle SCLM.PROMOTE.*.
La définition de profil ci-après sécurise tous les membres du projet intégré TESTPROJ au niveau du groupe PROD. Un ID utilisateur de substitution est également défini.
RDEFINE XFACILIT SCLM.BUILD.TESTPROJ.TESTPROJ.PROD.*.* UACC(NONE) APPLDATA('SUID=IBMUSER') SETROPTS RACLIST(XFACILIT) REFRESH
Cet exemple définit un profil de génération SCLM où :
L'exemple ci-après illustre les droits de sécurité définis pour les utilisateurs (ou les groupes d'utilisateurs) du projet TESTPROJ de l'exemple précédent :
PERMIT SCLM.BUILD.TESTPROJ.TESTPROJ.PROD.*.* CLASS(XFACILIT) ID(USERID) ACCESS(READ)
La commande PERMIT correspond au profil RDEFINE d'origine et autorise l'utilisateur USERID à générer tout membre du projet TESTPROJ et du groupe PROD. Comme un ID utilisateur de substitution est stocké dans la zone des données d'application (APPLDATA) du profil correspondant, la GENERATION est effectuée sous cet ID utilisateur de substitution (dans le cas présent).
Vous trouverez ci-après un exemple de création de profil de déploiement.
RDEFINE XFACILIT SCLM.DEPLOY.SERVERY.TESTAPP.NODE1.CELL1.TESTPROJ.TESTPROJ.PROD.J2EEDEP UACC(NONE)
Détails WAS :
Détails du projet SCLM :
Autres informations :
L'exemple ci-après illustre les droits de sécurité définis pour un groupe d'utilisateurs pour le profil de déploiement précédemment défini :
PERMIT SCLM.DEPLOY.SERVERY.TESTAPP.NODE1.CELL1.TESTPROJ.TESTPROJ.PROD.J2EEDEP CLASS(XFACILIT) ID(J2EEGRP) ACCESS(READ)
Cela correspond au profil RDEFINE d'origine et permet à tout utilisateur du groupe RACF J2EEGRP d'effectuer un déploiement sur le serveur ci-dessus et à partir des mêmes détails de projet SCLM.
Bien que la plupart des générations et promotions soient lancées via le client Developer Toolkit, il existe une disposition permettant de configurer les fichiers de promotion et de génération dans le système de fichiers z/OS UNIX System Services et de lancer ces générations ou compilations via le service CRON (time) dans UNIX System Services.
A l'aide de cette méthode, le client SCLM Developer Toolkit Client n'est pas nécessaire car les paramètres de promotion et de génération associés sont lus à partir d'un fichier de configuration du système de fichiers z/OS UNIX System Services et transmis au composant Developer Toolkit Host pour le traitement SCLM.
Ci-dessous figure une description des exemples SCLM Developer Toolkit qui fournissent des générations et des promotions lancées par CRON. Ces exemples sont disponibles dans le répertoire des exemples de Developer for System z, /usr/lpp/rdz/samples/. Une copie, qui doit être personnalisée en fonction de vos besoins, a été placée dans /etc/rdz/sclmdt/script/ lors de la personnalisation de Developer for System z.
Les variables PATH et STEPLIB dans le profil système (/etc/profile) ou le profil utilisateur (/u/userid/.profile) devront être configurées pour localiser les travaux CRON ($PATH) ainsi que les modules de chargement SCLM Developer Toolkit ($STEPLIB) si les modules de chargement SCLM Developer Toolkit ne résident pas dans le LINKLIST. Exemple :
PATH=/etc/rdz/sclmdt/script:$PATH STEPLIB=FEK.SFEKLOAD:FEK.SFEKAUTH:$STEPLIB
Une fois que les travaux CRON ont été ajoutés à la variable PATH, ils peuvent être exécutés en transmettant la sortie de parameter_exec à processing_exec. La sortie peut être envoyée dans un fichier journal de sortie.
Syntaxe
parameter_exec | processing_exec > output.log
Le signe "|" correspond au symbole de barre verticale de z/OS UNIX.
Exemple d'appel
A l'aide des exemples de nom fourni, l'exécutable de génération CRON peut être appelé comme suit ($ représente l'invite z/OS UNIX) :
$ BWBCRONB | BWBCRON1 > $HOME/bwbcronb.log 30 19 * * 1-5 BWBCRONB | BWBCRON1 > /u/userid/bwbcronb.log ;
Pour plus d'informations sur les services CRON disponibles et le format CRONTAB, voir UNIX System Services Command Reference (SA22-7802) et UNIX System Services Planning (GA22-7800).
Vous pouvez également utiliser la commande z/OS UNIX en ligne, man :
Cette section illustre les exemples de travaux BWBCRON1, BWBCRONB, BWBCRONP fournis dans la bibliothèque SFEKSAMV.
L'exemple suivant montre le code BWBCRON1.
/* REXX */ /* Customize STEPLIB, _SCLMDT_CONF_HOME and _SCLMDT_WORK_HOME */ /* The STEPLIB should reflect the load libraries for Rational Developer for System z. If these datasets resides in the LINKLIST then set STEPLIB to '' . */ STEPLIB = 'FEK.SFEKLOAD:FEK.SFEKAUTH' /* The Environment variables _SCLMDT_CONF_HOME and _SCLMDT_WORK_HOME determines the HOME directories where the configuration files and workarea reside for SCLM Developer Toolkit. Refer to the Rational Developer for System z configuration file /etc/rdz/rsed.envvars for the correct value. */ _SCLMDT_CONF_HOME = '/etc/rdz/sclmdt' _SCLMDT_WORK_HOME = '/var/rdz' /* SAMPLE USEAGE */ COMMAND : BWBCRONB|BWBCRON1 > BWBCRONB.log (passes build parameter list to BWBCRON1 & outputs to BWBCRONB.log) */ /* DO NOT ALTER BELOW */ CALL ENVIRONMENT 'STEPLIB',STEPLIB CALL ENVIRONMENT '_SCLMDT_CONF_HOME',_SCLMDT_CONF_HOME CALL ENVIRONMENT '_SCLMDT_WORK_HOME',_SCLMDT_WORK_HOME CALL BWBINT EXIT
L'exemple suivant montre le code BWBCRONB.
/* REXX */ /* SAMPLE BUILD PARAMETER FILE USED FOR CRON INITIATED BUILDS */ /* Update Build parameters below */ /* if parameter required as Blank then set as '' */ FUNCTION = 'BUILD' PROJECT = '' /* SCLM Project */ PROJDEF = '' /* Alt proj definition */ TYPE = '' /* SCLM Type */ MEMBER = '' /* SCLM Member name */ GROUP = '' /* SCLM Group */ GROUPBLD = '' /* Build at Group */ REPDGRP = '' /* Users Development group */ BLDREPT = 'Y' /* Generate Build report */ BLDLIST = 'Y' /* Generate List on error */ BLDMSG = 'Y' /* Generate Build Messages */ BLDSCOPE = 'N' /* Build Scope E/L/N/S */ BLDMODE = 'C' /* Build Mode C/F/R/U */ BLDMSGDS = '' /* Message dataset */ BLDRPTDS = '' /* Report dataset */ BLDLSTDS = '' /* list dataset */ BLDEXTDS = '' /* Exit dataset */ SUBMIT = 'BATCH' /* Online or Batch */ /* SI exécution en mode BATCH et JCL JOBCARD requis pour remplacer la valeur par défaut, ajoutez jusqu'à 4 lignes JOBCARD. Spécifiez au format LINE et incluez la variable LINECNT pour le nombre de lignes. */ LINECNT = 2 LINE.1 = '//SCLMBLD JOB (XXX),SCLMBUILD,MSGCLASS=X,NOTIFY=&SYSUID,' LINE.2 = '// CLASS=A,REGION=0M' /* DO NOT ALTER PARM BUILD VARIABLE BELOW */ PARM1 = 'SCLMFUNC='FUNCTION'&PROJECT='PROJECT'&PROJDEF='PROJDEF||, '&TYPE='TYPE'&MEMBER='MEMBER'&GROUP='GROUP'&GROUPBLD='GROUPBLD||, '&REPDGRP='REPDGRP'&BLDREPT='BLDREPT'&BLDLIST='BLDLIST||, '&BLDMSG='BLDMSG'&BLDSCOPE='BLDSCOPE'&BLDMODE='BLDMODE||, '&BLDMSGDS='BLDMSGDS'&BLDRPTDS='BLDRPTDS'&BLDLSTDS='BLDLSTDS||, '&BLDEXTDS='BLDEXTDS'&SUBMIT='SUBMIT /* outputs parameter string as input to BWBCRON1 */ SAY PARM1 If (SUBMIT = 'BATCH') & (LINECNT > 0) then Do SAY '<JOBCARD>' Do i = 1 to LINECNT SAY LINE.i End SAY '</JOBCARD>' Fin
L'exemple suivant montre le code BWBCRONP.
/* SAMPLE PROMOTE PARAMETER FILE USED FOR CRON INITIATED PROMOTES */ /* Update Promote parms below in quotes. */ /* if parameter required as Blank then set as '' */ FUNCTION = 'PROMOTE' PROJECT = '' /* SCLM Project */ PROJDEF = '' /* Alt proj definition(opt) */ TYPE = '' /* SCLM Type */ MEMBER = '' /* SCLM Member name */ GROUP = '' /* SCLM Group */ GROUPPRM = '' /* Promote at Group (opt) */ REPDGRP = '' /* Users Development group */ PRMREPT = 'Y' /* Generate Promote report */ PRMMSG = 'Y' /* Generate Promote Messages*/ PRMSCOPE = 'N' /* Promote Scope E/L/N/S */ PRMMODE = 'C' /* Promote Mode C/F/R/U */ PRMMSGDS = '' /* Message dataset */ PRMRPTDS = '' /* Report dataset */ PRMEXTDS = '' /* Exit dataset */ SUBMIT = 'BATCH' /* Online or Batch */ /* SI exécution en mode BATCH et JCL JOBCARD requis pour remplacer la valeur par défaut, ajoutez jusqu'à 4 lignes JOBCARD. Spécifiez au format LINE et incluez la variable LINECNT pour le nombre de lignes. */ LINECNT = 2 LINE.1 = '//SCLMBLD JOB (XXX),SCLMBUILD,MSGCLASS=X,NOTIFY=&SYSUID,' LINE.2 = '// CLASS=A,REGION=0M' /* DO NOT ALTER PARM PROMOTE VARIABLE BELOW */ PARM1 = 'SCLMFUNC='FUNCTION'&PROJECT='PROJECT'&PROJDEF='PROJDEF||, '&TYPE='TYPE'&MEMBER='MEMBER'&GROUP='GROUP'&GROUPPRM='GROUPPRM||, '&REPDGRP='REPDGRP'&PRMREPT='PRMREPT||, '&PRMMSG='PRMMSG'&PRMSCOPE='PRMSCOPE'&PRMMODE='PRMMODE||, '&PRMMSGDS='PRMMSGDS'&PRMRPTDS='PRMRPTDS'&PRMEXTDS='PRMEXTDS||, '&SUBMIT='SUBMIT /* outputs parameter string as input to BWBCRON1 */ SAY PARM1 If (SUBMIT = 'BATCH') & (LINECNT > 0) then Do SAY '<JOBCARD>' Do i = 1 to LINECNT SAY LINE.i End SAY '</JOBCARD>' Fin
SCLM Developer Toolkit, une fonction d'IBM Rational Developer for System z, offre les moyens permettant de gérer et générer les applications distribuées écrites dans Eclipse, à l'aide de SCLM (Software Configuration and Library Manager), le système de gestion du code source IBM z/OS.
Les langages et outils utilisés par les utilisateurs de grands systèmes et de systèmes distribués diffèrent autant que les environnements qu'ils emploient. En identifiant et assimilant les principaux concepts de ces environnements, il est possible de les intégrer correctement dans une structure cohésive.
En termes de structure d'application, SCLM Developer Toolkit est constitué d'un ensemble de plug-ins Eclipse et du code hôte z/OS correspondant qui permet d'utiliser les transports HTTP et RSE. Au niveau opérations, un développeur Eclipse enregistre un projet d'espace de travail dans SCLM. Les fichiers du projet peuvent être ajoutés à un projet SCLM, extraits et restitués et éventuellement créés et déployés. Tous ces services sont pilotés via le menu Team Actions. Du point de vue des administrateurs SCLM, ces derniers peuvent créer des projets, des types, des langages et les traducteurs de compilations associés. Les fonctions, telles que les codes de modification et d'autorisation dépendent des besoins.
Du point de vue d'un développeur Java/J2EE, les concepts suivants décrivent SCLM :
Le système de fichiers z/OS ne prend en charge que les noms de fichier de huit caractères. L'interface de SCLM Developer Toolkit fournit un service de traduction qui prend en charge les conventions des noms longs Java. Certains fichiers spécifiques à SCLM doivent respecter la restriction sur la règle de dénomination. Il s'agit principalement des restrictions sur la structure de l'ARCHDEF, décrite dans Format d'ARCHDEF J2EE.
Chaque fichier (ou membre selon la terminologie SCLM) stocké dans un projet SCLM est stocké dans un fichier. Ce dernier est identifié par le type SCLM. Le type fait partie du nom de fichier, constitué de SCLM Project.Group.Type pour SCLM, et associé à un langage. De nombreux types peuvent être définis dans un projet SCLM. Ces types permettent de stocker deux fichiers de même nom dans le même projet SCLM. Chaque projet peut contenir de nombreux types. En appliquant l'utilisation du type, il est possible de stocker plusieurs projets Eclipse dans le projet SCLM, bien que chaque projet IDE possède éventuellement un fichier .project et un fichier .classpath. Si nous n'isolons pas ces fichiers à l'aide du type, il n'existe qu'une seule copie de ces fichiers dans SCLM.
L'administrateur SCLM est chargé de définir les types SCLM. Lorsque vous partagez un projet à l'aide de SCLM, vous devez connaître le type à utiliser lors du stockage des objets dans SCLM.
Lorsque vous ajoutez un fichier à SCLM, vous devez le stocker avec une certaine définition de langage. L'administrateur SCLM est là aussi chargé de définir les langages. Cette définition contrôle le comportement de SCLM lorsque les fichiers sont transférés vers et depuis le système hôte. A l'aide de la définition de langage, il est possible de déterminer si un certain type de fichier est traduit en nom long, stocké sous forme d'objet binaire ou traduit en ASCII ou EBCDIC (codage z/OS natif). Par exemple, la définition de langage JAVABIN peut faire référence à un objet binaire traduit en nom long. Il est également possible de définir WEBHTML comme représentant un fichier texte traduit en nom long à stocker en ASCII. Le nombre de définitions de langage est défini par projet. Il est nécessaire de savoir quel langage utiliser pour s'assurer que le fichier est stocké correctement dans SCLM et qu'il peut en être extrait. Le langage définit également la manière dont SCLM crée un objet.
Tout fichier sous le contrôle de SCLM est associé à un certain nombre de propriétés. Ces propriétés correspondent en fait au mécanisme de mappage entre le fichier IDE et les propriétés SCLM correspondantes. Lorsque des appels de service sont envoyés à SCLM, ces données sont lues pour formuler les paramètres de service appropriés. Vous pouvez afficher ces paramètres à partir du menu Propriétés lorsque vous sélectionnez un membre contrôlé par SCLM à partir d'Eclipse.
Lorsque vous partagez un projet à l'aide de SCLM, vous devez également spécifier à quel groupe de développement vous appartenez. Les structures de projet SCLM se présentent sous forme d'arborescence.
A l'origine, le code est stocké au niveau DEVELOPPEMENT. Une fois qu'il a été créé et testé, il peut passer au niveau TEST. Enfin, une fois que les tests ont abouti, il peut passer au niveau PRODUCTION. Cela représente généralement le produit développé. Si un incident est détecté dans le code au niveau production, les fichiers à éditer pour résoudre l'incident sont copiés au niveau développement et la procédure de création est recommencée. Seule une partie du code qui constitue l'application est copiée au niveau développement. SCLM effectue le suivi des éléments qui compose la compilation et du niveau auquel ces éléments sont stockés.
Le niveau Développement peut comporter plusieurs groupes. Cela permet de séparer le code stocké au niveau développement. SCLM offre également des paramètres permettant de déterminer le comportement du code stocké dans les différents groupes de développement en terme de possibilités de promotion.
La structure du projet IDE se compose généralement d'un ou plusieurs projets IDE. En stockant chacun de ces projets IDE dans un type SCLM différent, cette structure est conservée. Le fichier ARCHDEF définit ensuite les fichiers qui constituent un projet IDE. Chaque projet SCLM peut posséder plusieurs ARCHDEF. Une ARCHDEF peut faire référence à d'autres ARCHDEF pour que cette structure à plusieurs projets IDE puisse être définie dans la procédure de création, l'ARCHDEF représentant le moyen principal de définir une liste de compilations pour SCLM. Une procédure de création en représente l'analogie la plus proche. L'ARCHDEF répertorie les fichiers qui constituent la compilation et spécifie un script de création qui permet d'indiquer l'emplacement des classes ou des fichiers JAR externes. Pour plus d'informations, reportez-vous à la section relative au Guide d'utilisation, dans le système d'aide en ligne.
Lorsqu'un projet IDE est créé dans l'espace de travail, un fichier de description de projet est automatiquement généré et stocké sous le nom .project. Ce document XML contient les descriptions des 'générateurs' ou 'natures' associés au projet. Les 'générateurs' sont des générateurs de projets incrémentiels qui créent un état de création en fonction du contenu du projet. Lorsque le contenu du projet est modifié, ce fichier est mis à jour.Les 'natures' définissent et gèrent l'association entre un projet spécifique et une fonction ou un plug-in particulier.
Le fichier .classpath décrit le chemin d'accès permettant de rechercher les classes et les fichiers jar externes auxquels le code source de votre projet IDE fait référence. La fonction équivalente lors d'une création via SCLM Developer est définie avec l'instruction CLASSPATH_JARS dans les scripts de création Ant. Cette instruction décrit le chemin d'accès sur l'hôte z/OS permettant de rechercher les classes et les fichiers jar externes auxquels le code source de votre projet IDE fait référence.
Les fichiers .classpath et .project sont tous deux utilisés pour préserver la configuration de votre projet IDE pour que ce dernier puisse être recréé dans un autre espace de travail. Pour cette raison, il est recommandé qu'ils soient tous deux restitués dans SCLM comme partie intégrante du projet IDE.
Le développement de projets présente un aspect important, surtout dans les projets J2EE : il est possible de créer différentes formes d'exécutable d'application. Les fichiers exécutables des projets Java sont souvent fournis sous forme de fichiers JAR, WAR, RAR ou EAR.
Les fichiers JAR sont généralement associés à des applications Java standard ou des EJB (Enterprise Java Bean).
Les fichiers WAR sont créés pour les applications Web. Ils sont en général composés de servlets Java, de fichiers JSP et de fichiers HTML. Les applications WAR représentent souvent applications le premier niveau des applications Web. Ces applications peuvent faire référence à d'autres fichiers JAR, tels que des EJB pour des services spécifiques. Chaque fichier WAR contient un fichier web.xml. Ce fichier décrit la composition de l'application WAR en termes de Java, HTML et de services de bibliothèque qu'il utilise.
Le développement des fichiers RAR n'est actuellement pas pris en charge dans SCLM Developer Toolkit.
Les fichiers EAR représentent les applications d'entreprise. Ces applications sont composées de fichiers JAR et WAR. En langage J2EE, la création du fichier EAR correspond à l'assemblage de ses fichiers JAR et WAR constituants. Cette méthode d'assemblage permet de créer des applications EAR qui sont en fait constituées de composants spécifiques (JAR/WAR). La véritable composition de l'application est décrite dans le fichier application.xml. Le fichier EAR lui-même n'est pas un objet exécutable autonome. Il doit être installé dans un conteneur J2EE tel que WAS (Websphere Application Server). L'installation du fichier EAR est appelé déploiement. Il est possible d'accéder à une application EAR déployée via l'environnement WAS. Le déploiement est une procédure distincte de la création. Il implique l'installation physique de l'application EAR.
Le développement d'applications J2EE risque donc d'impliquer le développement d'un certain nombre de composants distincts, tels que des fichiers WAR et JAR. Ces fichiers sont ensuite assemblés dans un fichier EAR. Le fichier EAR est alors prêt à être déployé dans un conteneur J2EE (par exemple, WAS) pour être utilisé.
Dans l'espace de travail Eclipse, les projets sont en réalité assez proches ; dans l'environnement IDE, ils peuvent en fait faire facilement référence à d'autres projets IDE en termes de conditionnement. Dans SCLM, chacun de ces projets IDE (par exemple, les projets WAR, JAR et EAR) doivent être mappés dans un même projet SCLM, chaque projet étant différencié via l'utilisation d'un type SCLM différent. En effet, des noms de fichier communs étant utilisés dans de nombreux projets IDE, tels que des fichiers .project, .classpath, web.xml et application.xml, l'utilisation de types distincts permet à des composants de même nom de coexister dans un même projet SCLM. Pour plus d'informations sur le mappage, voir Mappage de projets J2EE à SCLM.
Du point de vue de SCLM, il est préférable de référencer le développement de l'application EAR par l'intermédiaire d'une structure ARCHDEF de haut niveau. Dans SCLM, les ARCHDEF de haut niveau, appelés package dans de nombreux projets SCLM, représentent l'apex de la structure des ARCHDEF, qui est suivi de l'application EAR et des références de niveau inférieur (fichiers WAR et JAR) qui constituent l'application EAR. Cette structure permet l'utilisation de compilations aux niveaux supérieurs et inférieurs, ainsi que l'utilisation de compilations intégrales ou conditionnelles. Les ARCHDEF permettent donc également de définir les éléments du projet J2EE dans le projet SCLM.
Actuellement, le noyau de SCLM ne prend pas en charge l'utilisation du stockage du code avec des noms supérieurs à huit caractères.
Les codes, tels que les codes Java et les autres codes de client PC, possèdent de par leur nature des noms de longueur bien supérieure et incorporent même des informations sur le chemin d'accès (conditionnement) dans leur nom. Ainsi, le code dont certaines parties possèdent des noms de plus de huit caractères doit passer par un utilitaire de conversion de nom long/abrégé pour que ces parties puissent être stockées dans SCLM sous un nom de huit caractères ou moins.
Une table de traduction des noms longs en noms abrégés stocke les noms longs (noms réels) correspondant aux noms abrégés (tels qu'ils sont stockés dans SCLM). SCLM accède à ces tables, qui sont sauvegardées dans un fichier VSAM, et les contrôle. Cette fonction est apparue dans SCLM avec la PTF de l'APAR OA11426 pour z/OS 1.4 et les versions ultérieures. Pour z/OS 1.8 et les versions ultérieures, cette PTF n'est pas requise.
L'algorithme de conversion suit les étapes suivantes :
Exemple
Nom long | Nom abrégé dans le fichier partitionné ou le fichier partitionné étendu SCLM |
---|---|
com/ibm/workbench/testprogram.java | TE000001 |
source/plugins/Phantom/.classpath | XX000001 |
Le programme SCLM FLMLSTRN a été créé pour lire et mettre à jour la table de traduction VSAM. SCLM Developer Toolkit utilise ce programme pour lire et mettre à jour les noms longs et les noms abrégés en corrélation.
Le fichier VSAM permettant de stocker la table de traduction est un fichier KSDS de longueur variable pour lequel un chemin d'accès et un index secondaire sont définis. Un exemple de travail est fourni dans SCLM pour allouer ce fichier VSAM.
La structure interne du cluster VSAM est la suivante :
1 ls_record, 3 ls_short_name char(08), 3 ls_lngname_key char(50), 3 ls_long_name char(1024);
Vous trouverez un exemple de JCL permettant d'allouer le fichier VSAM de traduction des noms longs/abrégés à l'étape 6, relative à la configuration du fichier VSAM de traduction des noms longs/abrégés.
Le programme FLMLSTRN est appelé à l'aide du service ISPF SELECT avec l'un des paramètres répertoriés dans le tableau 12.
Syntaxe :
"SELECT PGM(FLMLSTRN) PARM(keyword)"
Exemple d'appel :
"SELECT PGM(FLMLSTRN) PARM(TRANSLATE)"
Enregistrement du mot clé | Traitement | Description |
---|---|---|
FINDLONG | Unique | Recherche un nom long pour un nom abrégé donné |
FINDSHORT | Unique | Recherche un nom abrégé pour un nom long donné |
TRANSLATE | Unique | Recherche un nom abrégé s'il existe ou affecte un nouveau nom abrégé dans le cas contraire |
MIGRATE | Multiple | Recherche plusieurs noms longs |
IMPORT | Multiple | Recherche plusieurs noms abrégés |
Le traitement est identique à celui de FINDSHORT :
Les fonctions MIGRATE et IMPORT ont été introduites pour améliorer les performances lors de la traduction d'un nombre important de noms longs traduits (MIGRATE) ou de la recherche d'un nombre important de noms abrégés (IMPORT).
Ces deux fonctions, "MIGRATE" et "IMPORT", lisent un fichier séquentiel bloqué par variable avec LRECL=1036, qui est alloué comme DD LSTRNPRC.
Avant d'être appelé, ce fichier contient les noms abrégés ou les noms longs, suivant la fonction appelée, dans la colonne et au format appropriés.
Après avoir été appelé, LSTRNPRC contient le nom abrégé et le nom long associé.
Le format du fichier est le suivant :
1 pr_record, 3 pr_short_name char(08), 3 pr_long_name char(1024);
Voici un exemple de code REXX permettant d'appeler la procédure de traduction des noms longs/abrégés.
/* REXX **************************************************************/ /* Sample to translate long name to a short name */ /*********************************************************************/ Address TSO "FREE FI(LSTRANS)" "FREE FI(LSTRNPTH)" "ALLOC DD(LSTRANS) DA('FEK.#CUST.LSTRANS.FILE') SHR REUSE" "ALLOC DD(LSTRNPTH) DA('FEK.#CUST.LSTRANS.FILE.PATH') SHR REUSE" /* Create short name for long name com/ibm/phantom.txt */ FLMLSLNG = "com/ibm/phantom.txt" Address ISPEXEC "VPUT (FLMLSLNG) PROFILE" Address ISPEXEC "SELECT PGM(FLMLSTRN) PARM(TRANSLATE)" LSRC=RC If LSRC > 0 Then Do Address ISPEXEC "VGET (FLMLSERR,FLMLSER1) PROFILE" Say "LS ERROR LINE 1 ==>" FLMLSERR Say "LS ERROR LINE 2 ==>" FLMLSER1 Return End Else Do Address ISPEXEC "VGET (FLMLSSHR,FLMLSLNG) PROFILE" Say " Shortname = " FLMLSSHR Say " Longname = " FLMLSLNG End Address TSO "FREE FI(LSTRANS)" "FREE FI(LSTRNPTH)"
Cette annexe présente l'API des services hôte de SCLM Developer Toolkit. Elle utilise un format de demandes et réponses basé XML et est accessible via le système de fichiers z/OS UNIX Systems Services.
Cette API permet aux utilisateurs d'utiliser les services hôte de SCLM Developer Toolkit avec leurs propres client/plug-in et couche de transport s'ils le souhaitent.
Un exemple de programme Java (avec entrée et sortie) est fourni, qui permet d'accéder à l'API des services hôte de SCLMDT à l'aide d'un serveur HTTP comme mécanisme de transport.
La plupart des demandes de fonction reposent sur les services hôte SCLM actuels et vous trouverez des informations supplémentaires sur les valeurs de paramètre similaires pour les fonctions communes dans le guide SCLM et le guide de référence de la version z/OS appropriée.
L'exemple de commande suivante illustre comment les services hôte de SCLMDT peuvent être appelés :
cat sclmdt_request.xml | BWBXML > sclmdt_response.xml
cat | Commande z/OS UNIX permettant d'afficher les fichiers texte |
sclmdt_request.xml | Fichier XML en entrée avec la demande utilisateur |
| | Commande z/OS UNIX permettant de transférer la sortie de la commande précédente comme entrée de la commande suivante |
BWBXML | Script de conversion XML, qui se trouve dans le répertoire /bin de Developer for System z, qui appelle l'interface de service SCLMDT |
> | Commande z/OS UNIX permettant de rediriger la sortie de la commande précédente vers un fichier |
sclmdt_response.xml | Fichier XML en sortie, contenant la réponse du service |
export PATH=/usr/lpp/rdz/bin:$PATH
L'exemple ci-après montre le schéma XML des commandes SCLMDT référencées dans le fichier en entrée XML. Cet exemple est également disponible comme membre BWBXSD1 dans l'exemple de bibliothèque FEK.SFEKSAMV.
<?xml version="1.0" encoding="ISO-8859-1" ?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="SCLMDT-INPUT"> <xs:complexType> <xs:all> <xs:element name="SERVICE-REQUEST"> <xs:complexType> <xs:all> <xs:element name="service"> <xs:simpleType> <xs:restriction base="xs:string"> <!-- Specifies native TSO or ISPF service call --> <xs:enumeration value="ISPF"/> <xs:enumeration value="TSO"/> <xs:enumeration value="SCLM"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="session" minOccurs="0"> <xs:simpleType> <xs:restriction base="xs:string"> <!-- Default NONE : Session terminates after service call--> <xs:enumeration value="NONE"/> <!-- Reuseable ISPF session stays active between calls --> <xs:enumeration value="REUSE"/> </xs:restriction> </xs:simpleType> </xs:element> <!-- Use existing ISPF profile in call --> <xs:element name="ispprof" type="xs:string" minOccurs="0"/> <!-- Free form TSO/ISPF command --> <xs:element name="command" type="xs:string" minOccurs="0"/> <!-- List of all SCLM DT functions available --> <!-- sclmfunc : SCLM function selected --> <xs:element name="sclmfunc" minOccurs="0"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="BUILD"/> <!-- SCLM build function--> <!-- Build parms : project,projdef,group,repdgrp,type,member,bldmode,bldlist, bldrept,bldmsg,bldmsgds,bldlist,bldlstds,bldextds,groupbld,submit --> <xs:enumeration value="PROMOTE"/> <!-- SCLM promote function --> <!-- Promote parms : project,projdef,group,repdgrp,type,member,prmmode,prmrept, prmmsg,prmsgds,prmextds,groupprm,submit --> <xs:enumeration value="EDIT"/> <!-- EDIT member --> <!-- Edit parms : project,projdef,group,repdgrp,type,member,lang --> <!-- Note: member transferred to DTinstall/WORKAREA --> <xs:enumeration value="BROWSE"/> <!-- Browse member --> <!-- Browse parms : project,projdef,group,repdgrp,type,member,lang --> <!-- Note: member transferred to DTinstall/WORKAREA --> <xs:enumeration value="SAVE"/> <!-- Save edited member--> <!-- Save parms : project,projdef,group,repdgrp,type,member,lang --> <!-- Note: member received from DTinstall/WORKAREA --> <xs:enumeration value="DELETE"/> <!-- SCLM delete member --> <!-- Delete parms : project,projdef,group,repdgrp,type,member,delflag --> <xs:enumeration value="UNLOCK"/> <!-- SCLM unlock member --> <!-- Unlock parms : project,projdef,group,repdgrp,type,member --> <xs:enumeration value="DEPLOY"/> <!-- J2EE deploy function --> <!-- Deploy parms : project,projdef,group,repdgrp,type,member, depmode,depsec,groupdpy --> <xs:enumeration value="REPORT"/> <!-- SCLM project list --> <!-- Report parms : project,projdef,reptype,repdgrp,repccode,replang, repacode,repmem,repgrp,repmode,repbmap --> <xs:enumeration value="MIGDSN"/> <!-- List non-sclm datasets & members --> <!-- Migdsn parms : project,projdef,groupdev,migmem,migdsn --> <xs:enumeration value="MIGPDS"/> <!-- Migrate NON-SCLM datasets to SCLM --> <!-- Migpds parms : project,projdef,group,type,migfile,migmode, authcode,ccode,migonly --> <xs:enumeration value="INFO"/> <!-- SCLM member status information --> <!-- Info parms : project,projdef,group,repdgrp,type,member,lang --> <xs:enumeration value="UPDATE"/> <!-- update SCLM member information --> <!-- Update parms : project,projdef,group,repdgrp,type,member, lang,ccode,authcode --> <xs:enumeration value="AUTHUPD"/> <!-- Change SCLM member authcode --> <!-- Authupd parms : project,projdef,group,type,member,authcode --> <xs:enumeration value="VERLIST"/> <!-- SCLM list versions--> <!-- Verlist parms : project,projdef,group,repdgrp,type,member --> <xs:enumeration value="VERBROW"/> <!-- SCLM browse versions --> <!-- Verbrow parms : project,projdef,group,repdgrp,type,member --> <xs:enumeration value="VERREC"/> <!-- SCLM recover versions --> <!-- Verbrow parms : project,projdef,group,repdgrp,type,member --> <xs:enumeration value="VERDEL"/> <!-- SCLM delete versions --> <!-- Verdel parms : project,projdef,group,repdgrp,type,member --> <xs:enumeration value="VERHIST"/> <!-- SCLM version history --> <!-- Verhist parms : project,projdef,group,repdgrp,type,member --> <xs:enumeration value="REPUTIL"/> <!-- SCLM DBUTIL report --> <!-- Reputil parms : project,projdef,group,repdgrp,type,member --> <xs:enumeration value="PROJGRPS"/> <!-- Retrieve SCLM groups for a project --> <!-- Projgrps parms : project,projdef --> <xs:enumeration value="J2EEMIG"/> <!-- Migrate project into SCLM--> <!-- J2eemig parms : project,projdef,group,type,member,lang,migmode, projarch,archtype,authcode,ccode,j2eetype,j2eesinc,J2eefile, sclmrefs,archac,archcc,submit --> <xs:enumeration value="J2EEMIGB"/> <!-- Batch migrate project into SCLM --> <!-- J2eemigb parms : project,projdef,group,type,member,lang,migmode, authcode,ccode --> <xs:enumeration value="J2EEIMP"/> <!-- Import SCLM project --> <!-- J2eeimp parms : project,projdef,group,repdgrp,type,member,repacode, repccode,replang,reparchm,reparcht,reparchg,replang--> <xs:enumeration value="PROJINFO"/> <!-- Retrieve SCLM project information --> <!-- Projinfo parms : project,projdef,repdgrp --> <xs:enumeration value="LRECL"/> <!-- Retrieve LRECL of SCLM dataset --> <!-- Reputil parms : project,projdef,group,repdgrp,type --> <xs:enumeration value="JOBSTAT"/> <!-- Retrieve status of batch job --> <!-- Jobstat parms : project, jobfunc,jobname,jobid --> <xs:enumeration value="JARCOPY"/> <!-- Copies SCLM JAR into cpath directory --> <!-- Jarcopy parms : project,projdef,group,repdgrp,type,classdir,jarname --> </xs:restriction> </xs:simpleType> </xs:element> <!-- List of common function parameters --> <!-- project : SCLM project --> <xs:element name="project" type="xs:string" minOccurs="0"/> <!-- projdef : SCLM project definition --> <xs:element name="projdef" type="xs:string" minOccurs="0"/> <!-- group : SCLM group selected --> <xs:element name="group" type="xs:string" minOccurs="0"/> <!-- repdgrp : Users SCLM development group --> <xs:element name="repdgrp" type="xs:string" minOccurs="0"/> <!-- type : SCLM type --> <xs:element name="type" type="xs:string" minOccurs="0"/> <!-- member : SCLM member --> <xs:element name="member" type="xs:string" minOccurs="0"/> <!-- lang : SCLM language for the member --> <xs:element name="lang" type="xs:string" minOccurs="0"/> <!-- submit : submission type either online or batch --> <xs:element name="submit" type="xs:string" minOccurs="0"/> <!-- sclmfunc=build : additional parameter options --> <!-- bldscope : Build scope --> <xs:element name="bldscope" type="xs:string" minOccurs="0"/> <!-- bldmode : Build mode --> <xs:element name="bldmode" type="xs:string" minOccurs="0"/> <!-- bldlist : Translator listing only if error --> <xs:element name="bldlist" type="xs:string" minOccurs="0"/> <!-- bldrept : build report generated --> <xs:element name="bldrept" type="xs:string" minOccurs="0"/> <!-- bldmsg : build messages generated --> <xs:element name="bldmsg" type="xs:string" minOccurs="0"/> <!-- bldmsgds: build messages dataset name --> <xs:element name="bldmsgds" type="xs:string" minOccurs="0"/> <!-- bldrptds : build report dataset name --> <xs:element name="bldrptds" type="xs:string" minOccurs="0"/> <!-- bldlstds : build list dataset name --> <xs:element name="bldlstds" type="xs:string" minOccurs="0"/> <!-- bldextds : build exit dataset name --> <xs:element name="bldextds" type="xs:string" minOccurs="0"/> <!-- groupbld : SCLM group to build against --> <xs:element name="groupbld" type="xs:string" minOccurs="0"/> <!-- sclmfunc=promote : additional parameter options --> <!-- prmscope : Promote scope --> <xs:element name="prmscope" type="xs:string" minOccurs="0"/> <!-- prmmode : Promote mode --> <xs:element name="prmmode" type="xs:string" minOccurs="0"/> <!-- prmrept : Promote report generated --> <xs:element name="prmrept" type="xs:string" minOccurs="0"/> <!-- prmmsg : Promote messages generated --> <xs:element name="prmmsg" type="xs:string" minOccurs="0"/> <!-- prmmsgds: Promote messages dataset name --> <xs:element name="prmmsgds" type="xs:string" minOccurs="0"/> <!-- prmrptds : Promote report dataset name --> <xs:element name="prmrptds" type="xs:string" minOccurs="0"/> <!-- prmextds : Promote exit dataset name --> <xs:element name="prmextds" type="xs:string" minOccurs="0"/> <!-- groupprm : SCLM group to promote from --> <xs:element name="groupprm" type="xs:string" minOccurs="0"/> <!-- sclmfunc=delete : additional parameter option --> <!-- delflag : either text|acct|txbm|bmap|all --> <xs:element name="delflag" type="xs:string" minOccurs="0"/> <!-- sclmfunc=deploy : additional parameter options --> <!-- depmode : If set to 'R' then deploy report only --> <xs:element name="depmode" type="xs:string" minOccurs="0"/> <!-- depsec : set to Y if using surrogate userids --> <xs:element name="depsec" type="xs:string" minOccurs="0"/> <!-- groupdpy : SCLM group deploying from --> <xs:element name="groupdpy" type="xs:string" minOccurs="0"/> <!-- sclmfunc=report : additional parameter options --> <!-- reptype : type|* - SCLM type to report on --> <xs:element name="reptype" type="xs:string" minOccurs="0"/> <!-- repmem : member|*|filter - SCLM member to report on --> <xs:element name="repmem" type="xs:string" minOccurs="0"/> <!-- replang : lang|* - SCLM language to filter with --> <xs:element name="replang" type="xs:string" minOccurs="0"/> <!-- repgrp : group|* - SCLM group to filter on --> <xs:element name="repgrp" type="xs:string" minOccurs="0"/> <!-- repccode : SCLM changecode to filter on --> <xs:element name="repccode" type="xs:string" minOccurs="0"/> <!-- repmode : D|E developer mode or explorer mode --> <xs:element name="repmode" type="xs:string" minOccurs="0"/> <!-- repbmap : If ON then report on build maps --> <xs:element name="repbmap" type="xs:string" minOccurs="0"/> </xs:all> </xs:complexType> </xs:element> </xs:all> </xs:complexType> </xs:element> </xs:schema>
L'exemple ci-après montre la structure de base du fichier en entrée XML, #function représentant la fonction appelée et #parameter et #value, un paramètre et sa valeur.
<?xml version="1.0"?> <SCLMDT-INPUT xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="sclmdt.xsd"> <SERVICE-REQUEST> <service>SCLM</service> <session>NONE</session> <sclmfunc>#function</sclmfunc> <#parameter>#value</#parameter> ... </SERVICE-REQUEST> </SCLMDT-INPUT>
La liste suivante représente des remarques générales sur les paramètres et la manière dont ils sont abordés dans la présente publication :
Cette fonction modifie le code des droits d'accès d'un membre.
>>-AUTHUPD--*----------*-GROUP-MEMBER-PROJECT-TYPE->< *-AUTHCODE-* *-PROJDEF--* *----<-----*
Paramètres requis :
Paramètres facultatifs :
Cette fonction copie un membre de SCLM dans le répertoire z/OS UNIX WORKAREA/userid/EDIT/ . Aucun verrouillage d'édition n'est effectué dans SCLM.
>>-BROWSE---*----------*-GROUP-MEMBER-PROJECT-TYPE->< *-PROJDEF--*
Paramètres requis :
Paramètres facultatifs :
Cette fonction demande à SCLM de compiler, d'associer et d'intégrer les composants logiciels aux définitions de l'architecture du projet.
>>-BUILD----*----------*-GROUP-GROUPBLD-MEMBER-PROJECT-REPDGRP-TYPE->< *-BLDEXTDS-* *-BLDLIST--* *-BLDLSTDS-* *-BLDMODE--* *-BLDMSGDS-* *-BLDREPT--* *-BLDRPTDS-* *-BLDSCOPE-* *-PROJDEF--* *-SUBMIT---* *----<-----*
Paramètres requis :
Paramètres facultatifs :
Cette fonction supprime un membre SCLM.
>>-DELETE---*----------*-GROUP-MEMBER-PROJECT-TYPE->< *-DELFLAG--* *-PROJDEF--* *----<-----*
Paramètres requis :
Paramètres facultatifs :
La fonction DEPLOY exécute le script de déploiement référencé par le membre pour déployer un fichier d'archive d'entreprise (EAR) J2EE d'USS ou de SCLM dans WAS (Websphere Application Server). Pour plus d'informations sur la création d'un membre de script de déploiement, reportez-vous au Guide d'utilisation de SCLM Developer Toolkit.
>>-DEPLOY---*----------*-GROUP-MEMBER-PROJECT-TYPE->< *-DEPMODE--* *-DEPSEC---* *-GROUPDPY-* *-PROJDEF--* *-REPDGRP--* *----<-----*
Paramètres requis :
Paramètres facultatifs :
Cette fonction copie un membre de SCLM dans le répertoire z/OS UNIX WORKAREA/userid/EDIT/ . Elle crée également un verrou SCLM sur le membre avec l'ID utilisateur comme clé d'accès.
>>-EDIT-----*----------*-GROUP-MEMBER-PROJECT-TYPE->< *-AUTHCODE-* *-PROJDEF--* *----<-----*
Paramètres requis :
Paramètres facultatifs :
Cette fonction fournit des informations sur le statut du membre SCLM.
>>-INFO-----*----------*-GROUP-MEMBER-PROJECT-TYPE->< *-LANG-----* *-PROJDEF--* *-REPDGRP--* *----<-----*
Paramètres requis :
Paramètres facultatifs :
Cette fonction importe un projet de SCLM dans le répertoire z/OS UNIX /var/rdz/WORKAREA/userid au format JAR (zippé). Le fichier du projet JAR peut alors être copié sur le client. Le nom du fichier du projet est renvoyé dans le mot clé J2EEFILE de la sortie de la fonction (XML).
>>-J2EEIMP--*----------*-PROJECT-REPDGRP->< *-GROUP----* *-MEMBER---* *-PROJDEF--* *-REPACODE-* *-REPARCHG-* *-REPARCHM-* *-REPARCHT-* *-REPCCODE-* *-REPLANG--* *-TYPE-----* *----<-----*
Paramètres requis :
Paramètres facultatifs :
Cette fonction extrait un fichier compressé (au format JAR) du répertoire USS et migre tous les membres de ce fichier dans SCLM, en convertissant le nom long en nom abrégé si nécessaire.
>>-J2EEMIG--*----------*-GROUP-J2EEFILE-LANG-MEMBER-PROJECT-TYPE->< *-ARCHAC---* *-ARCHCC---* *-ARCHTYPE-* *-AUTHCODE-* *-CCODE----* *-J2EESINC-* *-J2EETYPE-* *-MIGMODE--* *-PROJARCH-* *-PROJDEF--* *-SCLMREFS-* *-SUBMIT---* *----<-----*
Paramètres requis :
Paramètres facultatifs :
Cette fonction configure et exécute le travail PAR LOTS de la migration.
>>-J2EEMIGB-*----------*-GROUP-LANG-MEMBER-PROJECT-TYPE->< *-ARCHTYPE-* *-AUTHCODE-* *-CCODE----* *-MIGMODE--* *-PROJARCH-* *-PROJDEF--* *----<-----*
Paramètres requis :
Paramètres facultatifs :
Cette fonction copie un fichier JAR stocké dans SCLM dans un répertoire z/OS UNIX, qui peut être utilisé comme répertoire CLASSPATH.
>>-JARCOPY--*----------*-CLASSDIR-GROUP-JARNAME-PROJECT-REPDGRP-TYPE->< *-PROJDEF--*
Paramètres requis :
Paramètres facultatifs :
Cette fonction extrait le statut d'un travail par lots spécifique.
>>-JOBSTAT--JOBFUNC-JOBID-JOBNAME-PROJECT-><
Paramètres :
Cette fonction extrait la longueur d'enregistrement logique d'un fichier SCLM.
>>-LRECL----*----------*-GROUP-PROJECT-REPDGRP-TYPE->< *-PROJDEF--*
Paramètres requis :
Paramètres facultatifs :
Cette fonction répertorie les membres et les fichiers sélectionnés qui ne sont pas gérés par SCLM (pour une migration ultérieure dans SCLM).
>>-MIGDSN---*----------*-MIGDSN-MIGMEM-PROJECT->< |__PROJDEF_|
Paramètres requis :
Paramètres facultatifs :
Cette fonction migre les membres et les fichiers sélectionnés qui ne sont pas gérés par SCLM dans SCLM.
>>-MIGPDS---*----------*-GROUP-PROJECT-TYPE->< |_PROJDEF__|
Paramètres requis :
Paramètres facultatifs :
Cette fonction extrait les groupes SCLM d'un projet sélectionné.
>>-PROJGRPS-*----------*-PROJECT->< *-PROJDEF--*
Paramètres requis :
Paramètres facultatifs :
Cette fonction extrait les informations sur un projet SCLM sélectionné.
>>-PROJINFO-*----------*--PROJECT-REPDGRP->< *-PROJDEF--*
Paramètres requis :
Paramètres facultatifs :
Cette fonction transfère un membre SCLM (ou Archdef) à un niveau supérieur de la hiérarchie des groupes SCLM en fonction de la définition de l'architecture des projets et de la définition du projet.
>>-PROMOTE--*----------*-GROUP-GROUPPRM-MEMBER-PROJECT-REPDGRP-TYPE->< *-PRMEXTDS-* *-PRMMODE--* *-PRMMSG---* *-PRMMSGDS-* *-PRMREPT--* *-PRMRPTDS-* *-PRMSCOPE-* *-PROJDEF--* *-SUBMIT---* *----<-----*
Paramètres requis :
Paramètres facultatifs :
La fonction de rapport offre un rapport hiérarchique DBUTIL du projet, en fonction des filtres et paramètres de rapport utilisés.
>>-REPORT---*----------*-PROJECT-REPDGRP-REPGRP-REPMEM-REPTYPE->< *-PROJDEF--* *-REPACODE-* *-REPBMAP--* *-REPCCODE-* *-REPLANG--* *-REPMODE--* *----<-----*
Paramètres requis :
Paramètres facultatifs :
Le service DBUTIL extrait les informations de la base de données de projet et crée un rapport et une sortie personnalisés. Il décrit le contenu de la base de données de projet en fonction des critères de sélection que vous fournissez.
>>-REPUTIL--*----------*-GROUP-MEMBER-PROJECT-REPDGRP-TYPE->< *-PROJDEF--*
Paramètres requis :
Paramètres facultatifs :
Cette fonction copie un membre du répertoire WORKAREA/userid/EDIT/ dans SCLM sous le groupe de développement d'un utilisateur. Un nouveau membre est créé si le membre n'existe pas dans la hiérarchie du projet SCLM.
>>-SAVE-----*----------*-GROUP-MEMBER-PROJECT-TYPE->< *-PROJDEF--*
Paramètres requis :
Paramètres facultatifs :
Cette fonction déverrouille un membre SCLM qui était verrouillé par la fonction d'édition (EDIT).
>>-UNLOCK---*----------*-GROUP-MEMBER-PROJECT-TYPE->< *-PROJDEF--* *-REPDGRP--* *----<-----*
Paramètres requis :
Paramètres facultatifs :
Cette fonction met à jour les informations d'un membre dans SCLM.
>>-UPDATE---*----------*-GROUP-MEMBER-PROJECT-TYPE->< *-AUTHCODE-* *-CCODE----* *-LANG-----* *-PROJDEF--* *-REPDGRP--* *----<-----*
Paramètres requis :
Paramètres facultatifs :
Cette fonction explore une version d'un membre à partir du fichier de version.
>>-VERBROW--*----------*-GROUP-MEMBER-PROJECT-REPDGRP-TYPE->< *-PROJDEF--*
Paramètres requis :
Paramètres facultatifs :
Cette fonction supprime les informations sur un membre versionné ou audité de SCLM.
>>-VERDEL---*----------*-GROUP-MEMBER-PROJECT-REPDGRP-TYPE->< *-PROJDEF--*
Cette fonction supprime toutes les anciennes versions d'un membre dans SCLM.
Paramètres requis :
Paramètres facultatifs :
Cette fonction affiche l'historique des versions d'une version de membre sélectionnée dans SCLM.
>>-VERHIST--*----------*-GROUP-MEMBER-PROJECT-REPDGRP-TYPE->< *-PROJDEF--*
Paramètres requis :
Paramètres facultatifs :
Cette fonction répertorie les diverses versions d'un membre particulier.
>>-VERLIST--*----------*-GROUP-MEMBER-PROJECT-REPDGRP-TYPE->< *-PROJDEF--*
Paramètres requis :
Paramètres facultatifs :
Cette fonction restaure une version sélectionnée d'un membre dans le groupe de développement.
>>-VERREC---*----------*-GROUP-MEMBER-PROJECT-REPDGRP-TYPE->< *-PROJDEF--*
Paramètres requis :
Paramètres facultatifs :
Un exemple de programme Java (avec entrée et sortie) est fourni, qui permet d'accéder à l'API des services hôte de SCLMDT à l'aide d'un serveur HTTP comme mécanisme de transport.
L'exemple de demande de l'exemple ci-après appelle la fonction BUILD pour compiler et associer le membre ALLOCEXT dans le projet SCLMVCM.
<?xml version="1.0"?> <SCLMDT-INPUT xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="sclmdt.xsd"> <SERVICE-REQUEST> <service>SCLM</service> <session>REUSE</session> <bldrept>Y</bldrept> <groupbld>DEV1</groupbld> <projdef>SCLMVCM</projdef> <bldmode>C</bldmode> <repdgrp>DEV1</repdgrp> <sclmfunc>BUILD</sclmfunc> <member>ALLOCEXT</member> <project>SCLMVCM</project> <group>TEST</group> <type>SOURCE</type> </SERVICE-REQUEST> </SCLMDT-INPUT>
L'exemple ci-après illustre un exemple de programme Java (dans Eclipse) utilisant la demande d'entrée XML ci-avant. Lorsqu'il est exécuté, il établit une connexion URL au serveur HTTP sous z/OS (CDFMVS08) et transmet le flux XML en entrée sous forme de demande POST à la routine CGI BWBXML.
package com.ibm.sclmCaller; import java.io.*; import java.net.*; import java.util.*; public class XMLBLD { public static void main(String[] args) { try { BufferedReader in = new BufferedReader(new FileReader("C:\\logon.txt")); String logon = in.readLine(); in.close(); Date d = new Date() ; System.out.println("START Transfer DATE/TIME is :" + d.toString() ); // URL details for CGI POST URL url = new URL("http", "CDFMVS08", 8080, "/BWBXML"); HttpURLConnection con = (HttpURLConnection) url.openConnection(); con.setUseCaches(false); con.setDoInput(true); con.setDoOutput(true); con.setRequestMethod("POST"); con.setRequestProperty( "Authorization", "Basic " + Base64Encoder.encode( logon )); System.out.println("At url openConnection.. "); // POST CGI routines doPut(url, con); doGet(url, con); Date c = new Date() ; System.out.println("TOTAL Completion DATE/TIME is :" + c.toString() ); } catch (IOException exception) { System.out.println("Error: " + exception); } } public static void doPut(URL url, HttpURLConnection con) throws IOException { PrintWriter out = new PrintWriter(con.getOutputStream()); // Below is a sample inline XML input for an ISPF service request // This could alternatively be read from an external file out.println( "<?xml version=\"1.0\"?>" ); out.println( "<SCLMDT-INPUT" ); out.println( "xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"" ); out.println( "xsi:noNamespaceSchemaLocation=\"sclmdt.xsd\">" ); out.println( "<SERVICE-REQUEST>" ); out.println( "<service>SCLM</service>" ); out.println( "<session>NONE</session>" ); out.println( "<ispprof>IBMUSER.TEST.ISPPROF</ispprof>" ); out.println( "<sclmfunc>BUILD</sclmfunc>" ); out.println( "<project>SCLMVCM</project>" ); out.println( "<projdef>SCLMVCM</projdef>" ); out.println( "<member>ALLOCEXT</member>" ); out.println( "<group>TEST</group>" ); out.println( "<type>SOURCE</type>" ); out.println( "<repdgrp>DEV1</repdgrp>" ); out.println( "<groupbld>DEV1</groupbld>" ); out.println( "<bldrept>Y</bldrept>" ); out.println( "<bldmsg>Y</bldmsg>" ); out.println( "<bldmode>C</bldmode>" ); out.println( "</SERVICE-REQUEST>" ); out.println( "</SCLMDT-INPUT>" ); out.flush(); out.close(); } public static void doGet(URL url, HttpURLConnection con) throws IOException { BufferedReader in; try { System.out.println("About to accept response from Server"); in = new BufferedReader(new InputStreamReader(con.getInputStream())); System.out.println("Response from Server received"); } catch (FileNotFoundException exception) { InputStream err = ((HttpURLConnection)con).getErrorStream(); if (err == null) throw exception ; in = new BufferedReader(new InputStreamReader(err)); } String line; while ((line = in.readLine()) != null) System.out.println(line); in.close(); } }
L'exemple ci-après illustre l'exemple de sortie de la fonction BUILD appelée à l'aide de l'exemple de programme Java.
La figure 26 illustre l'exemple de sortie de la fonction BUILD appelée à l'aide de l'exemple de programme Java.
START Transfer DATE/TIME is :Wed Mar 26 09:44:03 WST 2008 At url openConnection.. About to accept response from Server Response from Server received <?xml version="1.0"?> <SCLMDT-OUTPUT> <SERVICE-REQUEST> <service>SCLM</service> <session>NONE</session> <ispprof>IBMUSER.TEST.ISPPROF</ispprof> <sclmfunc>BUILD</sclmfunc> <project>SCLMVCM</project> <projdef>SCLMVCM</projdef> <member>ALLOCEXT</member> <group>TEST</group> <type>SOURCE</type> <repdgrp>DEV1</repdgrp> <groupbld>DEV1</groupbld> <bldrept>Y</bldrept> <bldmsg>Y</bldmsg> <bldmode>C</bldmode> </SERVICE-REQUEST> <SERVICE-RESPONSE> <RETURN-CODE>0</RETURN-CODE> <REASON-CODES> <REASON-CODE ID="BWB00158">SELECT DETAILS-- BUTTON FOR BUILD MESSAGES, REPORTS, LISTINGS</REASON-CODE> </REASON-CODES> <BUILD-MESSAGES> <BUILD-MESSAGE ID="FLM42000">- BUILD PROCESSOR INITIATED - 09:53:01 ON 2008/03/26</BUILD-MESSAGE> <BUILD-MESSAGE ID="FLM46000">- BUILD PROCESSOR COMPLETED - 09:53:01 ON 2008/03/26</BUILD-MESSAGE> </BUILD-MESSAGES> <BUILD-REPORT> <![CDATA[ *********************************************************************** *********************************************************************** ** ** ** ** ** SOFTWARE CONFIGURATION AND LIBRARY MANAGER (SCLM) ** ** ** ** B U I L D R E P O R T ** ** ** ** 2008/03/26 09:53:01 ** ** ** ** PROJECT: SCLMVCM ** ** GROUP: DEV1 ** ** TYPE: SOURCE ** ** MEMBER: ALLOCEXT ** ** ALTERNATE: SCLMVCM ** ** SCOPE: NORMAL ** ** MODE: CONDITIONAL ** ** ** ** ** *********************************************************************** *********************************************************************** 1 *** B U I L D O U T P U T S G E N E R A T E D *** Page 1 MEMBER TYPE VERSION KEYWORD ------ ---- ------- ------- ******* NO MODULES GENERATED ******* 1 ******* B U I L D M A P S G E N E R A T E D ******* Page 2 (REASON FOR REBUILD) MEMBER TYPE VERSION MEMBER TYPE ------ ---- ------- ------- ---- ***** NO BUILD MAPS GENERATED ***** 1 ******* B U I L D O U T P U T S D E L E T E D ******* Page 3 MEMBER TYPE VERSION KEYWORD ------ ---- ------- ------- ******* NO MODULES DELETED ******* 1 ******* B U I L D M A P S D E L E T E D ******* Page 4 (REASON FOR DELETE) MEMBER TYPE VERSION MEMBER TYPE ------ ---- ------- ------- ---- ***** NO BUILD MAPS DELETED ***** ]]> </BUILD-REPORT> <SCLM-MESSAGES> <SCLM-MESSAGE ID="FLM87107">- BUILD SUCCEEDED FOR MEMBER ALLOCEXT AT 09:53:01, CODE: 0</SCLM-MESSAGE> </SCLM-MESSAGES> </SERVICE-RESPONSE> <OPERATIONS-LOG> <![CDATA[ Status: 200 Content-Type: text/plain Entering BWBINT (Service initialization) Host driver level : V4 12Feb08 09:52:57.48 Function ID timestamp = ID35577 Environment variables : 1 CONTENT_TYPE application/x-www-form-urlencoded 2 QUERY_STRING 3 PATH /usr/lpp/rdz/bin:/bin:.:/usr/sbin:/usr/lpp/internet/bin:/usr/lpp/ internet/sbin:/usr/lpp/java/J5.0/bin 4 AUTH_TYPE Basic 5 DOCUMENT_URI /BWBXML 6 SHELL /bin/sh 7 HTTPS OFF 8 HTTP_USER_AGENT Java/1.5.0 9 HTTP_ACCEPT text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 10 RULE_FILE //DD:CONF 11 SERVER_PORT 8080 12 CONTENT_LENGTH 554 13 PATH_INFO 14 GATEWAY_INTERFACE CGI/1.1 15 _CEE_RUNOPTS ENVAR("_CEE_ENVFILE=//DD:ENV") 16 REFERER_URL 17 _BPX_SPAWN_SCRIPT YES 18 _ ./BWBCRON1 19 CLASSPATH .:/usr/lpp/internet/server_root/CAServlet 20 REMOTE_ADDR 192.168.124.236 21 REQUEST_METHOD POST 22 STEPLIB CURRENT 23 CGI_TRANTABLE FEK.#CUST.LSTRANS.FILE 24 LANG C 25 REMOTE_USER IBMUSER 26 LIBPATH /bin:/usr/lpp/internet/bin:/usr/lpp/internet/sbin 27 FSCP IBM-1047 28 SERVER_ADDR 56. 9.42.112.75 29 HTTP_CONNECTION keep-alive 30 PATH_TRANSLATED 31 HTTP_HOST CFDFMVS08 32 SERVER_TOKEN 1 33 HTTP_CACHE_CONTROL no-cache 34 SERVER_SOFTWARE IBM HTTP Server/V5R3M0 35 _BPX_SHAREAS YES 36 NETCP ISO8859-1 37 DOCUMENT_ROOT /usr/lpp/rdz/bin 38 REPORTBITS 77 39 COUNTERDIR NULL 40 LC_ALL en_US.IBM-1047 41 SERVER_PROTOCOL HTTP/1.1 42 _BPX_USERID IBMUSER 43 _SCLMDT_CONF_HOME /etc/rdz/sclmdt 44 HTTPS_KEYSIZE 45 JAVA_HOME /usr/lpp/java/J5.0/ 46 TZ EST5EDT 47 SCRIPT_NAME /BWBXML 48 _BPX_BATCH_SPAWN SPAWN 49 _CEE_ENVFILE //DD:ENV 50 NLSPATH /usr/lib/nls/msg/%L/%N:/usr/lpp/internet/%L/%N:/usr/ lib/nls/msg/En_US.IBM-1047/%N 51 DOCUMENT_NAME /usr/lpp/rdz/bin/BWBXML 52 _SCLMDT_WORK_HOME /var/rdz 53 HTTP_PRAGMA no-cache 54 SERVER_NAME CDFMVS08 Timecheck1:09:52:57.49 Connection Protocol : HTTP Server Name : CDFMVS08 Server Port : 8080 SCRT check: /var/rdz/WORKAREA/scrtTimeStamp Time:1206492777 File: 1206492602 Timecheck2:09:52:57.51 Timecheck2b:09:52:57.51 FSCP = IBM-1047 NETCP = ISO8859-1 _SCLMDT_CONF_HOME = /etc/rdz/sclmdt _SCLMDT_WORK_HOME = /var/rdz CGI_TRANTABLE = FEK.#CUST.LSTRANS.FILE Server PATH = /usr/lpp/rdz/bin:/bin:.:/usr/sbin:/usr/lpp/internet/ bin:/usr/lpp/internet/sbin:/usr/lpp/java/J5.0/bin Check: userdir = /var/rdz/WORKAREA/IBMUSER Timechecklsa:09:52:57.51 Timecheck3:09:52:57.51 ** Development Group = DEV1 ** Selected Group = TEST Plugin version : NONE Host version : 4.1.0 Temporary data set prefix set to : SCLMVCM.IBMUSER Timecheck4:09:52:58.04 Parameters to be written to temporary data set 'SCLMVCM.IBMUSER.SCLMDT. VCMISPF.ID35577' :ISPPROF=IBMUSER.TEST.ISPPROF&SCLMFUNC=BUILD &PROJECT=SCLMVCM&PROJDEF=SCLMVCM&MEMBER=ALLOCEXT&GROUP=TEST &TYPE=SOURCE&REPDGRP=DEV1&GROUPBLD=DEV1&BLDREPT=Y&BLMSG=Y&BLDMODE=C /etc/rdz/sclmdt;/var/rdz /usr/lpp/rdz/bin:/bin:.:/usr/sbin:/usr/lpp/internet/bin:/usr/lpp/internet/ sbin:/usr/lpp/java/J5.0/bin/~~FEK.#CUST.LSTRANS.FILE Processing SCLM request : Value for SESSFLG = NONE Value for SESSION = NONE Value for SCLMFUNC = BUILD Value for PROJ = SCLMVCM Value for PROJDEF = SCLMVCM Value for Development GROUP = DEV1 Value for Selected GROUP = TEST Value for TYPE = SOURCE Value for LANG = NONE Value for MEMBER = ALLOCEXT Value for J2EEFILE = NONE Value for PROFDSN = IBMUSER.TEST.ISPPROF Value for PARMS = NONE pcnt = 3 parmline.1 = ISPF SELECT CMD(BWBBLD ID35577 SCLMVCM.IBMUSER SCLMVCM SCLMVCM TEST DEV1 SOURCE ALLOCEXT /) NEST LANG(CREX) time check before ISPZINT call :09:52:58.17 time check after ISPZINT call :09:53:02.51 ispzint rc = 0 check: respline count = 226 *** ISPZINT OUTPUT *** Content-type: text/plain Entering ISPZINT (Service initialization) About to read from fileno(stdin) = 0 Data read from STDIN is ISPF SELECT CMD(BWBBLD ID35577 SCLMVCM.IBMUSER SCLMVCM SCLMVCM TEST DEV1 SOURCE ALLOCEXT /) NEST LANG(CREX) EPOCH secs = 1206492778 Local Date & time: Tue Mar 25 20:52:58 2008 Hour: 20 Min: 52 Sec 58 Function ID timestamp = ID075178 Environment variables: 0 QUERY_STRING= 1 CONTENT_TYPE=application/x-www-form-urlencoded 2 PATH=/usr/lpp/rdz/bin:/bin:.:/usr/sbin:/usr/lpp/internet/bin:/usr/lpp/ internet/sbin:/usr/lpp/java/J5.0/bin 3 AUTH_TYPE=Basic 4 DOCUMENT_URI=/BWBXML 5 SHELL=/bin/sh 6 HTTPS=OFF 7 HTTP_ACCEPT=text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 8 HTTP_USER_AGENT=Java/1.5.0 9 SERVER_PORT=8080 10 RULE_FILE=//DD:CONF 11 GATEWAY_INTERFACE=CGI/1.1 12 PATH_INFO= 13 CONTENT_LENGTH=554 14 _CEE_RUNOPTS=ENVAR("_CEE_ENVFILE=//DD:ENV") 15 _BPX_SPAWN_SCRIPT=YES 16 REFERER_URL= 17 _=/u/SCLMDTIS/bin/ISPZINT 18 CLASSPATH=.:/usr/lpp/internet/server_root/CAServlet 19 STEPLIB=CURRENT 20 REQUEST_METHOD=POST 21 REMOTE_ADDR=192.168.128.236 22 CGI_TRANTABLE=FEK.#CUST.LSTRANS.FILE 23 LANG=C 24 LIBPATH=/bin:/usr/lpp/internet/bin:/usr/lpp/internet/sbin 25 REMOTE_USER=IBMUSER 26 SERVER_ADDR=9.42.112.75 27 FSCP=IBM-1047 28 PATH_TRANSLATED= 29 HTTP_CONNECTION=keep-alive 30 SERVER_TOKEN=1 31 HTTP_HOST=CDFMVS08 32 _BPX_SHAREAS=YES 33 SERVER_SOFTWARE=IBM HTTP Server/V5R3M0 34 HTTP_CACHE_CONTROL=no-cache 35 REPORTBITS=77 36 DOCUMENT_ROOT=/usr/lpp/rdz/bin 37 NETCP=ISO8859-1 38 COUNTERDIR=NULL 39 LC_ALL=en_US.IBM-1047 40 _SCLMDT_CONF_HOME=/etc/rdz/sclmdt 41 _BPX_USERID=IBMUSER 42 SERVER_PROTOCOL=HTTP/1.1 43 JAVA_HOME=/usr/lpp/java/J5.0/ 44 HTTPS_KEYSIZE= 45 TZ=EST5EDT 46 _CEE_ENVFILE=//DD:ENV 47 _BPX_BATCH_SPAWN=SPAWN 48 SCRIPT_NAME=/BWBXML 49 NLSPATH=/usr/lib/nls/msg/%L/%N:/usr/lpp/internet/%L/%N: /usr/lib/nls/msg/En_US.IBM-1047/%N 50 _SCLMDT_WORK_HOME=/var/rdz 51 DOCUMENT_NAME=/usr/lpp/rdz/bin/BWBXML 52 SERVER_NAME=CDFMVS08 53 HTTP_PRAGMA=no-cache Number of environment variables is 54 Connection Protocol = HTTP Server Name = CDFMVS08 Server Port = 8080 ***ERROR: Unable to get status information for ISPZTSO FSCP = IBM-1047 NETCP = ISO8859-1 Server PATH = /usr/lpp/rdz/bin:/bin:.:/usr/sbin:/usr/lpp/internet/bin:/ usr/lpp/internet/sbin:/usr/lpp/java/J5.0/bin/ ISPF standalone function invoked ISPF COMMAND = ISPF SELECT CMD(BWBBLD ID35577 SCLMVCM.IBMUSER SCLMVCM SCLMVCM TEST DEV1 SOURCE ALLOCEXT /) NEST LANG(CREX) ISPF PROFILE = NONE Re-usable ISPF session = About to spawn task for ISPZTSO Parameters passed to ISPZTSO - PROFILE Return code from ISPZTSO is 0 About to process PROFILE data in /tmp/IBMUSER.ID075178.ISPF.SYSTSPRT About to malloc() 252 bytes for profdat Temporary data set prefix set to : SCLMVCM About to call bpxwdyn to allocate VCMTEMP Allocating data set SCLMVCM.ISPF.VCMISPF.ID075178 to the VCMTEMP DD 1024 bytes of ISPF SELECT CMD(BWBBLD ID35577 SCLMVCM.IBMUSER SCLMVCM SCLMVCM TEST DEV1 SOURCE ALLOCEXT /) NEST LANG(CREX) written to VCMTEMP 1024 bytes of /etc/rdz;/var/rdz written to VCMTEMP 1024 bytes of /usr/lpp/rdz/bin:/bin:.:/usr/sbin:/usr/lpp/internet/bin: /usr/lpp/internet/sbin:/usr/lpp/java/J5.0/bin/~~ written to VCMTEMP Parameter to be passed to ISPZTSO CALL *(ISPZCNT) 'ISPF ID075178 SCLMVCM NONE ISPF SELECT CMD(BWBBLD ID35577 SCLMVCM.IBMUSER SCLMVCM SCLMVCM TEST DEV1 SOURCE ALLOCEXT /) NEST LANG(CREX)' About to spawn task for ISPZTSO Parameters passed to ISPZTSO - CALL *(ISPZCNT) 'ISPF ID075178 SCLMVCM NONE ISPF SELECT CMD(BWBBLD ID35577 SCLMVCM.IBMUSER SCLMVCM SCLMVCM TEST DEV1 SOURCE ALLOCEXT /) NEST LANG(CREX)' Return code from ISPZTSO is 0 About to open /tmp/IBMUSER.ID075178.ISPF.SYSTSPRT IKJ56003I PARM FIELD TRUNCATED TO 100 CHARACTERS Entering ISPZCNT (ISPF Initialization) Parameters ISPF ID075178 SCLMVCM NONE ISPF SELECT CMD(BWBBLD ID35577 SCLMVCM.IBMUSER SCLMVCM SCLMVCM TEST DEV1 REC: ispmlib=isp.sispmenu Allocation successful for ISPMLIB REC: isptlib=isp.sisptenu Allocation successful for ISPTLIB REC: ispplib=isp.sisppenu Allocation successful for ISPPLIB REC: ispslib=bzz.sbzzsenu,isp.sispsenu,isp.sispslib Allocation successful for ISPSLIB REC: ISPF_timeout = 300 NOTE: Data set allocations took 0.28 elapsed seconds Running user ISPF command: ISPSTART CMD(BWBBLD ID35577 SCLMVCM. IBMUSER SCLMVCM SCLMVCM TEST DEV1 SOURCE ALLOCEXT /) NEST <ISPINFO> ISPF COMMAND : ISPSTART CMD(BWBBLD ID35577 SCLMVCM.IBMUSER SCLMVCM SCLMVCM TEST DEV1 SOURCE ALLOCEXT /) NEST LANG(CREX) N <ISPF> Entering BWBBLD Temporary data set prefix : SCLMVCM.IBMUSER about to allocate VCMISPF rc from alloc is 0 Translate table allocated successfully SCLMDT CONFIG directory = /etc/rdz/sclmdt SCLMDT Working directory = /var/rdz SCLMDT Translate table = FEK.#CUST.LSTRANS.FILE ****** BUILD PARMS ****** PROJECT = SCLMVCM PROJDEF (Project Name) = SCLMVCM GROUP (SCLM Group) = TEST GROUPBLD (Build at group) = DEV1 TYPE (SCLM Type) = SOURCE MEMBER (SCLM Build Member) = ALLOCEXT BLDSCOPE (Build Scope) = N BLDMODE (Build Mode) = C BLDLIST (Listing Flag ) = Y BLDREPT (Report Flag ) = Y BLDMSG (Messages Flag ) = Y BLDLSTDS (Listing Data set name) = BLDRPTDS (Report Data set name) = BLDMSGDS (Messages Data set name) = BLDEXTDS (Exit Data set name) = SUBMIT (Submission type) = ONLINE ****** End PARMS ****** projfile = /etc/rdz/sclmdt/CONFIG/PROJECT/SCLMVCM.conf Security Flag set to N rc from FLMMSGS alloc is 0 PARMS=SCLMVCM,SCLMVCM,DEV1,SOURCE,ALLOCEXT,,N,C,Y,Y,,tmpmsg, tmprpt,tmplst,BLDEXIT BWBBLD CHECK: PARMS = SCLMVCM,SCLMVCM,DEV1,SOURCE,ALLOCEXT,, N,C,Y,Y,,tmpmsg,tmprpt,tmplst,BLDEXIT *** BUILD SUCCESSFUL *** Cleaning up workarea directories ********************** SCLM MESSAGES *********************** FLM87107 - BUILD SUCCEEDED FOR MEMBER ALLOCEXT AT 09:53:01, CODE: 0 ************************************************************** *** XML-NOTE *** Reference tagged SERVICE-RESPONSE </ISPF> RC=0 </ISPINFO> ISPRC = 0 *********************** ISPLOG CONTENTS *********************** 1 Time *** ISPF transaction log *** Userid: IBMUSER Date: 08/03/26 Page: 09:53 Start of ISPF Log - - - - Session # 1 ---------------------- 09:53 TSO - Command - - BWBBLD ID35577 SCLMVCM.IBMUSER SCLMVCM SCLMVCM TEST DEV1 SOURCE ALLOCEXT / 09:53 TSO - Command - - FLMCMD 09:53 BUILD,SCLMVCM,SCLMVCM,DEV1,SOURCE,ALLOCEXT ,,N,C,Y,Y,,tmpmsg,tmprpt,tmplst,BLD 09:53 EXIT 09:53 End of ISPF Log - - - - - Session # 1 ---------------------- ********************* END ISPLOG CONTENTS ********************* IKJ56247I FILE ISPLLIB NOT FREED, IS NOT ALLOCATED Leaving ISPZCNT READY END return code from ISPFInit = 0 PROCESSING COMPLETE End of SCLM Processing FUNC: BUILD - Cleaning up old 'SCLMVCM.IBMUSER.SCLMDT.VCMISPF.ID35577' EXIT BWBINT 09:53:02.86 WITH RC=0 ]]> </OPERATIONS-LOG> </SCLMDT-OUTPUT> TOTAL Completion DATE/TIME is :Wed Mar 26 09:44:11 WST 2008
Cette section aborde les améliorations apportées à la procédure de génération Java/J2EE à l'aide de l'utilitaire de génération Rational Application Developer for WebSphere Software (précédemment appelé AST, Application Server Toolkit). L'utilitaire de génération Rational Application Developer for WebSphere Software est fourni avec Rational Application Developer (RAD). Le composant RAD doit être commandé, installé et configuré séparément. L'installation et la personnalisation de ce produit ne sont pas décrites dans le présent ouvrage. Pour connaître les instructions d'installation et de personnalisation de l'utilitaire de génération, reportez-vous à la documentation fournie avec RAD. Cette section fera ultérieurement référence à l'utilitaire de génération Rational Application Developer for WebSphere sous le nom "utilitaire de génération".
L'utilitaire de génération permet à SCLM de générer des espaces de travail de projet dupliqué (qui ont été conservés dans SCLM) à partir de l'environnement de développement intégré RDz à l'aide du mode Eclipse sans interface graphique sous z/OS.
Cette section doit être utilisée avec le Guide d'utilisation en ligne de SCLM Developer Toolkit et le Guide d'installation et de personnalisation fourni avec le produit. SCLM Developer Toolkit fournit des traducteurs de langage Java/J2EE à SCLM afin d'offrir une fonction de génération Java/J2EE complète.
Non seulement SCLM Developer Toolkit offre cette fonction dans le but d'enregistrer du code source et des objets JAVA/J2EE, mais permet également à SCLM, grâce à ces traducteurs, de générer et de contrôler entièrement les applications Java/J2EE. Les objets Java/J2EE pris en charge par le biais de ces traducteurs de langage sont les fichiers classe Java, les fichiers d'archives Java (JAR), les fichiers jar EJB (Enterprise Java Beans), les fichiers d'archive Web (WAR) et les fichiers d'archive d'entreprise (EAR).
SCLM Developer Toolkit s'intègre à l'utilitaire de génération pour contrôler les projets SCLM J2EE répliqués dans l'espace de travail de l'utilitaire de génération sous UNIX System Services sous z/OS. Les projets répliqués sont ensuite générés par le traitement de génération ARCHDEF qui fait référence aux scripts de l'utilitaire de génération. Des exemples de script de génération sont fournis avec SCLM Developer Toolkit. Les objets résultant de la génération/compilation sont stockés dans SCLM.
L'utilitaire de génération prend en charge les générations de tous les projets J2EE acceptés sous Rational Application Developer V7. Les projets générés dans les versions précédentes de RAD devront être migrés dans un espace de travail RAD V7 sur le client IDE avant d'être ajoutés à SCLM. Les projets Java Eclipse normaux sont également pris en charge.
Les objets Java/J2EE sont stockés dans SCLM de la manière suivante :
SCLM Developer Toolkit est livré avec une procédure de génération ANT native pour la prise en charge de Java/J2EE. Reportez-vous au plug-in du Guide d'utilisation en ligne de SCLM Developer Toolkit et au Guide d'installation/de personnalisation.
L'utilitaire de génération Rational Application Developer for WebSphere Software améliore la prise en charge de la génération Java/J2EE en répliquant intégralement l'environnement IDE Eclipse sous z/OS lors de la génération.
Comme dans la procédure de génération ANT, la procédure de l'utilitaire de génération utilise la définition d'archive, qui contient les membres composant le projet Java/J2EE, et qui correspond à une représentation abrégée de la manière dont le projet existe dans un espace de travail Eclipse.
L'utilisateur peut choisir la procédure de l'utilitaire de génération ou la procédure de génération ANT native en affectant le script de génération (référencé par ARCHDEF) avec le convertisseur de langage approprié :
Lorsqu'elle est générée, la définition d'archive appelle le traducteur de langage de vérification de pré-génération (J2EEAST). Ce type de langage J2EEAST est affecté au script de génération référencé dans la définition d'archive par le mot clé SINC. Ce traducteur de langage copie tous les composants de définition d'archive dans le système de fichiers z/OS UNIX System Services à générer à l'aide de l'utilitaire de génération.
Les composants de projet et la source Java peuvent être stockés dans SCLM au format EBCDIC ou ASCII. Sous l'utilitaire de génération, les composants de texte et la source Java sont convertis par défaut au format ASCII dans l'espace de travail USS avant le traitement de génération.
L'utilitaire de génération Rational Application Developer for WebSphere Software est fourni avec Rational Application Developer (RAD). Le composant RAD doit être commandé, installé et configuré séparément. L'installation et la personnalisation de ce produit ne sont pas décrites dans le présent ouvrage. Pour connaître les instructions d'installation et de personnalisation de l'utilitaire de génération, reportez-vous à la documentation fournie avec RAD. Le module du répertoire de l'utilitaire de génération doit se trouver dans le système de fichiers z/OS UNIX.
Le traitement de génération J2EE peut nécessiter des tailles de région considérables pour éviter les erreurs de stockage ou de ‘mémoire insuffisante'. En prévision de générations en ligne volumineuses, spécifiez au moins REGION=512M sur le démon Developer for System z RSE (par défaut, il s'agit de la tâche démarrée RSED). Pour le traitement par lots, il est recommandé que ce paramètre de taille de région soit spécifié sur le lot JOBCARD.
Le traitement J2EEAST initial est similaire au traitement J2EEANT dans lequel le traducteur de langage détermine à partir de la définition d'archive quels composants doivent être régénérés en fonction du mode de génération (conditionnel ou forcé). Les fichiers source des projets et les objets générés inclus sont ensuite copiés dans la zone de travail du système de fichiers UNIX Systems Services pour l'utilitaire de génération. Le script d'exécution et le fichier XML de génération stockés dans SCLM sous le type J2EEBLD sont également copiés dans la même zone de travail. Le script d'exécution est appelé pour afficher Eclipse sans interface graphique sous z/OS et exécuter le code XML de génération de l'application référencée. L'utilitaire de génération compile et génère les objets Java/J2EE requis spécifiés par le script d'exécution, les données XML de génération et la définition d'archive.
J2EEAST examine les objets générés et ne sélectionne pour la mise à jour de SCLM que les composants/objets qui devaient être régénérés selon SCLM à partir du mode de génération (conditionnel/forcé).
SCLM traite chaque composant de définition d'archive en exécutant chaque traducteur de langage associé au composant. Le traducteur de langage JAVA associé à chaque membre de source Java copie les fichiers de classe associés à chacun dans SCLM.
La partie finale du traitement de génération consiste à traiter la définition d'archive (ARCHDEF) elle-même, où le traducteur de langage J2EEOBJ est exécuté. Ce traducteur de définition d'archive détermine quels objets J2EE ont été générés (JAR, WAR, EAR) et les recopie dans SCLM.
L'implémentation et l'exécution de l'utilitaire se déroulent de la manière suivante :
Pour l'utilitaire de génération, certains traducteurs de langage sont affectés au source J2EE, à ARCHDEF et au script de génération.
Des exemples de génération de ces langages dans un projet SCLM sont fournis avec SCLM Developer Toolkit dans la bibliothèque des exemples d'installation, SBWBSAMP.
Il s'agit d'un traducteur de langage du code XML du script de l'utilitaire de génération.
Récapitulatif : EXEMPLE : BWBTRAN4
Le traducteur de vérification J2EEAST est appelé lors de la génération de la définition d'archive. J2EEAST est le type de langage du code XML de génération J2EEBLD référencé par le mot clé SINC dans la définition d'archive. Ce traducteur de vérification copie la source sélectionnée et tous les objets de définition d'archive, quel que soit le mode de génération dans la zone de travail HFS z/OS à référencer lors de la génération comme espace de travail Projet. Cet espace de travail de projets se trouve provisoirement dans la zone de travail de SCLM Developer Toolkit. SCLM DT crée un espace de travail de projets temporaire sous l'arborescence de répertoires suivante : /var/SCLMDT/WORKAREA/userid/project/group/type/member/project
L'utilitaire de génération requiert l'intégralité de la structure du projet et tous les composants de projet sont donc copiés dans le système de fichiers UNIX System Services. Tous les composants texte sont copiés dans l'espace de travail des projets au format ASCII. Le code XML de génération est également copié dans la zone de travail du système hiérarchique de fichiers. Le code XML de génération contient les détails du projet et les demandes de génération J2EE, ainsi que les détails des autres propriétés référencés par SCLM.
Le code XML de génération fait référence à un script d'exécution AST associé. Ce script d'exécution est également copié dans la zone de travail (EBCDIC) et, lorsqu'il est exécuté, affiche Eclipse sans interface graphique sous z/OS pour exécuter les données XML de génération de l'application. L'implémentation actuelle permet une génération intégrale dans l'espace de travail mais SCLM ne traite les composants sélectionnés que si une génération conditionnelle a été demandée et que le traducteur détermine quels objets générés doivent être mis à jour dans SCLM, selon le mode de génération.
Les objets J2EE générés, tels que les fichiers d'archive JAR, WAR ou EAR seront de nouveau stockés dans SCLM lorsque le traducteur de définition d'archive J2EEOBJ est exécuté. Les fichiers de classe sélectionnés sont consignés et mis à jour dans SCLM lorsque la définition d'archive traite chaque composant Java (traducteur Java).
Il s'agit d'un traducteur de langage de définition d'archive référencé par le mot clé LKED.
Récapitulatif : EXEMPLE : BWBTRAN3
Ce traducteur de génération final est appelé dans le cadre du processus de génération de la définition d'archive. Ce traducteur détermine quels objets J2EE étaient déjà générés dans le traducteur J2EEAST et copie ces objets dans SCLM avec le nom abrégé indiqué.
Il s'agit d'un traducteur de langage de source Java stocké en EBCDIC.
Récapitulatif : EXEMPLE : BWBTRAN1
Le type de langage pour source Java est défini par l'exemple BWBTRAN1. Le traducteur Java détermine le type de génération effectué sur la source Java.Remarque : Cette définition de langage doit être affectée aux programmes Java si vous souhaitez enregistrer le code source Java en EBCDIC sur l'hôte (à savoir que le source peut être affiché et modifié directement sur l'hôte via ISPF). L'avantage de définir des programmes avec cette définition de langage est de pouvoir modifier et afficher la source directement sur l'hôte z/OS. Par contre, les pages de codes doivent être converties lors de la migration ou de l'importation de projets du client vers l'hôte.
Il s'agit d'un traducteur de langage de source Java stocké en ASCII.
Récapitulatif : EXEMPLE : BWBTRAN1
Type de langage similaire à Java et utilisé lors du stockage de la source Java au format ASCII dans SCLM.
Il s'agit d'un traducteur de langage de composant texte stocké en EBCDIC.
Récapitulatif : EXEMPLE : BWBTRANJ
J2EEPART est un type de langage qui spécifie un composant JAVA/J2EE et qui est défini par l'exemple BWBTRANJ. Aucune analyse syntaxique particulière n'est effectuée lors de la génération de cette définition de langage. Les sources autres que Java ou les composants J2EE qui requièrent une conversion de langage ASCII/EBCDIC peuvent être attribués de manière générique sous cette définition de langage si aucune analyse de génération particulière n'est requise (par exemples, HTML, XML, .classpath, .project, tables de définition). La définition de langage TEXT peut éventuellement être utilisée.
Il s'agit d'un traducteur de langage de source Java stocké en EBCDIC.
Récapitulatif : EXEMPLE : BWBTRANJ
Type de langage qui spécifie un composant ASCII ou binaire JAVA/J2EE et qui est défini par l'exemple BWBTRANJ. Aucune analyse syntaxique particulière n'est effectuée lors de la génération de cette définition de langage. Les fichiers binaires JAVA/J2EE et les fichiers texte que vous souhaitez enregistrer au format ASCII peuvent être attribués de manière générique sous cette définition de langage si aucune analyse de génération particulière n'est requise.
Comme pour la méthode du service de génération J2EE standard, la méthode de l'utilitaire de génération implique que les scripts de l'utilitaire de génération soient référencés par la définition d'archive (ARCHDEF) à l'aide du mot clé SINC.
Le script de génération appelé est un XML de génération d'application de l'utilitaire de génération qui doit être personnalisé et unique pour chaque projet J2EE. Ce script de génération fait également référence à un script d'exécution de l'utilitaire de génération qui contient les propriétés globales de cet utilitaire et les commandes d'exécution Eclipse permettant d'afficher Eclipse sous z/OS sans interface graphique et d'exécuter le XML de génération sélectionné. Généralement, le script BWBASTR personnalisé est utilisé par tous les scripts de génération Build. Le type de langage de tous les scripts de génération de l'utilitaire de génération doit être J2EEAST. Le type de langage du script BWBASTR doit être un traducteur de langage en texte seul, tel que TEXT ou J2EEPART.
Le script d'exécution de l'utilitaire de génération (BWBASTR) et les exemples de script de génération par projet (projet Java/Jar (BWBASTJ), projet EJB (BWBASTEJ), projet de client d'application (BWBASTAP), projet Web (BWBASTW) et projet EAR (BWBASTE)) peuvent être copiés de la bibliothèque d'exemples de l'utilitaire de génération de SCLM Developer Toolkit dans les projets SCLM des clients sous le type J2EEBLD.
Le format du script de génération inclut les éléments suivants :
Les routines ANT d'AST sont également incluses pour générer l'objet requis. Les scripts de génération SCLM requis sont des versions modifiées des exemples ci-après fournis par AST :
Les routines ci-après ont été extraites du guide Application Server Toolkit.
Cette tâche importe un système de fichiers existant dans un espace de travail.
Attribut | Description | Obligatoire |
---|---|---|
ProjectName | Nom du projet à importer | Oui |
ProjectLocation | Emplacement complet du projet (sous l'espace de travail ou ailleurs dans le système de fichiers). | Non, la valeur par défaut est ${workspaceLocation}/${projectName} |
Exemple : Importez un projet sous le répertoire de l'espace de travail, mais qui ne se trouve pas dans l'espace de travail :
<projectImport ProjectName="myProject"/>
Cette tâche génère le projet spécifié.
Attribut | Description | Obligatoire |
---|---|---|
ProjectName | Nom du projet à générer | Oui |
BuildType | Type de génération | Non, la valeur par défaut est Par incrément. Valeurs possibles : Par incrément et Saturé. |
FailOnError | Indique si les générations doivent échouer en cas d'erreur | Non, la valeur par défaut est true. |
DebugCompilation | Indique si les compilations doivent être déboguées | Non, la valeur par défaut est true. |
Concis (déprécié) | Indique si les messages doivent être imprimés | Non, la valeur par défaut est false. |
ShowErrors | Indique si le journal des générations Ant doit contenir les erreurs de projet | Non, la valeur par défaut est true. |
SeverityLevel | Niveau d'incident à comptabiliser et traiter comme une erreur de génération | Non, la valeur par défaut est ERROR. Valeurs possibles : ERROR, WARNING ou INFORMATION. |
CountValidationErrors | Indique si les incidents de validation doivent être comptabilisés comme des erreurs de projet | Non, la valeur par défaut est true. |
PropertyCountName | Propriété permettant de recevoir le nombre d'erreurs de projet | Non, la valeur par défaut est ProjectErrorCount. |
PropertyMessagesName | Propriété permettant de recevoir les messages d'erreurs du projet | Non, la valeur par défaut est ProjectErrorMessages. |
Exemples :
<projectBuild ProjectName="myProject" />
<projectBuild ProjectName="myProject" failonerror="true" DebugCompilation="false" BuildType="full" /> <echo message="projectBuild: projectName=${projectName} project Error Count=${ProjectErrorCount} project Error Messages=${ProjectErrorMessages}" />
Cette tâche effectue la même opération que l'assistant d'exportation de fichier JAR EJB pour exporter un projet EJB dans un fichier Jar EJB. Cette tâche n'est pas disponible dans les produits qui n'incluent pas d'outils de développement EJB.
Attribut | Description | Obligatoire |
---|---|---|
EJBProjectName | Nom du projet EJB (Sensible à la casse) | Oui |
EJBExportFile | Chemin d'accès absolu du fichier JAR EJB. | Oui |
ExportSource | Indique si les fichiers source doivent être inclus. | Non, la valeur par défaut est false. |
Overwrite | Indique si le fichier existant doit être remplacé. | Non, la valeur par défaut est false. |
Exemple : Exportez le projet "EJBProject" dans "EJBProject.jar"
<ejbExport EJBProjectName="EJBProject" EJBExportFile="EJBProject.jar"/>
Cette tâche effectue la même opération que l'assistant d'exportation de fichier WAR pour exporter un projet Web dans un fichier WAR.
Attribut | Description | Obligatoire |
---|---|---|
WARProjectName | Nom du projet Web (Sensible à la casse) | Oui |
WARExportFile | Chemin d'accès absolu du fichier WAR | Oui |
ExportSource | Indique si les fichiers source doivent être inclus. | Non, la valeur par défaut est false. |
Overwrite | Indique si le fichier existant doit être remplacé. | Non, la valeur par défaut est false. |
Exemple : Exportez le projet "ProjectWeb" dans "ProjectWeb.war"
<warExport WARProjectName="ProjectWeb" WARExportFile="ProjectWeb.war"/>
Cette tâche effectue la même opération que l'assistant d'exportation de fichier WAR pour exporter un projet Web dans un fichier WAR.
Attribut | Description | Obligatoire |
---|---|---|
EARProjectName | Nom du projet d'application d'entreprise (Sensible à la casse) | Oui |
EARExportFile | Chemin d'accès absolu du fichier EAR | Oui |
ExportSource | Indique si les fichiers source doivent être inclus. | Non, la valeur par défaut est false. |
IncludeProjectMetaFiles | Indique si les fichiers de métadonnées de projet qui contiennent entre autres le chemin de génération Java et les noms de projet doivent être inclus. Utilisé lors de la réimportation comme projets binaires. | Non, la valeur par défaut est false. |
Overwrite | Indique si le fichier existant doit être remplacé. | Non, la valeur par défaut est false. |
Exemple : Exportez le projet "EARProject" dans "EARProject.ear"
<earExport EARProjectName="EARProject" EARExportFile="EARProject.ear"/>
Cette tâche effectue la même opération que l'assistant d'exportation de fichier WAR pour exporter un projet Web dans un fichier WAR.
Attribut | Description | Obligatoire |
---|---|---|
AppClientProjectName | Nom du projet de client d'application (Sensible à la casse) | Oui |
AppClientExportFile | Chemin d'accès absolu du fichier JAR du client d'application | Oui |
ExportSource | Indique si les fichiers source doivent être inclus. | Non, la valeur par défaut est false. |
Overwrite | Indique si le fichier existant doit être remplacé. | Non, la valeur par défaut est false. |
Exemple : Exportez le projet "ProjectClient" dans "ProjectClient.jar" :
<appClientExport AppClientProjectName="ProjectClient" AppClientExportFile="ProjectClient.jar"/>
Le script d'exécution AST est référencé par les scripts de génération AST (type=J2EEBLD lang=TEXT).
/* Cet exemple de script de génération permet de générer des projets J2EE à l'aide d'AST (Application Server toolkit) sous z/OS. AST est un générateur Eclipse sans interface graphique, installable de manière distincte en dehors de SCLM Developer toolkit. Cet exemple de script doit être personnalisé et se trouver dans le type SCLM du J2EEBLD appelé à partir d'un membre de définition d'archive J2EE via le mot clé de définition d'archive SINC. Il doit être stocké avec un langage de texte tel que TEXT ou J2EEPART. Les arguments BUILDFILE et WORKSPACE sont transmis en interne à partir du traducteur de langage AST J2EE de SCLM Developer Toolkit */ parse arg $args parse var $args BUILDFILE WORKSPACE /*--------------------- Personnalisation de l'utilisateur ---------------*/ /* Personnalisez les valeurs de variable suivantes : AST_DIR et JAVA_DIR */ /* AST_DIR est le répertoire Eclipse z/OS où AST est installé */ AST_DIR='/u/AST/eclipse' /* JAVA_DIR est le répertoire bin Java z/OS approprié */ /* Spécifiez le bin Java fourni avec le package AST */ JAVA_DIR='/u/AST/eclipse/jdk/bin' /*------------- Fin de la personnalisation de l'utilisateur --------*/ /* Il n'est pas nécessaire de modifier le reste de l'exemple */ say 'AST Eclipse directory = 'AST_DIR say 'Java bin directory = 'JAVA_DIR say 'BUILDFILE = 'BUILDFILE say 'WORKSPACE = 'WORKSPACE If SUBSTR(WORKSPACE,1,1) /= '/' Then Do say 'ERROR : Invalid WORKSPACE ... Build terminated' exit 8 End /* Les paramètres ci-après sont définis pour un appel d'Eclipse sans interface graphique */ /* Options de paramètre de mémoire Java comprises entre 256 Mo et 512 Mo définies */ /* Augmentez la valeur du paramètre de mémoire maximale en cas d'erreur de mémoire Java */ M_parm = '-Xms256m -Xmx512m' A_parm = '-Dfile.encoding=ISO8859-1 -Xnoargsconversion' D_parm = '-Dwtp.autotest.noninteractive=true' cp_parm = '-cp 'AST_DIR'/startup.jar org.Eclipse.core.launcher.Main' ap_parm = '-application com.ibm.etools.j2ee.ant.RunAnt' w_parm = '-data "'workspace'"' f_parm = '-f 'buildfile PARMS = M_parm' 'A_parm' 'D_parm' 'cp_parm' 'ap_parm' 'w_parm' 'f_parm /* Les options de vidage Java ont été désactivées pour empêcher les vidages Java */ /* lors d'incidents d'allocation de mémoire */ JAVA_NODUMP='export JAVA_DUMP_OPTS="ONANYSIGNAL(NONE)"' JAVA_CMD = JAVA_DIR'/java 'PARMS AST_BUILD = JAVA_NODUMP' ; 'JAVA_CMD say "Invoking java launch of Eclipse ..." say AST_BUILD say "Executing ..." AST_BUILD ASTrc = rc If ASTrc = 23 Then say 'WARNING: UNINITIALIZED workspace' Else If ASTrc = 15 Then say 'ERROR : WORKSPACE is already BEING USED' If ASTrc /= 0 then Do say 'ERROR : BUILD FAILED - return code = 'ASTrc EXIT 8 End EXIT 0
Le script de génération suivant est type=J2EEBLD lang=J2EEAST. Il accepte tout nom de huit caractères ou moins. Les variables sont définies au format XML standard.
<!-- BWBASTJ : Exemple de JAR J2EE pour AST Il s'agit d'un exemple de script XML de génération à exécuter à l'aide d'AST Eclipse sans interface graphique sous z/OS. Le script de génération SCLM est copié dans le répertoire de zone de travail approprié sur le système de fichiers USS z/OS. Le mot clé projectlocation est remplacé de manière dynamique par l'espace de travail affecté approprié. Vérifiez que la ligne projectlocation est conservée en l'état : Personnalisez le projet et les variables de propriétés ci-après project name : Remplacez ASTJAR par le nom de projet de l'application Java AST_SHSCRIPT : Nom du squelette du script d'exécution AST pour la génération SCLM_ARCHDEF : Nom de la définition d'archive à générer JAR_FILE_NAME : Nom du fichier JAR créé SCLM_BLDMAP : Si la valeur est YES, inclure dans le répertoire MANIFEST du fichier JAR. Fournit un audit et une mappe de génération pour les composants inclus --> <project name="ASTJAR" default="init" basedir="."> <property name="AST_SHSCRIPT" value="ASTRUN"/> <property name="SCLM_ARCHDEF" value="JAR1"/> <property name="JAR_FILE_NAME" value="ASTjar.jar"/> <property name="SCLM_BLDMAP" value="NO"/> <target name="init"> <projectImport projectname="${ant.project.name}" projectlocation="$WORKSPACE" /> <Eclipse.refreshLocal resource="${ant.project.name}" depth="infinite" /> <echo message="refresh done" /> <projectBuild ProjectName="${ant.project.name}" failonerror="true" DebugCompilation="true" BuildType="full" /> <jar update="true" destfile="${JAR_FILE_NAME}"> <fileset dir="." excludes="**/*.java"/> </jar> </target> </project>
Le script de génération suivant est type=J2EEBLD lang=J2EEAST.
<!-- BWBASTW : Exemple J2EE pour AST Il s'agit d'un exemple de script XML de génération à exécuter à l'aide d'AST Eclipse sans interface graphique sous z/OS. Le script de génération SCLM est copié dans le répertoire de zone de travail approprié sur le système de fichiers USS z/OS. Le mot clé projectlocation est remplacé de manière dynamique par l'espace de travail affecté approprié. Vérifiez que la ligne projectlocation est conservée en l'état : Personnalisez le projet et les variables de propriétés ci-après project name : Remplacez ASTWAR par le nom de projet de l'application WAR AST_SHSCRIPT : Nom du squelette du script d'exécution AST pour la génération SCLM_ARCHDEF : Nom de la définition d'archive à générer WAR_NAME : Nom du fichier WAR créé SCLM_BLDMAP : Si la valeur est YES, inclure dans le répertoire MANIFEST du fichier WAR. Fournit un audit et une mappe de génération pour les composants inclus --> <project name="ASTWAR" default="init" basedir="."> <property name="AST_SHSCRIPT" value="BWBASTR"/> <property name="SCLM_ARCHDEF" value="WAR1"/> <property name="WAR_NAME" value="ASTwar.war" /> <property name="SCLM_BLDMAP" value="NO"/> <target name="init"> <projectImport projectname="${ant.project.name}" projectlocation="$WORKSPACE" /> <Eclipse.refreshLocal resource="${ant.project.name}" depth="infinite" /> <echo message="refresh done" /> <projectBuild ProjectName="${ant.project.name}" failonerror="true" DebugCompilation="true" BuildType="full" /> <warExport WARProjectName="${ant.project.name}" ExportSource="true" WARExportFile="${WAR_NAME}"/> </target> </project>
Le script de génération suivant est type=J2EEBLD lang=J2EEAST.
<!-- BWBASTEJ : Exemple EJB J2EE pour AST Il s'agit d'un exemple de script XML de génération à exécuter à l'aide d'AST Eclipse sans interface graphique sous z/OS. Le script de génération SCLM est copié dans le répertoire de zone de travail approprié sur le système de fichiers USS z/OS. Le mot clé projectlocation est remplacé de manière dynamique par l'espace de travail affecté approprié. Vérifiez que la ligne projectlocation est conservée en l'état : Personnalisez le projet et les variables de propriétés ci-après project name : Remplacez ASTEJB par le nom de projet de l'application EJB AST_SHSCRIPT : Nom du squelette du script d'exécution AST pour la génération SCLM_ARCHDEF : Nom de la définition d'archive à générer EJB_NAME : Nom du fichier JAR EJB créé SCLM_BLDMAP : Si la valeur est YES, inclure dans le répertoire MANIFEST du fichier JAR, WAR ou EAR. Fournit un audit et une mappe de génération pour les composants inclus --> <project name="ASTEJB" default="init" basedir="."> <property name="AST_SHSCRIPT" value="ASTRUN"/> <property name="SCLM_ARCHDEF" value="EJB1"/> <property name="EJB_NAME" value="ASTejb.jar" /> <property name="SCLM_BLDMAP" value="NO"/> <target name="init"> <projectImport projectname="${ant.project.name}" projectlocation="$WORKSPACE" /> <Eclipse.refreshLocal resource="${ant.project.name}" depth="infinite" /> <echo message="refresh done" /> <projectBuild ProjectName="${ant.project.name}" failonerror="true" DebugCompilation="true" BuildType="full" /> <ejbExport ExportSource="true" EJBProjectName="${ant.project.name}" EJBExportFile="${EJB_NAME}"/> </target> </project>
Le script de génération suivant est type=J2EEBLD lang=J2EEAST.
<!-- BWBASTE : Exemple d'EAR J2EE pour AST Il s'agit d'un exemple de script XML de génération à exécuter à l'aide d'AST Eclipse sans interface graphique sous z/OS. Le script de génération SCLM est copié dans le répertoire de zone de travail approprié sur le système de fichiers USS z/OS. Le mot clé projectlocation est remplacé de manière dynamique par l'espace de travail affecté approprié lors de la génération. Vérifiez que la ligne projectlocation est conservée en l'état. Personnalisez le projet et les variables de propriétés ci-après project name : Remplacez ASTEAR par le nom de projet de l'application EAR AST_SHSCRIPT : Nom du squelette du script d'exécution AST pour la génération SCLM_ARCHDEF : Nom de la définition d'archive à générer EAR_NAME : Nom du fichier EAR créé SCLM_BLDMAP : Si la valeur est YES, inclure dans le répertoire MANIFEST du fichier JAR, WAR ou EAR. Fournit un audit et une mappe de génération pour les composants inclus --> <project name="ASTEAR" default="init" basedir="."> <property name="AST_SHSCRIPT" value="BWBASTR"/> <property name="SCLM_ARCHDEF" value="EAR1"/> <property name="EAR_NAME" value="ASTear.ear"/> <property name="SCLM_BLDMAP" value="NO"/> <target name="init"> <projectImport projectname="${ant.project.name}" projectlocation="$WORKSPACE" /> <Eclipse.refreshLocal resource="${ant.project.name}" depth="infinite" /> <echo message="refresh done" /> <projectBuild ProjectName="${ant.project.name}" failonerror="true" DebugCompilation="false" BuildType="full" /> <earExport EARProjectName="${ant.project.name}" ExportSource="true" EARExportFile="${EAR_NAME}"/> </target> </project>
Le format d'ARCHDEF est le même que pour la procédure de génération J2EEANT normale.
SINC SCRIPT1 J2EEBLD INCLD XX000001 SOURCE INCL PAULWAR2 ARCHDEF OUT1 * J2EEEAR LIST * J2EELIST LKED J2EEOBJ
SCLM permet la prise en charge de SQLJ via les traducteurs Java/J2EE livrés avec SCLM Developer Toolkit. Ces traducteurs, conjointement avec les scripts de génération AST permettent de stocker et de générer des projets sqlj. Ils offrent des points d'intégration permettant aux routines client de définir des propriétés de personnalisation sqlj db2 et prenant en charge le traitement des liaisons db2 par l'intermédiaire des étapes de génération et de promotion de SCLM via les exits de génération et de promotion de SCLM.
Pour plus d'informations sur la prise en charge de SQLJ, reportez-vous au Guide d'utilisation de SCLM Developer Toolkit.
La prise en charge de SQLJ dans SCLM (à l'aide de la méthode AST) peut se résumer ainsi :
Le support sqlj DB2 est installé. Le répertoire db2 ci-après (ou un répertoire similaire selon le répertoire d'installation du site) doit se trouver dans le système de fichiers USS z/OS : /usr/lpp/db2/db2810/* (il s'agit du répertoire de db2 v8). Ce répertoire est requis pour la personnalisation du script de génération SQLJ. Pour SQLJ, des dépendances de chemin d'accès aux classes existent sur /usr/lpp/db2/db2810/jcc/classes/sqlj.zip. Pour db2sqljcustomize, les dépendances de chemin d'accès aux classes existent sur /usr/lpp/db2/db2810/jcc/classes/ db2jcc.jar.
Un nouveau traducteur de langage SQLJ est fourni et doit être attribué en tant que type de langage à l'ensemble du code source SQLJ enregistré dans SCLM. Ce nouveau traducteur requiert la définition de types SCLM supplémentaires. Le nouveau traducteur est similaire au traducteur JAVA mais il contient des définitions IOTYPE supplémentaires pour les types de sortie SCLM SQLJSER et DBRMLIB. Si le client ne génère pas de fichiers de module d'interrogation de base de données dans le cadre de l'étape db2sqljcustomize, cet élément DBRMLIB IOTYPE peut être retiré de la définition de langage SQLJ. (Référence à l'exemple de définition de traducteur SQLJ BWBTRANS). Dans le projet PROJDEF, générez le nouveau traducteur SQLJ et les types supplémentaires, comme suit :
Les clients doivent définir les propriétés DB2 SQLJ dans le script de génération SQLJ principal (exemple BWBASTSQ) qui se trouve dans le type J2EEBLD. Ces propriétés seront utilisées dans les étapes "sqlj" et "db2sqljcustomize".
Vous trouverez ci-après une liste des définitions de propriétés "sqlj" et "db2sqljcustomize" requises.
<!-- spécifiez l'emplacement d'exécution du bin JAVA --> <property name="JAVA_BIN" value="/usr/lpp/java/J5.0/bin"/>
<!-- spécifiez l'emplacement de la routine d'exécution sqlj et db2sqljcustomize bwbsqlc.rex (exemple BWBSQLC) --> <!-- Par défaut, cet exemple doit se trouver dans le répertoire d'installation de SCLM DT ou y être copié --> <property name="sqlj.exec" value="/etc/SCLMDT/bwbsqlc.rex"/> <!-- specify global property arguments below for sqlj processing --> <property name="sqlj.arg" value="-compile=false -status -linemap=NO -db2optimize"/>
<!-- spécifiez l'emplacement du fichier db2jcc.jar à inclure dans le chemin d'accès aux classes db2sqljcustomize --> <property name="db2sqljcustomize.cp" value="/usr/lpp /db2/db2810/jcc/classes/db2jcc.jar":./SRC:/usr/lpp/db2810/jcc/ classes/db2jcc_license_cisuz.jar"/ > <!-- spécifiez les arguments des propriétés globales ci-après pour db2sqljcustomize --> <property name="db2sqljcustomize.arg" value='-automaticbind NO -onlinecheck YES -staticpositioned YES -bindoptions "ISOLATION(CS)" -genDBRM'/> <!-- Vous trouverez ci-après le nom du fichier de propriétés temporaire à transmettre à une routine de propriétés utilisateur pour stocker des propriétés d'argument supplémentaires. Aucune personnalisation n'est requise --> <property name="db2sqljcustomize.propfile" value="user.properties"/> <!-- Vous trouverez ci-après le nom d'un programme utilisateur facultatif qui sera exécuté immédiatement avant le processus db2sqljcustomize. Il met à jour dynamiquement un fichier de propriétés db2sqljcustomize. propfile à utiliser comme entrée de la commande db2sqljcustomize La routine db2sqljcustomize (property: sqlj.exec) concaténera et utilisera à la fois les propriétés d'argument définies dans ce fichier build.xml (db2sqljcustomize.arg) et les propriétés d'argument lues à partir du fichier des propriétés utilisateur. La routine utilisateur recevra les arguments suivants : basedir : Répertoire de base correspondant au répertoire de l'espace de travail propfile : Nom du fichier de propriétés à créer (fichier temporaire à créer dans l'espace de travail) sqljf : Tous les noms de fichier .ser à traiter par db2sqljcustomize Remarque : Le fichier de propriétés doit être basedir'/'propfile Les propriétés doivent être définies dans le fichier au format suivant argument=value (eg: singlepkgname=longname:pkgname) (une déclaration de propriété par ligne) eg: singlepkgname=src/TeSQLJ986_SJProfile0.ser:SQLJ986 singlepkgname=src/TeSQLJ987_SJProfile0.ser:SQLJ987 pkgversion=1 url=jdbc:db2://site1.com:80/MVS01 qualifier=DBT Si aucun programme utilisateur n'est requis, spécifiez : <property name="sqlj.userpgm" value="NONE"/> --> <property name="sqlj.userpgm" value="/u/userdir/BWBSQLD"/> *** fin des paramètres de propriété ***
Les propriétés d'argument sont utilisées pour la génération de la chaîne d'arguments requise dans l'appel SQLJ ou db2sqljcustomize. Exemple :
db2sqljcustomize -automaticbind NO -collection ${db2.collid} -url ${db2.url} -user ${db2.user} -password ???????? -onlinecheck YES -qualifier ${db2.qual} -staticpositioned YES - pkgversion ${db2.packversion} -bindoptions "ISOLATION (CS)" -genDBRM -DBRMDir DBRMLIB -singlepkgname ${db2.pack}
* * LKED J2EEOBJ * J2EE Build translator * * Source to include in build * INCLD XX000001 ASTSQLJ * .classpath INCLD XX000002 ASTSQLJ * .project INCLD XX000103 ASTSQLJ * .runtime INCLD BU000082 ASTSQLJ * build.xml INCLD DE000155 ASTSQLJ * deploy.xml INCLD SQ000001 ASTSQLJ * SQLJAntScripts/sqlj.customize.xml INCLD SQ000002 ASTSQLJ * builder/sqlJava.java INCLD SQ000003 ASTSQLJ * builder/sqlJava.sqlj INCLD TE000137 ASTSQLJ * Tester.java INCLD SQ000004 ASTSQLJ * builder/sqlJava_SJProfile0.ser * * Build script and generated outputs * SINC ASTSQLJ J2EEBLD * J2EE JAR Build script OUT1 * J2EEJAR LIST * J2EELIST
<project name="ASTSQLJ" default="compile" basedir="."> <property name="AST_SHSCRIPT" value="BWBASTR"/> <property name="SCLM_ARCHDEF" value="ASTSQLJ"/> <property name="JAR_FILE_NAME" value="ASTSQLJ.jar"/> <!-- spécifiez l'emplacement d'exécution du bin JAVA --> <property name="JAVA_BIN" value="/u/java/J5.0/bin"/> <!-- spécifiez l'emplacement du fichier db2jcc.jar à inclure dans le chemin d'accès aux classes db2sqljcustomize --> <property name="db2sqljcustomize.cp" value="/usr/lpp/products/db2/db2810/jcc/ classes/db2jcc.jar:.:/usr/lpp/products/db2/db2810/jcc/classes/ db2jcc_license_cisuz.jar"/> <!-- specify global property arguments below for sqlj processing --> <property name="sqlj.arg" value="-compile=false -status -linemap=NO -db2optimize"/> <!-- spécifiez les arguments des propriétés globales ci-après pour db2sqljcustomize --> <property name="db2sqljcustomize.arg" value='-automaticbind NO -onlinecheck YES -bindoptions "ISOLATION(CS)" -genDBRM'/> <!-- spécifiez l'emplacement de la routine d'exécution db2sqljcustomize BWBSQLC --> <property name="db2sqljcustomize.exec" value="/u/SCLMDT/bwbsqlc.rex&cdqg;/> <!-- Vous trouverez ci-après le nom du programme utilisateur à exécuter dans le cadre de la procédure db2sqljcustomize. Il met à jour de manière dynamique un fichier de propriétés à utiliser comme entrée de la commande db2sqljcustomize --> <property name="sqlj.userpgm" value="NONE"/> <target description="Pre-Compile SQLJ Files" name="sqlj"> <echo> SQLJ TRANSLATOR </echo> <apply executable="java" skipemptyfilesets="true" type="file" failonerror="true" logerror="true"> <arg line="-Dfile.encoding=ISO8859-1 -Xnoargsconversion"/> <arg line="sqlj.tools.Sqlj"/> <arg line="${sqlj.arg}"/> <!-- SER Files --> <fileset dir="."> <patternset> <include name="**/*.sqlj"/> </patternset> </fileset> </apply> </target> <target description="Customize SQLJ Files" name="db2sqljcustomize" depends="sqlj"> <!-- Le code ci-après envoie les propriétés dans un fichier de propriétés db2 props -> <apply executable="${db2sqljcustomize.exec}" skipemptyfilesets ="true" parallel="true" type="file" failonerror="true" relative="true"> <arg value="${basedir}"/> <arg value="${db2sqljcustomize.cp}"/> <arg value="${sqlj.userpgm}"/> <arg value="${db2sqljcustomize.propfile}"/> <arg value="db2sqljcustomize ${db2sqljcustomize.arg}"/> <arg value="sqlj-source"/> <!-- SER Files --> <fileset dir="."> <patternset> <include name="**/*.ser"/> </patternset> </fileset> </apply> </target> <target name="compile" depends="db2sqljcustomize"> <projectImport projectname=&odq;ASTSQLJ&cdqg; projectlocation="$WORKSPACE" /> <eclipse.refreshLocal resource=&odq;ASTSQLJ&cdqg;depth="infinite" /> <echo message="refresh done" /> <projectBuild ProjectName=&odq;ASTSQLJ&cdqg;failonerror="true" DebugCompilation="true" BuildType="full" /> <jar update="true" destfile="${JAR_FILE_NAME}"> <fileset dir="." excludes="**/*.java"/> </jar> </target> </project>
Par défaut, la source Java est copiée dans l'espace de travail USS au format ASCII avant que les générations de compilation ne soient effectuées. Cela se produit même si la source Java est stockée dans SCLM au format EBCDIC.
Si l'utilisateur demande que la source Java soit incluse dans le fichier d'archive (JAR), la source est par défaut au format ASCII. Il est toutefois possible de configurer les scripts de génération de sorte que la source Java soit copiée dans l'espace de travail et compilée au format EBCDIC pour que, si une inclusion de la source Java est souhaitée, cette dernière soit au format EBCDIC.
Pour inclure la source Java au format EBCDIC, les scripts de génération suivants doivent être modifiés en conséquence, comme suit :
WebSphere Application Server contient un certain nombre d'exemples de projet. Ces derniers peuvent être déployés à l'aide de fichiers EAR préconfigurés ou assemblés à l'aide d'une procédure de génération ANT. Vous trouverez ci-après un exemple d'utilisation de SCLM Developer Toolkit pour restituer ce projet dans SCLM et le générer/déployer sous z/OS à l'aide de la procédure de génération AST. PlantsByWebSphere est un projet J2EE qui implémente un magasin de vente de plantes en ligne. Il est composé des quatre composants suivants :
Ce document décrit un scénario dans lequel cette source est placée dans une structure de projets Eclipse, restituée dans Developer Toolkit, puis générée et déployée sur l'hôte.
* * LKED J2EEOBJ * J2EE Build translator * * Source to include in build * INCL PLANTWE1 ARCHDEF INCL PLANTWE2 ARCHDEF INCL PLANTEJB ARCHDEF * INCLD XX000002 PLANTEAR * .project INCLD OR000005 PLANTEAR * .settings/org.Eclipse.wst.common.component INCLD OR000006 PLANTEAR * .settings/org.Eclipse.wst.common.project.fa * cet.core.xml INCLD BU000147 PLANTEAR * EarContent/build.xml INCLD BU000148 PLANTEAR * EarContent/Database/PLANTSDB/build.xml INCLD MA000028 PLANTEAR * EarContent/META-INF/MANIFEST.MF INCLD AP000004 PLANTEAR * EarContent/META-INF/application.xml INCLD IB000007 PLANTEAR * EarContent/META-INF/ibm-application-bnd.xmi INCLD IB000008 PLANTEAR * EarContent/META-INF/ibm-application-ext.xmi INCLD WA000004 PLANTEAR * EarContent/META-INF/was.policy INCLD PL000017 PLANTEAR * EarContent/Database/PLANTSDB/PLANTSDB.zip INCLD OR000001 PLANTEAR * .settings/org.Eclipse.core.resources.prefs INCLD SE000049 PLANTEAR * EarContent/META-INF/ibmconfig/cells/default * Cell/security.xml INCLD VA000001 PLANTEAR * EarContent/META-INF/ibmconfig/cells/default * Cell/applications/defaultApp/deployments/de * faultApp/variables.xml * * Build script and generated outputs * SINC PLANTEAR J2EEBLD * J2EE EAR Build script OUT1 * J2EEEAR LIST * J2EELIST
<project name="PBWProject" default="init" basedir="."> <property name="AST_SHSCRIPT" value="ASTRUN"/> <property name="SCLM_ARCHDEF" value="PLANTEAR"/> <property name="EAR_NAME" value="PlantsByWebSphere.ear"/> <target name="init"> <projectImport projectname="PBWProject" projectlocation="$WORKSPACE" /> <Eclipse.refreshLocal resource="PBWProject" depth="infinite" /> <echo message="refresh done" /> <projectBuild ProjectName="PBWProject" failonerror="true" DebugCompilation="false" BuildType="full" /> <earExport EARProjectName="PBWProject" EARExportFile="${EAR_NAME}"/> </target> </project>Pour PLANTWE1, le fichier EJB doit se trouver sur le chemin d'accès aux classes lors de la phase de génération. Par conséquent, modifiez le script de génération de PLANTWE1, pour ajouter une propriété CLASSPATH_JARS_FILES, avec la valeur "PlantsByWebSphereEJB.jar".
#----------------------------------------------------------------- # # Exemple de script JACL pour le déploiement d'application J2EE # #----------------------------------------------------------------- # # IBM SCLM Developer Toolkit utilise l'outil wsadmin d'IBM WebSphere Application # Server pour déployer les applications J2EE dans WAS, sous z/OS. L'outil # wsadmin requiert un script JACL pour assister la procédure de déploiement. # Par conséquent, le script JACL doit être installé sous UNIX Systems Services # pour que la procédure de déploiement puisse être appelée. # Cet exemple de script JACL ne doit nécessiter aucune personnalisation. source /u/WebSphere/V6R0/AppServer/samples/bin/AdminUtil.jacl proc ex1 {args} { #-------------------------------------------------------------- # set arguments #-------------------------------------------------------------- set app [lindex $args 0] set appName [lindex $args 1] set cellName [lindex $args 2] set nodeName [lindex $args 3] set serverName [lindex $args 4] #-------------------------------------------------------------- # set up globals #-------------------------------------------------------------- global AdminConfig global AdminControl global AdminApp #-------------------------------------------------------------- # -- was a earfile name supplied #-------------------------------------------------------------- if {[llength $app] == 0} { puts "deploy: Error -- No application specified." return } #-------------------------------------------------------------- # -- was the appname supplied #-------------------------------------------------------------- if {[llength $appName] == 0} { puts "deploy: Error -- Application name not specified." return } #-------------------------------------------------------------------- # Create J2C Resource Adapter #-------------------------------------------------------------------- createJ2CResourceAdapter $nodeName $serverName #-------------------------------------------------------------------- # Setup security cell #-------------------------------------------------------------------- set secAuthAlias "$cellName/samples" set secDescript "JAAS Alias for WebSphere Samples" set secUserID "samples" set secPassword "s1amples" createJAASAuthenticationAlias $cellName $secAuthAlias $secDescript $secUserID $secPassword #-------------------------------------------------------------------- # Create JDBC Provider #-------------------------------------------------------------------- set templName "Cloudscape JDBC Provider (XA)" # All Samples that need JDBC Provider should use/share this one set provName "Samples Cloudscape JDBC Provider (XA)" createJDBCProvider $nodeName $serverName $templName $provName #-------------------------------------------------------------------- # Create Datasource #-------------------------------------------------------------------- set templName "Cloudscape JDBC Driver XA DataSource" set dsName "PLANTSDB" set dsJNDI "jdbc/PlantsByWebSphereDataSource" set dsDesc "Data source for the Plants by WebSphere entity beans" set dsAuthMech "BASIC_PASSWORD" set dbName "\${APP_INSTALL_ROOT}/\${CELL}/PlantsByWebSphere.ear/ Database/PLANTSDB" set secAuthAlias "N_O_N_E" set connAttrs "upgrade=true" createDatasource $nodeName $serverName $provName $templName $dsName $dsJNDI $dsDesc $dsAuthMech $dbName $secAuthAlias $connAttrs #-------------------------------------------------------------------- # Create Connection Factory (use builtin_rra) #-------------------------------------------------------------------- set dsName "PLANTSDB" set cfName "PLANTSDB_CF" set cfAuthMech "BASIC_PASSWORD" set secAuthAlias "N_O_N_E" set cfi "javax.resource.cci.ConnectionFactory" createConnectionFactory $nodeName $serverName $provName $dsName $cfName $cfAuthMech $secAuthAlias $cfi #-------------------------------------------------------------------- # Create Mail Session #-------------------------------------------------------------------- set provName "Built-in Mail Provider" set msName "PlantsByWebSphere Mail Session" set jndiName "mail/PlantsByWebSphere" set mailTransportHost "yourcompany.ComOrNet" set mailFrom "userid@yourcompany.ComOrNet" createMailSession $cellName $nodeName $provName $msName $jndiName $mailTransportHost $mailFrom #-------------------------------------------------------------- # Setup options for the deployment # Additinal options can be added here as required # For Example: # lappend app_options -update # lappend app_options -appname MyAppName # lappend app_options -contextroot MyAppName # lappend app_options -preCompileJSPs # lappend app_options -defaultbinding.force # for a full list of options please use the AdminApp command # wsadmin [return] # $AdminApp options - generic options # or # $AdminApp options MyApp.ear - valid options for your ear file # lappend app_options -node WXP-KEFA25B #-------------------------------------------------------------- puts "deploy: installing the application" set app_options [list -server $serverName] lappend app_options -node $nodeName lappend app_options -verbose lappend app_options -usedefaultbindings lappend app_options -deployejb lappend app_options -deployejb.dbtype DERBY_V10 #-------------------------------------------------------------- # Install the application onto the server #-------------------------------------------------------------- $AdminApp install $app $app_options #-------------------------------------------------------------- # Save all the changes #-------------------------------------------------------------- puts "deploy: saving the configuration" $AdminConfig save #-------------------------------------------------------------- # Start the installed application #-------------------------------------------------------------- puts "Starting the application..." set appManager [$AdminControl queryNames cell=$cellName, node=$nodeName,type=ApplicationManager, process=$serverName,*] $AdminControl invoke $appManager startApplication $appName puts "Started the application successfully..." puts "deploy: done." } #----------------------------------------------------------------- # Main #----------------------------------------------------------------- if { !($argc == 5) } { puts "deploy: This script requires 5 parameter: ear file name, application name, cell name, node name and server name" puts "e.g.: deploy /WebSphere/AppServer/installableApps/ jmsample.ear myapp1 myCell myNode myServer" } else { set application [lindex $argv 0] set appName [lindex $argv 1] set cellName [lindex $argv 2] set nodeName [lindex $argv 3] set serverName [lindex $argv 4] ex1 $application $appName $cellName $nodeName $serverName }
Cette section couvre les questions de mise en oeuvre et de configuration qui permettent d'accéder à Build Forge et de l'utiliser. Elle inclut des exemples de personnalisation et de test pour les générations et les promotions SCLM.
Le serveur de console Build Forge se trouve généralement sur une plateforme Windows et doit être configuré avec un appel de service SCLM dans la zone de projet de la console. Au démarrage, ce projet configuré SCLM se connecte au serveur de l'agent Build Forge sous z/OS qui doit déjà se trouver en cours d'exécution. Le plug-in Build Forge permet de démarrer les projets de console à partir de l'environnement RDz en communiquant le serveur de console via une connexion socket. La sortie des exécutions de projet terminées est également accessible à partir du plug-in RDz Build Forge au sein de RDz.
http://www-01.ibm.com/support/docview.wss?&rs=3099&uid=swg24016541
Pour télécharger la version correcte du plug-in, effectuez une mise à jour à partir du site du serveur http://<console_host_name>/prism/eclipse/updateSite/site.xml
Démarrez l'agent Buildforge sous z/OS. Le port par défaut de l'agent est 5555. Par exemple :
bfagent -s -f /répertoire_installation/bfagent-7.1.1.007/src/bfagent.conf
lancez la console BF -> accédez aux serveurs nom d'hôte (nomhôte:port) tester la connexion (à l'aide d'une authentification par ID z/OS)
Exemple de réponse :
Test de l'agent démarré Hôte:nomhôte Port:5555 Version de l'agent : 7.1.1.007 Authentification : userid Plateforme : os/390 18.00 03 Test opérationnel : OK Test de l'agent terminé (durée 9s) Configurez un projet dans la console Build Forge et lancez l'exécution.
La configuration minimale suivante est nécessaire pour activer la fonction SCLM au sein de Build Forge.
L'ID utilisateur doit être un ID utilisateur et un mot de passe valides sur le système z/OS où l'agent s'exécute et où vous souhaitez exécuter le service SCLM. Le groupe d'accès est un groupe d'accès existant ou le groupe d'accès par défaut résidant sur le serveur de console avec les droits appropriés : Administration -> Groupe d'accès.
Testez le connexion établie avec l'hôte en cliquant sur Tester la connexion . Cette opération effectue un test de la connexion établie avec l'agent du serveur exécuté sous z/OS. Le test est réussi s'il apparaît sous la forme suivante :
Test de l'agent démarré Hôte:pthisd1.au.ibm.com Port:5555 Version de l'agent : 7.1.1.007 Authentification : IBMUSER Plateforme : os/390 18.00 03 Test opérationnel : OK Test de l'agent terminé (durée 9s)
Affectez BF_NAME au nom du serveur. (Par exemple : PTHISD1)
Configurez les variables d'environnement SCLM DT suivantes :
Vous devez à présent configurer des projets SCLM pour les différentes demandes de service SCLM. Les exemples ci-après s'appliquent aux services de génération et de promotion SCLM qui sont généralement les principaux services adaptés à la planification de travaux Build Forge. Les exemples de script de projet reposent sur le format d'API XML SCLM indiqué dans le document SCLM Developer Toolkit Administrators Guide.
L'exemple suivant est un exemple de génération configuré distribué dans le fichier SAMPLIB de l'hôte (BWBBFBLD).
echo '<?xml version-"1.0"?>' > Build_input.txt echo '<SCLMDT-INPUT' >> Build_input.txt echo 'xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"' >> Build_input.txt echo 'xsi:noNamespaceSchemaLocation="sclmdt.xsd">' >> Build_input.txt echo '<SERVICE_REQUEST>' >> Build_input.txt echo '<service>SCLM</service>' >> Build_input.txt echo '<session>NONE</session>' >> Build_input.txt echo '<ispprof>HLQ.SCLMDT.ISPPROF</ispprof>' >> Build_input.txt echo '<sclmfunc>BUILD</sclmfunc>' >> Build_input.txt echo '<project>PROJECT</project>' >> Build_input.txt echo '<projdef>PROJDEF</projdef>' >> Build_input.txt echo '<member>MEMBER</member>' >> Build_input.txt echo '<group>GROUP</group>' >> Build_input.txt echo '<type>TYPE</type>' >> Build_input.txt echo '<repdgrp>DEVGRP</repdgrp>' >> Build_input.txt echo '<groupbld>BLDGRP</groupbld>' >> Build_input.txt echo '<bldmode>C</bldmode>' >> Build_input.txt echo '<bldlist>Y</bldlist>' >> Build_input.txt echo '<bldlstds>NONE</bldlstds>' >> Build_input.txt echo '<bldrept>Y</bldrept>' >> Build_input.txt echo '<bldscope>N</bldscope>' >> Build_input.txt echo '<bldmsg>Y</bldmsg>' >> Build_input.txt echo '<bldmsgds>NONE</bldmsgds>' >> Build_input.txt echo '<bldextds>NONE</bldextds>' >> Build_input.txt echo '</SERVICE-REQUEST>' >> Build_input.txt echo '<SCLMDT-INPUT>' >> Build_input.txt cat Build_input.txt | BWBXML >Build_output.txt cat Build_output.txt
Configurez l'exemple ci-dessus avec les options de projet, de groupe, de type, de membre et de génération SCLM, comme indiqué dans l'ANNEXE C de la fonction de génération, à la section relative à l'API DT SCLM.
Ajoutez cet exemple configuré à la première étape de l'exemple Project SCLM Build sample1.
Toutes les autres zones doivent conserver les valeurs par défaut. (Cette étape hérite des paramètres de l'environnement du projet principal.)
Cliquez sur Projets -> SCLM Build sample1 -> Démarrer projet. La sortie de la génération est renvoyée dans la console TRAVAUX -> Balise de génération.
La sortie de la demande et de la réponse sont également stockés dans le répertoire z/OS Unix Systems Services défini par la variable PATH indiquée dans la configuration du serveur. Dans l'exemple précédent, pour le serveur PHISD1 with PATH=/u/IBMUSER/BUILDFORGE, les fichiers de demande et de réponses sont stockés dans le répertoire:
/u/IBMUSER/BUILDFORGE/SCLM_Build1_sample/BUILD_1 : >ls Build_input.txt Build_output.txt
Les fichiers de demandes et de réponses ci-dessus peuvent être renommés lors de l'étape de génération personnalisée.
Les étapes de la section précédente peuvent être répétées pour créer un projet de promotion dans Build Forge. Remplacez le script de génération par un exemple de script de promotion dans la zone "COMMAND" du projet. L'exemple suivant est un exemple de promotion configuré dans le fichier SAMPLIB de l'hôte (BWBBFPRM).
echo '<?xml version="1.0"?>' > Promote_input.txt echo '<SCLMDT-INPUT' >> Promote_input.txt echo 'xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"' >> Promote_input.txt echo 'xsi:noNamespaceSchemaLocation="sclmdt.xsd">' >> Promote_input.txt echo '<SERVICE-REQUEST>' >> Promote_input.txt echo '<service>SCLM</service>' >>Promote_input.txt echo '<session>NONE</session>' >>Promote_input.txt echo '<ispprof>HLQ.SCLMDT.ISPPROF</ispprof>' >>Promote_input.txt echo '<sclmfunc>PROMOTE</sclmfunc>' >>Promote_input.txt echo '<project>PROJECT</project>' >>Promote_input.txt echo '<projdef>PROJDEF</projdef>' >>Promote_input.txt echo '<member>MEMBER</member>' >>Promote_input.txt echo '<group>GROUP</group>' >>Promote_input.txt echo '<type>TYPE</type>' >>Promote_input.txt echo '<repdgrp>DEVGRP</repdgrp>' >>Promote_input.txt echo '<groupprm>PRMGRP</groupprm>' >>Promote_input.txt echo '<prmmode>C</prmmode>' >>Promote_input.txt echo '<prmrept>Y</prmrept>' >>Promote_input.txt echo '<prmscope>N</prmscope>' >>Promote_input.txt echo '<prmmsg>Y</prmmsg>' >>Promote_input.txt echo '<prmmsgds>NONE</prmmsgds>' >>Promote_input.txt echo '<prmextds>NONE</prmextds>' >>Promote_input.txt echo '</SERVICE-REQUEST>' >>Promote_input.txt echo '</SCLMDT-INPUT>' >>Promote_input.txt cat Promote_input.txt | BWBXML >Promote_output.txt cat Promote_output.txt
Configurez l'exemple précédent avec vos options de projet, de type, de membre et de promotion SCLM, comme indiqué dans la fonction Annexe C. API de SCLM Developer Toolkit for Promote.
© Copyright IBM Corporation - 2009
U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
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 auprès du IBM Intellectual Property Department de votre pays ou par écrit à l'adresse suivante :
Le paragraphe suivant ne s'applique ni au Royaume-Uni, ni à aucun pays dans lequel il serait contraire aux lois locales : LE PRESENT DOCUMENT EST LIVRE "EN L'ETAT" SANS AUCUNE GARANTIE EXPLICITE OU IMPLICITE. IBM DECLINE NOTAMMENT TOUTE RESPONSABILITE RELATIVE A CES INFORMATIONS EN CAS DE CONTREFAÇON AINSI QU'EN CAS DE DEFAUT D'APTITUDE A L'EXECUTION D'UN TRAVAIL DONNE. Certaines juridictions n'autorisent pas l'exclusion des garanties implicites, auquel cas l'exclusion ci-dessus ne vous sera pas applicable.
Le présent document peut contenir des inexactitudes ou des coquilles. Ce document est mis à jour périodiquement. Chaque nouvelle édition inclut les mises à jour. IBM peut, à tout moment et sans préavis, modifier les produits et logiciels décrits dans ce document.
Les références à des sites Web non IBM sont fournies à titre d'information uniquement et n'impliquent en aucun cas une adhésion aux données qu'ils contiennent. Les éléments figurant sur ces sites Web ne font pas partie des éléments du présent produit IBM et l'utilisation de ces sites relève de votre seule responsabilité.
IBM pourra utiliser ou diffuser, de toute manière qu'elle jugera appropriée et sans aucune obligation de sa part, tout ou partie des informations qui lui seront fournies.
Les licenciés souhaitant obtenir des informations permettant : (i) l'échange des données entre des logiciels créés de façon indépendante et d'autres logiciels (dont celui-ci), et (ii) l'utilisation mutuelle des données ainsi échangées, doivent adresser leur demande à :
Ces informations peuvent être soumises à des conditions particulières, prévoyant notamment le paiement d'une redevance.
Le logiciel sous licence décrit dans cette documentation et tous les éléments sous licence disponibles s'y rapportant sont fournis par IBM conformément aux dispositions de l'IBM Customer Agreement, des Conditions internationales d'utilisation des logiciels IBM ou de tout autre accord équivalent.
Les données de performance indiquées dans ce document ont été déterminées dans un environnement contrôlé. Par conséquent, les résultats peuvent varier de manière significative selon l'environnement d'exploitation utilisé. Certaines mesures évaluées sur des systèmes en cours de développement ne sont pas garanties sur tous les systèmes disponibles. En outre, elles peuvent résulter d'extrapolations. Les résultats peuvent donc varier. Il incombe aux utilisateurs de ce document de vérifier si ces données sont applicables à leur environnement d'exploitation.
Les informations concernant des produits non IBM ont été obtenues auprès des fournisseurs de ces produits, par l'intermédiaire d'annonces publiques ou via d'autres sources disponibles. IBM n'a pas testé ces produits et ne peut confirmer l'exactitude de leurs performances ni leur compatibilité. Elle ne peut recevoir aucune réclamation concernant des produits non IBM. Toute question concernant les performances de produits non IBM doit être adressée aux fournisseurs de ces produits.
Toute instruction relative aux intentions d'IBM pour ses opérations à venir est susceptible d'être modifiée ou annulée sans préavis, et doit être considérée uniquement comme un objectif.
Le présent document peut contenir des exemples de données et de rapports utilisés couramment dans l'environnement professionnel. Ces exemples mentionnent des noms fictifs de personnes, de sociétés, de marques ou de produits à des fins illustratives ou explicatives uniquement. Toute ressemblance avec des noms de personnes, de sociétés ou des données réelles serait purement fortuite.
Le présent logiciel contient des exemples de programmes d'application en langage source destinés à illustrer les techniques de programmation sur différentes plateformes d'exploitation. Vous avez le droit de copier, de modifier et de distribuer ces exemples de programmes sous quelque forme que ce soit et sans paiement d'aucune redevance à IBM, à des fins de développement, d'utilisation, de vente ou de distribution de programmes d'application conformes aux interfaces de programmation des plateformes pour lesquels ils ont été écrits ou aux interfaces de programmation IBM. Ces exemples de programmes n'ont pas été rigoureusement testés dans toutes les conditions. Par conséquent, IBM ne peut garantir expressément ou implicitement la fiabilité, la maintenabilité ou le fonctionnement de ces programmes. Les exemples de programme sont fournis "EN L'ETAT", sans garantie d'aucune sorte. IBM ne sera en aucun cas responsable des dommages liés à l'utilisation de ces exemples de programme.
IBM, le logo IBM et ibm.com sont des marques d'International Business Machines Corp. dans la plupart des juridictions du monde. Les autres noms de produit et service sont des marques d'IBM ou d'autres sociétés. La liste actualisée de toutes les marques d'IBM est disponible sur la page Web "Copyright and trademark information" à www.ibm.com/legal/copytrade.shtml.
Rational est une marque d'International Business Machines Corporation et de Rational Software Corporation aux Etats-Unis et/ou dans certains autres pays.
Intel et Pentium sont des marques d'Intel Corporation aux Etats-Unis et/ou dans certains autres pays.
Microsoft, Windows et le logo Windows sont des marques de Microsoft Corporation aux Etats-Unis et/ou dans certains autres pays.
Java et toutes les marques et logos incluant Java sont des marques de Sun Microsystems, Inc. aux Etats-Unis et/ou dans certains autres pays.
UNIX est une marque enregistrée de The Open Group aux Etats-Unis et/ou dans certains autres pays.