Discussion :

[JauB]

Bonjour,
Est ce qu'il y a un moyen (sans passer par des développements spécifiques) pour clearer tous les fichiers DATA d'une bibliothèque donnée. Ceci me permettra d'éviter de faire un CLRPFM par fichier de la bibliothèque en question.
Merci d'avance.

[JauB]

Bon,
Juste pour débloquer la situation j'ai procédé comme suit :
1. J'ai récupéré la liste des fichiers données , via une requête, à partir de la bibliothèque voulue en générant directement la requête de suppression des données comme suit :

Requête :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
 
select  'DELETE FROM ' || TABLE_SCHEMA || '.' || TABLE_NAME || ';'
from sysibm.TABLES
WHERE TABLE_SCHEMA = 'MABIB'
AND   TABLE_TYPE = 'BASE TABLE'
AND   TABLE_NAME NOT LIKE 'Q%'

2. J'ai exporté le résultat de la requête dans un fichier que j'ai exécuté via un outil SQL.

3. Le tour est joué

[jump400]

Bjr,

A ma connaissance cela n'existe pas. Mais il est très simple de faire un petit CL pour cela.
Voici une trame simple (Aucun controle d'erreurs) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
              PGM        PARM(&LIB)                                     
              DCL        VAR(&LIB) TYPE(*CHAR) LEN(10)                  
              DCLF       FILE(QADSPOBJ)                                 
              DSPOBJD    OBJ(&LIB/*ALL) OBJTYPE(*FILE) +          
                           OUTPUT(*OUTFILE) OUTFILE(QTEMP/WOBJD)        
              OVRDBF     FILE(QADSPOBJ) TOFILE(QTEMP/WOBJD)             
 NEXT:                                                                  
              RCVF                                                      
              MONMSG     MSGID(CPF0864) EXEC(GOTO CMDLBL(EOF))          
              /* On ne traite que les objets *FILE/PF, SAUF ceux  */    
              /* commençant pat 'Q' pour ne pas clearer les sources */  
              IF         COND(&ODOBTP *EQ '*FILE' *AND &ODOBAT *EQ +    
                           'PF' *AND %SST(&ODOBNM 1 1) *NE 'Q') THEN(DO)
              CLRPFM     FILE(&LIB/&ODOBNM)                             
              GOTO       CMDLBL(NEXT)                                   
 EOF:                                                                   
              ENDPGM

[jump400]

Bien vue le SQL

Il y a cependant une petite différence entre DELETE (SQL) et CLRPFM au niveau des perfs et des verrouillages.
- CLRPFM est bien plus rapide (surtout si la table est journalisée) car travaille au niveau du membre, mais impose un verrouillage exclusive sur l'objet *FILE
- DELETE est plus lent (il travaille ligne à ligne) mais du coup n'a pas besoin d'un verrouillage exclusif sur l'objet

[JauB]

Merci pour le CL.
Sinon question performance, je ne voulais pas m'y prendre la tête, je cherchais juste à vider ma bibliothèque d'une façon automatique

Bien vue le SQL

Il y a cependant une petite différence entre DELETE (SQL) et CLRPFM au niveau des perfs et des verrouillages.
- CLRPFM est bien plus rapide (surtout si la table est journalisée) car travaille au niveau du membre, mais impose un verrouillage exclusive sur l'objet *FILE
- DELETE est plus lent (il travaille ligne à ligne) mais du coup n'a pas besoin d'un verrouillage exclusif sur l'objet

[Mercure]

DELETE ne fait que détruire les liens de chaînage des enregistrements dans la BDD mais l'espace disque est toujours occupé, alors que CLRPFM nettoie le fichier en le vidant de ses enregistrements et surtout en récupérant l'espace disque occupé pour le mettre à disposition des autres fichiers.
Quant à l'aspect perfs, CLRPFM bat à plates coutures tout delete, quel qu'il soit, il n'y a pas photo. En final, cela fait une grosse différence, surtout sur les fichiers volumineux !

[K2R400]

Bien vue le SQL

Il y a cependant une petite différence entre DELETE (SQL) et CLRPFM au niveau des perfs et des verrouillages.
- CLRPFM est bien plus rapide (surtout si la table est journalisée) car travaille au niveau du membre, mais impose un verrouillage exclusive sur l'objet *FILE
- DELETE est plus lent (il travaille ligne à ligne) mais du coup n'a pas besoin d'un verrouillage exclusif sur l'objet

Depuis la V5R3, un DELETE * FROM MATABLE sans clause WHERE et sur une table non journalisée n'est pas plus lente qu'un CLRPFM, car "under the cover" c'est bien un CLRPFM qui est exécuté si la table n'est pas tenue par un autre job, c'est que ce l'on appelle communément le FASTER DELETE.

[jump400]

Depuis la V5R3, un DELETE * FROM MATABLE sans clause WHERE et sur une table non journalisée n'est pas plus lente qu'un CLRPFM, car "under the cover" c'est bien un CLRPFM qui est exécuté si la table n'est pas tenue par un autre job, c'est que ce l'on appelle communément le FASTER DELETE.

Oups, faut que je me mette à jour merci pour l'info

[Mercure]

Moi aussi !

[JauB]

moi on n'en parle plus