Rédaction Article : Qu'est-ce que le Mainframe IBM aujourd'hui ?

Faire une liste des mainframes que je connais est relativement compliqué....

Sans vouloir faire le rabat-joie, j'ai un gros problème avec le mot "mainframe". En effet, autant quand on dit "mainframe IBM zSeries", c'est clair et précis, mais le mot seul ne veut pas dire grand chose... il ne faut surtout pas perdre de vue que c'est au final un terme de marketeux et de journaleux...

Pour preuve évidente : si un anglophone vous dit "the mainframe of whatevercompany", il parle de l'infrastructure principale (salle serveur ou datacenter) qui gère le "métier" (donc hors datawarehouse ou systèmes redondants ou autres systèmes périphériques), peu importe le type d'ordinateur dont est composée cette infrastructure.

Donc partant de là, faire une classification des machines d'aujourd'hui devient compliquée. Parce que même le terme "minis", si on regarde wikipedia, il y est inscrit : "In a 1970 survey, the New York Times suggested a consensus definition of a minicomputer as a machine costing less than 25 000 USD, with an input-output device such as a teleprinter and at least 4K words of memory, that is capable of running programs in a higher level language, such as Fortran or Basic". Cela donne une idée sur la précision de la définition ;)

Ces termes "mainframe" et "minis" date d'avant l'époque du PC où le traitement était totalement déporté sur le mainframe alors que les utilisateurs utilisaient des terminaux passifs. Et quand le PC s'est développé, les termes sont restés pour différencier les anciennes architectures centralisées des "nouvelles" architectures distribuées se reposant beaucoup sur des clients lourds installés sur les postes clients. Sauf que depuis la fin des 90s avec l'avènement d'internet, de la virtu et maintenant du cloud, on ne peut que constater un retour à une architecture centralisée... qu'elles reposent sur du power, de l'itanium ou du x86, les infrastructures modernes reprennent les même concepts architecturaux que les "mainframes" originels.

Tout ça pour dire qu'un article dédié aux mainframes IBM zSeries c'est une idée génial, mais qu'aborder le monde du "mainframe" dedans c'est s'aventurer sur une pente très glissante. Pour peu qu'un gros relou comme moi passe dessus, cela peut décrédibiliser à tort le contenu complet de l'article...

Les "types d'ordinateurs" auraient besoin d'un article complet. Par exemple : comment classer les Oracle EXADATA ou appliance TERADATA qui peuvent rivaliser avec les zSeries en terme de puissance brut et de prix mais qui sont dédiés à un service ?

OK !

Donc on restera à 100% dans Mainframe IBM zSeries ! :o

Les types d'ordinateurs ce sera pour plus tard, mais c'est une idée ! :P

Donc je retirerai la partie "constructeurs" avec ton explication... je citerai à la va-vite que Bull (cocorico...) en fait encore quelques-uns sous GCOS avec un dialecte JCL légèrement différent de celui d'IBM.


Bon bah au moins on se recentre bien.

Citation:

---

Envoyé par Metalman

OK !

Donc on restera à 100% dans Mainframe IBM zSeries ! :o

---

Attention ! ... " System z " ... et plus " zSeries " ...

Si je comprends bien vous souhaitez parler de ces grosses boboîtes là :

Pièce jointe 142970

Dont les utilisateurs ont un vocabulaire bien particulier, ils parlent de DSN ou GSAM pour les fichiers, il n'y a pas d’arborescence hiérarchique mais un catalog, les programmes ne plantent pas mais ils se terminent anormalement ABEND, la console système est une HMC, on ne reboote pas un monolithe mais il fait IPL, on ne patche pas le système mais on applique un PTF, point d’ASCII mais de l'EBCDIC, et on aime tellement le COBOL et le codage décimal que des instructions sont câblées pour fonctionner nativement avec cette représentation…
Bref un monde (celui de z/OS) qui a ses propres codes et en définitive pas grand-chose à voir avec celui de la « micro » informatique ?

