Version imprimable
Bonjour,
j'ai actuellement un petit souci, j'ai un programme qui prend en entrée un fichier sequentiel et qui doit ecrire chacun des enregistrements de ce fichier dans un fichier vsam.
Le programme tourne bien mais 5 des ces enregistrements renvoient le code 48 lors de l'ecriture, ce qui semble anormal puisque tous les autres passent.
Si vous avaez la moindre idée concernant l'origine de ce probleme je suis preneur.
Merci d'avance.
Bonjour.
- quel OS et quel compilateur ?
- mode d'ouverture et d'accès au fichier vsam ?
- ordre de tri du fichier en entrée selon la clé du vsam ?
- qu'ont en commun les 5 enregistrements à problème ?
Edit :Citation:
A WRITE operation has been tried on a file not opened in the OUTPUT, I-O, or EXTEND mode, or on a file open I-O in the sequential access mode.
Alors l'os est z/os, le compilateur je ne sais pas du tout, le vsam est ouvert en i-o, le vsam est cense etre trie sur la cle mais j'y accede en dynamique, et le seul point commun est que ces 5 enregistrements sont en double dans le fichier en entrée.
Mais le code retour devrait etre 22.
Je n'ai pas supprimmé les doublons du fichier car il y a plus de 100 000 enregistrements et qu'ils ne sont pas censés poser probleme.
Ok.Citation:
Envoyé par Mephista
- Bon l'essentiel c'est ce problème du Duplicate key, je laisserai mes confrères z/OS t'expliquer pourquoi le File Status est à 48 et non 22.
- Le vsam est bien sûr trié sur sa clé, je parlais du fichier en entrée qui doit contenir les enregistrements dans le même ordre que la clé du vsam lorsque ce dernier serait ouvert en output avec accès séquentiel.
- Si le vsam est ouvert en i-o et l'accès est dynamic, ça ne pose aucun problème quant à la séquence des enregistrements à y écrire.
Sauf que voilà ça arrive ;)Citation:
Je n'ai pas supprimmé les doublon du fichier car il y a plus de 100 000 enregistrements et qu'ils ne sont pas censés poser probleme.
A mon avis, il faudrait sortir par invalid key du Write et gérer ces doublons en les négligeant tout simplement, en en imprimant une liste ou en les écrivant dans un autre fichier.
Edit :
Ton fichier en sortie ne serait pas en ORGANIZATION RELATIVE ?
Je n'ai pas de fichier de sortie autre que le vsam danslequel j'ecris.
Mais si j'ai bien compris, le code 48 que je recois est cense etre 22 mais il s'agit d'un bug ?
Si c'est ca, alors mon probleme est resolu ;)
Oui mais il peut être un vsam rrds :
Edit :Citation:
Relative Record Data Set (RRDS)This VSAM format allows retrieval of records by number; record 1, record 2, and so forth. This provides random access and assumes the application program has a way to derive the desired record numbers.
- y a-il des logiques ou des alternate keys basés sur le vsam ?
- j'écarte jusqu'à nouvel ordre un quelconque bug
Oui il y a une cle alternative sur le fichier vsam et il est en organisation indexed.
hummmm, bizarre il détecterait une erreur sur l'alternative key avant la primaire ?
Je ne sais pas du tout, ce serait etrange vu que je n'utilise jamais la seconde cle.
Par contre je viens de finir un outil pour supprimer les doublons, je reessaie sans voir ce que ca donne.
Même si tu ne l'utilises pas, si elle est là, elle est maintenue par le système.Citation:
Envoyé par Mephista
J'ai relance le traitement avec un fichier trié et sans doublon.
J'affiche en sysout tous les enregistrments traites avec leur code retour lors de l'ecriture et j'ai remarque que tous mes codes retours 22 sont regroupes à la fin (le retour 22 n'est pas genant le client a du deja integrer les enregistrments dont il avait le plus besoin) et que les 3 codes 48 qui me genent sont les 3 seuls enregistrements dont la cle n'est pas deja presente dans le vsam.
Serait-il donc possible que le code retour 22 empeche ensuite l'ecriture d'un autre enregistrement ?
- tu n'as pas besoin de trier, sauf pour des raisons pratiques d'identification des enregistrementsCitation:
Envoyé par Mephista
- pourquoi tu n'utilises pas la clause INVALID KEY, c'est plus pratique
- Non, une clé en double sur un enregistrement n'empêche pas l'écriture d'un autre enregistrement, sauf bien entendu si la clé n'est pas bien renseignée
- je pense de plus en plus que ton 48 concerne l'Alternative key, tu dois aussi gérer (ou éliminer) les doublons la dessus.
D'accord,
en fait si j'utilise pas la clause invalid key c'est parce que ca fait à peine un mois je bosse sur grand systeme du coup j'me suis pas encore tout à fait familiarise.
Tu peux m'expliquer comment gerer la cle alternative ?
Et si effectivement il s'agit de ca pourquoi uniquement 3 enregistrements sont touches ?
- justement c'est bien de commencer par de bonnes habitudes.
- je ne peux pas trop de parler de l'alternate key sur z/OS, je ne connais pas son utilisation exacte sur ce système, mais grosso modo on doit indiquer cette clé dans les ordres d'entrée/sortie (KEY IS...).
- peut être qu'il n'y a que trois enregistrements qui provoquent la condition d'erreur, laquelle ?
- à ta place, comme c'est un traitement d'un grand lot de données en entrée à intégrer dans des fichiers, je ferais en sorte de m'assurer de la validité de toutes ces données dans leur globalité avant de commencer l'intégration. Je m'assurerais qu'elles sont saines de toute erreur et qu'elles sont conformes aux contraintes générales des données : unicité des clés, types des données, validité des dates, etc...
- je ferais un ou plusieurs tris sur les clés des fichiers vsam et des alternate key qu'elles doivent intégrer et sortirais un état d'erreurs , faire recycler ces données et une fois totalement nettoyées de toute erreur, je ferais l'intégration.
- enfin tu devrais avoir un encadreur ou un chef de projet qui doit te fixer les règles à suivre et les techniques à utiliser.
Ok, je me renseigne sur l'utilisation de cette cle, pour ce qui est de la verification des données, elles proviennent du client, du coup à part le formatage je ne sais pas vraiment à quoi m'attendre.
En tout cas merci du coup de main, je te tiens au courant de l'evolution.
Regarde bien le type compilateur que tu as et vas sur les sites z/OS d'IBM où tu trouveras un tas de brochures (au moins deux, le reference et le guide) dont certaines en pdf que tu peux télécharger gratuitement.
Bon, j'ai ete sur le site IBM mais leurs critères de recherche ne m'ont pas permis de trouver la doc correspondante, de plus je n'ai toujours aucune idée du compilateur que j'utilise.
Néanmoins je me suis documenté sur l'utilisation de la clé alternative.
Alors effectivement elle peut etre renseignée lors de la lecture (read ... key is ...) mais pas lors de l'ecriture puisqu'elle est renseignée lors de la valorisation de l'enregistrement.
Du coup j'ai pris soin de renseigner la valeur de la clé avant l'ecriture.
Rien n'y fait, toujours 3 enregistrements renvoient un code 48.
Le formatage de la clé est bon (le meme que les autres), du coup serait-il possible qu'il y ait une contrainte sur la valeur de certaines données de la cle ?
Edit: entretemps j'ai appris à utiliser la clause invalid key. La clé est invalide pour les 3 codes retours 48, mais je n'arrive vraiment pas à determiner pourquoi. Ce qui m'interpelle en revanche c'est que la clé est invalide sur la majorite des codes retours 22 mais pas tous.
Si essayer d'inserer une clé existante ne fait pas d'elle une clé invalide je me demande d'où ca sort.
Edit2: le vsam dans lequel j'insere les enregistrements est une reproduction complete d'un fichier de production.
Lorsque je fais une repro partielle (un enregistrement) tout se passe sans probleme. Serait-il possible que le probleme vienne du fichier ?
La première ligne de la liste de compilation du programme donne la version du compilateur COBOL utilisé ...Citation:
Envoyé par Mephista
Par exemple :
Code:PP 5655-G53 IBM Enterprise COBOL for z/OS 3.4.1
J'ai trouve:
PP 5668-958 IBM VS COBOL II Release 4.0 09/15/92
Bonjour.Citation:
Envoyé par Mephista
Bien sûr que le problème vient du fichier et des données qui existent déjà dedans, anciennes ou nouvellement ajoutées, au moment des nouvelles insertions. C'est pour cela que ça marche quand il n'y a pas grand chose dedans. Je pense que c'est un problème de clés doubles sur la clé primaire ou les alternates key. C'est pour cela que je suggère de mettre de côté les doublons de la clé primaire et des clés secondaires.
- L'une des façons de les détecter est de faire des read avec la valeur des clés en provenance des données en entrée, aussi bien avec la clé primaire que les clés secondaires, et lorsqu'on sort par un invalid sur toutes les lectures, on écrit l'enregistrement, sinon on le met de côté.
- ou alors tester le statut du fichier après écriture, et s'il n'est pas à 00 on met l'enregistrement entrant de côté.
J'insiste sur le contrôle de la validité des données en bloc avant leur prise en charge et de recycler les erreurs. C'est obligatoire quand on fait des traitements par lot. Ce n'est pas comme de l’interactif où l'on rejette les données quand elles sont erronées au moment de la saisie.