Discussion :

[Luc Orient]

Moi je veux bien prendre le sujet COBOL ...

Sachant que pour moi, ce ne sera pas un chapitre sur le COBOL en général, mais bien sur le COBOL dans le contexte du z ... Il existe par ailleurs un forum COBOL ...

Sinon, concernant IMS, ça ne me semble pas une bonne idée de séparer la partie SGBD (IMS DB) de la partie Moniteur Transactionnel (IMS TM) ... IMS est à la fois un SGBD et un Moniteur TP ... Bien sûr, les deux fonctions peuvent être présentées séparément, et c'est souvent le cas, mais il existe aussi un ensemble de services communs à ces deux rôles, et de plus, la philosophie du produit, même si elle est datée (mais c'est un autre débat ...) reste quand même assez cohérente ...

[Metalman]

J'ai séparé... pour cette raison justement : que c'est présenté comme séparé en 2 fonctions !
Mais si quelqu'un veut faire IMS en un bloc, pas de problème... on pourra voir plus tard comment présenter les 2 parties dans ce plan !

Et pour le COBOL : pas de problème ! allez-y !

Je vais essayer de faire toute l'intro ce WE, et pourquoi pas un peu de JES2 & JCL.

[BernardBZH]

Bonjour,

Alors ça c'est une belle idée !! Après quelques temps d'absence je la découvre et suis très enthousiasmé !!

Dans la mesure de mes modestes moyens, je tâcherais d'apporter ma pierre à ce avec quoi je travaille depuis plus de 20 ans (COBOL, JCL, IMS/DB, REXX et ISPF).

En V.1)SGBD pourrait-on faire une petite place à IDMS (et à son alter-ego IDS2) (ou en V.6)Autres ... étant donné la rareté des sites qui utilisent encore ces SGBD en France) ?

Et tant que j'y pense, dans la partie VII consacrée au développement, on pourrait parler du cycle de vie avec notamment SCLM qui est fourni en standard par IBM.

[xfanx]

Bonjour,

c est une très belle idée, personnellement je veux bien prendre IMS TM, CICS et WMQ.

pour revenir à la discussion précédente, IMS est à la fois un moniteur transactionnel ET un sgbd certes, mais les 2 fonctions restent très distinctes personnellement j'ai été IS IMS quelques années sur 2 sites qui n'avaient que IMS TM et DB2 en sgbd, le DL1 vu le peu d'activité avait été remplacé par un très bon produit, DL2.

bref, je n'ai pas excessivement de disponibilité, mais je veux bien traiter ces sujets s. A vrai dire, j'avoue j'aimerais bien participer a beaucoup plus , ce type d’initiative me fait plus que plaisir, il reste encore des passionnés du Z!

une petite suggestion cela dit, serait il possible d'avoir quelque part un index avec le qui fait quoi afin de se synchroniser?

[Luc Orient]

...
En V.1)SGBD pourrait-on faire une petite place à IDMS (et à son alter-ego IDS2) ....

Attention, autant IDMS est bien un produit fonctionnant sur le z ( certes non IBM, mais ce n'est pas une raison pour l'exclure, j'en conviens ... ), autant IDS2 est un produit, à ma connaissance, uniquement issu du monde des moyens et grands systèmes Bull, à savoir GCOS 7 et GCOS 8 ...

Par contre, il est vrai de dire que le modèle théorique sous jacent à ces deux SGBD est commun, à savoir le modèle réseau ...

[egshuml]

Bonjour à tous

Vous trouverez ci-joint le document sur DFSMS :

DFSMS 00.docx

Je commence un document sur les disques et cassettes

[Metalman]

Le document est d'une très bonne qualité ! (il reste 2-3 fautes, mais ce n'est pas le plus grave pour le moment)

Cependant, il est très technique/fortement lié à l'utilisation du produit.
Personnellement, je serais plutôt pour le publier sous la forme d'un article à part entière.
Ainsi, dans l'article général sur tout le z, on récupère seulement une partie de ce document (on retire les données techniques liées aux panels ISPF par exemple).

Cela vous dérange egshuml ?
Je peux m'occuper de le mettre au gabarit pour developper.com, et vous serez présenté comme l'auteur du document.




