Les flux transmis sont bien au format définitif (exception faite des éventuelles évolutions entre PJ1 et PJ2), montants inclus.
Les flux générés par notre ETL sont à destination de l'environnement MVS. Il sortent de notre ETL au format EBCDIC, les différentes données étant restituées dans un format COBOL : Les montants avec décimales n'ont pas de virgule réelle. C'est le "masque" de lecture utilisé sur MVS (par ex copy Cobol) qui va gérer cette virgule virtuelle.
Ex pour un format S9(10)V9(5) qui correspond à un numérique signé avec 10 chiffres max pour la partie entière et 5 chiffres max pour les décimales : Si le montant issu de GT AIA est de 1 234 567,89, notre ETL transmettra un montant 000123456789000.
Sur MVS, les montants, selon qu'ils sont packés ou non, signés ou non, etc n'ont pas la même transcription en hexadécimal.
Ex : Dans le flux Stock Contrat PJ1, sur la donnée "somme des primes" du contrat 3N160001613X. Avec le masque de lecture on a :
RIV-SOM-PRIM DISPLAY 00000011250000é
15/SNUM 0000001125.00000
Le "é" est caractéristique d'un montant MVS signé (c'est le dernier caractère qui porte le signe)
En hexadécimal, le même champ donne ceci :
0 0 0 0 0 0 1 1 2 5 0 0 0 0 é
F F F F F F F F F F F F F F C
0 0 0 0 0 0 1 1 2 5 0 0 0 0 0
Une valeur de type 00000000000000é correspond donc à une zone de type numérique signée (format exacte à voir selon le flux et la donnée), le "é" étant un zéro+signe. Le problème est que dans une récupération d'un flux au format texte, le "é" n'a plus vraiment de sens. Il ne correspond à quelque chose que dans un contexte MVS, par rapport à sa correspondance hexadécimale.
Partager