Gestionnaire d'exploitation CE7 automate miracle

...qui permet d’administrer les tâches d’exploitation les plus complexes d’un réseau hétérogène,
à partir d’un poste unique de gestion , telles que :

Planification des travaux	Lancement automatique conditionné et valorisé de travaux et de commandes	Contrôle du déroulement des travaux et de la gestion dynamique des enchaînements	Gestion des sauvegardes automatiques en local et à distance
Gestion du calendrier, automatique, puissante et complète, prenant en compte les variantes locales ou spécifiques suivant les pays et régions			Gestion de ressources et d'évènements externes (transmission de fichiers, liaisons avec d'autres machines, GCOS7, OPEN7, LINUX, UNIX, NT- W2000-XP)
Visualisation des évènements d’exploitation (plannings, incidents, ressources, calendrier, gestion des dates, variables...)			Meilleur compromis entre puissance fonctionnelle et ressources nécessaires (moins de 1% du temps CPU).
Puissant grâce à ses principes de base, issus de la cybernétique et des systèmes experts, et à sa conception modulaire.	Facile à mettre en oeuvre il permet d’intégrer rapidement les contraintes d’exploitation et d’en personnaliser finement tous les processus.	Livré avec une interface permettant d’assurer les liaisons avec une application existante ou un produit annexe.	Discret mais efficace il occupe moins de 20 Mo sur disque

est un produit original, né de besoins réels, destiné à contrôler toutes les phases d'une exploitation, sur une ou plusieurs machines, même équipées de systèmes différents.

signifie " Contrôleur d'Exploitation pour DPS7 " car c'est pour cette machine qu'il a été initialement prévu.
Très rapidement, le même besoin s'est rencontré sur d'autres machines fonctionnant sous UNIX ou Windows, souvent reliées entre elles par un réseau local et souvent en liaison avec un gros système.

L'architecture particulière de lui permet de fonctionner sous diverses versions, compatibles entre elles, sur les différentes machines d'un site.
La complexité des traitements sur ces gros systèmes nécessite un suivi rigoureux afin de limiter au maximum les conséquences des erreurs de toutes sortes.