Euh... oui... à peu près (et c'est pas GSAM mais VSAM... la HMC ne sert que de console équivalente à celle du BIOS car cela modifie la déclaration du matériel, et non le système d'exploitation... l'ASCII est géré "maintenant", etc.)

Ca pue le troll mais je vais oser répondre :
Car le vocabulaire en question est arrivé "avant" l'ère de la micro et "avant" que les technologies soient disponibles sur micros.
Ce qui fait que les choix sont technologiquement "légèrement" différents et impliquent une vision technique différente elle aussi.

Le but sera donc de montrer les différences, et SURTOUT de démontrer que l'on ne fonctionne plus avec des cartes perforées aujourd'hui en 2014, et que les machines sont belles et bien à la pointe de la technique....
...et que le monde "open"/"moderne" est totalement disponible avec zLinux qui utilise réellement les capacités impressionnantes de la machine.

EDIT : et jeudi dernier à l'université du mainframe 2014, il a été montré qu'un hébergeur web créé en 1996 a finalement sauté le pas : il a acheté un zBC12 sous zLinux (aucun z/OS) pour assurer ses SLA pour du streaming continu.

Citation:

---

Envoyé par Metalman

...
VI) Le développement sous z/OS
1) Le développement classique : TSO et ISPF
2) Les principaux langages de programmation.
2.1) L'assembleur.
2.2) Le COBOL.
2.3) Le PL/1
2.4) Le C/C++
2.5) Les langages de script : CLIST et REXX
2.6) L'arrivée de Java.
3) Le développement "moderne" avec RDz
4) Les autres outils du développeur.

---

oups ... j'ai oublié FORTRAN

Donc :

VI) Le développement sous z/OS
1) Le développement classique : TSO et ISPF
2) Les principaux langages de programmation.
2.1) L'assembleur.
2.2) Le FORTRAN
2.3) Le COBOL.
2.4) Le PL/1
2.5) Le C/C++
2.6) Les langages de script : CLIST et REXX
2.7) L'arrivée de Java.
3) Le développement "moderne" avec RDz
4) Les autres outils du développeur.

Je ne sais pas si sur mainframe le FORTRAN est encore utilisé, mais je connais plusieurs scientifiques qui utilisent du FORTRAN, du C, du C++ et du OCaml pour leurs travaux (mais sur des Linux tout à fait classiques bien évidemment).
Je serais bien curieux de savoir à quoi il servait et à quoi il sert encore.
Le COBOL, je vois plutôt bien la partie "business" liée avec z/OS... mais le FORTRAN me semble très "calcul pur".



Bref donc le sommaire pour le moment serait :

I) Introduction
1) usages actuels (citer les ERPs dispos dessus) + raisons actuelles de l'utilisation des mainframes + OS actuellement disponibles sur les Mainframes IBM
2) positionnement des mainframes IBM dans les SI/infras (les schémas dans les slides IBM que l'on m'avait fourni il y a longtemps semblent bien, et celles de jeudi dernier avec zLinux et z/OS travaillant "ensemble" semblent encore mieux !)
3) organisations autour du mainframe (des études à la "prod'" : études/recette/qualification (préprod')/production)
4) quelques chiffres sur le mainframe (on pourrait extraire les chiffres du livre blanc IDC présenté à l'université du mainframe 2014 ?)

II) Historique
1) S360 => EBCDIC & cartes perforées, JCL & JES, FORTRAN & COBOL & PL/I & BAL
2) S370 & MVS => mémoire virtuelle, partage de la machine physique (PR/SM, LPAR, Sysplex) "le 1er Cloud", ouverture sur le réseau
3) S390 => insertion d'USS/OMVS
4) zSeries/System z/z Architecture => zLinux, zBX et liaison AIX/Windows encore plus proches, ...

III) Matériel
1) Baies, CPU et mémoire (les 4 baies)
2) Connectique, I/O, et disques (CU, channels & CHPID, 3390 émulés, SAN)
3) Réseau (SNA, TCP/IP) & Terminaux (3270)
(où mettre les HiperSocket ? Réseau ou I/O ? Est-ce vraiment du matériel ?...)
4) zBX & ajout d'autres OS en connectique ultra rapide

