Lire des données numériques signées

[pierre24]

Je souhaiterai creer une table SAS à partir d'un fichier issu de l'environnement MVS. Probleme : ces fichiers contiennent des formats numériques signés et je n'arrive pas à les lire avec SAS. Savez vous s'il existe une manipulation pour lire ce type de format ?

Quel format attribuer à cette donnée pour pouvoir récupérer un champ numérique décimal ?

Voici a quoi ressemble les données numériques signées

00000012250000é 00000000000000é 00000000000000é

Voici le mail d'une personne qui ma expliqué ce qu'était une zone numérique signée

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.

[steelspirit]

rien compris à ton truc !

J'ai juste noté 2 choses qui pourront t'aider :

1)

Il sortent de notre ETL au format EBCDIC

Il existe un Informat en SAS qui lit l'EBCDIC : S370FF

2)

Le problème est que dans une récupération d'un flux au format texte, le "é" n'a plus vraiment de sens.

A mon avis oublie le é et n'essaie pas de l'importer.

Le mieux est que tu fasse un test sur la première ligne, premier chiffre. Donc essaie ça :

Code :

1
2
3
4
5
 
DATA ma_table;
   INFILE 'chemin\nom_de_ton_fichier' obs=1; /*je lis que la première ligne */
   INPUT @1 test S370FF14. ; /*je me positionne sur la première colonne et j'utilise l'informat S370FF pour lire les 14 premiers caractères. */
run;

J'ai pas testé, dis moi comment ça se comporte.

Steel

[pierre24]

merci je vais essayer

[bahraoui]

Envoyé par steelspirit

rien compris à ton truc !

J'ai juste noté 2 choses qui pourront t'aider :

1)


Il existe un Informat en SAS qui lit l'EBCDIC : S370FF

2)


A mon avis oublie le é et n'essaie pas de l'importer.

Le mieux est que tu fasse un test sur la première ligne, premier chiffre. Donc essaie ça :

Code :

J'ai pas testé, dis moi comment ça se comporte.

Steel

Il ne faut oublier le : S9(10)V9(5)
il faut que tu importes tes données osus format chaîne de caractères.
faire un découpage de ta chaînes avant_virgule après_virgule
EX 00000012253000é
avant_virgule 0000001225 (10 caractères)
après virgule 3000é (5 caractères)
tu supprimes le "é"
tu multiplies le 3000*0.0001
tu aditionnes le résultats à avant_virgule.

[steelspirit]

ah oui mais j'avais pas vu ça aussi :

Si le montant issu de GT AIA est de 1 234 567,89, notre ETL transmettra un montant 000123456789000.

et

RIV-SOM-PRIM DISPLAY 00000011250000é
15/SNUM 0000001125.00000

en fait ici c'est beaucoup plus simple que ce que je croyais, les 5 derniers caractères sont des décimales. Donc si j'ai bien compris : 00000012250000é ça donne 1225.0000 !

Si c'est le cas, rien de plus simple en SAS, utilise l'informat 14.4

Code :

1
2
3
4
5
 
DATA ma_table;
   INFILE 'chemin\nom_de_ton_fichier' obs=1; 
   INPUT @1 test 14.4 ; 
run;

[steelspirit]

Envoyé par bahraoui

Il ne faut oublier le : S9(10)V9(5)
faire un découpage de ta chaînes avant_virgule après_virgule

pas besoin de découpage l'informat le fait directement

essaie ça bahraoui :

Code :

1
2
3
4
5
 
DATA test;
   var="00000012250200é";
   test=input(var,14.4);
run;

[pierre24]

C'est ce que je fait en fait l'informat 15.5 mais ca ne marche pas !
Et pour le "é" à la fin de la chaine ???j'en fais quoi ? car c'est celui la qui contient le signe !!!

[pierre24]

DATA test;
var="00000012250200é";
test=input(var,14.4);
run;

Cela marche mais je ne suis pas sur que ce soit cela qu'on attende en sortie, toujours à cause de ce "é" !!!

[steelspirit]

Et pour le "é" à la fin de la chaine ???j'en fais quoi ? car c'est celui la qui contient le signe !!!

A mon avis laisse le tomber pour l'instant. Parceque admettons que é c'est le signe positif, le négatif c'est quoi alors ???

donc déja fait plutot 14.4 et essaie de demander à ton collègue qui t'a envoyé le mail ce qu'on en fait du é.

[bahraoui]

Il faudra demnder s'il faut multiplier par -1 si la chapine se termine par "é"!!
Il est codé comment un nombre positif?

[pierre24]

le "é" est utlise que dans un contexte MVS apparement. Si je tiens compte de ce que tu dis, je pense que ca va erroner ma donnée ! Le fait qu'il y est un "é" en fin , ne justifie pas si le signe est + ou - !

[steelspirit]

c'est pour ça que je dis qu'a mon avis il faut pas en tenir compte surtout si c'est spécifique à MVS !

[pierre24]

Et alors du coup , comment fait on pour savoir si nous avons a faire à un signe positif ou négatif si l'on ne s'occupe plus du "é" ?