tracer les load lmodules actifs [Résolu]

[xfanx]

Bonjour,

Après quelques fusions/acquisitions nous nous retrouvons en production avec un PDS des load modules de la société de plus de 28000 load dont je suis bien sur que la moitié au minimum n'est plus utilisé. Le problème est de trouver lesquels afin d'opérer un gros ménage.
Aussi, connaitriez vous un utilitaire ou un produit capable de donner une liste des load modules actifs sur une Lpar?
l'idée serait de faire "tourner" cet utilitaire/outil quelques mois afin de constituer une liste de tous les loads modules ayant ete loadés au moins 1 fois sur la lpar de production.

[Homer-ac]

vaste problème.
L'idéal serait de trapper les SVC de Fetch, j'ai déjà vu ça en DOS VSE. Jamais un MVS, c'est une solution qui serait pour le moins risquée.
Sinon des outils sortent un référentiel croisé en partant de ce qui tourne. Jobs Batch, RDO CICS, JCLLIB, LOADLIB et SRCLIB en passant par SMF. C'est de l'artillerie lourde parce que ça doit être exhaustif. Je pense à un en particulier, mais je ne veux pas faire de pub sur un forum pour une société de service. En message privé éventuellement. On parle de retrait de production. Pour avoir donné, je ne te cache pas que c'est une mise en oeuvre plutôt lourde qui se passe sur plusieurs mois. Implantation, analyse, vérification, on affine jusqu'aux retraits final par lots pour retour arrière en cas de pépin. C'est surtout lourd par ce que l'on ne vise pas le retrait que des load, mais tout ce qui gravite autour, souces, JCL etc. J'ai cherché longtemps en outil de trap des SVC de FETCH en MVS (approuvé celà s'entend). Si quelqu'un a ceci, j'avoue qu'il m'intéresserai également d'installer et tester ça sur LPAR dédiée (une SVC user, personne ne prendrait le risque directement en prod).

[xfanx]

merci Homer-ac de ta réponse,

ce qui m'intéresse surtout dans un premier temps c'est le retrait des loads modules. à partir de cette liste (si nous arrivons à la construire), nous avons les outils nécessaires pour faire le ménage dans notre AGl, jcl, source et autres..

PDSMAN offre cette fonction de trace des load modules fetchés mais après l'avoir testé sur uen lpar de test le système était tellement lent qu'il n'est pas imaginable de le mettre sur les Lpar de production.
Mais si tu as un autre outil en tete, je suis preneuse par MP

par contre, je vois que tu indiques la possibilité de records SMF sur les loadlib? je t'avoue qu'après avoir cherché, les seuls références étaient sur les PDS eux même mais je n'ai rien trouvé sur les membres de PDS (load). Si tu as des informations à ce sujet notamment le no de record SMF, je suis aussi preneuse.

en tout cas, si nous trouvons une solution, je ne manquerai pas de la poster ici.

[Homer-ac]

Deux liens intéressants sur les SMF type 30 :
Pour le détail (JOB et exec PGM, ça donne juste le bout de la ficelle pour remonter aux appelés batch)
Pour résumé des différents record SMF

[xfanx]

bonjour,

en fait, sauf si nous avons mal lu et testé, le record 30 SMF ne permet que de retrouver les programmes de premier niveau. (ceux de la carte EXEC PGM= ); nous n'avons pas retrouvé dans ces records les sous modules appelés en CALL dynamique.
Donc, pour l'instant nous revenons à l'idée de l'exit LLA trouvé dans le CBTtape 497 qui trace tous les load fetchés à partir d'un PDS en LLA. Il est nécessaire de l'adapter dans un cadre global puisque pour l'instant il nécessite de lui indiquer le nom d'un job/stc/reg ims à tracer et de vérifier que le résultat de la trace, stockée en Extend CSA n'est pas d'une taille excessive malgré que nous souhaitions tracer toute l'activité de production.

[Homer-ac]

