Transférer des données de l’iSeries à  SQL Server

par Michael Otey, Mis en ligne le 26/04/2006 - Publié en Décembre 2005

En novembre, Microsoft a présenté SQL Server 2005. Cette release modifie totalement le mode de transfert de données entre SQL Server et d’autres plates-formes base de données (pour plus d’informations sur la release, voir l’encadré « Les nouveautés de SQL Server 2005 »). L’outil DTS (Data Transformation Services) qui faisait partie de SQL Server 7 et de SQL Server 2000, a disparu. Il cède la place au nouveau SSIS (SQL Server Integration Services). SSIS et DTS sont complètement différents, au point que toutes les techniques qui servaient à transférer des données entre l’iSeries et SQL Server avec DTS ont été profondément modifiées. Dans cet article, j’explique comment utiliser SSIS pour transférer des informations base de données de l’iSeries sur SQL Server 2005.

Network Access Protection sur Windows Server 2003 R2

La gestion simultanée des environnements Windows et UNIX coûte-t-elle cher à  votre entreprise ?

Réduisez vos coûts et utilisez la puissance d'UNIX - avec Secure Shell, scp, sftp, secure X, Kornshell, CShell, awk. telnet server, xterm, rsh, rlogin et plus de 400 commandes et utilitaires additionnels pour gérer votre environnement Windows avec la puissance des outils UNIX. Tous les produits MKS Toolkit sont entièrement supportés et disponibles aussi bien pour les systèmes Windows 64-bit que les systèmes Windows 32-bit. Utilisez l'expertise de vos Développeurs et vos Administarteurs Système à la fois sur Windows et UNIX.

Trucs & Astuces : Commande ARP sur iSeries

Les trucs & astuces de la semaine du 19 au 25 Juin 2006

Ouvrir les connexions à  distance

Si, comme beaucoup de vos homologues, vous êtes chargés de l’administration et du support du poste et si vous êtes aussi débordés qu’eux, vous avez probablement relégué certaines fonctions utilisateur de Windows XP sur le pourtour de l’écran radar, pour vous concentrer sur des sujets plus importants. Remote Desktop est une de ces fonctions jugées de faible priorité dans la plupart des sites IT, et ce pour plusieurs raisons. La principale est peut-être la suivante : l’idée de laisser des utilisateurs se connecter à leurs postes à partir du domicile, de l’hôtel ou de tout autre endroit, suscite toujours de grandes craintes pour la sécurité.Si votre entreprise ne permet pas une telle connectivité, vous pouvez mettre en avant la politique maison pour repousser les utilisateurs désireux de se connecter à partir d’un lieu distant. Mais beaucoup d’entre nous devront satisfaire la frange d’utilisateurs dont les demandes ont l’onction la haute direction, et devront bon gré mal gré mettre en oeuvre des fonctions délicates. Dans cet article, je vais essayer d’atténuer vos craintes à propos de la connectivité à distance, en expliquant ce qui fait fonctionner Remote Desktop et comment configurer sa sécurité. Vous pourriez même trouver dans Remote Desktop d’excellentes prestations pour le support à distance des systèmes utilisateur.

Mettez-vous en conformité : éliminez les risques majeurs !

par Dan Riehl, Mis en ligne le 10/05/2006 - Publié en Janvier 2006

Jouons à Jeopardy ! « La catégorie est le calendrier IT ».
Pour 400 euros, la réponse est SOX, ISO19977, COBIT, COSO, GLBA, HIPAA, et autres ».
Bip, bip. « Alex, la question est : pour quelles lois, réglementations, standards et structures d’audit, mon entreprise consacrera beaucoup de temps de travail et d’argent en 2005, 2006 et au-delà ? »
« Correct ! Pour 400 euros ! »
Mais est-ce inéluctable ? Nous pouvons et devons réduire le coût et l’effort de pratiquer la conformité et de la démontrer par rapport à la sécurité de notre iSeries. Si nous sommes capables de percevoir les principaux risques et de mettre en oeuvre et d’utiliser des outils intelligents (conjointement aux facultés natives du système d’exploitation) pour identifier et atténuer ces préoccupations, nous pourrons réduire les coûts et démontrer notre conformité, beaucoup plus facilement.

Améliorer et ajuster la performance de l’IFS, 1ère partie

par Richard Theis, Mis en ligne le 26/04/2006 - Publié en Novembre 2005

