Discussion :

[Metalman]

Je confirme, le RedBook est introuvable ! ^^'
Ca reste uniquement dans la documentation V1R13....

Enfin c'est pas grave, on indiquera le lien des redbooks avec tous les prochains articles du coup...



Et en fait ma correction est nulle... le texte de base est correct...
Mais je ne comprends pas pourquoi je m'étais perdu du coup !
On pourrait préciser entre parenthèses "LRECL, RECFM, ..." pour les DATA CLASS ?

Et on pourrait rajouter l'histoire du cache pour les STORAGE CLASS :
Les STORAGE CLASS pour affecter le meilleur support physique pour ce fichier, en fonction des besoins de disponibilité et de performance exprimés (cache nécessaire, temps de réponse, ...)

Ca rallonge pas mal, je l'admets, mais ça ajoute des détails intéressants !



EDIT : egshuml a posté en même temps que moi... donc les remarques ne sont probablement pas à prendre en compte !

EDIT2 : egshuml, si la modification pour la STORAGE CLASS vous parait utile, dites-le moi, et je la rajoute dans le fichier que je vais envoyer aux correcteurs !
Mais sinon : merci pour tout ce travail ! C'est très gentil de votre part de partager tout cela ! (et merci à Luc Orient de nous apporter des précisions !)

[egshuml]

Bonjour Metalman,

Il n'est possible de forcer un LRECL ou un RECFM dans les DATA CLASS que s'ils ne sont pas indiqués dans le JCL lors de l'allocation. Il faut laisser la responsabilité de ces paramètres au créateur du fichier.

Les paramètres CACHE ou temps de réponse de la STORAGE CLASS n'étaient valables que pour des 3390 attachés à une 3990 avec cache. Aujourd'hui, la banalisation des unités de contrôle avec des tailles de cache importantes (plusieurs dizaines Gigabytes) et des disques en grappe rendent ces paramètres obsolètes.

[Metalman]

Pour les LRECL et RECFM... c'est vrai qu'en réfléchissant... c'est... probablement pas une bonne idée de forcer, en effet... donc ça n'a sûrement pas été fait !

Pour les STORAGE CLASS : ok !

Bah ce soir je modifie le fichier, et je l'envoie vers la suite de sa vie !

Je vais aussi envoyer ce que j'ai réalisé jusqu'à maintenant concernant l'article global.

[Metalman]

Bonsoir,

J'ai envoyé l'article de egshuml en relecture orthographique et je l'ai mis au gabarit !

Sinon, comme promis pour ma "partie" d'introduction au document principal... (j'ai honte de n'avoir fait QUE cela pour le moment...)
Voici le résultat !
J'attends vos critiques !

[bernard59139]

Bonjour

z/OS V1R13.0 DFSMShsm Managing Your Own Data

@+

[Metalman]

Je suppose que mon introduction vous plait à tous !

Si jamais ceux qui se sont proposés pour rédiger certaines parties pouvaient nous montrer leurs textes, ce serait fabuleux ! (et surtout je pourrais commencer à les ajouter au texte principal)

Merci encore de votre participation.

[egshuml]

Bonjour Metalman et bonjour à tous,

J'ai pris beaucoup retard lors de la rédaction de ce document et je vous prie de m'en excuser.

Disques et cassettes.docx

Suite à une remarque de Bernard59139, je souhaite faire une modification dans l'article DFSMS.
Comment dois-je faire ?

Cordialement

[Metalman]

Ecrivez-moi dans un Word le chapitre complet où la modif doit être faite, et indiquez la/les lignes exactes ajoutées/supprimées dedans !


Je vais lire le dernier document aussi !

[egshuml]

Bonjour Metalman

Dans le document, supprimer le paragraphe V-A-4. Les STORAGE GROUP et le remplacer par le paragraphe ci-joint.

correction.docx

Merci

[Metalman]

Je fais ça ce soir !
La mise à jour de la publication mettra un petit peu de temps je suppose, mais on va s'arranger !