IV) OS & Logiciels liés
1) z/OS
1.a) JES (JES2 & JES3) et le JCL
1.b) OPC/TWS (ardu à placer ici... car il n'est pas "fondamental" pour z/OS, mais très utilisé en entreprise)
1.c) TSO & ISPF
1.d) OMVS/USS
1.e) Datasets
1.f) VSAM
2) zLinux
3) z/VM
4) z/VSE & z/TPF (en diagonale)

V) "middlewares" (à améliorer)
1) SGBD
1.a) DB2
1.b) IMS DB
2) Transaction Processing/Moniteurs Transactionnels
2.a) CICS
2.b) IMS DC
3) WAS
4) MQ
5) CFT
6) autres...

VI) Le développement sous z/OS
1) Le développement classique : TSO et ISPF
2) Les principaux langages de programmation.
2.a) L'assembleur.
2.b) Le FORTRAN
2.c) Le COBOL.
2.d) Le PL/1
2.e) Le C/C++
2.f) Les langages de script : CLIST et REXX
2.g) L'arrivée de Java.
3) Le développement "moderne" avec RDz
4) Les autres outils du développeur.



Cadre d'intro :

Citation:

---

Cet article traitera du Mainframe, et particulièrement celui d'IBM appelé System z. Il ne faut pas confondre les "Mainframes" avec les "Minis" dont les System i (aussi appelés AS/400) font partie. Il existe actuellement d'autres constructeurs de mainframes sur lesquels nous ne nous attarderons pas : en France par exemple, Bull continue à commercialiser ses GCOS dont le langage de batch est un dialecte JCL très proche de celui des System z d'IBM.

---

EDIT : dès que vous me validez le sommaire, je fais le .docx de base... chacun est libre d'y ajouter ses connaissances... je mettrai les miennes évidemment :)
Et je recondenserai le tout.

Citation:

---

Envoyé par Metalman

IV) OS & Logiciels liés
1) z/OS
1.a) JES (JES2 & JES3) et le JCL
1.b) OPC/TWS (ardu à placer ici... car il n'est pas "fondamental" pour z/OS, mais très utilisé en entreprise)
1.c) TSO & ISPF
1.d) OMVS/USS
1.e) Datasets
1.f) VSAM
2) zLinux
3) z/VM
4) z/VSE & z/TPF (en diagonale)

V) "middlewares" (à améliorer)
1) SGBD
1.a) DB2
1.b) IMS DB
2) Transaction Processing/Moniteurs Transactionnels
2.a) CICS
2.b) IMS DC
3) WAS
4) MQ
5) CFT
6) autres...

---

Il faut, je pense, aborder en premier toute la couche sysplex & cie : la mutualisation des ressources hardware, pour ne faire qu'une "plate-forme virtuel" qu'on redécoupe en LPAR (genre de vm) avec des ressources partagées, est un des points clé du "mainframe" par rapport aux types d'ordinateurs.(Il me semble qu'ESX permet maintenant de le faire sur des serveurs x86 mais je n'ai pas eu le temps - ni l'opportunité - d'étudier tout ça encore...)

Ensuite concernant le système de fichier, là aussi il ya de grande différences avec la micro. Donc déjà c'est gérer par DFSMS et DFHSM, et honnêtement, je n'ai jamais compris ce que faisais l'un où l'autre excatement (à part quelques services précis). Et pour les types de fichiers, je pense que par "datasets" tu entends les fichiers séquentiels "de base" qui sont de mémoire des QSAM qui, comme tu l'as noté, sont bien différents des VSAM. Mais ils existe aussi les BDAM et les ISAM et d'autres que je ne connais pas (alors oui la plupart sont obsolètes, mais j'en ai déjà croisé récemment :aie: ). Le mot "dataset" pour désigner les QSAM est aussi un abus de langage très répandu, un dataset étant un fichier quelque type soit-il.

Pour finir sur cette partie, je ne suis pas convaincu par le "classement" des logiciels et middleware mais j'avoue ne pas avoir de réelle proposition... en effet, pour moi, TSO et CICS devraient dans le même bac : ce sont 2 moniteurs, certes le premier en Time Sharing et le second en Transactionnal mais le service fondamental rendu est le même. Et OPC/TWS n'est pas au même niveau que ces moniteurs : par exemple, on accède à TWS par TSO.
Peut être des sections du style : "Services Systèmes" avec TSO, CICS, JES, IMS DC, et "Applications standard" avec TWS, DB2, MQ, IMS DB... à voir (au passage : CFT est à ma connaissance un produit AXWAI et est payant en sus)

Citation:

---

Envoyé par Metalman

VI) Le développement sous z/OS
1) Le développement classique : TSO et ISPF
2) Les principaux langages de programmation.
2.a) L'assembleur.
2.b) Le FORTRAN
2.c) Le COBOL.
2.d) Le PL/1
2.e) Le C/C++
2.f) Les langages de script : CLIST et REXX
2.g) L'arrivée de Java.
3) Le développement "moderne" avec RDz
4) Les autres outils du développeur.