C'est ce que j'avais indiqué, le type 30-4 ne donne que l'EXEC PGM=. C'est donc seulement un point de départ pour remonter ensuite aux appelés, statiques, le plus facile dans les Load, et dynamique mais là il faut se cogner une analyse des sources en hiérarchie verticale qui plus est ! Mais ca reste dans le domaine du possible, même si c'est juste pour une vérification croisée avec l'exit LinkList.
J'ai quand même pris le temps de vérifier ce que ça rendait avec le JCL trivial d'extraction suivant :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
//STEP000  EXEC PGM=IEFBR14                                  
//DD1      DD  DSN=&SYSUID..SMF30.TEMP1,                     
//             UNIT=3390,SPACE=(TRK,1),DISP=(MOD,DELETE)     
//DD2      DD  DSN=&SYSUID..SMF30.TEMP2,                     
//             UNIT=3390,SPACE=(TRK,1),DISP=(MOD,DELETE)     
//*                                                          
//STEP001  EXEC PGM=IFASMFDP,REGION=4M                     
//SYSPRINT DD SYSOUT=*                                       
//IN       DD DISP=SHR,DSN=MON.FICHIER.MAN                   
//QSAMOUT  DD  DSN=&SYSUID..SMF30.TEMP1,DISP=(,CATLG,DELETE),
//             RECFM=VBS,LRECL=32760,BLKSIZE=0,              
//             SPACE=(CYL,(5,5),RLSE),UNIT=3390              
//SYSIN    DD *                                              
   INDD(IN,OPTIONS(DUMP))                                    
   ABEND(NORETRY)                                            
   OUTDD(QSAMOUT,TYPE(30(4)))                                
//*                                                          
//STEP002  EXEC PGM=SORT                                     
//SYSPRINT DD  SYSOUT=*                                      
//SYSOUT   DD  SYSOUT=*                                      
//SORTIN   DD  DSN=&SYSUID..SMF30.TEMP1,DISP=SHR             
//SORTOUT  DD  DSN=&SYSUID..SMF30.TEMP2,DISP=(,CATLG,DELETE),
//             RECFM=FB,LRECL=354,BLKSIZE=0,                 
//             SPACE=(CYL,(5,5),RLSE),UNIT=3390              
//SYSIN    DD  *                                             
 SORT FIELDS=COPY                                            
 OMIT COND=(5,2,CH,NE,X'DE1E')
 OUTFIL FNAMES=SORTOUT,VTOF,OUTREC=(5,354),VLFILL=C' '                                 
//*

nb. Il y a aussi la piste du module ASM de scan en LLA de MXI qu'il peut être intéressant de creuser également. Comme ça devrait pouvoir se jouer en batch périodiques, pas de risque de sur-consommation de l'Extended CSA.

[Homer-ac]

Bonjour,
Juste pour compléter ce que j'avais suggéré pour MXI.
J'ai un peu vérifié cette piste, appel d'un exit LLA également, mais l'idée d'alimenter des records SMF spécifiques me plaisait bien. Sauf que l'exit appelle un module MXILLAX1 dont seul le load est livré (uniquement le source pour l'appel en amode 31 est fourni). Dommage, piste à abandonner donc, surtout que la DSECT data ne semble pas avoir le niveau de finesse suffisant.

[xfanx]

Bonjour,

juste parce que ce vieux sujet est enfin en phase d'industrialisation sur notre production.
Afin de tracer tous les load modules utilisés sur une Lpar et ainsi faire un certain ménage dans nos Loadlib, nous avons implémenté et quelque peu adapté l'exit LLA distribuée dans le CBTTAPE 497.
en résumé, celle ci trace en extend CSA tous les load modules chargés depuis un PDS en LLA; Nous avons de plus développé un Batch qui régulièrement vide cette liste en Ecsa et insert dans une table DB2 pour garder les historiques.

après quelques mois de mise en place nous avons pisté 9800 modules utilisés sur une totalité d'un peu plus de 30000 présents en Loadlib.

la 2eme phase va consister à supprimer de manière progressive tous ces loads obsolètes

Si vous êtes intéressé par ce sujet et la démarche, je suis dispo pour donner nos sources et notre expérience un petit MP suffira.

en tout cas, merci de votre aide