Une rentrée rayée jaune et bleu

Une rentrée rayée jaune et bleu

Une manifestation dédiée à  Domino AS/400 pour les partenaires Lotus et Domino, et de nombreuses autres initiatives ont marqué la rentrée. La manifestation appelée “ Victory 99 EMEA ”, qui s'est tenue à  Cannes au tout début septembre, a remporté un franc succès puisque environ 2600 IBMers et partenaires s'y étaient donné rendez-vous.

L'AS/400 figurait en bonne place dans cette manifestation consacrée à  l'ensemble de la gamme serveurs d'IBM Des ténors de la plate-forme comme Tom Jarosh, Tony Madden ou encore Malcolm Haynes figuraient en tête de l'affiche. C'est aussi à  l'occasion de cette manifestation que s'est faite l'annonce de la cession à  Cisco Systems de l'offre “ réseaux ” d'IBM.

Mais après une conclusion en grande pompe de Victory 99 EMEA, avec notamment une immense soirée sur la plage du Carlton le mercredi, c'est par un événement beaucoup plus confidentiel mais néanmoins important que s'est poursuivie la semaine : IBM et Lotus avaient en effet convié leurs BP (Business Partners) et LBP (Lotus Business Partners) à  un séminaire marketing baptisé Victory AS/400, sur le thème : “ Les clés du succès pour vendre Domino AS/400 ”. Vaste programme !

Une soixantaine de représentants des ces deux “ espèces ” se sont alors réunis au long des deux jours restants de la semaine, pour mieux comprendre et connaître l'AS/400 pour les LBP, Lotus Domino pour les BP, ceci dans le but avoué de se donner les moyens de “ booster ” les installations Domino sur AS/400. L'objectif de la réunion était double : fournir à  tous les arguments de vente sur Domino pour AS/400, et réunir les partenaires AS/400 et Lotus pour développer du Business commun sur Domino pour AS/400.

Et sur ce dernier point, force est de constater qu'il y avait fort à  faire. L'initiative a non seulement montré qu'un rapprochement entre partenaires Lotus et IBM et une meilleure connaissance du domaine de compétences de l'autre étaient indispensables, mais a largement oeuvré dans le sens de rapprochements effectifs. Les tendances de la rentrée étaient donc sans conteste à  l'alternance des couleurs, aux rayures jaune Lotus et bleu IBM.

L'AS/400 est devenu la seconde plate-forme d'installation de Domino en termes de nombre de serveurs

Contraintes d’intégrité et Triggers: vers une chronologie parfaite

par Paul Conte
Maîtrisez la chronologie d'exécution des contraintes et des triggers des bases de données DB2 Universal Database for AS/400 (DB2 UDB) comporte plusieurs fonctions importantes qui d'une part assurent l'intégrité des données et d'autre part, étendent les fonctions des bases de données. Deux de ces fonctions, les contraintes d'intégrité référentielle et les triggers (ou programmes déclencheurs) peuvent être définis par un administrateur de bases de données (ou un utilisateur autorisé) pour se protéger des mises à  jour susceptibles de générer des données invalides ou incohérentes. On peut également utiliser des triggers pour exécuter des tâches qui ne sont pas intégrées dans DB2 UDB (comme afficher des informations sélectionnées sur des mises à  jour de bases de données dans une table de journalisation définie par un utilisateur par exemple).

Du fait qu'une opération sur une base de données peut entraîner DB2 UDB à  évaluer une ou plusieurs contraintes et appeler un ou plusieurs triggers, il est essentiel de maîtriser la chronologie des différentes opérations d'insertion, de modification et de suppression dans les bases de données. Le présent article apporte quelques informations sur la chronologie des contraintes et des triggers afin de vous permettre de concevoir des applications fonctionnant de manière efficace.

Pour commencer, examinons rapidement les concepts de base des contraintes d'intégrité référentielles et des triggers (pour plus de plus amples informations, veuillez consulter l'encadré "Bibliographie").

Les contraintes d'intégrité référentielle et les triggers peuvent protéger des données invalides ou incohérentes

Quoi de neuf ? Un digest des dernières nouveautés

L'architecte des sécurités de l'AS/400 recense les nouveautés et améliorations des V4R2 et V4R3

