Discussion :

[Hédhili Jaïdane]

Bonjour à tous,

Je vais tester ce que vous m'avez envoyer hier et ce matin.
Je ne sait plus si j'ai fait un IPL ou non... pour le RCLSTG quel risque pour le système AS?

Pour l'IPL, il y a eu au moins un au redémarrage de la machine après la coupure de courant si tant est que la machine se soit arrêtée et pas seulement les autres ressources (device, programmes, comm, etc...)
Pour le RCLSTG, aucun risque, du moins très peu, bien au contraire, ça va te permettre de vérifier l'intégrité de la totalité du système entre autres celle des objets.

The command corrects, where possible, objects that were incompletely updated (such as database files, etc...)

Ça prend du temps et exige le mode restreint, il exécute entre autres le RCLDBXREF qui semble ne pas exister comme commande à part entière chez toi. Après l'exécution et avant l'arrêt et le redémarrage de la machine, il faudrait vérifier les log (Système et Job) et regarder les objets qui ont été déplacés dans la bibliothèque QRCL

Bien sûr il faudrait un onduleur pour l'AS400 mais.... le matériel étant dans ces 6 derniers mois de vie, la direction ne souhaite pas faire l'achat...

Je ne connais pas ton système mais un petit onduleur de 2Kva ne doit pas coûter si cher et il pourra servir pour les nouveaux matériels.

Si un ENDJOB contrôlé a été lancé, rien ne servira d'en relancer un autre, il faudrait essayer de le forcer par un ENDJOBABN après au moins 10mn.

La solution préconisée par notre ami badaze marche bien à condition de le faire pour tous les LF, voir la commande DSPDBR pour les lister et surtout qu'on puisse libérer le PF et/ou le LF bloqués en arrêtant le job.

oubliez certaines remarques

[zacaoa]

Voici ce que F1 m'indique:

[Hédhili Jaïdane]

Pour le moment :
- Fais une copie de sécurité ppar CRTDUPOBJ ou de préférence par CPYF
- Vérifie à nouveau les locks sur ce fichier et/ou ses LF et s'il y a des jobs, arrête les par ENDOBJ *IMMED
- Relance le RGZPFM

[zacaoa]

Pour le moment :
- Fais une copie de sécurité ppar CRTDUPOBJ ou de préférence par CPYF
- Vérifie à nouveau les locks sur ce fichier et/ou ses L et s'il y a des jobs, arrête les par ENDOBJ *IMMED
- Relance le RGZPFM

La commande CPYF ne fonctionne pas, il me dit ne pas trouver le nouveau fichier à créé ou ne pas arriver à le créer.
Pour la commande CRTDUPOBJ, est-ce que ce sont les bonnes infos?

[badaze]

La bib de destination doit être différente de celle de départ.

[zacaoa]

La bib de destination doit être différente de celle de départ.

Comment je fais pour la rapatrier ensuite dans la bonne librairie?
Si je comprend bien, il faudrait que je créer une copie du fichier dans une autre librairie puis je renomme l'actuelle en vrac, puis je déplace celle créée dans la bonne librairie avant de faire un RGZPFM?

Pouvez-vous me dire l'exactitude des commandes à passer sur l'AS400 s'il vous plait? Je ne maitrise pas complêtement ce système... remarque je crois que cela se voit!

[Hédhili Jaïdane]

Pour le CPYF voilà un exemple :
CPYF FROMFILE(FIDGRSF/PPLAJO) TOFILE(FIDRSFAUTR/PPLAJOSAVE) MBROPT(*REPLACE) CRTFILE(*YES) FMTOPT(*NOCHK)
Tu remarqueras que j'ai donné un nouveau nom au fichier et je le mets dans une autre biblio (plus sécurisant)

Pour le CRTDUPOBJ, je préfère que là aussi tu lui donnes un autre nom et tu le mettes dans une autre biblio.
Si tu gardes le même nom il faut obligatoirement le mettre dans une autre biblio (même nom, même type, même biblio ça marche pas)
Si tu veux faire une copie de sécurité il faut mettre duplication des données à *YES sinon ton nouveau fichier ne contiendra pas les données.

[Hédhili Jaïdane]

Comment je fais pour la rapatrier ensuite dans la bonne librairie?
Si je comprend bien, il faudrait que je créer une copie du fichier dans une autre librairie puis je renomme l'actuelle en vrac, puis je déplace celle créée dans la bonne librairie avant de faire un RGZPFM?

