[Fortran 77] Illegal unit member

Bonjour tout le monde,
Je suis malheureusement contraint de vous faire part de l'acte II des "mysterieuses et fabuleuses peripeties de userB au pays Fortran"

Je continue mon petit bonhomme de chemin dans ce monde etrange peuplé d'etiquettes, de labels et de bien d'autres choses.

Cette fois c'est un veritable mystere ( enfin au vue de mes maigres connaissances ) qui s'offre a moi.
Treve de blabla, place au code.
Voici le message d'erreur que j'ai lors de l'execution

Code:

---

1 2 3 4 5 6 7 8

C:\f\G77>TESTv1.exe open: illegal unit number apparent state: unit 10 named inputpgm last format: list io lately reading sequential formatted external IO   abnormal program termination

---

Cette fois, je me suis pas laissé demonté et j ai suivi les conseils de maitre daZumba.
De ce que je comprend qd le program veut ouvrir mon unit numero 10 et bien .... et bien il ne l a trouve pas pour des raisons X ( jusque la ai je raison ? )
Il apparait que l unit 10 nommé inputpgm ne soit pas disponible.

Bon maintenant le probleme c'est que j ai bien un fichier inputpgm qui stock ceci :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

COD inputarb.001 IDC inputcnd.001 INI inipotrs.001 0 86400 I CPC VGN inputprs.001 5 7 I POT PTS inputpot.001 1 4 6 O POT PTS temps1.001 1 2 3 4 5 6 7 O FLU PTS temps2.001 2 3 4 5 6 7 

---

note : je ne remarque que maintenant le caractere en derniere ligne

donc on remarque qu'inputpgm existe bien et qu il stock des information.
Maintenant le code de l'unit 10 :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

OPEN (UNIT=10,FILE=FICOM) NLHEAD=4 REWIND (10) READ (10,1002) ARC,FIARC READ (10,1002) CND,FICND READ (10,1002,ERR=2) INI,FINICP GOTO 3 2 NLHEAD=3 3 REWIND(10) DO 6,I = 1, NLHEAD-1 6 READ(10,*) READ (10,*,ERR=4) T0,TFINAL,T0GRA,DTGRA 4 CLOSE (10) CALL LITARC(NMAX,ARC,FIARC,NPT,IFIS)

---

note 2 : FICOM est une variable de type character qui stocke a l'initialisation le nom du fichier qui contiendra les variables de commandes ( donc ici inputpgm )

Voila, je pense avoir fait le tour du probleme, si une ame charitable voulait bien eclairer ma lanterne je lui en serait reconnaissant:)

Je suis loin d'avoir les connaissances de maître DaZumba... mais ce que je comprends c'est que tu tentes d'utiliser l'unité 10 alors que ce n'est pas permis. Est-ce que tu es sûr que tu n'as pas utilisé cette même unité pour ouvrir un autre fichier?

Citation:

---

Envoyé par userB

De ce que je comprend qd le program veut ouvrir mon unit numero 10 et bien .... et bien il ne l a trouve pas pour des raisons X ( jusque la ai je raison ? )
Il apparait que l unit 10 nommé inputpgm ne soit pas disponible.

---

Non, si le fichier n'etait pas disponible, il renverrait un 'unexpected EOF' ou un truc comme cela. Ici, il dit que 10 n'est pas un numero d'unite legal. Cela me surprend. La plupart des compilateurs reservent les unites 0, 5 et 6 et se plaignent lorsque le numero d'unite est negatif ou plus grand que 99 (typiquement). 10 ne devrait pas poser de probleme... Tu utilises bien 10, n'est-ce pas? Tu n'ouvres pas un fichier sur l'unite 10 alors qu'un autre est encore associe a cette unite?
Sinon, ton code est etrange. Pourquoi rewind()-tu le fichier - tu le lis deux fois de deux facons differentes, ce qui est inattendu. Egalement, evites les goto et ferme les boucle do par un enddo plutot qu'indiquer un label de fin. Cela facilite grandement la lecture...

Citation:

---

Envoyé par YOY205

Est-ce que tu es sûr que tu n'as pas utilisé cette même unité pour ouvrir un autre fichier?

---

Oui, c'est une bonne hypothese, mais en testant vite fait avec quelques compilateurs, aucun ne cree d'echec lorsqu'on associe deux fichiers a la meme unite... Le dernier fichier ouvert ecrase les precedents, il semblerait.

ca ne pourrait pas etre l unite liee a l entree standard ou a la sortie standard?