Deux releases de l'OS/400 (V4R2 et V4R3) ont été annoncées depuis ma dernière revue en matière de sécurités. Toutes deux renforcent les sécurités dans deux domaines principaux.

Les améliorations

• permettent de mieux maîtriser la configuration de l'environnement TCP

• facilitent la protection et la gestion du e-business

• permettent de mettre en place un plan de sécurité initial tout en découvrant des possibilités plus détaillées

Lire l'article

Le blues du hardware

Windows 2000 a la réputation de supporter plus de périphériques grâce au support de Plug and Play et à  l'ajout d'une grande quantité de drivers. Pourtant, partir du principe que vos périphériques matériels seront supportés par Windows 2000 est peut-être une erreur. Mon expérience de la connexion de périphériques à  un système Windows 2000 ne m'a pas franchement rassuré sur le support hardware de Windows 2000. D'autant que ces matériels exploitent des drivers Windows NT 4.0. Les matériels que j'ai essayé de faire fonctionner avec un système Windows 2000 sont une imprimante/scanner/fax HP OfficeJet 710 et un contrôleur SCSI Future Domain TMC-850 MER.

Offrez la

Le module RPG IV CallerID permet d'identifier le programme ayant provoqué une modification d'une base de données. Vous êtes-vous jamais demandé ce qui se cachait à  l'autre bout de l'appel d'un programme trigger ? Eh bien, il est maintenant possible d'installer "CallerID" (gratuitement) pour permettre aux programmes trigger de déceler l'origine des modifications survenues dans la base de données.

Techniquement, des opérations internes sur les fichiers OS/400 telles que QDBPUT (Database add a record) et QDBUDR (Database update, delete, or release a record) entraînent l'appel d'un programme trigger. Toutefois, avec l'aide de quelques API de gestion des messages, il est possible d'identifier le programme qui se cache derrière ces opérations.

La connaissance de l'origine des modifications de la base de données peut se révéler fort utile. Envisageons les scénari suivants :

Attention: inondation. Etant donné que les triggers interceptent toutes les modifications effectuées dans un fichier base de données, ils peuvent se révéler efficaces pour assurer la cohérence des données dans une ou plusieurs applications. Mais, un fichier qui change fréquemment peut imposer une charge très importante à  un programme trigger. Aussi, afin de limiter le surcroît de travail de ce type de programme, on peut choisir de filtrer certaines des modifications pour que le programme trigger n'exécute pas l'intégralité de sa routine à  chaque fois qu'une modification est effectuée.

Supposons que vous utilisiez un programme trigger pour introduire des modifications démographiques effectuées par une application sur une autre, et que l'application effectuant les modifications stocke des informations démographiques et financières dans le même fichier. Supposons également que vous ayez un traitement de nuit sur ce fichier, qui ne met à  jour que les informations financières mais agit sur un grand nombre d'enregistrements. Plutôt que de comparer systématiquement les images de chaque champ "démographie" avant et après que le programme trigger ait été appelé, vous pouvez simplement filtrer les modifications effectuées par le traitement de nuit.

Surveiller toutes les issues. Peut-être essayez-vous de faire un contrôle qualité en surveillant la fréquence à  laquelle il est nécessaire de "glisser" des modifications dans une base de données du fait de limitations des applications existantes. Il est possible de calculer le nombre de fois que DFU (Data File Utility ), SQL ou un utilitaire base de données quelconque a été utilisé pour modifier certains fichiers de la base. Même si vos applications standards sont excellentes, vous pouvez souhaiter garder une trace des interventions réalisées sur les fichiers sans utiliser d'application, pour identifier des violations de sécurités potentielles, ou d'éventuels besoins en formation.

Eviter les boucles sans fin. Imaginons que vous utilisiez des programmes triggers pour transmettre des modifications démographiques entre une application A et une application B. Quand un fichier est mis à  jour dans l'application A, le programme trigger met à  jour le fichier associé de l'application B, et vice versa. Ce processus paraît clair et simple. Cependant, il se pose un problème lorsque le programme trigger de l'application A met à  jour un fichier de l'application B, obligeant le trigger de cette dernière à  mettre à  jour l'enregistrement original qui a été modifié dans l'application A. Ce cas de figure peut provoquer l'appel récursif du programme trigger de l'application A, d'où risque de bouclage.

