Discussion :

[Isma.S]

Bonjour à tous,

Je souhaiterais connaitre en quoi consiste le métier de développeur Mainframe, quelqu'un qui exerce actuellement ce métier, pourrait-il m'expliquer en quoi consiste son métier et quelles sont ses missions quotidiennes?

En vous remerciant par avance pour la prise en compte de mon message!

Bonne soirée!

Vos réponses sont les bienvenues

[Isma.S]

Si possible un bref descriptif pourrait me convenir également

[el_slapper]

Le mainframe, ce sont des machines très vieilles et très fiables, qui sont optimisés pour des traitements de gestion massifs, notamment comptables. La plupart des développements là-dessus sont en COBOL(avec parfois du C ou de l'assembleur), et c'est généralement de la maintenance. Au moins 80% de maintenance, évolutive, corrective, ou, quand on a de la chance, préventive. Ces machines sont très présentes dans les grands comptes, spécialement les banques. On y trouve généralement des programmes qui ont 10, 20 voire 30 ans d'âge. J'ai partiellement refondu, en 2008, une chaine dont l'un des programmes datait de 1972.

Donc, parfois on a du projet : une feuille blanche, et on doit développer un nouvel applicatif. Mais même là, l'aspect feuille blanche est limité : on doit prendre en compte les référentiels existants, les normes de développement locales, très souvent d'intégrer entre deux chaines existantes, etc...

Mais le plus fréquent, c'est la maintenance. La maintenance préventive, i.e. corriger un existant pour prévenir de futurs problèmes, c'est trop rare à mon gout. Les deux standards sont la maintenance évolutive et corrective.

La maintenance évolutive, c'est "Tiens, el_slapper, il faudrait que désormais, dans le tableau de bord des privés, pour telles assurances-vie, on compte aussi les professionnels, les entreprises, et même les institutionnels"(je sais, c'est un contresens fonctionnel total. On m'a vraiment fait faire ça en 2010). Le délai se compte généralement en semaines.

La maintenance corrective, aussi appelée "à chaud", c'est "au secours!!! el_slapper, les tableaux de bord des privés sont plantés, le grand chef les veux pour avant-hier sans faute! Remets-nous ça d'équerre!!!". Le délai se compte généralement en heures.

On travaille sur des terminaux en mode texte, qui font peur aux jeunots habitués aux interfaces graphiques. On m'a traité plusieurs fois de "Star Trek" à cause de ça. Ca m'a fait beaucoup rigoler. Mais au moins, on bosse sur des machines hyper-fiables.

[Isma.S]

Merci pour la réponse, à vrai dire je voulais me renseigner sur ce métier pour en avoir une idée, donc en gros c'est de la maintenance.

[el_slapper]

Merci pour la réponse, à vrai dire je voulais me renseigner sur ce métier pour en avoir une idée, donc en gros c'est de la maintenance.

Pas seulement, mais vu l'âge des applicatifs, oui, il y en a beaucoup.

EDIT : ça ne veut pas dire que c'est facile, ou mécanique. Il y a pas mal de savoir-faire, et souvent besoin de créativité pour résoudre des problèmes tordus. Mais, en effet, on ne part jamais d'une feuille blanche. On est toujours les lointains successeurs d'une longue lignée de codeurs..... certains étant plus clairs que d'autres.

[Isma.S]

Ok, donc si je comprends bien, en résumé c''est trouver un moyen d'optimiser des bases de données pour que celles-ci fonctionnent bien?

[el_slapper]

Ok, donc si je comprends bien, en résumé c''est trouver un moyen d'optimiser des bases de données pour que celles-ci fonctionnent bien?

Euh, c'est très loin de se limiter aux bases de données. D'ailleurs, on travaille plus souvent sur fichiers plats(question de performances). Mais oui, ça fait partie du boulot. D'une manière générale, on a un grand nombre de traitements par lots, quelques transactions(pour elles, on échappe pas aux bases de données), et parfois il faut les mettre au gout du jour. Et parfois, il y a des plantages, ou des anomalies, donc il faut corriger.

Exemple de plantage : une petite transaction permet de générer une liste de clients à contacter par la banque pour leur vendre un produit. Derrière, un traitement par lot transforme mensuellement l'ensemble des listes par produit en listes par agent, chaque agent devant contacter ses propres clients. Problème : quand l'utilisateur a oublié de donner un motif à l'appel, la chaine plante. Boum. Cassé. Pas de fichier de sortie, pas de liste pour les agents, pas d'appels pour vendre les produits aux clients, pas de chiffre d'affaires qui augmente, pas de prime pour le grand chef. Le drame.

Correction de niveau 1 : on injecte manuellement et salement une valeur là ou il en faut une(base ou fichier), et on relance. Ca permet de passer la journée.

Correction de niveau 2 : on change le traitement par lot pour qu'il fasse un rejet propre si il lui manque des données importantes. Comme ça, quand il tourne et que ça ne marche pas, les gens qui créent des campagnes sont avertis qu'ils ont fait des conneries, corrigent en vitesse, et on relance. Ca permet de passer le mois.

Correction de niveau 3 : on ne permet pas, dans la transaction, de valider une campagne qui n'a pas tout impeccable. Et on a plus de problème du tout.

Donc voilà, on a du transactionnel, du batch, de la base de données, du fichier plat, des problèmes à chaud, de la maintenance à plus long terme, tout ça. Et un peu de politique aussi, parceque le client n'était pas chaud pour financer les niveaux 2 et 3.

[Isma.S]

Ok, j'ai un peu insisté comme ça me semble très éloigné de ce que je connais, c'est vrai qu'on a un peu du mal à s'imaginer les choses, après c'est vrai qu'il n'y a pas mieux que pour bien comprendre un métier, c'est de l'expérimenter mais à défaut on fait avec,

Merci pour ce descriptif détaillé