---

Qu'entends-tu par "1) Le développement classique : TSO et ISPF" ?
Si cela concerne l'édition du code source, il existe des AGL qui tournent sur des CICS (je connais PACBASE - qui a même un client lourd windows pour le dev z - mais il m'en a été évoqués d'autres)

Ensuite, seule la couche programmation semble être abordée, or le développement d'application c'est bien plus que ça ;)
Et c'est surtout au niveau conception logicielle que la différence entre la micro et le mainframe se voit. Une application en micro est souvent constitué de programmes/classes réparties par fonctionnalité (une fonctionnalité = un programme/classe). Or sur le z, une application est souvent d'une part divisé entre la partie TP et la partie batch, mais d'autre part les programmes sont répartis par transaction ou chaines batch, et ce sont ces derniers qui sont répartis par fonctionnalité. Au final, un programme z correspond à une fonction dans un programme/classe micro, alors qu'un programme/classe micro correspond à une transaction/chaine batch sur le z. Cette différence a de grandes implications sur la façon de penser et de concevoir les applications.
De plus, dans le développement d'applications z, on a beaucoup recours aux utilitaires standards (comme le DFSORT ;) ), qu'il faudrait présenter aussi dans un tel dossier, mais là encore je n'ai pas de proposition pour bien les ranger...

Voili voilou !
Alors je suis désolé d'apporter plus de remarques "négatives" que de propositions mais je n'ai malheureusement pas le temps de faire plus de recherches pour être vraiment moteur...

Côté matériel : c'est abordé avant les logiciels... donc c'est réglé ! :P
Par contre j'avais zappé le coup des sysplex !
Donc à modifier dans le sommaire :

III) Matériel
1) Baies, CPU et mémoire (les 4 baies)
2) Connectique, I/O, et disques (CU, channels & CHPID, 3390 émulés, SAN)
3) Réseau (SNA, TCP/IP) & Terminaux (3270)
(où mettre les HiperSocket ? Réseau ou I/O ? Est-ce vraiment du matériel ?...)
4) Sysplex : Mutualisation & Redondance
5) HMC et IPL
6) zBX & ajout d'autres OS en connectique ultra rapide


DFSMS et DFHSM c'est... je ne sais pas non plus.
Après pour les QSAM/BDAM/ISAM... il me semble qu'il s'agit toujours de données stockées à plat mais avec quelques optimisations pour l'accès (genre on n'a pas à lire tout le fichier maintenant :P)
Enfin je ne suis pas expert... c'est un lointain souvenir de juillet 2012 avec mon formateur.
Mais en effet, "dataset" est utilisé assez abusivement.


Dans la section "middleware" on cherche à exprimer... euh.... bein... les logiciels qui permettent d'échanger et traiter des données venues "de l'extérieur"....
Après...
On ne trouve pas de nom ! :P
Et CFT c'est en effet payant, mais en France c'est largement utilisé (et à mon grand étonnement il semblerait que cela ne soit utilisé qu'en France et quasiment pas du tout ailleurs ! ^^')


Pour le dév (et beaucoup d'autres parties) j'ai repris les propositions des autres posteurs d'ici ! :P
C'est vrai que l'on pourrait parler de comment développer et ce qui va autour.
L'outil DFSORT (quelqu'un en pense quelque chose de mon artiiiiiicle ! xD) est en effet très TRES utile.
On devrait pouvoir placer les principaux langages, les IDE, les flowcharts, les scripts