L’IFS i5/OS est solide, évolutif, fiable et hautement disponible. Peut-il aussi être très performant ? Si vous répondez négativement à cette question, lisez ce qui suit car vous pourriez bien trouver quelques conseils de performance IFS qui changeront votre opinion. Et même si vous répondez oui, il se pourrait bien que quelques-uns des conseils, pas tellement connus, de cet article soient capables de le rendre encore plus performant.Cet article est le premier d’une série de deux contenant des conseils et des astuces visant à améliorer et à régler finement les performances de l’IFS. Cet article donne des conseils sur les performances générales et de répertoires, tandis que le second s’intéressera aux performances des fichiers stream. D’une manière générale, les conseils des deux articles vont du général au spécifique et devraient améliorer le fonctionnement de l’IFS tant sur le plan global que sur celui des applications. Cependant, pour tenir compte des écueils habituels quant aux données de performances, veuillez lire l’avertissement à la fin de cet article.

On sait que l’IFS comprend dix systèmes de fichiers uniques. Mais, en matière de performances générales de l’IFS, les systèmes de fichiers racine (/), QopenSys, et définis par l’utilisateur (UDFS, user-defined file systems) sont généralement impliqués. Par conséquent, dans cet article et dans le suivant, les conseils et le terme « système de fichiers » s’appliquent à ces trois systèmes.

News iSeries – Semaine 38 – 2006

Les actualités de la semaine du 18 au 24 Septembre 2006

Trucs & Astuces : API SET GID

Les trucs & astuces de la semaine du 10 au 16 Juillet 2006

Journal à  distance

Dans les entrailles d’i5/OS se cache une technologie qui commence à susciter de l’intérêt. A en croire le volume de questions posées au lab Rochester d’IBM sur ce thème, on mesure une extrême sensibilisation au cours de la dernière année. Il s’agit du journal à distance, un petit aspect du support peu connu jusque-là.
Introduit voilà quelques années, le journal à distance est passé presque inaperçu pendant un certain temps. Mais, récemment, les projecteurs se sont braqués sur lui et il est le moyen privilégié de transporter efficacement les changements de données récents d’un iSeries sur un autre.Mon premier contact avec le journal à distance remonte à quelques années, quand la V4R2 de l’OS/400 était encore en chantier.
On m’a invité alors à rejoindre l’équipe de développement du journal IBM, à participer à la conception du journal à distance, et à l’amener sur le marché. Mes prédécesseurs d’alors voyaient le journal à distance comme un simple mécanisme de transport amélioré et très efficace grâce auquel nos Business Partners haute disponibilité pourraient construire les versions améliorées de leurs produits.
Ils n’ont pas pressenti que d’autres fournisseurs le considèreraient comme un moyen facile d’atteindre le marché de la haute disponibilité. Et peu d’entre eux ont perçu que ce serait aussi un moyen intéressant d’établir un environnement coffre-fort à distance. Pendant un temps, nous avons simplement cru fabriquer une meilleure tuyauterie pour les produits existants.

Comprendre les plans d’accès et les chemins de données ouverts

par Dan Cruikshank, Mis en ligne le 07/06/2006 - Publié en Février 2006

Dans l’article « Comparaison des performances entre fichiers définis par DDS et fichiers définis par SQL » (iSeries News juillet 2005, www.itpro.fr Club abonnés), j’expliquais les différences architecturales entre les objets base de données créés par SQL DDL et DDS. J’indiquais aussi comment reconditionner les bases de données DDS existantes pour que les programmes HLL existants puissent bénéficier des améliorations SQL. Cette stratégie constitue la phase 1 de ma méthodologie de réingénierie de base de données et de transformation des programmes applicatifsIci, je commence à examiner la phase 2 :
l’isolation de la base de données. En fait, la phase 1 était la première étape vers cette isolation. En essence, tous les objets et membres source PF (Physical File) DDS ont été convertis en objets et membres source LF (Logical File) DDS. Le code source LF DDS existant a été modifié pour partager les chemins d’accès index 64 K SQL et, si nécessaire, partager le format du fichier physique original transformé (figure 1).

Les environnements de la phase 2 sont caractérisés par la séparation de la fonction d’I/O base de données d’une part, des processus de gestion et de présentation de l’application d’autre part. Cela a porté plusieurs noms (développement d’application n-tier, Model-View-Controller, par exemple).
Pour obtenir les meilleurs résultats avec SQL, je vous conseille de commencer avec une base de données créée par SQL (phase 1) et d’effectuer tous les accès base de données via des instructions DML (Data Manipulation Language) SQL imbriquées dans les modules d’I/O HLL (phase 2).

