Discussion :

[freed201]

Salut a tous,

Voici ma requete. J'ai beau me creuser la tete, pas de reponse pour l'instant.

Je dois faire un programme qui genere, suivant differents facteur, un texte.

en gros:
Si 1 --> Generer le message 1
Si 2 --> generer le message 2
...

Ca serait simple mais voici ce qui me pose probleme.
1- gestion de 2 langues : suivant un autre critere, le message sera soit en francais, soit en anglais
2- le message peut comporter de 2 a 25 lignes
3- il y a 30 messages differents. ( donc 60 si on compte les deux langues)
4- je dois mettre dans le message "dynamiquement" certaines valeur.
5- le tout sort dans un fichier en sortie du programme cobol.

Mon gros soucis est de savoir comment structurer mon programme.
Si je mets les messages a l'intérieur : il deviendra illisible.

Merci d'avance

[Mercure]

Principe :
Réunis les données du message à constituer dans la WSS de ton programme et passe ensuite ces données en tant que paramètres à un autre programme qui se chargera de générer le message et de l'écrire sur le fichier.


Sur quelle plate-forme travailles-tu ?

[el_slapper]

C'est une possibilité. Voire tu peux générer des fichiers/tables de référence, avec des jokers là ou tu veux rajouter des données.

message de 2 lignes puis message de 3 lignes avec valeurs

001rzetretzer
001blablabla
002bla*valeur*bla
002truc
002bidule

quand tu as le message 001, tu vas chercher dans ta référence de langage toutes les lignes commençant par 001. Facile.

quand tu as le message 002, pareil, sauf qu'après tu dois scanner tes lignes en remplaçant *valeur* par ton calcul dynamique. Genre, INSPECT REPLACING, ce genre de choses.....

Effectivement cette référence peut être plaçée dans une working, mais bon, c'est plus embêtant à maintenir.

[Mercure]

Oui, mais ça fait un fichier supplémentaire à gérer, donc des I/O qui pénalisent le traitement.

[Homer-ac]

Il me semble que chacun pourra proposer une solution différente tant que les critères de disponibilité n'auront pas été posés :
- quel taux de mise a jour des messages, souvent, parfois (> mois, > année, presque jamais.
- quel circuit de mise à jour et quels délais et besoins de pertinence de ces MAJ (cours : centralisation ou pas ? mais mise à jour externes, longs pourquoi pas dans un module dédié).
Après voir si on n'a pas sur site un produit qui gère ça (SPITAB est par exemple encore assez répendu en z/OS). Si ensuite on en déduit que l'on peut charger une table dans un COBOL (en fait 2, une par langage. Il semble effectivement prudent d'isoler ça dans un module qui se contentera de faire de la restitution du message dont le numéro à été demandé. Personnellement dès lors que je suis amené à écrire un module dédié, je prends en plus la précaution de demander communication d'un numéro de version dans la zone d'appel (obligatoire et bien entendu vérifié dès le départ), histoire de se prémunir de corrections fonctionnelles futures (changement de longueur du message ou ajout d'une restitution de message court, ou autre ?) .

J'oubliais, bien entendu le taux d'utilisation et donc l'objectif de performances est un facteur discriminant, Maintenant si besoin, 60 messages de disons 200 caractères à lire représentent un overhead I/O relativement insignifiant (un seul bloc en z/OS)

[el_slapper]

Oui, je n'avait pas parlé de SPITAB, mais si tu a ça à disposition, c'est quand même idéal : très performant en lecture, et externalisé pour mise à jour facile.

[freed201]

Salut a tous, et merci de vos réponses

je suis sur Z/Os et SPITAB ne me dit rien mais je vais me renseigner.

l'idée des tables me semble pas mal : facile a mettre a jour, limite le bordel dans le programme cobol et surtout c'est lisible. (j'aime moi l'idée du fichier en entrée).

Les messages seront normalement rarement mis a jour (mais bon comme vous devez le savoir, rarement ca veut dire que ca sera mis a jour ...). donc la table c'est mieux pour ca aussi.

merci pour vos reponses.