Des boucles inutiles peuvent également poser problème lorsqu'une interface EDI (Echange de Données Informatisées) est utilisée entre deux systèmes. Une modification de la base de données d'un système se répercuter de système en système jusqu'à  ce que le système récepteur sache que la modification provient du système émetteur, et que par conséquent il n'est pas nécessaire de lui renvoyer la modification.

Par où commencer avec les jointures SQL/400

Le coding de base des jointures SQL est simple ; voici comment procéder Une opération de jointure sur la base de données combine des lignes (c'est-à -dire des enregistrements) provenant de deux ou plus tables (c'est-à -dire des fichiers) pour produire une table résultat utilisable ensuite pour d'autres opérations. DB2 Universal Database for AS/400 (UDB/400) permet les opérations jointes par l'intermédiaire de plusieurs mécanismes :

• fichiers logiques joints définis en DDS
• les paramètres FILE et FLD de la commande OPNQRYF (Open Query File)
• les clauses FROM et WHERE d'une sous-selection SQL
  

Prédicat Between et sous-requêtes SQL

par Mike Cravitz Ce mois-ci, nous allons voir l'utilisation du prédicat Between dans la clause Where d'une requête SQL, dans le but de trouver une valeur située entre deux bornes Je vous présente aussi un puissant mécanisme, appelé sous-requête. Et, pour faire bonne mesure, je montre comment utiliser la fonction SQL Count pour renvoyer le nombre de lignes d'une table de résultat de requête. En route !

IBM-Intel : la guerre des processeurs continue

par Frank G. Soltis
Les processeurs IBM continuent de surpasser ceux d'Intel lorsqu'il s'agit de serveurs sur lesquels s'exécutent plusieurs applications La plupart des lecteurs de ce magazine connaissent peu ou prou les plans d'IBM en matière de processeurs pour l'AS/400. Il est donc intéressant de comparer les plans d'IBM pour ses serveurs à  l'offre processeurs d'Intel.
Les processeurs PowerPC présents dans les AS/400 actuels appartiennent à  la famille dite Star Series. Cette famille de microprocesseurs monopuces, 64 bits, a été spécialement conçue à  Rochester pour le type de tâches confiées aux serveurs sur l'AS/400. Ces mêmes processeurs animent également les modèles RS/6000 affectés à  des tâches de gestion.
En septembre 1998, nous présentions le premier membre de la Star Series, dénommé Northstar. C'était et c'est encore un microprocesseur de pointe.
En septembre 1999, nous présentions une version de Northstar plus rapide dénommée Pulsar et utilisée uniquement dans le RS/6000.
Dans le courant de cette année, nous présenterons le nouveau processeur I-Star. Il utilise les toutes dernières technologies semiconducteur d'IBM, y compris cuivre et SOI (Silicon-On-Insulator), pour plus que doubler les performances de Northstar. Au moment de son introduction, I-Star sera le microprocesseur destiné à  des serveurs le plus performant. Loin de s'endormir sur leurs lauriers, les ingénieurs de Rochester sont en train de créer un autre membre de la Série Star : S-Star, qui pousse encore plus loin les technologies semiconducteur pour obtenir une augmentation de performances d'environ 50 % par rapport à  I-Star. S-Star, qui devrait être le dernier membre de la Star Series, apparaîtra dans l'AS/400 au cours de l'année 2001.

Solutions ERP 100% “ prêtes à  l’emploi ” : la panacée ?

par Scott Steinacher