J’évoque d’autres changements architecturaux notables concernant la manière dont un programme HLL RLA (Record Level Access) et un programme HLL contenant du SQL imbriqué statique, sont activés puis exécutés. En particulier, je compare la vérification du format d’enregistrement RLA et la validation du plan d’accès SQL et je parle de la faculté de réutilisation d’ODP (Open Data Path).

Je suis la structure de la série Performance Mystery écrite avec James Stewart. Pour commencer, je présente une situation client réelle, en comparant les résultats avant et après.
Ensuite, j’entre dans le détail de la solution à apporter au problème client. Je clos le débat avec quelques considérations et recommandations.
Dès lors que les développeurs d’applications comprennent le mécanisme de base de l’initiation, de l’exécution et de la terminaison des programmes, ils pourront écrire un code meilleur et plus efficace dès la première fois, évitant ainsi de rendre une visite coûteuse à votre serviteur. Parfois, ces visites ne sont pas très agréables.

Utiliser .NET pour développer des applications de file d’attente de données iSeries

par Michael Otey, Mis en ligne le 10/05/2006 - Publié en Décembre 2005

Les files d’attente de données sont depuis longtemps l’un des mécanismes de transfert de données les plus rapides sur l’iSeries. Leur vitesse permet d’écrire des applications Windows qui interagissent avec l’iSeries. De plus, comme elles peuvent transporter des données et des messages structurés et non structurés entre deux plates-formes, on peut même les utiliser pour un contrôle d’application bidirectionnel, où l’on peut contrôler et passer des données à une application client Windows ou Web à partir de l’iSeries, ou vice-versa – le tout avec un temps de réponse de moins d’une seconde.Cependant, malgré leur vitesse, les files d’attente de données sont souvent sous-utilisées sur l’iSeries. Et elles sont difficiles à utiliser dans le développement client Windows .NET parce qu’IBM n’a pas encore fourni une composante de file d’attente de données .NET native. Mais, en tirant parti de la capacité de .NET Framework à utiliser directement des objets COM (Component Object Model) existants, vous pouvez employer les possibilités d’accès aux files d’attente de données du provider OLE DB (IBM OLE for Databases) pour utiliser Visual Studio et le .NET Framework dans des applications de files d’attente de données iSeries.

News iSeries – Semaine 16 – 2006

Toutes les actualités de la semaine du 17 au 23 Avril 2006

Trucs & Astuces : Telnet pour UDP, système Voip

Les trucs & astuces de la semaine du 18 au 24 Septembre 2006

De nouvelles manières de stocker la source

Vous l’avez fait des centaines de fois, peut-être des milliers. Vous connaissez le scénario par coeur : (1) créer un membre dans un fichier source, (2) éditer le membre source, et (3) compiler le membre source pour créer un programme ou un module.
L’enchaînement est le même, que la source soit RPG, CL ou Cobol, que vous utilisiez l’OPM (Original Program Model) ou ILE, ou que vous utilisiez PDM ou WDSc (WebSphere Development Studio Client). En substance, un programme est toujours un membre dans un fichier source qui réside dans une bibliothèque. Pas si vite ! Voici que de nouvelles releases et outils de développement offrent plus de variété pour stocker, éditer et compiler la source. Désormais, votre source peut être dans des membres source traditionnels, dans des fichiers texte de l’IFS, ou dans des fichiers texte sur votre PC en tant que projets WDSc.Dans cet article, je présente les nouvelles possibilités en matière d’éditeurs de type PC, d’outils de gestion des changements et d’outils collaboratifs pour le développement de programmes iSeries.

De la haute disponibilité à  la continuité de l’activité