VI) Le développement sous z/OS
1) Les principaux langages de programmation
1.a) Les Assembleurs (BAL, HLASM)
1.b) Le FORTRAN
1.c) Le COBOL
1.d) Le PL/1
1.e) Le C/C++ & USS
1.f) L'arrivée de Java.
2) Les IDE
2.a) Le développement classique : TSO et ISPF
2.b) "AGL" (il faudra me dire ce que c'est :P) Pacbase, etc...
2.c) Le développement "moderne" avec RDz
3) Utilisation des programmes
3.a) Conception de flowcharts JCL
3.b) Les langages de script : CLIST et REXX

Ca parait mieux ?

Citation:

---

Envoyé par Pico-----

... Donc déjà c'est gérer par DFSMS et DFHSM, et honnêtement, je n'ai jamais compris ce que faisais l'un où l'autre excatement (à part quelques services précis) ...

---

DFSMS = Data Facility Storage Management Subsystem
Pour moi, DFSMS, souvent abrégé en SMS, est à la fois un concept de gestion du stockage et une famille de produits dédiés à ce stockage.

DFSMShsm ( attention à la casse ! ) = Data Facility Storage Management Subsystem Hierarchical Storage Management ( ouf ! ).
Pour moi, DFSMShsm, parfois abrégé en hsm, est un des produits de SMS qui s'occupe des sauvegardes et de la hiérarchie du stockage (migration).

Ce qui est bien dans le z, c'est que chacun a sa définition, en fonction de son expérience. Pour simplifier assez "basiquement" ma pensée: TSO, CICS, IMS DC, les Batchs sont des contextes d'exécution de programmes. La différence entre TSO et les autres c'est son objectif: pour moi, ce n'est qu'une interface d'administration, avec ISPF un service de fenêtrage.

Quant aux "middlewares"/sous-systèmes, ils seraient plutôt destinés à traiter les données liées au métier de l'entreprise... Pour OPC/TWS, TSA, et autres consorts (y'en a plein....), ce ne sont que des outils (ou solutions) nécessaires (parfois) pour le bien-être du système et des équipes système.

Pour le sysplex, il y a une partie matériel (les Coupling Facility) mais le gros du morceau est quand même est niveau z/OS. Les hipersockets c'est matériel par contre (enfin z/VM est capable de créer des hipersockets virtuels mais on s'éloigne !). Pfiou y'a tellement de choses !!!!!

Ce WE j'ai beaucoup BEAUCOUP marché et autant roulé... donc pas très très dispo...

Bref, je reviens pour poster le sommaire actuel.
Proposition pour la section V :
V) "middlewares"/Outils Transactionnels & Echanges (ou "Communications" ? oui ? non ?)

Une section "Outils Systèmes Supplémentaires" a été ajoutée.
Evidemment.. je peux parler du produit sur lequel je travaille... les quelques autres qui m'entourent... mais pas de tout !
OPC/TWS est quand même un pilier, mais je ne peux pas le laisser seul non plus.
Si vous avez une meilleure idée OU des outils "très importants", je suis preneur !

I) Introduction
1) usages actuels (citer les ERPs dispos dessus) + raisons actuelles de l'utilisation des mainframes + OS actuellement disponibles sur les Mainframes IBM
2) positionnement des mainframes IBM dans les SI/infras (les schémas dans les slides IBM que l'on m'avait fourni il y a longtemps semblent bien, et celles de jeudi dernier avec zLinux et z/OS travaillant "ensemble" semblent encore mieux !)
3) organisations autour du mainframe (des études à la "prod'" : études/recette/qualification (préprod')/production)
4) quelques chiffres sur le mainframe (on pourrait extraire les chiffres du livre blanc IDC présenté à l'université du mainframe 2014 ?)

II) Historique
1) S360 => EBCDIC & cartes perforées, JCL & JES, FORTRAN & COBOL & PL/I & BAL
2) S370 & MVS => mémoire virtuelle, partage de la machine physique (PR/SM, LPAR, Sysplex) "le 1er Cloud", ouverture sur le réseau
3) S390 => insertion d'USS/OMVS
4) zSeries/System z/z Architecture => zLinux, zBX et liaison AIX/Windows encore plus proches, ...