[Metalman]

La correction a été uploadée !


Quelques questions concernant votre dernier écrit :

Page 3, dans le tableau :

3380 1,26 Gb 12 3 Mb/s 3380K : 1,89 Mb

Le commentaire dit "3380K : 1,89 Mb", mais... ça veut dire quoi ? Qu'il existe un modèle K avec 1,89 Mb ? (êtes-vous sûr que ce sont des Mb dans ce cas, et non des Gb ?)
Les capacités sont bien en Gigabits et non en GigaBytes/GigaOctets ?


Page 6, à propos de l'écriture en NVS, section 2 :

2. Si non, l’interface avec les données libère un espace dans la NVS avant de la stocker. C’est un « WRITE MISS » qui est également comptabilisé dans les statistiques RMF. Elle indique alors à l’interface avec les canaux que la donnée est stockée dans la baie. L’interface avec les unités de stockage se charge d’écrire la donnée sur le disque qui lui est attribué comme précédemment.

Autant le 1 réussit l'écriture, et tout me semble correct... autant le 2.... ce n'est pas contradictoire avec le 1 ?
Car dans les 2 cas de l'espace est utilisé, et une écriture est faite !


Page 6, le types d'unités :

2. Les disques SATA (Serial ATA) ou SAS (Serial Attached SCISI) sont également

SCSI il me semble ! :o


Page 7, PAV :

C’est le poids du passé car ce traitement existe depuis les premiers disques des Systems 360.
La modification de MVS était probablement très importante.
Comme à cette époque certains utilisateurs avaient encore des 3380 ou 3390 accrochés à des unités de contrôle 3990, la modification de MVS n’était pas envisageable.
La solution d’IBM pour contourner ce problème consiste à créer un ou plusieurs « ALIAS » pour un disque particulièrement chargé en E/S.
C’est WLM qui effectue l’opération en attribuant un ALIAS à ce disque dont l’adresse de l’UCB est différente de ce dernier dont l’adresse est appelé BASE.

Je propose de réécrire :

La modification de MVS était probablement très importante.

La modification de MVS aurait probablement dû être très importante.

La solution d’IBM pour contourner ce problème consiste à créer un ou plusieurs « ALIAS » pour un disque particulièrement chargé en E/S.
C’est WLM qui effectue l’opération en attribuant un ALIAS à ce disque dont l’adresse de l’UCB est différente de ce dernier dont l’adresse est appelé BASE.

La 2e phrase est très lourde je trouve.... je n'arrive moi-même pas à tout comprendre... ma proposition de réécriture :
Chaque disque possède une adresse appelée BASE liée à un UCB. C’est WLM qui effectuera l’opération en attribuant un ALIAS à chaque disque passant par d'autres UCB que celui de l'adresse BASE.


Page 7, HyperPAV :

Une commande dans le membre IECIOSxx permet de l’activer à l’IPL et c’est tout.

Une simple commande dans le membre IECIOSxx permet de l’activer lors de l’IPL.


EDIT : j'ai cliqué trop vite... je posterai d'autres propositions dans la journée !

EDIT2 : la suite & fin de propositions :

Page 8, zHPF :

Sans entrer dans les détails, le nouveau protocole diminue les échanges entre le canal et l’unité de contrôle et permet donc d’augmenter le nombre d’E/S de plus de 70 pour un canal FICON occupé à 100%.

augmenter le nombre d’E/S de plus de 70% pour un canal FICON ?