A l'exception des PC et de l'Internet, aucune innovation technologique n'a impacté le monde de l'entreprise plus profondément que les logiciels ERP (Enterprise Resource Planning). Au départ, d'une manière générale, les managers utilisaient les logiciels ERP pour automatiser les fonctions back-office de l'entreprise telles que la comptabilité, la finance et la gestion des ressources humaines. Plus récemment, les principaux éditeurs d'ERP s'intéressant désormais au traitement des commandes, à l'automatisation de la force de vente, à la gestion de la chaîne d'approvisionnement, à la planification des besoins et à bien d'autres processus pour les entreprises stratégiques, les ERP se sont éloignés de leur rôle traditionnel.

            Au fur et à mesure que l'euphorie qui entoure les ERP gagne de nouveaux marchés, de nombreuses sociétés ne semblent que trop heureuses de se débarrasser de leurs logiciels spécifiques qui les ont si bien servis pendant de nombreuses années. A mon avis, certaines entreprises vont trop vite en besogne. En effet, dans de nombreux cas de figure, les applications développées en interne ne nécessitent probablement qu'un ravalement de façade, et non une retraite prématurée.

            Il est par exemple possible de rendre les systèmes existants accessibles depuis le Web en attachant des rapports classiques aux messages électroniques émis sur l'Internet. Une autre alternative consiste à placer les rapports existants sur un intranet pour qu'ils puissent être consultés à l'aide d'un navigateur. Les interfaces graphiques des navigateurs peuvent remplacer les écrans passifs. Certes, les interfaces graphiques ne présentent peut-être aucun intérêt pour les applications de type back-office, mais pour fournir un accès aux données à des utilisateurs distants, l'Internet et les interfaces graphiques représentent désormais la norme.

            Bien évidemment, les organisations qui ont plusieurs systèmes différents redondants ont probablement besoin d'une refonte en profondeur. Ainsi, au sein d'une organisation issue de fusions et d'acquisitions, il n'est pas rare de voir plusieurs applications distinctes remplir la même fonction (la saisie des commandes par exemple) dans des divisions différentes. Dans de tels cas, l'utilisation de logiciels ERP pour normaliser les systèmes et les processus de l'entreprise est probablement justifiée mais pas forcément déterminante. Construire des interfaces reliant les applications disparates existantes ou normaliser en se basant sur l'application la plus efficace peut représenter un coût moindre. Le fait est qu'il existe souvent des alternatives attrayantes aux ERP, mais que celles-ci ne sont pas toujours envisagées sérieusement.

Platinum : un avenir doré pour Exchange ?

Microsoft fait tout son possible pour que Windows 2000 Server rencontre le succès du premier coup. Alors que le Gartner Group fait preuve de scepticisme en conseillant à  ses clients d'attendre jusqu'en 2000 avant de déployer le nouvel OS, Microsoft a bien l'intention de persuader ses clients de migrer en veillant à  ce que les applications les plus répandues fonctionnent bien sous Windows 2000 Server, notamment la nouvelle version d'Exchange Server. La prochaine version majeure du système de messagerie Microsoft Exchange (nom de code Platinum) ne tournera que sous Windows 2000 Server. Microsoft n'a pas encore fixé de date ferme pour sa sortie, mais ce sera dans tous les cas après Windows 2000.Platinum sera la version la plus stratégique d'Exchange et d'une envergure inégalée depuis les débuts la version 4.0 en 1996. Exchange 5.0 et 5.5 partaient d'une base établie par Exchange 4.0, qu'elles amélioraient et embellissaient, mais en conservaient le kernel. En revanche, Platinum comportera d'importantes modifications de certains composants majeurs d'Exchange Server. Pour vous permettre de préparer une éventuelle décision de passage à  Platinum, je vais décrire les développements les plus significatifs du produit.

Les performances d’Exchange 2000

Les caractéristiques de performances de Microsoft Exchange Server 5.5 sont bien connues. En 1996, Exchange Server 4.0 a posé ses principes de base : atteindre des performances optimales grâce à  la distribution des fichiers et depuis, pas grand-chose n'a changé. Microsoft a bien étendu la capacité de l'Information Store (IS) jusqu'à  la limite théorique de 16 To, mais le serveur de messagerie conserve ses caractéristiques essentielles. Dans Exchange Server, les points névralgiques, c'est-à -dire les fichiers générant la plus lourde charge d'E/S, sont les bases de données de l'IS et du Directory Store, leurs journaux de transactions, la copie sur disques de Windows NT et le répertoire de travail MTA (Message Transfer Agent).

Exchange 2000 Server est d'un tout autre acabit. Le nouveau serveur de messagerie bénéficie des améliorations suivantes :

