Journaux sur fichier pour transaction. [Résolu]

[Sankasssss]

Bonsoir,
Ayant voulut tester les transactions sur les fichiers de l'AS400 de mon entreprise j'ai fait quelque test.
J'ai donc créé, sur un fichier très peu utilisé de l'entreprise, un récepteur de journal et un journal. (Via ce tuto de dvp)

Tout fonctionne bien mais aujourd'hui, surprise, je vois une multiplication du récepteur.
A la base je l'avais nommé par le nom du fichier (ACCFRE) + RJ (pour récepteur
journal)
Et maintenant de nouveau fichier font leur apparition nommé par le nom du fichier + un n° sur 4 numérique qui s'incrémenter : ACCFRE0001
Preuve :


Je me demande donc comment cela se fait-il?
Pour info, ce fichier n'est utiliser qu'en lecture par les applications qui ne faisait pas de transaction. Le remplissage se faisait en DFU et mon test de transaction via programme fait en .net n'a durer qu'une demi journée.

Si je dois faire ça sur tout les fichiers et qu'il se multiplie tous ça va vite devenir ingérable pour la maintenance...

Donc toute aide / idée / lien vers site explicatif est le bienvenu

[punkoff]

Les journaux ont un seuil de détachement.
Quand on arrive à ce seuil le récepteur est détaché et un autre est créé.

Donc si tes récepteurs se détachent c'est qu'ils sont plein (logiquement).

La technique de maintenance, c'est de sauvegarder tes récepteurs sur bande puis de supprimer ceux sauvegardé.

Pour voir les options lié a ton journal déjà créé utilise la commande WRKJRNA.
Pour celle de tes récepteur : DSPJRNRCV, grâce à celle-là tu verras le seuil de détachement.


Concernant le seuil de détachement il faut mettre cette valeur : nbre de bras * 64 = résultat en MO du seuil de détachement.


Pour voir ce qu'il y a dans tes journaux utilise la commande : DSPJRN, ne prend pas peur à la vue des différentes options, tu ne pourras rien casser avec cette commande



Quand tu crées un journal, il y une option en particulier qui permet de supprimer les récepteurs détaché en automatique : DLTRCV *YES. Attention ce n'est pas forcément une bonne idée !


Ensuite une autre option intéressante est à mettre dans RCVSIZOPT : *RMVINTENT. Ceci dit au système de ne pas logger dans ce récepteur les postes de journaux liés au redémarrage du système. Cette option doit à mon sens être utilisée.

Autre option JRNCACHE : à mettre à *YES si tu as l'option 42 activée sur ton system i et que les programmes qui utilises la journalisation le font sans commitment control. (sinon inutil).

Enfin l'option MINENTDTA : à mettre à *FILE. Ceci permet de ne logger que les différences lors d'update par exemple. Ca permettra à tes récepteurs de grossir moins vite.

[K2R400]

Si tes journaux sont gérés en *SYSTEM, ils sont détachés puis recréés à chaque IPL. Un IPL par mois suffit, et tu journaliser une grandre quantités de tables dans le même journal.
Si tu préfères les détacher toit même à la demande gère les en *USER.
Mais attention s'il est plein, tu auras un message dans QSYSOPR et toutes les transactions seront en attente

[Sankasssss]

Bonsoir,
tout d'abord merci pour vos excellentes réponses

Suite à l'intervention de punkoff j'ai regardé au boulot la date de création des différents récepteurs et ils sont bien créé à chaque IPL comme vous l'avez précisé tout les deux.
Donc lors de la création de nouveau récepteur et journaux j'utiliserai l'option RCVSIZOPT : *RMVINTENT afin d'éviter ce désagrément.

J'ai quelque question sur l'intervention de punkoff :

Envoyé par punkoff

La technique de maintenance, c'est de sauvegarder tes récepteurs sur bande puis de supprimer ceux sauvegardé.

Pour voir les options lié a ton journal déjà créé utilise la commande WRKJRNA.
Pour celle de tes récepteur : DSPJRNRCV, grâce à celle-là tu verras le seuil de détachement.


Concernant le seuil de détachement il faut mettre cette valeur : nbre de bras * 64 = résultat en MO du seuil de détachement.


Pour voir ce qu'il y a dans tes journaux utilise la commande : DSPJRN, ne prend pas peur à la vue des différentes options, tu ne pourras rien casser avec cette commande

