[Fortran 77] Problème open/read

Version imprimable

Bonjour
J'ai récupéré un programme qui tournait sous HPUNIX et je doit le faire tourner sous Linux. Le programme ouvre un fichier et vient lire des valeurs dans celui.

l'ouverture du fichier :
Code:

1 2 3 4 5 6 7 OPEN ( UNIT=IUNIT, % FILE=AC_NOM_FICHIER, % ACCESS='SEQUENTIAL', % FORM='UNFORMATTED', % CONVERT='SWAP', % STATUS='OLD', % IOSTAT=IOS )
L'ouverture du fichier se passe très bien, j'ai IOS=0 en sortie.

Première lecture :
Code:

1 2 INTEGER*4 INFOS_ENREG(7) READ (IUNIT,IOSTAT=IOS) INFOS_ENREG(1), INFOS_ENREG(2)
La premère lecture se passe bien, j'ai IOS=0 en sortie.
Deuxième lecture

Code:

READ (IUNIT,IOSTAT=IOS) INFOS_ENREG(3), INFOS_ENREG(4)

La deuxième lecture pose problème, j'ai IOS=-1 en sortie.
Je ne comprends pas pourquoi.

Je n'ai jamais fais de FORTRAN avant, je compile avec gcc.
Si quelqu'un peut m'aider merci.

11/12/2008, 14h06
genteur slayer

déjà, si tu compile avec gcc, en fait il va appeler f2c (qui converti ton fichier fortran en C) puis appelé gcc pour compiler ce code... cette methode marche mais elle est vraiment très sale, je te conseille déjà d'utiliser gfortran (compilateur basé sur gcc mais qui ne fait pas de convertion de language donc plus propre)

ensuite est-tu sûr que ton fichier est bien propre en particulier en ce qui concerne le caractère de fin de ligne... j'ai des problème de ce genre entre des fichier windows/MAC/Unix qui ont des caractères de fin de ligne différents et donc cela met le bordèle à la lecture...

si ton code n'est pas du F77 mais au moins du fortran90, tu peux rajouter dans ton open un POSITION='rewind' forçant le pointeur de fichier à être à son début...

(à vérifié) mais il me semble que le ios=-1 signifie qu'il est arrivé à la fin du fichier... à chaque nouveau read, tu passe à la ligne suivante
11/12/2008, 17h05
bybby83

J'ai esseyé de compiler avec gfortran, mais j'ai toujours la même chose.
De plus, la première instruction que je lit n'est pas vraiment la première.
Mon fichier commence par :
00000008 00000001 00000017 00000008
Quand je fais un READ (IUNIT,IOSTAT=IOS) INFOS_ENREG(1), INFOS_ENREG(2)
j'ai INFOS_ENREG(1) = 23 = 17hex
et INFOS_ENREG(2) = 8, et ceux même en utilisant le POSITION='rewind'
INFOS_ENREG(1) et INFOS_ENREG(2) sont des INTEGER*4
Mon fichier est un fichier binaire, il n'y a pas de caractere de fin de ligne.
Merci de ton aide
11/12/2008, 19h42
Sylvain Bergeron
Citation:

Envoyé par bybby83

...Mon fichier commence par :
00000008 00000001 00000017 00000008
Quand je fais un READ (IUNIT,IOSTAT=IOS) INFOS_ENREG(1), INFOS_ENREG(2)
j'ai INFOS_ENREG(1) = 23 = 17hex
et INFOS_ENREG(2) = 8, et ceux même en utilisant le POSITION='rewind'
INFOS_ENREG(1) et INFOS_ENREG(2) sont des INTEGER*4
Mon fichier est un fichier binaire, il n'y a pas de caractere de fin de ligne...

Pour que ça soit clair, ton fichier n'est pas binaire, il est sequential unformatted. Le fichier n'est pas pure binaire au sens où il est structuré (j'exclus ici le fait qu'au sens strict, tout fichier informatique est binaire...).

Le problème auquel tu fais face est que cette structure n'est pas définie par le standard. Ce dernier défini la fonctionnalité, non l'implantation physique. En pratique, les fichiers sequential unformatted respectent souvent la structure suivante :
- Longueur du premier enregistrement
- Données (binaire) du premier enregistrement
- Longueur du premier enregistrement (encore)
- Longueur du deuxième enregistrement
- Données du deuxième enregistrement.
- ...
Toutes ces informations sont en binaire (par opposition à texte). La longueur peut représenter le nombre d'octets ou de mots ou de champs de 32 bits. En regardant l'extrait de fichier que tu fourni, on peut supposer que le premier enregistrement est :
- 00000008 (longueur des données en octets)
- 00000001 00000017 (données)
- 00000008 (longueur des données)
Ton programme devrait alors lire 1 dans INFOS_ENREG(1) et 23 dans INFOS_ENREG(2). S'il lit 23 et 8, c'est qu'il «saute» le 00000001. Il est plus probable à mon avis que ton programme considère que les longueurs sont codées en 64 bits. Il «voit» alors que le premier enregistrement a une longueur de 34 359 738 369. Il y a alors un EOF (ioStat=-1) à la lecture du 2ème enregistrement...

Tu devrais lire le manuel de ton compilateur pour t'assurer que l'interprétation est bonne et pour voir si une switche existe pour contourner le problème. Sinon ? Il te faudrait recréer le fichier dans un format compatible avec ton compilateur, ou le lire en vrai binaire (stream) pour le convertir. Il est parfois possible de contourner en lisant en binaire direct...