III) Matériel
1) Baies, CPU et mémoire (les 4 baies)
2) Connectique, I/O, et disques (CU, channels & CHPID, 3390 émulés, SAN)
3) Réseau (SNA, TCP/IP) & HiperSocket & Terminaux (3270)
4) Sysplex/Coupling Facility : Mutualisation & Redondance
5) HMC et IPL
6) zBX & ajout d'autres OS en connectique ultra rapide

IV) OS & Logiciels liés
1) z/OS
1.a) JES (JES2 & JES3) et le JCL
1.b) TSO & ISPF
1.c) OMVS/USS
1.d) Datasets
1.e) VSAM
1.f) Sysplex
1.g) RACF (héhé... personne ne l'avait précisé jusqu'à maintenant :p)
2) zLinux
3) z/VM
4) z/VSE & z/TPF (en diagonale)

V) "middlewares"/Outils Transactionnels & Echanges (ou "Communications" ? oui ? non ?)
1) SGBD
1.a) DB2
1.b) IMS DB
2) Transaction Processing/Moniteurs Transactionnels
2.a) CICS
2.b) IMS DC
3) WAS
4) MQ
5) CFT
6) autres...

VI) Outils Systèmes Supplémentaires
1) OPC/TWS
2) Suite Tivoli

VII) Le développement sous z/OS
1) Les principaux langages de programmation
1.a) Les Assembleurs (BAL, HLASM)
1.b) Le FORTRAN
1.c) Le COBOL
1.d) Le PL/1
1.e) Le C/C++ & USS
1.f) L'arrivée de Java.
2) Les IDE
2.a) Le développement classique : TSO et ISPF
2.b) "AGL" (il faudra me dire ce que c'est :p) Pacbase, etc...
2.c) Le développement "moderne" avec RDz
3) Utilisation des programmes
3.a) Conception de flowcharts JCL
3.b) Les langages de script : CLIST et REXX

On part là dessus comme base, alors ?

Je peux créer le docx avec le sommaire et je commence à rédiger ?

EDIT : voici le docx de base ! :)
N'hésitez pas à remplir et améliorer !

Bonjour à tous

L'objectif de ce document est vaste et je comprend les difficultés rencontrées pour établir un plan.
Celui proposé par Metalman me convient. Il pourra être amendé si nécessaire.

Je suis à la retraite et je dispose de temps pour rédiger certains articles.

J'aime la citation de M.Dlb : "Il y a tellement de choses à dire sur le sujet... Il faut nécessairement parler du passé, puisque c'est notre ADN, mais il faut aussi parler du futur et les futures utilisations du z : Cloud, Analytique, Mobilité, Sécurité....... ". Je suis devenu IS en 1973 (en MFT) et quarante ans après, j'ai l'impression d'avoir du sang "blue" dans les veines.

Je n'ai jamais douté des capacités d'IBM de se sortir des difficultés rencontrées (Merci à Lou Gestner pour avoir redressé IBM) car c'est ce qui m'a permis de vivre (grassement) ma passion.

J'ai accumulé beaucoup de documents durant ces 40 années d'IS et de consultant et je peux en faire profiter la communauté, surtout dans le domaine des médias (Disques, cassette, DON) dont je suis spécialiste.

Metalman peut-il m'indiquer si ma proposition l'intéresse ?

Moi je suis preneur pour toute aide !

Si vous avez lu l'intégralité du topic, vous verrez qu'il y a certaines parties où je n'ai strictement aucune connaissance... donc votre aide est la bienvenue.
Vous faire rédiger l'ensemble de l'article serait peut être... trop ! :P
Mais certaines sections précises seraient très utiles :

CICS, IMS (en SGBD et en MT), DFSMS (je l'ai oublié dans le sommaire...), PL/1, FORTRAN, Les Sysplex, RACF, les "AGL", CLIST, z/VM, z/VSE & z/TPF

Et dans l'historique aussi...
Enfin après notez ce que vous voulez, et postez ici ! :)
Je ferai le merge de tous les écrits et/ou de mes parties... et on décidera ce qui sera à refaire/garder/supprimer !