j avais personnellement eu des problemes avec cette unitee la aussi sur le ifort (intel fortran) a une epoque. En passant au dela de 20 ca change ou pas?

Je ne me souviens pas avoir rencontré de compilateurs utilisant d'autres unités que 5 et 6 pour les entrées et sorties standard (clavier et écran).
Quel compilateur utilises-tu d'ailleurs ?

Citation:

---

Envoyé par fafaro

Je ne me souviens pas avoir rencontré de compilateurs utilisant d'autres unités que 5 et 6 pour les entrées et sorties standard

---

Moi non plus (c'est peut etre meme une exigence de la norme du langage). En tout cas, je ne vois pas ce que l'unite 10 peut avoir de special...

Citation:

---

Envoyé par fafaro

Quel compilateur utilises-tu d'ailleurs ?

---

Vu la facon dont les erreurs sont rapportees (style libg2c), je dirais que c'est g77. Donc l'unite 10 n'a rien de special, a priori.

Bonjour tout le monde,
je suis attentivement cette discussion ( heu ... normal et encore heureux me diront certain ) et en parrellele j'essaie plusieurs choses.
Alors effectivement on open plusieurs fois dans le code l unit 10
au debut j ai pensé a un close oublié, et effectivement il manquait 2 close ( donc des open unit 10 se succedait ) mais l'erreur ne venait pas de la.
Ensuite j'ai essayé de passé des blocs ou l'unit 10 est traité en commentaire, histoire d'isoler l'endroit d'ou provient le message d'erreur:
>>encore un echec, les messages d'erreurs font crescendo au fur et a mesure de cette etape.

Donc j'en suis la, je continu d'essayer de debug ce module
Pour information il n'est pas de moi ( je ne suis meme pas un developpeur fortran) je fais un stage dans une treessss grande institut de recherche francaise et je dois entre autre reprendre ce module ( que personne n'a touché depuis tres longtemps )
Enfin bref, si vous avez besoin de certains details sur le code n'hesitait pas a demander ^^

re tout le monde,
Bon je continu cette seance douloureuse de debug.
A l'ordre du jour :
- j ai trouvé dans les meandres du code un:

Code:

---

(open unit = 10, FILE = 'resultaj')

---

Donc comme vous l'aviez presenti il y avait bien une unit 10 utilisé pour un autre fichier, je l ai donc changé par un classique ( mais neanmoins efficace ) unit = 51
Cependant le sempiternel message d'erreur persiste :

Code:

---

1 2 3 4 5 6 7 8

C:\f\G77>test10v8.exe open: illegal unit number apparent state: unit 10 named inputpgm last format: list io lately reading sequential formatted external IO   abnormal program termination

---

- J'ai tenté bien naivement de changer tous les %10% par une valeur arbitraire lambda, bien evidement ca n'a pas fonctionné.

J'en suis la, et presque a court d'idée, si vous avez d'autre idée, ou si vous desirez avoir une idée plus claire du code je suis a votre entiere disposition

Cordialement, userB perdu au pay Fortran

Citation:

---

Envoyé par userB

Code:

---

(open unit = 10, FILE = 'resultaj')

---

---

J'imagine que tu voulais ecrire

Code:

---

open(unit = 10, FILE = 'resultaj')

---

Citation:

---

Envoyé par userB

Donc comme vous l'aviez presenti il y avait bien une unit 10 utilisé pour un autre fichier, je l ai donc changé par un classique ( mais neanmoins efficace ) unit = 51

---

Comme je l'indique dans le message 4, associer plusieurs fichiers a la meme unite ne produit pas le comportement que tu observes. Ceci dit, il est bon de corriger ces defauts en faisant un close(10) avant de refaire un open(unit=10, ...).

Ton erreur est franchement deconcertante. Ce message signifie que open() recoit une unite qui est negative, reservee par la runtime library, ou plus grande que la limite autorisee (99 la plupart du temps). Or 10 n'est pas negatif, pas reserve et plus petit que 99 (jusqu'a preuve du contraire!). Tu es sur que ce n'est pas ecrit 100 par erreur, n'est-ce pas?
Essaie

Code:

---

1 2 3 4 5

integer ios ... open(unit=10, file='myfile.txt', iostat=ios) print *, ios

---

En nous donnant le compilateur que tu utilises et la valeur de ios, on aura peut-etre plus d'infos (mais j'en doute)...

