Détails

https://www.ibm.com/history/as-400 — L'AS400, une machine populaire qui a ouvert l'informatique d'entreprise aux ETI

Hommage à l'AS400

Succès commercial, l'AS400 a été adopté avec enthousiasme dans les années 1990 par les ETI pour créer leur SI.

L'AS400, enjeu de migrations ERP

Il faudra un jour arrêter l'AS400 ... Quand, comment.

Machine robuste, adulée par ses administrateurs et parfois véritable épine dans le pied de DSI digitaux à la feuille de route trop politisée.

Très populaire dès ses premières commercialisations en 1988, l'AS400 a été le socle du SI de nombreuses entreprises intermédiaires, heureuses d'accéder à des technologies fiables et souples réservées aux grands groupes.

L'écosystème s'est développé fonctionnellement avec de nombreux ERP, progiciels, applications verticales. Par exemple, MOVEX présent dans l'industrie.

Evidemment, avec le PC, les smartphones, la virtualisation, d'autres solutions sont venues et ont mis l'AS400 hors jeu.

Le poids du legacy et le développement par opportunités d'éléments du SI ont rendu bien délicates les cohabitations et migrations.

Le départ à la retraite de toute une génération d'informaticiens, plus ou moins autodidactes, termine la discussion.

Vocabulaire et composants d'une machine tant aimée

Le terme AS/400 n'existe plus depuis longtemps, mais il a été tellement populaire...

Nous pourrons utiliser le terme générique AS400 pour l'OS IBM i, voire la base DB2, la plateforme matérielle, même si ce sont des composants différents.

Détaillons le vocabulaire, les composants, l'architecture, cela aidera à mieux comprendre la situation pour vivre avec l'AS400 et le quitter.

La petite machine qu'il était possible d'installer sur son bureau et opérationnelle en 2 heures d'installation est devenue un système complexe nécessitant plusieurs compétences différentes.

L'OS s'appelait OS/400. Selon le marketing IBM et le portage sur la plateforme hardware Power d'IBM, l'OS s'est appelé eServer i5, i5/OS, IBM i.
L'OS comprend aussi des services de sécurité, la base de donnée, un système de développement, une interface user. Il est donc fonctionnellement riche.

Le hardware est maintenant à celui de la famille Power, une plateforme middle range bâtie autour des processeurs propriétaires IBM Power.

Ce socle matériel accueille des partitions qui se partagent les ressources matérielles. On peut comparer une partition à une VM, mais plus statique et très localisée à un serveur. Il est possible d'avoir des partitions d'OS différents, IBM i ou AIX, l'Unix d'IBM, mais aussi des Linux. Dans la pratique, un client ne mélange pas trop sur le même serveur Power des partitions AIX et IBM i parce qu'il n'a pas les doubles compétences.

La plateforme Power a bénéficié d'une certaine façon du savoir faire de haute disponibilité IBM atteint sur ses mainframes.

Pour autant, les entreprises clientes de l'AS400 n'ont généralement que deux serveurs AS400 en réplication et ne vont pas sur le clustering étendu type banque, compte tenu des investissements requis et de leur besoin métier. Voir l'article sur les outils de réplication Mimix, QuickEDD et les solutions de sauvegardes.

Le stockage a évidemment évolué. Les disques internes ont été remplacés par du stockage externe attaché en direct ou via un SAN. L'AS400 voit les disques, la mémoire comme un seul groupe, ce qui est une forme de limitation.

L'autre aspect concerne le stockage de fichiers qui sont quelque part hors de l'AS400 car la base DB2 AS400 joue un rôle central. L'accès par les applicatifs AS400 aux données peu structurées, aux fichiers bureautiques est plus compliqué qu'aux données de la base.

L'ingénieur AS/400 devient donc un spécialist Power, ce qui est une discipline à part.

Généralement, c'est l'intégrateur IBM qui prend complètement à sa charge le socle. Il faut maîtriser plusieurs couches : le firmware Power, l'hyperviseur Power, une première couche de virtualisation dépendante du hardware SLIC, une seconde XPF avec une interface TIMI, etc

De plus, l'intégrateur devra posséder un savoir-faire SAN de bon niveau car le besoin métier nécessite souvent d'aller jusqu'à une réplication des données.

Bref, il vaut mieux que l'intégrateur ait de bons spécialistes.

Il est clair que la plateforme Power va durer encore longtemps. IBM est impliqué dans des contrats longue durée avec des clients américains stratégiques.

Par contre, la tarification reste celle d'un système propriétaire géré par IBM.

Un point clé de l'AS400, c'est la base de donnée relationnelle.

L'OS est bâti sur une base relationnelle, appelée ensuite DB2 for IBM i. pour évoquer un air de famille avec le DB2 original sur mainframe IBM, dont il ne partage pas le code.

Comme les équipes client sont de petites tailles, l'ingénieur système devra à un moment ou à un autre devenir un DBA avec une vraie maîtrise SQL. Une compétence DB2 AS400 en cas de problème de performance n'est pas simple à trouver.

L'AS400 n'a pas un vrai moniteur transactionnel comme sur mainframe, ce qui a indirectement favorisé un code applicatif spaghetti, d'autant plus que le savoir faire en termes de génie logiciel était l'apanage de quelques secteurs clés, sans enseignement informatique dans les cursus d'ingénieur. Si le développement n'a pas été migré sur un progiciel structurant, l'entreprise se retrouve souvent avec un code, dont la maîtrise a pu être perdu, voire plusieurs fois.

Autre aspect, l'absence de moniteur transactionnel distribué.

En conclusion, peu d'API utilisables pour l'intégration applicative. Il faut aller piocher directement dans la base.

Les commandes systèmes IBM i ou d'exploitation peuvent être lancées par menu (les fameux écrans verts) ou tapées à la main. La grammaire est claire ce qui fait que les administrateurs maîtrisent bien les commandes. Ce qui donne au non-initié l'impression d'un système hésotérique. La partie maintenance dite DST ou purement Power est par contre moins maîtrisée. Il est peu fréquent d'y accéder.

Exemple d'écran AS400. Le menu princpal :

L'AS400 était accédé via des terminaux ligne à ligne 5250 avec ses écrans verts avec le protocole propriétaire IBM, puis en TCP/IP. Des émulateurs sont disponibles sur PC.

Comme le point de référence de la donnée pour l'entreprise est la base AS400, les clients et éditeurs ont souvent construit des requetages ou des applications client/serveur autour de la base DB2. Sur chaque PC, on installe le client lourd applicatif, souvent développé en France avec Windev.

Puis, les équipes ont virtualisé ces clients lourds sur PC Windows avec des infrastructures de type CITRIX. Cela a permis de rendre les applications accessibles en local à des partenaires, réseaux commerciaux tiers sur Internet. Et éviter d'installer le client lourd.

Comme l'usage de l'applicatif AS400 a grossi, il a fallu mettre l'AS400 dans un vrai datacenter et l'éloigner de la machine à café. D'où le même problème d'accès pour les équipes de client.

Avec les applications digitales, les équipes ont ajouté d'autres applications frontales, au début avec avec des framework PHP, puis d'autres technologies multi-couches. En général, ces applications internet accédaient à leurs propres serveurs bases données open source mais aussi Oracle dont il fallait synchroniser tout ou partie des données avec l'AS400.

L'usine à gaz ... pas facile à démonter sans une vraie stratégie SI et une approche donnée.