Pour ma partie d'introduction, j'ai pris pas mal de retard... et je me suis réinscrit au MOOC gros système du MARIST IDCP.
J'étais entré en contact avec l'un des organisateurs du programme l'an dernier, et il m'a aussi donné un peu de documentation pour cet article récemment.
Bref, ça avance à petits pas, mais ça avance !

[egshuml]

Bonjour Metalman

J'ai pensé que ce document permettrai à un néophyte z/OS de comprendre sur le tas ce que signifiait DFSMS en production, mais j'aurai du ne pas oublier le contexte.

Je suis d'accord pour le publier hors du contexte "Qu'est-ce que le mainframe IBM aujourd'hui" et d'en faire un abstract pour ce contexte.

Je trouve intéressant de faire un document pour néophyte dont on extraira un texte pour le contexte de la discussion.

Qu'en pense-tu ?

[Metalman]

Si vous voulez "aussi" faire le document pour néophytes, allez-y !
Mais n'hésitez pas à continuer sur les disques et les bandes comme pour DFSMS.


Je vais vous contacter par MP pour les "formalités" de publication.

[Metalman]

Je double post, mais c'est surtout pour "bumper", et poser une grande question : quelqu'un peut-il valider le contenu technique du document fourni par egshuml ?
Ce n'est pas que je doute du contenu, mais c'est demandé par les responsables de rédaction ! ^^'

Pour le très gros article, je "pense" que l'on se corrigera/validera tous en retaillant les bouts des autres...
Mais comme celui-là passera en article "seul", il me faudrait quelques "oui c'est correct !"

Merci à tous, et à egshuml pour avoir rédigé ça !

[egshuml]

Tout à fait d'accord pour la validation.

[Metalman]

J'ai relu le texte, et il y a quelques petites... choses que je ne comprends pas :

Page 2-3 :

• Les DATA CLASS pour les paramètres d’allocation d’un fichier
• Les MANAGEMENT CLASS pour la gestion de ces fichiers

On pourrait faire comme pour les SC et SG :

• Les MANAGEMENT CLASS pour la gestion des DATA CLASS

Ou encore :

• Les MANAGEMENT CLASS pour la gestion de plusieurs fichiers (les DATA CLASS)

Page 4 :

Afin de vous prémunir des conséquences d’un STORAGE GROUP, je vous conseille la création d’un STORAGE GROUP de type OVERFLOW qui permettra d’allouer des fichiers lorsque le STORAGE GROUP principal sera plein (pool de débordement). Dans ce cas, vous indiquez le nom de ce STORAGE GROUP dans le paramètre Extend SG Name du groupe principal.

Il n'y a pas un mot manquant au niveau du "Afin de vous prémunir des conséquences d’un STORAGE GROUP," ?
"Afin de vous prémunir des conséquences d’un STORAGE GROUP plein," ?
Ainsi on aurait (avec une autre modif) :

Afin de vous prémunir des conséquences d’un STORAGE GROUP plein, je vous conseille la création d’un STORAGE GROUP de type OVERFLOW qui permettra d’allouer les fichiers qui dépasseront du STORAGE GROUP principal (pool de débordement). Dans ce cas, vous indiquez le nom de ce STORAGE GROUP dans le paramètre Extend SG Name du groupe principal.

Page 4 :

Il ne peut y avoir qu’un seul pool de débordement par STORAGE GROUP. Par contre, un pool de débordement peut être commun à plusieurs STORAGE GROUP. Plusieurs pools de débordement peuvent être déclarés dans les STORAGE GROUP.

1 pool de débordement par SG... ok.
1 pool de débordement peut être commun à plusieurs SG... ok.
Mais... "plusieurs pools de débordement peuvent être déclarés dans les SG" ?... associés aux SG (contradiction avec la 1ère assertion) ? Ou juste déclarés et possiblement non utilisés ?

Page 6 :

Seule l’ACS routine concernant peut modifier la classe de gestion correspondante (par exemple l’ACS routine de traitement de la MANAGEMENT CLASSS ne peut modifier que la variable &MGMTCLAS).

"concernée" ? Ou il manque un nom ?

Page 9 :

Si le code retour est 0 cette routine on peut la valider.

Je propose :
"Si le code retour de cette routine est 0, alors on peut la valider."

Page 10 :

Celui-ci s’intégrera dans DFSMS, mais comment l’architecture et l’accès au « Cloud » seront résolu afin de centraliser sa gestion par DFSMS car les concurrents sont déjà à l’œuvre ?