Merci de votre aide !


EDIT : j'ai lu trop vite.... n'hésitez pas à rédiger la partie disque/bandes physique & la partie logicielle associée !

Je commence par DFSMS que je connais bien.

Je pars en vacances la semaine prochaine (Ah que la vie de retraité est dure) mais j'attaquerai la semaine suivante.

Je pense que l'article me prendra bien une semaine d'écriture.

Oulalalala !
On est parti pour faire un redbook non-officiel là ! xD

Vous n'allez remplir que la partie DFSMS, non ? Oui ?

Ne détaillez pas trop trop non plus....
Enfin... en fait.... Si !
Allez-y, écrivez l'article !
Si vous faites 1 semaine de rédac' sur DFSMS, on pourra s'arranger pour vous publier sur un article à part entière à votre nom, je mettrai au gabarit, et je ferai un résumé pour l'article global mainframe IBM en vous citant.

Comme personne d'autre ne semble pouvoir expliquer DFSMS "comme il le faut" (excepté la doc qui détaille trop), faites donc ! :)

Hello, je peux tenter de m'occuper d'IMS et peut-être z/VM... Mais en ce moment, je n'ai que **très** peu de temps libre !!! Je vais voir ce que je peux faire (sans rien promettre...).

Pour cadencer la chose, il serait tentant de mettre une deadline, sinon ça n'en finira jamais. Metalman, je te laisse choisir une date qui te parait appropriée.

Bon, mes chers élèves, vous me rendrez vos jolies rédactions pour lundi matin 8h00 ! :D

Nan plus sérieusement, ça risque d'être long à faire.
Je propose plusieurs deadlines pour que l'on puisse retravailler le tout et/ou remplir les parties manquantes au fur et à mesure....
La remarque que l'on n'ose peut être pas mettre : en effet la rédaction de l'article n'est pas notre occupation principale ! (pour les actifs tout du moins).

Je vais faire mon chef de projet qui teste des méthodes AGILE :
Phase 1 :
On fait des runs de 3 semaines~1 mois et on se présente ce que l'on a fait ! (si vous finissez plus tôt, n'hésitez pas à poster !)

Phase 2 :
- soit on inclut dans la version finale les chapitres complets fait par 1 personne.
- soit on merge les travaux de plusieurs personnes en se mettant d'accord ici-même.
Donc cette phase prendra 1 à 2 semaines environ.

Dans tous les cas, si les rédactions de certains sont trop épaisses (n'ayez pas peur de le faire !... vu que trop peu de personnes savent exactement ce que fait chaque produit), on n'hésitera pas à les sortir pour en faire un article à part entière signé de votre nom.
M.Dlb ou moi-même gabarierons vos productions (si tu en as envie/le temps ! Personnellement, je commence à savoir le faire : gabarier + où poster les demandes d'articles/corrections/publications), et on se mettra tous d'accord pour condenser le contenu pour l'article global.

Phase 3 (plutôt jalon) :
Publication du docx mis à jour ici-même, avec les sections restantes à remplir (je le ferai).

Puis on repart en Phase 1 tant que l'on n'a pas un article complet qui nous satisfait.

--

Nb de RUNs effectués : 0

Phase 1	Rédaction des Chapitres	En Cours	A RENDRE POUR LE 1er JUIN 2014
Phase 2	Merge des Chapitres || Gabarisation chapitres/articles	A venir	08 ou 15 juin 2014
Phase 3	Mise en ligne du nouveau DOCX	A venir	16 juin 2014

--

EDIT : M.Dlb, si tu peux éditer mon tout premier post et y mettre devant mon texte le pitit tableau... ça serait cool ! :D

Soit rassuré Metalman, ce ne sera pas un redbook mais ce sera consistant.

Ma prose sera parsemé de remarques suite à mon expérience dans ce domaine.

J'insisterai sur la nécessité de créer des ACS routines les plus simple possible et d'utiliser ISMF pour les jeux de test avant mise en production.

C'est ce qui manque le plus à la documentation IBM.