Hommage à l'AS400

L'AS400, enjeu de migrations délicates

Il faudra un jour arrêter l'AS/400 ... Quand, comment.

Machine robuste, adulée par ses administrateurs et parfois véritable épine dans le pied de DSI digitaux.   

Très populaire dès ses premières commercialisations en 1988, l'AS/400 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'AS/400 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, etc même si ce sont des composants différents.

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

L'OS s'appellait 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.

Le hardware est maintenant à celui de la famille Power, une plateforme middle range bâtie autour des processeurs propriétaires Power. Il est possible d'ajouter des processeurs autres d'ailleurs mais c'est un détail.

Ce socle matériel accueille des partitions, l'équivalent des VM, de plusieurs OS différents, IBM i ou AIX, l'Unix d'IBM, mais aussi des Linux.  Dans la pratique, un client ne mélange pas sur le même hard 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, généralement les entreprises clientes de l'AS/400 n'ont que deux AS/400 en réplication et ne vont pas sur le clustering type banque compte tenu des investissements 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 hors de la base AS400. L'accès par les applicatifs AS400 aux données peu structurées, aux fichiers bureautiques est toujours 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. 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 DB2. L'OS est bati 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. 

L'AS400 n'a pas un vrai moniteur transactionnel comme sur mainframe, ce qui a 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 été perdu plusieurs fois.

Autre aspect, l'absence de moniteur transctionel 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 maitrisent 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. 

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.

Exemples de positions sur l'AS400 de cabinets impliqués dans les migrations :

https://www.axopen.com/blog/2024/05/migration-as-400/

en plus nuancé

https://archipelia.com/logiciel-as400/ 

Logiciels de réplication et haute disponibilité par le socle

https://foxeet.fr/contenu/solutions-haute-disponibilite-ibm-i-as400-cloud

Profils users

https://www.volubis.fr/news/liens/courshtm/AS400/AS_SECURITE.htm

Anectode : en France, les premiers clients de l'AS400 ont été tirés au sort.