Pouvez-vous me dire l'exactitude des commandes à passer sur l'AS400 s'il vous plait? Je ne maitrise pas complêtement ce système... remarque je crois que cela se voit!

Perso, ce n'est pas ce que je préconise pour le moment. Ça sera notre dernier recours. Pour le moment il faut libérer le fichier et reconstruire son index.

[zacaoa]

Perso, ce n'est pas ce que je préconise pour le moment. Ça sera notre dernier recours. Pour le moment il faut libérer le fichier et reconstruire son index.

La copie via CRTDUPOBJ est faite avec les données.
La commande RGZPFM se fait mais dans les logs de DSPLOG j'ai toujours le même message indiquant que la reconstruction n'a pas réussi.

[Hédhili Jaïdane]

La copie via CRTDUPOBJ est faite avec les données.

Ok, mais ce n'est pas ce que j'ai vu sur l'image envoyée. Vérifie le par un DSPPFM sur le nouveau fichier.

La commande RGZPFM se fait mais dans les logs de DSPLOG j'ai toujours le même message indiquant que la reconstruction n'a pas réussi.

Vérifie les locks sur le fichier physique, ses membres et sur tous ses LF. Et si tu dois arrêter les jobs, fais le avec *IMMED.
Vérifie si l'applic qui utilise PPLAJO03 peut tourner.

[zacaoa]

La commande DFSPFM ne fonctionne pas, il me retourne commande non trouvée dans la bibliothèque.
J'ai vérifié, le fichier a bien été créé avec les données dans une autre librairie FIDGRSFAUT.

Pour ce qui est des locks, je n'en ai plus aucun sur le fichier physique PPLAJO ni sur un logique comme PPLAJO03, la liste retournée est entièrement vide pour les OBJ, les membres. Les LF je ne sais pas ce que c'est.

J'ai testé de nouveau l'application et j'ai toujours le même résultat lors de la commande:

[Hédhili Jaïdane]

désolé, c'est DSPPFM
LF = Logical File

Essaie un RGZPFM sur le nouveau fichier et regarde le log
Essaie le CPYF de PPLAJO comme je te l'ai montré

Tout ça c'est pour avoir une copie viable et fiable de tes données.

[zacaoa]

Voilà le résultat du CPYF:



et

[FORMULARY]

Bonjour,
Le fichier PPLAJO est un fichier logique (peut-être un fichier joint, à la vue du nom) avec une clé unique.
Or le fichier physique dont il dépend (ou un des fichiers si fichier joint) a plusieurs enregistrements avec la même clé.
Si tu retrouve le message CPF5090, place le curseur dessus et utilise la touche F1 pour afficher le détail du message. Il doit indiquer le numéro d'enregistrement du fichier physique.
Les questions qui se posent, c'est :
- Qu'est-ce que ce fichier PPLAJO ?
- Pourquoi y a t-il plusieurs enregistrements avec la même clé ?
- La solution est-elle de supprimer un des enregistrements, et lequel ? ou modifier l'un des enregistrements, et lequel ?
La commande DSPPFM permet d'afficher le fichier physique
La commande UPDDTA permet de modifier ou de supprimer les enregistrements d'un fichier (logique ou physique). Attention lors de son utilisation.

[zacaoa]

Bonjour,
Le fichier PPLAJO est un fichier logique (peut-être un fichier joint, à la vue du nom) avec une clé unique.
Or le fichier physique dont il dépend (ou un des fichiers si fichier joint) a plusieurs enregistrements avec la même clé.
Si tu retrouve le message CPF5090, place le curseur dessus et utilise la touche F1 pour afficher le détail du message. Il doit indiquer le numéro d'enregistrement du fichier physique.
Les questions qui se posent, c'est :
- Qu'est-ce que ce fichier PPLAJO ?
- Pourquoi y a t-il plusieurs enregistrements avec la même clé ?
- La solution est-elle de supprimer un des enregistrements, et lequel ? ou modifier l'un des enregistrements, et lequel ?
La commande DSPPFM permet d'afficher le fichier physique
La commande UPDDTA permet de modifier ou de supprimer les enregistrements d'un fichier (logique ou physique). Attention lors de son utilisation.

En faisant F1 sur le message CPF5090 voici ce qui m'est retourné:



Le fichier PPLAJO est un fichier physique et non logique qui contient des données pour le logiciel de paye tournant sur l'AS400. Je suppose que le traitement en cours au moment de la coupure de courant a pu généré des erreurs de clés dans le fichiers logique PPLAJO03 rattaché au fichier PPLAJO, mais je ne peux faire là que des suppositions...

[Hédhili Jaïdane]