(l'anatomie d'une I/O... c'est fabuleux ce que vous avez réalisé ! maintenant je comprends mieux les SAP, les CCW et tout ce qui vient après ! )



Page 14, 2.4 Les cassettes virtuelles :

Ce sont les mêmes disques que pour les baies (Disques Fiber Channel ou SATA mais pas de SDD) en RAID 5 ou 6.

Mais pas de SSD ?

[Metalman]

Mes propositions ne conviennent pas ? ^^'
Pas de réaction ?

[egshuml]

Bonjour Metalman.

Je viens de rentrer de voyage et je n'ai pas eu le temps de lire le message précédent.

Je regarderai ce soir.

Cordialement,

[egshuml]

Bonsoir Metalman

Pour le 3380K, il s'agit bien de Gb. Une erreur qui m'a échappé à la relecture.

Pour la page 6, il y a une différence avec le 1 car dans ce cas, c'est un "Write Miss", La baie relâche le canal le temps de libérer la place et d'écrire la donnée. Lors de mes expertises, je n'ai jamais vu de "Write Miss".

Page 6 toujours, je maintient SATA et SAS. L'interface SCISI a bien évolué.

Page 7 : L'ensemble du texte est trop lourd. Je propose :

"C’est le poids du passé car ce traitement existe depuis les premiers disques des Systems 360.

Comme à cette époque certains utilisateurs avaient encore des 3380 ou 3390 accrochés à des unités de contrôle 3990, la modification de MVS n’était pas envisageable.

La solution d’IBM pour contourner ce problème consiste à créer un ou plusieurs « ALIAS » pour un disque particulièrement chargé en E/S.

Chaque disque possède une adresse appelée BASE liée à un UCB. Si le disque est « busy », WLM effectuera l’opération en attribuant un ALIAS à chaque disque passant par d'autres UCB que celui de l'adresse BASE."

Page 7, HyperPAV : Il fallait attirer l'attention de l'utilisateur sur la simplicité d'activation de l'HyperPAV. C'est pour cela que j'ai ajouté le "et c'est tout". Il peut être retiré.

Page 8 : zHPF : Les tests effectués par IBM montrent qu'avec zHPF, le débit en lecture des canaux FICON sur des bases DB2 permet d'augmenter le débit des I/O de plus de 70%.

Page 14, 2.4 Les cassettes virtuelles : Les disques SSD sont utilisés pour la performance en lecture des baies de disques. Pour les sauvegardes ou le ML2 de DFSMShsm, cet aspect performance est secondaire. Le coût des disques SSD rendrait les unités de cassettes virtuelles très chère.

Cordialement.

[Metalman]

Pour le SCISI, c'est que ce nom est incorrect, il s'agit de SCSI il me semble.
Je l'ai transformé en "SCSI", sauf si c'est vraiment moi qui ne connait pas le "SCISI" (je veux bien un lien vers de la doc pour voir de quoi il s'agit, du coup).

J'ai fait les modifs, cf la pièce jointe.
Si le docx vous convient, je me lance dans la mise au gabarit developpez.net, puis on corrige et publie !

[egshuml]

Bonjour Metalman

C'est évidemment SCSI. Il est plus facile de dire SCISI que S C S I dans une conversation. Merci pour la remarque.

Je lirai la texte dans la journée.

Cordialement

[Metalman]

Haha, pendant des années je disais S C S I (èssé èssi), jusqu'à ce qu'un de mes enseignant dise SCISI (skeuzi)... donc rassurez-vous, tout est possible dans ce monde !

[egshuml]

Bonjour Metalman

J'ai lu le document et je l'approuve. Seule ombre au tableau, le dessin d'une baie de disque est déstructuré et il y a une faute d'orthographe dans le préambule (epression au lieu de expression).

Je joint une nouvelle mouture si nécessaire.

Disques et cassettes_metalman_corrigé.docx

Cordialement.

[Metalman]

En effet, en enregistrant avec mon Word cela a tout cassé...

Je vais faire des screenshots des images au pire, pour les mettre en dur dans le document final !

Je m'en occupe au plus tôt, du coup !

Merci pour votre travail !

[Metalman]

Il restait quelques erreurs de Kb/Mb/Gb dans un des tableaux concernant les débits.
C'est corrigé (je suis allé vérifier dans la doc).


J'envoie l'article en correction orthographique comme prévu !