Come Together Part Ii - The secrets of mainframe island - Wie iws und ejm zusammenarbeiten

Come together Part II The Secrets of Mainframe Island - Comment IWS et EJM travaillent ensemble Bienvenue à la présentation "The Secrets of Mainframe Island" Ca parle de quoi? Il s'agit de la combinaison de IWS et EJM. IWS est l'abréviation de "IBM Workload Scheduler" et est un système logiciel permettant de contrôler les tâches, en particulier sur les systèmes mainframe.IWS signifie IBM Workload Scheduler et est un système logiciel permettant de contrôler les tâches, en particulier sur les systèmes mainframe. IWS est encore connu de nombreuses personnes sous les anciens noms TWS ou OPC. EJM signifie "Enterprise Job Manager" et est un système logiciel de Betasystems, Ceci permet à IWS d'être étendu avec des fonctions pour le Distributed Scheduling et le Joblog Management. EJM s'appelait autrefois Beta48. Distributed est le mot d'IBM pour le traitement des travaux par lots sur les systèmes non-Mainframe, par exemple AIX, Linux ou Windows. Voici comment IWS et EJM peuvent vous aider dans le traitement multiplateforme. Qu'est-il arrivé jusqu'à présent ... Au début, Mainframe était complètement seul dans le traitement du Jobs. Puis les premières connexions avec les possibilités existantes de TWS ont été construites. Cette solution a été appelée TWS-E2E. La solution a été étendue par l'ajout de EJM. Les fonctions de l'Agentless Scheduling sont flambant neuves. Afin que Jobs puisse être contrôlé dans la DMZ. Traitement multiplateforme de Batch Jobs. Les premières versions du système IWS ont été conçues uniquement pour le contrôle de Jobs sur les systèmes mainframe. À un certain point, TWS Tracker a également été ajouté pour les systèmes Unix. À partir de la version 8.1 de TWS, les Tracker ont été remplacés par des FTA (Fault Tolerant Agent). Afin d'utiliser FTA, un environnement complexe doit être exploité sur le Mainframe. Mais alors vous pouvez continuer à utiliser les agents existants des systèmes Maestro. Maestro est un système de planification pour la planification distribuée. Cela a été appelé plus *** "TWS for Distributed". Dans les versions ultérieures de TWS, des types d'agents supplémentaires ont été ajoutés. Certaines différences importantes avec EJM ont été conservées. Devrait-on utiliser Shadow-Jobs ou une connexion directe? Pour élargir les fonctions de IWS Bridge-Solutions (solutions de pont) ont été offerts. Mais ces solutions ont un inconvénient. Pour chaque Distributed-Job, un Shadow-Job devait être traité sur le Mainframe. Shadow-Jobs sont démarrés sur le Mainframe. La connexion à la Distributed-System est activée à partir du oui. Là se déroule l'exécution effective de la Distributed-Job. EJM n'a pas besoin de Shadow-Jobs. C'est un gros avantage. Les travaux EJM sont envoyés directement de l'IWS Workstation au système distribué. Les Joblogs arrivent directement en Beta92 sur le Mainframe. La communication utilise TCP/IP et IWS User Interfaces. Cela permet de sauvegarder les ressources du système sur le Mainframe. Par exemple. CPU, Memory, Service Units et JES Initiators. Nous arrivons à l'architecture d'EJM: Voici un aperçu de tous les types d'agents et de toutes les tâches. Vous pouvez le faire avec IWS et EJM. Ceci est nécessaire dans toutes les situations: Le contrôleur IWS pour contrôler l'ordonnancement central. Le maître Beta92 Lock Manager pour la gestion des joblogs. Sur les systèmes z / OS IWS-Tracker et Beta92 Sub Systems. Pour EJM, cela est également nécessaire: Un EJM Task sur le Mainframe. Sur chaque serveur connecté, un agent Beta92 EJM. Ceci est nécessaire pour IWS-E2E: Un End-to-End Task supplémentaire, une connexion et une installation sur l'Unix System Service (USS), et sur chaque système distribué, un agent FTA (Scheduling) et un agent Beta92 OSY (Joblogs). Si vous utilisez uniquement EJM et n'utilisez pas TWS-E2E, vous pouvez enregistrer du Task. Cela permet également d'atteindre la DMZ. EJM utilise un Task central sur la Mainframe pour contrôler le Jobs et les agents. L'EJM Task (STC) est plus économique que, par exemple, une tâche IWS-E2E. Et EJM n'exige pas de plan de jour spécial (Current Plan) pour Jobs distribuée. Les avantages du EJM Task sont: La communication réseau centrale n'a pas besoin d'un Shadow-Jobs. Le contrôle Jobs central permet Workload Balancing (WLB). L'administration centrale pour les systèmes, Agent, Connection et Users est possible. Vous pouvez accéder de manière centralisée aux journaux depuis EYM-Jobs actif et complété. Il y a des interfaces utilisateur dans le TSO (z/OS) et dans le Browser. IWS Workstation peut être connecté très différemment avec les agents EJM. Un tel Single Configuration est assez simple. Un IWS Workstation est exactement connecté à un agent EJM. La plupart du temps, vous avez besoin de plus de fiabilité. Alors un tel Cluster Configuration est nécessaire. Voici deux agents EJM connectés à un IWS Workstation. Les agents travaillent sur deux serveurs. Pour un Cluster Switch, le premier agent EJM envoie un signal à EJM sur le Mainframe. La connexion est ensuite commutée. Le prochain Jobs commence alors sur le nouvel agent actif. Encore mieux, vous êtes préparé avec un tel Group Configuration. Quatre agents EJM sont connectés à un IWS Workstation. Les agents EJM peuvent être hiérarchisés différemment. Ou, avec la même priorité, les travaux sont distribués dans la même quantité à tous les agents. Mais il y a d'autres constructions. Une distribution intelligente de la Jobs travaille avec l'EJM Workload Balancing. Plusieurs agents EJM sont connectés à un IWS Workstation. La distribution de la Jobs fonctionne alors selon les critères du WLB. Les agents EJM envoient constamment leurs données de charge à l'EJM Task. Ceci sélectionne alors le meilleur agent pour le prochain Jobs. Avec Multi-STC, la pyramide est inversée. Voici un agent EJM connecté à plusieurs IWS Workstation. Ceux-ci fonctionnent sur différents systèmes IWS. Ceci est une variante intéressante pour les fonctions interfonctionnelles dans une entreprise. Vous pouvez atteindre un serveur de tous les côtés. Tout nouveau est EJM Agentless. Cela peut également automatiser les tâches dans un DMZ. Ou dans un Cloud System. Dans cet exemple, un IWS Workstation est initialement connecté à un agent EJM. Pour l'agentless, cette connexion ne serait pas nécessaire. Mais c'est souvent utile. Un deuxième poste de travail est connecté à un EJM Remote System dans le DMZ. TLe Remote System n'est pas un agent ou un processus actif. C'est la définition d'une connexion. Au-dessus, le Jobs peut être démarré. Nous avons terminé avec le kit d'agent EJM. Nous arrivons aux fonctions de temps EJM. C'est un défi Scheduling possible. Les intervalles de démarrage courts pour les travaux ne sont pas faciles à mettre en œuvre avec IWS. Cela alourdit le système. Les intervalles difficiles pour le départ sont inférieurs à une minute. Limiter l'exécution des travaux aussi. Difficile pour IWS. Les fenêtres de temps de Jobs, les heures exactes de début, les répétitions fréquentes pour Jobs, tout est difficile avec IWS. Voici quelques exigences pour un Scheduling System. Deux de ces exigences sont présentées plus en détail. Premier exemple: Un Job en cours d'exécution pendant trois heures. Si le temps est dépassé, il devrait se terminer par Return Code 3. Deuxième exemple: un Job devrait commencer toutes les 30 secondes. Pour IWS, ce sont de grands défis. Cela peut être fait très facilement avec les fonctions de temps EJM. Cela ne prend que quelques lignes supplémentaires dans Job. Dans le premier exemple, la durée de Job devrait être limitée à trois heures. Nous pouvons voir ça ici: MAXRUNTIME=180m MAXRUNTIMERC=3 Si le terme est dépassé, le Job se termine par Return Code 3. Dans le deuxième exemple, le Job devrait être démarré toutes les 30 secondes. Nous pouvons voir ça ici: INTERVAL=30s Si les travaux se répètent souvent, il est bon de collecter les Output. Il y a le paramètre OUTPUTPOOLING pour cela. Output peut donc être résumé pendant des heures, des jours ou autrement. Nous avons déjà vu EJM Agentless dans le kit de l'agent. Sur les systèmes distributed avec un traitement étendu, un agent est utile. Dans DMZ, cependant, un agent n'est pas autorisé. Pas même la communication nécessaire. Ici vous pouvez travailler avec la technique Agentless. C'est seulement un agent pour cela. Il n'est pas dans le DMZ. À partir de ce moment, Jobs sera traité via Secure Shell (SSH). Avec les clés sur les systèmes, un traitement en Jobs sans Password est possible. Seul l'agent EJM en dehors de la zone démilitarisée établit les connexions, démarre Jobs, les contrôle et récupère le Joblogs. Les définitions de Agentless sont stockées de manière transparente et sécurisée dans EJM. (dans les panneaux TSO ou dans le ECC). Agentless est également adapté pour Jobs en Computing Clouds. Voici un aperçu de Agentless. Chaque participant Agentless a besoin d'un Key-File (SSL/TLS). Un agent EJM dédié lance le Jobs dans le DMZ via Secure Shell. L'état Job est surveillé pendant l'exécution Job. Après la fin du Job, le Joblog sera transféré à Beta92 sur le Mainframe. Nous arrivons à la fin. Mais ce n'est pas "Game Over", c'est "All together now! Avec IWS vous obtenez un plan solide et des fonctionnalités Job pour tous les Jobs. Avec EJM, une extension pour Distributed Scheduling et un Joblog Management très sécurisé. Tous les systèmes ont des interfaces de navigateur supplémentaires. XINFO aide à la vue d'ensemble dans le traitement et la visualisation de grandes données. Tout est réglementé et tout est dit. Merci pour votre attention! Au revoir!