* L'architecture de l'IS a nettement évolué, passant du simple partitionnement de bases de données privées et publiques à  un point où elle permet, théoriquement, d'exécuter jusqu'à  90 bases de données sur un seul serveur.

* Microsoft IIS (Internet Information Server) traite tous les accès de protocoles pour SMTP, IMAP4 (Internet Message Access Protocol), HTTP, NNTP (Network News Transfer Protocol) et POP3, et joue donc un rôle plus important pour Exchange 2000 que pour les précédentes versions d'Exchange Server.

* Une nouvelle base de données déroulante peut contenir le contenu Internet natif.

* Active Directory (AD) de Windows 2000 remplace le Directory Store.

* Un nouveau moteur de routage et de mise en file d'attente, basé sur SMTP, remplace l'ancien MTA basé sur X.400.

Ces améliorations font partie d'une solution customisable que les solutions tierces étendront vraisemblablement pour doter Exchange 2000 de fonctions telles que antivirus, fax, workflow, gestion de documents et autres fonctions qui ne font pas partie du serveur de base.
Exchange 2000 apporte d'importants changements architecturaux affectant considérablement les performances. Les concepteurs de systèmes vont devoir à  présent se poser une question cruciale : comment optimiser au maximum ces nouvelles fonctions en termes de configurations systèmes et matériels.

Pour y répondre, commençons par examiner le partitionnement de l'IS d'Exchange 2000.Exchange 2000 apporte d'importants changements architecturaux affectant considérablement les performances

Windows NT Terminal Server en action

Lorsque Microsoft a signé un accord avec Citrix pour acquérir la licence de WinFrame et développer l'édition Terminal Server de Windows NT Server 4.0, de nombreux observateurs se sont demandés comment ce nouveau produit allait changer la vie des utilisateurs de Windows NT. La réponse m'a été apportée par la pratique. La promesse, faite par Terminal Server, d'associer le meilleure des fonctions multiutilisateurs de WinFrame avec les fonctions et l'interface de NT 4.0 m'a semblé séduisante dès son annonce. Mais j'attendais l'occasion de tester Terminal Server dans la réalité pour voir comment il allait se comporter. Elle s'est présentée à  moi récemment lorsqu'un de mes clients m'a appelé pour résoudre un problème. C'est Terminal Server qui m'a permis de le résoudre. Voici comment.

Le SMP n’est plus seulement une affaire de serveurs

Lors de la sortie par Microsoft de Windows NT 3.5, j'ai décidé d'utiliser NT sur mon PC de bureau. J'en avais assez de la tendance de Windows 3.x à  planter à  des moments inopportuns et mon activité ne m'obligeait pas à  exécuter des applications anciennes que NT ne pouvait pas traiter. Pour moi, cette migration était la bonne décision.

La gestion des disques de Windows 2000

En général, j'ai le sentiment que les nouvelles versions des outils sont plus compliquées à  utiliser que leurs prédécesseurs. Une croyance qui vient probablement de mes expériences passées et d'une tendance mainte fois observée. Pourtant, l'outil de gestion des disques de Windows 2000 évite le piège : le nouvel outil offre une interface simplifiée et compte de nouvelles fonctions très utiles.Les utilisateurs expérimentés de Windows NT sont des habitués de l'Administrateur de disques, l'outil intégré de NT pour la création, l'administration et la suppression des volumes logiques sur les disques physiques. L'équivalent Windows 2000 de l'Administrateur de disques de NT est le composant logiciel enfichable Gestion des disques que l'on peut démarrer depuis Outils d'administration, Gestion des disques (écran 1).

Bâtir un site Web à  haute disponibilité avec MSCS et IIS

Microsoft Cluster Server est un service précieux, mais méconnu, de Windows NT Server 4.0 édition Enterprise, qui augmente le temps de production grâce à  une disponibilité élevée. Dans cet article, nous détaillerons les fonctions de base de MSCS et son utilisation avec Internet Information Server pour configurer un site Web à  haute disponibilité.

SSL et la cryptographie