Bonjour tout le monde, je tiens a m'excuser pour ce silence radio alors que vous essayez tous de m'aider, mais j'ai eu des soucis assez long avec internet depuis mon poste.
Enfin.
Bon j'ai essayé via la methode de maitre daZumba de voir la valeur de iostat dans un premier temps, et d'isoler de le block ou l'erreur survient dans un second temps ( via un jeu de print )
a l'execution voila ce que cela donne :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

C:\f\G77>testprintv4.exe 1 0 XXX 2 0 XXX TESTPRRINT1 open: illegal unit number apparent state: unit 10 named inputpgm last format: list io lately reading sequential formatted external IO   abnormal program termination

---

En effet, et comme je pense vous l'avoir dit plus haut, il y a 4 ouverture de l unit 10 avec comme fichier ficom ( qui designe inputpgm)
du coup a chaque ouverture et conformement aux instruction de maitre daZumba j'avais qq chose de la forme :

Code:

---

1 2 3 4 5

OPEN (UNIT=10,FILE=FICOM, iostat = ios) print *, '2' // 1 ou 2 ou 3 ou 4 print *,ios print *, 'XXX'

---

Du coup on note que le probleme est entre l'ouverture numero 2 et l'ouverture numero 3, et aussi apres le print 'TESTPRRINT1' donc voici le code source de ce block:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62

C lecture de la ligne de commande NL de FICOM OPEN (UNIT=10,FILE=FICOM, iostat = ios) print *, '2' print *,ios print *, 'XXX' 10 NI = 0 REWIND(10) DO 20, I=1,NL 20 READ (10,*) READ (10,1001,END=80) ES,VAR,TYPE,FI NL = NL+1 C exclue certaines lignes: on incremente le nombre de lignes C si la commande est suivie d'une liste d'identificateurs IF((ES.NE.'I').OR.(TYPE.EQ.'POL').OR.(VAR.EQ.'CPC'))THEN READ (10,*,ERR=10,END=80) IBIDON NL = NL+1 GOTO 10 END IF print *,'TESTPRRINT1' //ce print est correctement affiché C cas ou VAR donne des entrees ('POT' ou 'FLU') a partir d'un fichier C recherche du nombre de points cites sur la ligne et lecture 30 NI = NI+1 READ (10,*,ERR=50,IOSTAT=IEOF,END=50) (IDT(I),I=INUM+1,INUM+NI) REWIND(10) DO 40, I=1,NL 40 READ (10,*) GOTO 30 50 NI=NI-1 IF (NI .NE. 0) GOTO 70 C cas ou la liste est vide , pas encore developpe C recalculer NI,remplir IDT() 60 CONTINUE print *,'TESTPRRINT2' // ce print par contre non, le programme plante avant C ouvre le fichier d'indice NF C et lit eventuellement des parametres sur la 1ere ligne 70 NF = NF + 1 OPEN (UNIT=100+NF,FILE=FI) TYPEIN(NF) = TYPE IF (TYPE .EQ. 'STP') THEN READ(100+NF,*) (PARAIN(NF,I),I=3,4) END IF print *,'TESTPRRINT3' C calcul des indices de position des points pour les causalites IF (VAR.EQ.'FLU') THEN DO 73, I=1,NI 73 IFLU(NPFLU+I)=INUM+I NPFLU=NPFLU +NI ELSE IF (VAR.EQ.'POT') THEN DO 75, I=1,NI 75 IPOT(NPPOT+I)=INUM+I NPPOT=NPPOT +NI END IF print *,'TESTPRRINT4' INUM = INUM + NI LASTIN(NF) = INUM C ligne suivante ou fin de lecture IF (IEOF .EQ. -1) GOTO 80 IF (NI .NE. 0) NL = NL+1 GOTO 10 80 CONTINUE print *, 'TESTTEST' // je laisse le reste mais je ne pense pas que ce code interfere ou est une incidence avec le probleme, mais sait on jamais

---

Alors voila ou j'en suis, je ne vois pas comment c'est 3 malheureuses lignes de codes separant mes 2 print puissent faire planter le programme .... si vous avez des idées/remarqué une erreur ... je suis plus que prenneur.
En vous remerciant
Votre devoué userB

Bon j'ai trouvé une nouvelle erreur:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

60 CONTINUE print *,'TESTPRRINT2' C ouvre le fichier d'indice NF C et lit eventuellement des parametres sur la 1ere ligne 70 NF = NF + 1 print *,NF OPEN (UNIT=100 + NF,FILE=FI) print *,'GOTO70' TYPEIN(NF) = TYPE IF (TYPE .EQ. 'STP') THEN READ(100+NF,*) (PARAIN(NF,I),I=3,4) END IF print *,'TESTPRRINT3'