Les notions de haute disponibilité, et de poursuite de l’activité sont intimement liées à la reprise après sinistre. Et, trop souvent, nous nous trouvons au coeur même de la catastrophe. Les ouragans Katrina et Rita ont dévasté des centaines de milliers de kilomètres carrés, déplacé des milliers de personnes et perturbé une multitude de sociétés et d’entreprises. Ailleurs dans le monde, d’autres catastrophes naturelles ont anéanti des populations entières. L’enseignement à en tirer n’est pas simplement que la nature a le pouvoir de mettre fin à nos vies et à nos activités, mais aussi l’étendue et la durée de telles tragédies. Trop souvent, nous considérons les sinistres comme des ennuis qui suspendent notre exploitation pendant une courte période. En réalité, nous voyons de grandes zones géographiques frappées pendant plusieurs mois.La nature n’est pas le seul danger que courent les entreprises. Il y a aussi les menaces de terrorisme, comme en témoignent les attaques mortelles dans le monde et près de chez nous. Une sale bombe ou un agent biologique peut rendre une ville inhabitable pendant plusieurs années. Songez aux centaines ou aux milliers d’ordinateurs présents à proximité de la Maison Blanche et du Capitole. Ces centres de gouvernement sont-ils suffisamment protégés contre d’éventuelles campagnes de terreur ?

La figure 1 ne contient qu’une liste partielle des sinistres susceptibles de frapper une société. Si de tels événements se produisent, nous risquons d’être coupés de nos centres informatiques pendant de longues périodes. Et même si nous pouvons récupérer l’information depuis des sites de secours, le personnel pourrait être tellement dispersé que toute reprise de l’exploitation normale serait impossible. Pis encore, nos centres de secours pourraient se trouver près de l’entreprise et, par conséquent, être aussi mal en point que le site principal. Enfin, même si la reprise purement informatique réussit, nos autres actifs et ressources pourraient être tellement affectés que toute poursuite de l’activité serait illusoire.

En tant que professionnels IT, nous devons, avec nos entreprises, élaborer des plans à plusieurs niveaux pour la haute disponibilité, la poursuite de l’exploitation, la reprise après sinistre et la continuité de l’activité. De tels plans doivent viser une protection continue contre des dangers très divers, allant de problèmes techniques internes aux événements externes et aux perturbations globales. Ils doivent répondre aux préoccupations de tous les responsables de l’entreprise, dans tous les services et départements.

Comparaison des diverses techniques de tri de sous-fichiers

par Scott Klement, Mis en ligne le 07/06/2006 - Publié en Février 2006

Au fil des ans j’ai reçu de nombreux conseils sur « la meilleure » manière de trier un sous-fichier. Certaines des méthodes préconisées étaient simples, d’autres très complexes, mais toutes m’étaient présentées comme « la plus efficace ». Vous conviendrez avec moi que toutes ne peuvent pas être les plus efficaces. Dans cet article, je passe en revue plusieurs méthodes de tri d’un sous-fichier, j’analyse leurs avantages et inconvénients et teste chacune d’elles pour illustrer les différences de performances.Les documents traitant de performances doivent toujours être interprétés avec circonspection. En effet, les performances résultent de nombreux facteurs qu’il est difficile de prendre en compte globalement. Si vous attachez une grande importance à la performance, le mieux est d’essayer chaque méthode de tri par vous-mêmes avant d’en choisir une. Bien que je me sois efforcé de fournir des résultats aussi exacts que possible, votre matériel et vos données sont certainement différents des miens et il est donc probable que vos résultats ne seront pas exactement les mêmes. Pour que vous compreniez bien comment j’ai obtenus les nombres présentés dans cet article, je vais commencer par décrire l’environnement utilisé.

ISA Server 2004

par Paul Thurrott - Mis en ligne le 15/05/06 - Publié en Janvier 2005

Microsoft a prolongé sa première tentative de produit pare-feu et de cache sur Internet, sous le nom de Microsoft Proxy Server, avec une release logicielle bien plus impressionnante : Microsoft Internet Security and Acceleration (ISA) Server 2000. ISA Server 2000 offre des possibilités pare-feu d’entreprise multicouches, un proxy Web et des services de cache, une inspection de paquets « stateful » et d’autres fonctions de sécurité modernes dans un package logiciel évolutif et performant. Quatre ans après, Microsoft est sur le point d’annoncer son produit pare-feu de troisième génération, ISA Server 2004. Le nouveau venu offrira toujours plus de fonctionnalités, dont une option de type matériel intéressante qui devrait séduire les grandes entreprises. Voici ce qu’il faut savoir sur ISA Server 2004.

Les nouveautés de la semaine 16 – Windows IT Pro – 2006

Tous les nouveaux produits de la semaine du 17 au 23 Avril 2006

Trucs & Astuces : fichiers save PTF

Les trucs & astuces de la semaine du 11 au 17 Septembre 2006

Comment supprimer des fichiers SAVE PTF ?