est-ce que tu sais comment est écrit le fichier que tu lit?

moi je fait des écriture sytle:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 program test integer L,H real(kind=8)temps L=10 H=15 temps=2.5d0 open ( unit = 11, & file = "toto.hex", & form = "unformatted", & access = "sequential", & action = "write", & position = "rewind", & status = "unknown", & iostat =ios) write (11) L, H, temps close(11) end program test
le fichier qui a été généré est de la forme:
Code:

1 2 3 10 00 00 00 0a 00 00 00 0f 00 00 00 00 00 00 00 00 00 00 04 40 10 00 00 00
je suis sous cygwin, avec gfortran et il semble que les octets sont "à l'envers":

10000000 0a000000 0f000000 0000000000000440 10000000

j'ai donc une séquence d'entrée et de sortis des données, mes deux entier et mon réél...

cela dit tu as peut-être un problème de format des données si ton prog attend 0a000000 et que tu lui donne 0000000a il risque de pas comprendre et d'interprèter de travers....

donc regarde bien comment a été écrit ton fichier d'entrée!

12/12/2008, 10h57
bybby83

Merci pour vos réponse
Mon fichier a été écrit en big-endian, et je le lis en big-endain, c'est grâce à l'option convert='SWAP'.
Mon fichier est écrit de la façon suivante :
1er mot = Type d'info
2 ième mot = longueur de la données en mot (x mots)
x mots = données
1er mot = type d'info
...
Pour l'instant je n'ai pas avancé, j'en suis toujours au même point

J'ai fait la même manipulation, j'ai créé un fichier avec dedans 10, 15 et 2.5. J'ai eu le même fichier
10 00 00 00 0a 00 00 00 0f 00 00 00 00 00 00 00 00
00 00 04 40 10 00 00 00.
Ensuite j'ai essayer de le relire et je suis retomber sur 10, 15 et 2.5.
J'ai inséré ce code dans le code principal qui lit l'autre fichier.

Par curiosité, j'ai exécuté ceci
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 L=10 H=15 temps=2.5d0 OPEN ( unit = 11, % file = "/lv001/thetis/toto2.hex", % form = "unformatted", % access = "sequential", % action = "read", % position = "rewind", % status = "old", % iostat =ios) write (11) L write (11) H write (11) temps close(11)
toto2.hex vaut :
04000000 00000000 0A000000 04000000 00000000 04000000 00000000 0F000000 00000000 08000000 00000000 00000000 00000440 08000000 00000000

Dans les deux cas, la relecture effectuée comme l'écriture se passe bien.

Je ne comprends pas pourquoi les fichiers sont différents.

12/12/2008, 14h01
genteur slayer

les fichiers sont différent car tu fait 3 write au lieu d'un seul dans le premier, cas soit trois enregistrements...

comme on peut le voir sur ton exemple:
le fichier toto2.hex
commence par
04000000 00000000 0A000000 04000000 00000000

tout comme dans ton problème: il donne la taille de l'enregistrement sur 8octets (au lieu de 4 dans l'autre cas....)
je trouve ça bizarre, pourquoi dans un cas cela écrit

04000000 0A000000 04000000

et dans l'autre il l'écrit avec une longueur en 64bits????

du coup j'adhere complètement à l'idée de sylvain: il cherche à lire la taille de tes données sur 64bits au lieu de 32 et du coup il arrive pas à trouvé les données qu'il a besoin et te revoie donc un End Of File à la lecture!!!

j'ai testé chez moi le fait de mettre trois write mais j'ai toujours mes longueurs sur 32bits

je ne vois qu'une solution: tu as une machine 64bits avec le compilo également 64bits et ton fichier a été écrit avec une machine 32bits... je me trompe???
12/12/2008, 17h09
bybby83

Tu dois avoir raison, je suis sur que le fichier a été créé sur une machine 32 bits. Et etant donné que je travaille sur une machine récente anvec un compilateur récent, ca doit être du 64 bits.
J'ai été voir sur le site de gnu, et il y a un topics disant d'utiliser la commande RECM='4' (record marker = 4 octets) dans les options du OPEN. Mais mon compilateur gfortran ne l'accepte pas.
15/12/2008, 10h47
genteur slayer

as-tu le moyen de réécrire ce fichier???

sinon il doit y avoir une option de compilation qui regle le truc ou bien une variable d'environement à changer etc...
17/12/2008, 20h10
bybby83

Je n'ai pas trouvé de variable d'environement ou d'option. J'ai contacter les développeurs de gfortran et ils m'ont conseillé de télécharger la nouvelle version de gfortran car la version que j'ai lit les fichier avec un marqueur de 64 bit.
J'espere qu'un fois la nouvelle version téléchargée, j'arriverai à lire le fichier sans problème
Merci pour votre aide
17/12/2008, 23h34
genteur slayer

ce n'est pas avec l'option "recl=" dans les read et write que tu regle la taille des marqueurs....???

sinon tu n'a pas moyen de réécrire ton fichier d'entrée avec un format compatible?
18/12/2008, 14h19
Sylvain Bergeron

Citation:

Envoyé par genteur slayer

ce n'est pas avec l'option "recl=" dans les read et write que tu regle la taille des marqueurs....???

Le recl= sert à définir la longueur des records des fichiers à accès direct et non la longueur des marqueurs dans les fichiers sequentials.
06/01/2009, 17h47
bybby83

Je viens d'essayer avec une nouvelle version de gfortran, et j'ai toujours le même problème.
Merci pour vos réponses qui m'ont permises d'avancer