Historiquement, SSL est un protocole mis au point par Netscape pour la sécurisation des communications sur le Web. Tous les acteurs du marché ont accepté ce protocole et le supportent, en attendant l'arrivée d'un standard international. Ce standard appelé TLS (Transport Layer Security), basé sur SSL, est mis au point par le l'IETF (Internet Engineering Task Force) et a été publié il y a peu de temps (TLS 1.0). Tous les éditeurs significatifs supportent ou ont annoncé leur intention de supporter TLS 1.0.Afin de comprendre ce qu'est SSL, il est indispensable de maîtriser les concepts de cryptographie qui en constituent les fondations.

Optimiser les applications pour Terminal Server

L'un des aspects les plus épineux de l'installation d'un système informatique basé sur les clients légers est de faire fonctionner pour plusieurs utilisateurs des applications conçues pour un utilisateur unique. Windows NT Server 4.0 édition Terminal Server risque donc de rencontrer des problèmes avec certaines applications. Toutes les applications ne fonctionnent pas correctement en environnement multiutilisateur. Certaines utilisent trop de cycles de processeur ou trop de mémoire, d'autres ne savent pas s'il faut appliquer des paramètres à  un utilisateur ou à  un ordinateur, et certaines stockent les informations dans des emplacements inadaptés à  un OS multiutilisateur.
Il arrive même de se retrouver bloqué par ces problèmes et, pour les applications de ce type, de devoir les exécuter à  partir de l'ordinateur client. Heureusement certains problèmes peuvent se résoudre, à  condition de leur consacrer un peu de temps.Les applications ne fonctionnent pas toutes avec Terminal Server, mais les astuces présentées ici vous aideront à  tuner celles pour lesquelles c'est le cas.

Visite guidée de Babylone

Le tout dernier serveur d'interopérabilité d'entreprise, mis au point par Microsoft sous le nom de code Babylone, va remplacer SNA Server de la suite BackOffice et permettra, tout comme ce dernier, d'intégrer les réseaux Windows avec les mainframes et les AS/400 d'IBM. L'un des principaux objectifs de Microsoft pour Babylone est de se débarrasser des contraintes de SNA Server et d'englober totalement TCP/IP comme protocole réseau de base. L'objectif secondaire est d'approfondir le niveau d'intégration assuré par le serveur. Si Microsoft SNA Server assurait la connectivité de base des hôtes, Babylone passera, quant à  lui, de la couche de connectivité de base au domaine de l'intégration des applications. Le tout nouveau serveur d'interopérabilité d'entreprise de Microsoft comprend beaucoup de nouvelles fonctions, dont certaines s'appuient sur les technologies actuelles de SNA Server, mais il lui manque malgré tout quelques pièces du puzzle de l'interopérabilité d'entreprise.

Les stratégies de groupe

Microsoft affirme que la réduction du coût de possession est une des raisons de migrer vers Windows 2000. Le concept de TCO dépasse le simple prix d'achat de l'ordinateur et prend en compte bien d'autres centres de coûts, tels que le coût rémanent consistant à  supporter le système et les utilisateurs. Quiconque a un jour travaillé à  l'assistance aux utilisateurs, sait qu'en fixant des stratégies pour empêcher les utilisateurs de faire des modifications intempestives sur leurs systèmes, on peut éviter bien des problèmes pouvant affecter leur productivité et qui demandent fréquemment, pour les résoudre, l'intervention de personnels qualifiés. Dans Windows NT 4.0, les stratégies système sont à  peine plus que des modifications du shell qu'un utilisateur averti peut contourner sans problème. En revanche, dans Windows 2000, Microsoft a développé considérablement la notion de stratégies systèmes. Détaillons les stratégies de groupe, principalement pour comprendre comment il fonctionne dans le modèle Active Directory (AD).

Le Triangle d’Or

par Samy Mosimann Dans le monde de la banque privée, la place de l'AS/400 reste prépondérante, avec un facteur de 1 à  8 par rapport au nombre d'installations Unix Genève, Zurich et Luxembourg sont les trois sommets du triangle d'or de l'activité bancaire privée en Europe. Ces banques sont des établissements qui ne se comparent pas aux grandes banques nationales ou publiques européennes. Elles sont moins importantes et emploient de moins de 40 à  plus de 500 employés. Globalement, on peut estimer qu'environ 1000 banques sont en activité dans ce domaine en Suisse et au Luxembourg.