---

etant donné que la variable NF == 1 dans le cas present nous etions dans le cas ou l unit number n'etait pas valable et donc ca plantait ( mais j'ai pas l impression que ca soit la mm erreur que tout a l heure... enfin bon)
J ai changé le + en - mais maintenant ca me fait des conflits avec l'unit 99 qui existe plus loin.
Je commence a soupsonner la validité du jeu de test que l on m a remis, bien plus que la qualité du code ( qui je le rappelle date d'il y a plus de 15 ans )

Citation:

---

Envoyé par userB

Alors voila ou j'en suis, je ne vois pas comment c'est 3 malheureuses lignes de codes separant mes 2 print puissent faire planter le programme ....

---

Bon, on avance. On sait que le illegal unit number est du a la tentative d'ouverture d'un fichier a une unite superieure a 99. Le fait que le print ne se fasse pas est du a la bufferisation des ecritures: pour des raisons de performances, le compilateur s'arrange pour ordonner le moins d'impressions possibles (i.e. quand un tampon pre-defini est plein). Ici, ton programme se plante bien sur

Code:

---

1 2	OPEN (UNIT=100 + NF,FILE=FI)

---

et le print precedent n'a pas lieu.
Il faut donc que tu re-travailles ce code en regardant la plage de valeurs que peut prendre NF et choisir une gamme d'unites qui est libre et qui couvre cette plage de valeurs. Le code est en Fortran ancien style, avec beaucoup de goto, ce qui nuit a la comprehension du flux de logique. La lecture des fichiers se fait de facon incroyablement acrobatique, avec des rewind() partout. C'est le genre de code que seul l'auteur peut comprendre (et les commentaires n'aident pas - j'espere que tu as une documentation!).

malheureusement non, aucune documentation disponible, et l'auteur de ce module n'est plus dans cette unité de recherche depuis bien longtemps deja.
Par contre, ce que j'ai du mal a comprendre c'est que d'une execution a l'autre et juste en rajoutant quelques print * de ci de la, le message d'erreur en retour change oO
J'avoue que ca reste pour moi un mystere.
Exemple : au tout debut, lorsque je n'avais pas du tout touché au code le message d'erreur concernait l'unité 10.
Au fur et a mesure que je rajoute des print * ( chose qui a mon sens ne change rien a la logique de l'algorothyme ) le message d'erreur c'est peu a peu tranformé.
Et maintenant ce n'est plus l'unit 10 avec le fameux inputpgm qui pose probleme, mais cette declaration d'unit du a NF 8O.
J'avoue n'y rien comprendre, et plus je me plonge dans ce code plus je comprend pourquoi nos professeurs d'algo nous ont toujours formellement interdit l'interdiction des go to meme sur des plateformes le permettant !

Citation:

---

Envoyé par userB

Par contre, ce que j'ai du mal a comprendre c'est que d'une execution a l'autre et juste en rajoutant quelques print * de ci de la, le message d'erreur en retour change

---

C'est en general un signe de probleme dans la memoire, par exemple un depassement de tableau. Essaie de compiler ton programme avec l'option -fbounds-check si tu utilises g77 comme je le pense. Si un depassement de tableau est constate, le programme echouera.
(Si tu utilises ifc, l'option est -CB et pour pgf90 c'est -Mbounds).

Citation:

---

J'avoue n'y rien comprendre, et plus je me plonge dans ce code plus je comprend pourquoi nos professeurs d'algo nous ont toujours formellement interdit l'interdiction des go to meme sur des plateformes le permettant !

---

Il faut se souvenir qu'a l'epoque, le f77 ne comportait pas de boucle do while( ), qui est quand meme bien pratique...
Ainsi, l'auteur du programme avait utilise goto pour creer un do while:

Code:

---

1 2 3 4 5 6 7

10 NI = 0 ... IF((ES.NE.'I').OR.(TYPE.EQ.'POL').OR.(VAR.EQ.'CPC'))THEN ... GOTO 10 END IF

---

s'ecrirait de nos jours

Code:

---

1 2 3 4 5

do while( (es .ne. 'I') .or. (type .eq. 'POL') .or. (var .eq. 'CPC')) ni = 0 ... end do

---

Bon j'avoue ne rien y comprendre, mais l'executable marche .... et pourtant je n'ai rien modifié dans ce code ....
Je vais mettre tout ca sur le dos du vaudou !
Quoiqu'il en soit cela m aura permis de m'immerger dans la syntaxe de Fortran.
Je vous remercie en tout cas pour votre aide.
Votre devoué userB