J'avais déjà regardé ce qu'il y avait dans le journal (via l'option 5 afficher qui à le même effet que DSPJRN) et j'ai bien compris les différents code de comit et de rollBack (vive la touche F1 )
Par contre, j'ai essayé de faire la même chose sur le récepteur et la j'obtiens juste une fenêtre de résumé nommée Attributs de récepteur de journal disant le poid du journal, le mien fait actuellement 356Ko, le seuil (10.000.000Ko) et d'autre information sur la sauvegarde.
Donc je n'arrive pas à afficher les données du récepteur d'où cette question :
Pourquoi vouloir le sauvegarder vu que je ne sais rien en faire???

Envoyé par punkoff

Quand tu crées un journal, il y une option en particulier qui permet de supprimer les récepteurs détaché en automatique : DLTRCV *YES. Attention ce n'est pas forcément une bonne idée !

Même question que ci-dessus : pourquoi n'est-ce pas une bonne idée de supprimer ces récepteurs vu que je ne peux les visualiser?

Envoyé par punkoff

Concernant le seuil de détachement il faut mettre cette valeur : nbre de bras * 64 = résultat en MO du seuil de détachement..

Qu'entend tu par nombre de bras?


Encore merci pour vos excellentes interventions

[punkoff]

Envoyé par Sankasssss

Bonsoir,
tout d'abord merci pour vos excellentes réponses

Suite à l'intervention de punkoff j'ai regardé au boulot la date de création des différents récepteurs et ils sont bien créé à chaque IPL comme vous l'avez précisé tout les deux.
Donc lors de la création de nouveau récepteur et journaux j'utiliserai l'option RCVSIZOPT : *RMVINTENT afin d'éviter ce désagrément.

Seul K2R a précisé le fait que le récepteur se détachait à chaque IPL

RCVSIZOPT : *RMVINTENT n'évitera pas ca. Ca évitera qu'une partie de la journalisation système ne se fasse dans ton journal.

Donc je n'arrive pas à afficher les données du récepteur d'où cette question :
Pourquoi vouloir le sauvegarder vu que je ne sais rien en faire???


Même question que ci-dessus : pourquoi n'est-ce pas une bonne idée de supprimer ces récepteurs vu que je ne peux les visualiser?

Es-tu en production ?
La journalisation permet 2 choses :
- de garder l'historique intégral des modifications fait à ta base de donnée (ou ton fichier en l'occurence) => sécurisation des données.
- de gérer les pgm avec du commit / rollback.

Grâce à d'autre commande tu peux, via les journaux, "défaire" ce qui a été fait en invalidant les entrées dans tes journaux.

Les données de chaque action fait sur une table journalisée sont gardées dans les récepteurs, donc si tu supprimes ceux détachés tu perd les infos de ces changements.

l'option DLTRCV *YES dit au système de supprimer le récepteur détaché systématiquement. Et ceci (d'après ce que je comprend) sans prendre en compte le fait que le récepteur soit sauvegardé ou pas.

Qu'entend tu par nombre de bras?

C'est le nombre de disk que possède ta machine, si tu es en mirroring il faudra diviser le nombre totale de disk par 2.

[Sankasssss]

Envoyé par punkoff

Seul K2R a précisé le fait que le récepteur se détachait à chaque IPL

J'avais cru comprendre cela par tes écris ce qui a été vérifié en visualisant les dates de création...
J'ai bien retenu l'intervention de K2R400 quand au fait de gérer en *USER pour éviter d'avoir un détachement lors de l'IPL mais je ne préfère pas vu qu'il faudrait dès lors une intervention du QSYSOPR ce qui n'est pas génial vu que le journal me servira principalement pour gérer les transactions (COMIT et ROLBACK) dans nos programmes.

Envoyé par punkoff

La journalisation permet 2 choses :
- de garder l'historique intégral des modifications fait à ta base de donnée (ou ton fichier en l'occurence) => sécurisation des données.
- de gérer les pgm avec du commit / rollback.

Grâce à d'autre commande tu peux, via les journaux, "défaire" ce qui a été fait en invalidant les entrées dans tes journaux.

Les données de chaque action fait sur une table journalisée sont gardées dans les récepteurs, donc si tu supprimes ceux détachés tu perd les infos de ces changements.

Comme dit plus haut, nos journaux nous servirons uniquement au transaction, aucunement à l'historique, c'est pour ça que je ne pense pas sauvegarder ces journaux et que je penche pour l'utilisation de l'option DLTRCV *YES, bien sur je testerai sur un fichier test avant la production.

Je pense aussi créer une bibliothèque spécial pour les journaux et leurs récepteurs, ca sera plus facile pour la maintenance et pour l'exclure du système de sauvetage sur bande...

Merci à vous deux pour vos remarquables interventions

[Mercure]

Si tu te décides à conserver les récepteurs, j'ajouterais qu'il est préférable de les placer outre la bibliothèque dans un ASP particulier de façon à ce que, par précaution, ils ne soient pas détruits en cas de crash disk sauf si malheureusement cet ASP est affecté par le crash. C'est malgré tout AMA un risque à courir qui en vaut la peine.