ok, on y est petit à petit. On a des clés doubles dans le fichier physique.

Le fichier PPLAJO est bien un fichier physique sinon le RGZPFM ne tournerait pas. Vérifie tout ça avec WRKOBJ OBJ(biblio/PPLAJO*) OBJTYPE(*FILE)

As tu fais un DSPPFM PPLAJO ?
Essaie le CPYF en y ajoutant ERRLVL(*NOMAX) et PRINT(*ERROR) et regarde le log et le spool généré et dis nous ce qu'il se passe.

[FORMULARY]

Bonjour zacaoa,
le message que tu donne est le RPG1299 reçu par le programme RPG PHMVFG1 de la biblio FIPGRS.
Ce programme n'est normalement pas appelé par un CPYF, sauf si il s'agirait d'un programme trigger sur ajout.
Est-ce que tu as eu ce message sur un CPYF ou sur un programme de saisie ?

Dans ton job log, le message précédent était le CPF5090. En regardant le détail de ce message,
on aurait eu le numéro d'enregistrement existant avec la même clé.

Note que le programme RPG essaie de créer un doublon, mais sans y arriver ...
Le CPYF qui plante se produit lorsque l'on a déjà les clés en double.

Essaie un CPYF du fichier dans un fichier inexistant avec CRTFILE(*YES)
Ca devrait créer le fichier avec les attributs du fichier d'origine, donc avec clés uniques.
Si ça se plante, vérifie dans ton log le message CPF5090 (si tu as fait le CPYF en intéractif),
la commande DSPJOBLOG devrait afficher le log. F10 pour avoir le détail, F18 pour aller à la fin,
et vérifie le messsage CPF5090. Tu devrais y trouver le numéro d'enregistrement en double.

Après, c'est à toi de corriger les enregistrements pour avoir les bonnes infos.
Et là, on ne pourra pas vraiment t'aider ...

[zacaoa]

Bonjour zacaoa,
le message que tu donne est le RPG1299 reçu par le programme RPG PHMVFG1 de la biblio FIPGRS.
Ce programme n'est normalement pas appelé par un CPYF, sauf si il s'agirait d'un programme trigger sur ajout.
Est-ce que tu as eu ce message sur un CPYF ou sur un programme de saisie ?

Dans ton job log, le message précédent était le CPF5090. En regardant le détail de ce message,
on aurait eu le numéro d'enregistrement existant avec la même clé.

Note que le programme RPG essaie de créer un doublon, mais sans y arriver ...
Le CPYF qui plante se produit lorsque l'on a déjà les clés en double.

Essaie un CPYF du fichier dans un fichier inexistant avec CRTFILE(*YES)
Ca devrait créer le fichier avec les attributs du fichier d'origine, donc avec clés uniques.
Si ça se plante, vérifie dans ton log le message CPF5090 (si tu as fait le CPYF en intéractif),
la commande DSPJOBLOG devrait afficher le log. F10 pour avoir le détail, F18 pour aller à la fin,
et vérifie le messsage CPF5090. Tu devrais y trouver le numéro d'enregistrement en double.

Après, c'est à toi de corriger les enregistrements pour avoir les bonnes infos.
Et là, on ne pourra pas vraiment t'aider ...

Le message envoyé est celui reçu par l'intermédiaire d'un programme de saisie et non d'un CPYF.

Voilà le descriptif du message CPF5090 en faisant F1 sur l'historique du programme:


Je vais voir avec le CPYF et je vous tiens au courant

[FORMULARY]

Une autre possibilité serait de créer en intéractif le fichier logique dans qtemp.
Tapez CRTLF QTEMP/PPLAJO03
Vous devriez alors avoir dans votre log un/des messages CPF3240 : Clé en double
Chacun de ces messages indique le numéro d'enregistrement du fichier. Un dsppfm permettra de trouver ces enregistrements en double.
Note: Le fichier peut se créer même si il y a des doublons :
DLTF QTEMP/PPLAJO03 pour supprimer le fichier créé (ou fermer la session)

Ensuite, à vous de voir si un enreg en double doit/peut être supprimé ou modifié de façon à ne plus avoir de valeur en double.

A partir de ce moment là, la réorganisation du logique devrait se faire et vous ne devriez plus avoir le message.

[zacaoa]

J'ai trouvé dans le fichier les lignes en doublon à supprimer.
Problème, je ne sais pas utiliser la commande UPDDTA correctement et je ne veux pas faire de boulette.

Pouvez-vous m'aiguiller sur une solution pour modifier les données du fichier?