Discussion :

[Fred Ratel]

Bonjour,

En VSAM, quelqu'un pourrait-il me donner l'utilité du PATH à créer entre l'index secondaire et le cluster principal ?

En cas d'utilisation dans un programme batch. Que doit-on déclarer en carte DD ?

Et en CICS, l'index secondaire et le path doivent-il être déclarés quelque part (FTC ?)

Merci d'avance
Fred

[Homer-ac]

Tout d'abord le vocabulaire.
En VSAM le CLUSTER est le nom du fichier décrit au catalogue. Il est constitué d'une composante DATA pour tous les types de VSAM (KSDS, ESDS, RRDS et LDS)
Spécifiquement pour les KSDS, également d'une composante INDEX. Sauf à l'avoir spécifié différemment au DEFINE IDCAMS, correspondent au nom du cluster suffixé par DATA et INDEX et constituent les fichiers physiques inscrits en VTOC.
Au sens JCL, c'est le nom du CLUSTER sur lequel on accède que l'on donne. C'est la méthodes d'accès qui se charge du reste. C'est pourquoi un VSAM est depuis toujours catalogué.

Détaillons d'abord la gestion pour un VSAM KSDS :
Accès par clé mais celle-ci doit toujours être unique !
Quand on a besoin d'accéder sur des clés non uniques, on crée un index secondaire. C'est aussi un KSDS (donc clé unique) dont la composante DATA contient les clés du cluster de base.
Comme n'importe quel VSAM on peut lire directement l'AIX mais ça ne donnerait que la liste des clés du cluster de base, cette fois dans l'ordre des clés secondaires
La solution : Définir toujours par IDAMS un PATH qui n'a pas d'existance physique. Ce n'est rien d'autre que la relation cataloguée entre un nom d'AIX et un autre KSDS, normalement le cluster de base.
La méthode d'accès pourra dès lors accéder aux données du cluster de bases depuis les indexes secondaires en DATA de L'AIX.
Au sens JCL on donne en DD le DDNAME du CLUSTER que l'on veut accéder. Quand on utilise un PATH on donne en général les 3 mais c'est plutôt une logique administrative. logiquement, donner simplement le nom du Cluster Path devrait marcher.
Se rappeler que c'est ça le rôle primaire d'une DD JCL. Indirection entre un DDNAME spécifé dans un programme et un nom de fichier catalogué qui permet de pointer sur le fichier physique via la VTOC (ou DSN en VTOC quand on spécifiait encore le VOLSER pour un QSAM, usage totalement obsolète avec SMS)
L'accès au fichier physique ne concerne que la méthode d'accès, totalement différente en QSAM et en VSAM.

Bon c'est un résumé,j 'espère être clair mais VSAM est tellement à part !
On pourrait à la limite accéder directement sur les entrées VTOC d'un VSAM mais ces entrées fichiers seraient inexploitables les enregistrements VSAM sont particuliers et dotés notemment de CIDF er RDF pour décrire longueurs des données (un enregistrement VSAM est toujous variable) et occupation des données (on donne un FREESPACE par CI et CA au DEFINE d'un KSDS)
Un dernier point, On continue de parler de DEFINE IDCAMS, mais ça peut aussi à présent se faire directement via une allocation JCL.
Enfin un moyen simple de 'visualiser' les relations d'un Upgrade Set VSAM est de faire un LISTCAT BASE, AIX et PATH et un REPRO COUNT(3 ou 4) de chacune de ces composantes.

[Fred Ratel]

Un grand merci pour ces éclaircissements.