fonctionne de manière autonome, pratiquement sans intervention humaine (à l'exception du paramétrage initial), ce qui explique qu'il n'a pas vraiment besoin d'une interface graphique pour travailler correctement.
Cependant, quelques composants de sont prévus pour centraliser, sous forme graphique, des informations relatives aux travaux en cours sur les différentes machines concernées.

se compose de plus d'une centaine de composants élémentaires qui remplissent une tâche bien précise qu'il n'est pas toujours possible, selon les systèmes d'exploitation, de réaliser autrement.

La plupart des fonctions qui manquent dans Windows mais que l'on trouve dans UNIX sont disponibles dans , ce qui permet d'appliquer les mêmes méthodes et les mêmes contrôles, avec le même langage, quel que soit le système utilisé.

dispose aussi de composants de type Client Serveur qui permettent des dialogues automatiques entre les différentes machines, locales ou distantes, en utilisant le réseau local ou Internet. Lancer une application quand les fichiers nécessaires sont disponibles sur plusieurs machines est d'une simplicité exemplaire avec !

Du fait de son architecture ouverte, peut s'interfacer facilement avec d'autres produits moins puissants, en mode graphique ou non, pour résoudre les cas les plus complexes, à la satisfaction générale.

La gestion des dates de , de 1900 à 2173, lui procure une souplesse incontestable. Les fonctions de conditionnement et de valorisation dynamiques associées à cette gestion des dates donnent à une puissance inégalée !

Lancer une application sur une machine A (sous Windows), le dernier jour ouvré du mois à condition que le contenu d'un fichier situé sur la machine B (sous UNIX) soit correct et qu'un traitement soit bien terminé sur la machine C (sous Windows) , sans le moindre clic ni la moindre intervention humaine, est tout à fait possible avec !

Les limites de sont bien souvent celles de l'imagination de ceux qui s'en servent et sa souplesse lui permet de s'adapter aux différentes habitudes sans les remettre en cause...

--- UNE ARCHITECTURE MODULAIRE ---

est proposé en plusieurs modules constituant une suite évolutive adaptable au besoin de chaque client et à sa structure.

- Module OPERATEUR = module de base
- Module CONTROLEUR = pour une gestion très fine de l'exploitation
- Module CLIENT-SERVEUR = pour assurer les échanges
entre des machines reliées en réseau.

- Module VISUAL = pour assurer une gestion
dans un environnement graphique (Windows)

- Module DÉVELOPPEMENT
Avec les modules OPÉRATEUR et CLIENT-SERVEUR, des fichiers de type DLL peuvent être fournis, avec leur documentation détaillée, pour permettre à ceux qui le souhaiteraient, le développement de composants sous Windows avec le langage de leur choix (Visual Basic, Visual C, Delphi, Windev, etc) qui feraient appel à l'un de ces fichiers de type DLL pour bénéficier des fonctions de base de tout en utilisant une présentation personnalisée.

son architecture repose sur un fichier unique qui abrite la base de connaissances de chaque exploitation : le PILOTE.

Le PILOTE peut être consulté ou modifié facilement par les interventions du gestionnaire ou un programme propriétaire, ce qui permet notamment de transmettre des variables de conditionnement et d’assurer une gestion parfaitement dynamique.

peut aussi s’adapter à l’existant et prendre en compte vos applications locales, préservant ainsi vos développements et les usages ou habitudes de vos utilisateurs ou développeurs.

a des composants prévus pour assurer la liaison entre la ou les plate- formes serveurs : GCOS7, LINUX, NT, UNIX , W2k et les postes clients hétérogènes, y compris des gros systèmes (main frame) ou des micro-ordinateurs (dès lors ou une liaison existe).

Il devient ainsi possible d'imaginer une gestion dans laquelle le serveur principal recevrait des informations d'autres serveurs ou postes clients, même très éloignés, ces informations pouvant être du type 'Gestion ou Procédure' (Fichiers) ou 'Technique'
(Informations issues de capteurs de toutes sortes : température, tension, sécurité, eau, intrusion, etc...), puis traiterait les données en fonction des processus et des conditions définis ( règles de gestion, calendrier,) et adresserait des ordres ou réponses aux serveurs ou postes connectés.

peut ainsi assurer des tâches aussi variées que :
- le contrôle de machines distantes,
- l’exécution complexe de chaînes d’exploitation conditionnées,
- le contrôle de produits de surveillance installés sur plusieurs micro-ordinateurs,
- le déclenchement de procédures d’édition ou de routage,
- les sauvegardes ou restaurations automatiques des postes serveurs ou clients,
- etc...

--- MODULE OPÉRATEUR ---

Ce module de base permet de réaliser les fonctions de lancement et de suivi des travaux. Il comporte :

>>> Le GESTIONNAIRE du PILOTE,
qui sert à paramétrer et gérer le pilote en mode texte ou graphique (VISUAL).

>>> Le LANCEUR AUTOMATIQUE assurant :

- la planification et le lancement des travaux en fonction de conditions horaires, calendaires, logiques etc...

- la prise en compte automatique d'un décalage horaire (pour la gestion des heures d'été, d'hiver, heure locale, GMT etc...).

- le contrôle de la date machine (détection des erreurs).

- une gestion calendaire complète et puissante.

- la gestion des variables : plus de 300 mots réservés et un nombre illimité de variables disponibles pour valoriser les commandes.

- les rotations automatiques, avant ou arrière, en mode direct ou indexé, permettant jusqu'à 10000 générations par variable.

- La gestion de Mots Réservés qui concerne principalement tous les éléments de dates qui, en liaison avec le calendrier automatique, permettent de prendre en compte tous les besoins spécifiques associés à des notions calendaires : jours ouvrés, fériés, lendemains de fêtes, premier ou dernier jour du mois , semaine, année, etc..., ainsi que tous les calculs sur dates.

- La simulation, pour tester la mise au point des lancements avec changement éventuel de la date ou de l'heure de référence du lanceur et test des variables.

>>> Le LANCEUR peut aussi se relier facilement à d'autres produits pour les faire profiter de toute sa puissance de traitement.

>>> Les COMPOSANTS LOGICIELS annexes permettent la gestion des événements, des enchaînements, des reprises, des sauvegardes, de l'espace disque ainsi que diverses listes. Parmi ces composants, certains servent aussi à créer des temporisations, répondre aux messages, ou gérer les échanges entre machines distantes.

La gestion des enchaînements est traitée d'une manière simple et puissante qui permet le traitement de cas complexes et autorise les solutions les plus originales sans avoir à modifier le paramétrage initial.

Tout le fonctionnement de est dynamique, comme partout dans , ce qui signifie qu'un événement de dernière minute peut être pris en compte dans un chaînage sans avoir à interrompre le lanceur.
Cette gestion dynamique permet de synchroniser facilement des travaux organisés en chaînage automatique, à partir d’un événement quelconque.

>>> MODULE VISUAL
Ce module, optionnel, permet la gestion de dans un environnement graphique
(Windows).

>>> MODULE CONTRÔLEUR
Ce module permet de traiter tous les cas particuliers, simples ou complexes, avec seulement quelques lignes de commandes.

Il peut se charger de gérer toutes sortes d'événements, de gérer les ressources de la machine, de vérifier le contenu d'un fichier (utile quand celui-ci est reçu par transmission), de mettre à jour le PILOTE, de gérer les incidents et les reprises, etc...

On peut considérer le CONTRÔLEUR comme un capteur programmable qui, placé aux endroits stratégiques d'une procédure, assure la liaison entre le produit et son environnement matériel ou humain.

>>> MODULE CLIENT - SERVEUR
Ce module contient des composants qui permettent de centraliser les différents systèmes d'exploitation GCOS7 (et OPEN7), LINUX, NT, UNIX ou W2k sur un seul poste gestionnaire d'exploitation et d'assurer ainsi une importante économie de coûts d'administration et de sécurité.

Les grandes dates de

est le résultat de près de 10 années d'observations et de corrections d'erreurs de toutes sortes dans un centre de traitement parisien qui travaillait 24H su 24. Très vite, il est apparu que la plupart des erreurs pouvaient être évitées par un certain nombre de contrôles et de mécanismes particuliers.

Ce centre était équipé d'un matériel BULL de type H64 puis DPS7, ce qui explique le nom du produit qui signifie " Contrôleur d'Exploitation pour DPS7 ".
a été écrit dans un autre centre parisien, face à Saint Augustin, et mis sur le marché en septembre 1987.

Le produit initial ne comportait qu'une vingtaine de programmes, écrits en COBOL, mais répondait déjà à la plupart des besoins.
En mars 1988, suite à une présentation dans un environnement bancaire, le produit a été équipé d'un module de gestion des dates surpuissant, afin de pouvoir répondre aux besoins évoqués lors de cette présentation.

L'écoute permanente des utilisateurs a fait évoluer le produit à chaque fois que cela était nécessaire. C'est ainsi que des besoins rencontrés en Alsace puis en Suisse ont permis l'internationalisation du calendrier, descendant même au niveau de la région.

Les utilisateurs devenant de plus en plus exigeants, de nouvelles fonctions ont été ajoutées en 1990 pour traiter les cas d'enchaînements complexes.

L'évolution des matériels (DPS7 puis DPS7000) a conduit à de nouveaux composants et le produit comptait près de 50 programmes en 1992.

C'est alors qu'un client prestigieux (là où " la vie est moins chère ") a exprimé le souhait d'avoir le même produit pour ses machines sous UNIX !

La conjoncture internationale n'était pas favorable mais cela n'a pas empêché la réécriture complète du produit, en C ANSI sous Linux, en 1995.

En 1997, la première version pour UNIX faisait ses premiers pas sur un matériel BULL de type Escala , 100% compatible avec la version pour DPS7, ce qui enchantait les clients de l'époque.

En 1998, des composants de type Client-Serveur ont été écrits du fait des vastes possibilités de communication par réseau de Linux/UNIX. Les premiers dialogues entre les 2 versions de CE7 (GCOS7 et UNIX) étaient réalisés.

Ceux qui découvraient dans sa version pour UNIX demandaient souvent la même chose pour Windows NT (à l'époque) !

Par chance, les programmes étant écrits en C ANSI, il était assez facile de réaliser une version parallèle, ce qui fut entamé dés 1999.

Du fait de sa gestion de date surpuissante (de 1900 à 2173), le passage de l'an 2000 ne fut qu'une formalité pour et tous ceux qui avaient fait ce choix ne l'ont pas regretté à cette occasion.

L'écoute des utilisateurs et l'évolution des technologies ont donné lieu à la création de nombreux composants autour du réseau et d'Internet.

En 2001, des composants sont apparus pour gérer l'envoi et la réception de messages de type e-mail.

La même année, une demande originale a conduit à la réalisation de composants de type Client Serveur pour OPEN-7, un sous-système de GCOS7 qui permet des liaisons avec les mondes UNIX et Windows. Ceci a permis de lancer un travail sur un DPS7000, à travers OPEN-7, depuis un navigateur Internet situé sur un MacIntosh avec retour des résultats sur un ordinateur portable sous Windows 2000 !

En 2002, une action de normalisation interne a permis la réalisation d'une version unique des programmes sources pour UNIX et Windows ! Cela facilite beaucoup la maintenance et l'évolution car, par exemple, une amélioration faite dans un programme pour UNIX est immédiatement disponible dans la version pour Windows.

En 2003, un certain nombre de composants ont été dédiés à la surveillance d'évènements physiques, donnant ainsi une ouverture intéressante au produit.

Depuis 2004, le contrôle centralisé de plusieurs machines fait l'objet de nouveaux composants.

Le produit complet se compose à ce jour de 112 composants !

RETOUR