Peut être :
"Celui-ci s’intégrera dans DFSMS, mais comment l’architecture et l’accès au « Cloud » seront résolu afin de centraliser sa gestion par DFSMS ? Car les concurrents sont déjà à l’œuvre..."


Ce n'est pas une grosse critique envers votre production... normalement cette phase se fait entre l'auteur et les correcteurs (mais je la fais avec vous pour éviter trop d'aller-retours plus tard ! )
Merci encore pour ce texte !

[egshuml]

Bonjour Metalman,

Malgré ma relecture, il reste effectivement des choses pas claire ou erronées.

Je revoie le contenu et je replacerai la nouvelle version dans la discussion.

[egshuml]

Bonjour Metalman

Avant de vous livrer la version améliorée du texte, je souhaite des éclaircissements concernant le début du message :

Page 2-3 :
• Les DATA CLASS pour les paramètres d’allocation d’un fichier
• Les MANAGEMENT CLASS pour la gestion de ces fichiers
On pourrait faire comme pour les SC et SG :
• Les MANAGEMENT CLASS pour la gestion des DATA CLASS
Ou encore :
• Les MANAGEMENT CLASS pour la gestion de plusieurs fichiers (les DATA CLASS)

Je ne comprend pas ce que vous voulez dire.

Cordialement,

[Metalman]

Oui... j'ai eu du mal à améliorer la phrase en effet... je voulais que ça saute aux yeux l'explication, mais en fait je n'ai pas réussi !

Mais si j'ai bien compris lors de ma lecture :
Les DATA CLASS gèrent des fichiers (donc elles permettent d'abstraire les fichiers via des classes).
Les MANAGEMENT CLASS gèrent "ces fichiers" (donc elles permettent de gérer les DATA CLASS) ?

Cela est mieux dit ?

[Luc Orient]

Cela est mieux dit ?

Désolé, mais non ... pour moi ces deux concepts s'appliquent aux fichiers, donc on peut dire qu'il les "gèrent" d'une certaine façon, même si le mot n'est peut être pas idéal, je trouve, mais en tout cas ils ne gèrent pas la même chose, donc il n'y a pas de hiérarchie entre les deux concepts ...

[Luc Orient]

Trouvé dans un Redbook :

Data class

A list of allocation attributes for data sets (for example, logical record
length and record format). The data class simplifies and standardizes
data set creation.

Management class

A list of backup, retention, and migration attributes for data sets.

[Metalman]

Merci ! En effet j'ai cru que l'un gérait l'autre...

Donc pour mieux tourner la phrase + me corriger, je propose :

- Les DATA CLASS servent à gérer les attributs d'allocation des fichiers (RECFM, LRECL, ...)
- Les MANAGEMENT CLASS s'occupent des attributs autour des fichiers : sauvegarde, rétention et migration


Bon, c'est quasiment de la traduction... je l'admets
Ca serait bien si l'on pouvait citer en source le redbook que vous avez utilisé !
z/OS V1R13.0 DFSMShsm Managing Your Own Data (SC35-0420-10)... mais je ne trouve plus de PDF associé

[Luc Orient]

Merci ! En effet j'ai cru que l'un gérait l'autre...

Donc pour mieux tourner la phrase + me corriger, je propose :

- Les DATA CLASS servent à gérer les attributs d'allocation des fichiers (RECFM, LRECL, ...)
- Les MANAGEMENT CLASS s'occupent des attributs autour des fichiers : sauvegarde, rétention et migration

On n'y est presque ... mais n'oublions pas un troisième larron ( Storage class ) :

Storage class
A list of storage performance and availability required by applications.
The storage class contains availability and performance attributes,
such as response time and cache requirements, for data sets

Ca serait bien si l'on pouvait citer en source le redbook que vous avez utilisé !

C'est " IBM z/OS DFSMShsm Primer " mais il ne s'intéresse qu'à la partie hsm de SMS.

z/OS V1R13.0 DFSMShsm Managing Your Own Data (SC35-0420-10)... mais je ne trouve plus de PDF associé

Tout est là :
http://www.redbooks.ibm.com/

[egshuml]

Bonjour à tous,

Les remarques précédentes mettent fin à la discussion sur DFSMS.

Je vous joint la dernière version corrigée du document sur DFSMS

cordialement

egshuml