From: e p chandler on 11 Jun 2010 02:22 "rfengineer55" <rfengineer55(a)aol.com> wrote in message news:251de982-07fc-4df0-8a32-2c7b8ff5f1d3(a)q12g2000yqj.googlegroups.com... On Jun 10, 11:47 pm, "e p chandler" <e...(a)juno.com> wrote: > "rfengineer55" <rfenginee...(a)aol.com> wrote in message > > news:f73f40db-1dde-4d45-8673-e807071e68cd(a)q12g2000yqj.googlegroups.com... > > > My Intel compiler is giving me the following error message for a > > project I'm working in: > > > Error 1 error #5503: Variable 'IREC' has not been assigned a label in > > this program unit. > > > I did a Google search to find a possible explanation, and had no luck. > > What in heck does this mean? > > > I can post the source cod listing here if you want it. This > > errorpopped up when compiling another of my legacy VAX VMS Fortran > > programs. > > It would be better to just post the minimum code fragment that produces > this > error. > > In a PRINT statement, the first argument is taken to be a Format specifier > or the statement label for a Format. > > PRINT *,'abc' > PRINT '(a)','abc' > PRINT 100,'abc' > 100 FORMAT(a) > > Could this be related to the deleted feature > > "Assigned FORMAT specifier" where you would > > ASSIGN F TO 606 > > PRINT F,'abc' > > where 606 is a FORMAT statement? > > A google search shows this error message where the program code > > is > > PRINT A > > Now I do make this mistake myself sometimes when I want to display the > value > of A and I forget that I am not programming in BASIC where > > PRINT A is perfectly legal. > > but > > PRINT *,A is Fortran. No, the error is not happening with print statements. Here is the line in te code where the Intel compiler zeros in on - WRITE ( UNFDAT,IREC ) FREQ, SIG(II), +D1( JJ ), UMVM(II,JJ), D2( JJ ), BMVM(II,JJ) IREC is the variavle that the compiler says is not assigned to a label. ----> OK. Look at the WRITE statement IREC is a format sepcifier. The format specifier can be a number of things. a literal integer * (list directed format) a literal string containing a format expression an integer variable containing an integer which is the statement label of a format statement an integer variable which is assigned an integer value which is the statement label of a format statement a character variable which contains a format expression back in the days before character variables existed it was also possible to stuff character (Hollerith) data into integer,real or logical (array) variables. IIRC these could be used to hold format expressions. This is an odd message because it happens at COMPILE time whereas the value of IREC may vary at RUN time. Look at this console window session (Win32): Microsoft Windows [Version 6.0.6002] Copyright (c) 2006 Microsoft Corporation. All rights reserved. C:\Users\epc\temp>type foo.f90 i=998 write(*,i) 'hello' assign 999 to i write(*,i) 'world' 998 format(1x,a,' 998') 999 format(1x,a,' 999') end C:\Users\epc\temp>g95 foo.f90 C:\Users\epc\temp>a hello 998 world 999 C:\Users\epc\temp> >I would be happy to drop my source off at an FTP drop box. I asked >about that in the beginning, which is why I ended up posting the whole >source here. I have no I dea where to post it.Maybe one of the members >here has a personal FTP server we could use temporarily. Do you have some IT support at your academic institution that could help you? Some universities do provide their students/staff/faculty with web space. Or you could e-mail an archive out on request. --- Elliot
From: e p chandler on 11 Jun 2010 02:35 "glen herrmannsfeldt" <gah(a)ugcs.caltech.edu> wrote in message news:husjfd$olv$1(a)speranza.aioe.org... > rfengineer55 <rfengineer55(a)aol.com> wrote: > (snip) > >> No, the error is not happening with print statements. Here is the line >> in te code where the Intel compiler zeros in on - > >> WRITE ( UNFDAT,IREC ) FREQ, SIG(II), >> +D1( JJ ), UMVM(II,JJ), D2( JJ ), BMVM(II,JJ) > >> IREC is the variavle that the compiler says is not >> assigned to a label. > > The IBM form of unformatted direct access I/O looks like: > > WRITE ( UNFDAT'IREC ) FREQ, SIG(II), > +D1( JJ ), UMVM(II,JJ), D2( JJ ), BMVM(II,JJ) > > Someone might have missed that apostrophe and replaced > it with a comma. > > The name IREC looks like a record number, not an ASSIGNed > format label. The more modern form is: > > WRITE ( UNFDAT,REC=IREC ) FREQ, SIG(II), > +D1( JJ ), UMVM(II,JJ), D2( JJ ), BMVM(II,JJ) > > -- glen
From: e p chandler on 11 Jun 2010 02:38 "glen herrmannsfeldt" <gah(a)ugcs.caltech.edu> wrote in message news:husjfd$olv$1(a)speranza.aioe.org... > rfengineer55 <rfengineer55(a)aol.com> wrote: > (snip) > >> No, the error is not happening with print statements. Here is the line >> in te code where the Intel compiler zeros in on - > >> WRITE ( UNFDAT,IREC ) FREQ, SIG(II), >> +D1( JJ ), UMVM(II,JJ), D2( JJ ), BMVM(II,JJ) > >> IREC is the variavle that the compiler says is not >> assigned to a label. > > The IBM form of unformatted direct access I/O looks like: > > WRITE ( UNFDAT'IREC ) FREQ, SIG(II), > +D1( JJ ), UMVM(II,JJ), D2( JJ ), BMVM(II,JJ) > > Someone might have missed that apostrophe and replaced > it with a comma. > > The name IREC looks like a record number, not an ASSIGNed > format label. The more modern form is: > > WRITE ( UNFDAT,REC=IREC ) FREQ, SIG(II), > +D1( JJ ), UMVM(II,JJ), D2( JJ ), BMVM(II,JJ) > > -- glen I ignored the NAME of the variable which does suggest it is a record number (see other post). IIRC the original program ran on VMS and used RMS (indexed) files. I don't know how the OP has converted from indexed to sequential access (if only this was a COBOL program....).
From: dpb on 11 Jun 2010 09:23 e p chandler wrote: > "rfengineer55" <rfengineer55(a)aol.com> wrote in message > news:251de982-07fc-4df0-8a32-2c7b8ff5f1d3(a)q12g2000yqj.googlegroups.com... > On Jun 10, 11:47 pm, "e p chandler" <e...(a)juno.com> wrote: >> "rfengineer55" <rfenginee...(a)aol.com> wrote in message >> news:f73f40db-1dde-4d45-8673-e807071e68cd(a)q12g2000yqj.googlegroups.com... .... .... > No, the error is not happening with print statements. Here is the line > in te code where the Intel compiler zeros in on - > > WRITE ( UNFDAT,IREC ) FREQ, SIG(II), > +D1( JJ ), UMVM(II,JJ), D2( JJ ), BMVM(II,JJ) > > IREC is the variavle that the compiler says is not assigned to a > label. > > ----> OK. Look at the WRITE statement IREC is a format specifier. The > format specifier can be a number of things. Yes, most specifically, a label to a FORMAT string. .... > Look at this console window session (Win32): > .... > C:\Users\epc\temp>type foo.f90 > i=998 > write(*,i) 'hello' > assign 999 to i > write(*,i) 'world' > 998 format(1x,a,' 998') > 999 format(1x,a,' 999') > end .... Or more to the point, the following programette generates the error in CVF... program nolabel integer:: irec real:: anyvar irec = 1 anyvar = 3.14 open(11, file='anyfilename') write(11,i) anyvar end As noted elsewhere, the program used ISAM which is built into VAX OS and FORTRANM knew how to handle it. AFAIK, CVF and Intel Fortran extensions don't include ISAM files as part of the VAX/DEC-compatible extensions. You've got (again as somebody else already noted) convert from an ISAM file to another format such as sequential but to do so you'll have to figure out how to read the right data at the right time into the right variables. I'll reiterate my previous (and that of at least one other poster) advice to chill, slow down and think this through in a logical and ordered manner instead of just flailing around and throwing a tantrum when it doesn't "just work". Consider the task for what it really instead of what you wish it were; you've tackled moving an old OS-specific piece of code using a compiler that took advantage of the unique features of the machine and OS, some of which features were utilized by the authors of the code you're attempting to use. To move that to another OS which doesn't support some of those specific features (ISAM in this case, specifically) and a compiler which, while it has some syntax extensions to Standard Fortran that were also present in the DEC/VAX compiler, doesn't completely emulate that former compiler on a system that doesn't have all the facilities by which to do so will require working around that lack. Doing that successfully won't happen just by throwing the code at the compiler and futzing around w/ a few options switches; it'll require actually understanding what the file structure of the input file is and modifying the code to handle it. --
From: rfengineer55 on 11 Jun 2010 09:38
On Jun 11, 2:22 am, "e p chandler" <e...(a)juno.com> wrote: > "rfengineer55" <rfenginee...(a)aol.com> wrote in message > > news:251de982-07fc-4df0-8a32-2c7b8ff5f1d3(a)q12g2000yqj.googlegroups.com... > On Jun 10, 11:47 pm, "e p chandler" <e...(a)juno.com> wrote: > > > > > > > "rfengineer55" <rfenginee...(a)aol.com> wrote in message > > >news:f73f40db-1dde-4d45-8673-e807071e68cd(a)q12g2000yqj.googlegroups.com.... > > > > My Intel compiler is giving me the following error message for a > > > project I'm working in: > > > > Error 1 error #5503: Variable 'IREC' has not been assigned a label in > > > this program unit. > > > > I did a Google search to find a possible explanation, and had no luck.. > > > What in heck does this mean? > > > > I can post the source cod listing here if you want it. This > > > errorpopped up when compiling another of my legacy VAX VMS Fortran > > > programs. > > > It would be better to just post the minimum code fragment that produces > > this > > error. > > > In a PRINT statement, the first argument is taken to be a Format specifier > > or the statement label for a Format. > > > PRINT *,'abc' > > PRINT '(a)','abc' > > PRINT 100,'abc' > > 100 FORMAT(a) > > > Could this be related to the deleted feature > > > "Assigned FORMAT specifier" where you would > > > ASSIGN F TO 606 > > > PRINT F,'abc' > > > where 606 is a FORMAT statement? > > > A google search shows this error message where the program code > > > is > > > PRINT A > > > Now I do make this mistake myself sometimes when I want to display the > > value > > of A and I forget that I am not programming in BASIC where > > > PRINT A is perfectly legal. > > > but > > > PRINT *,A is Fortran. > > No, the error is not happening with print statements. Here is the line > in te code where the Intel compiler zeros in on - > > WRITE ( UNFDAT,IREC ) FREQ, SIG(II), > +D1( JJ ), UMVM(II,JJ), D2( JJ ), BMVM(II,JJ) > > IREC is the variavle that the compiler says is not assigned to a > label. > > ----> OK. Look at the WRITE statement IREC is a format sepcifier. The format > specifier can be a number of things. > > a literal integer > * (list directed format) > a literal string containing a format expression > an integer variable containing an integer which is the statement label of a > format statement > an integer variable which is assigned an integer value which is the > statement label of a format statement > a character variable which contains a format expression > > back in the days before character variables existed it was also possible to > stuff character (Hollerith) data into integer,real or logical (array) > variables. IIRC these could be used to hold format expressions. > > This is an odd message because it happens at COMPILE time whereas the value > of IREC may vary at RUN time. > > Look at this console window session (Win32): > > Microsoft Windows [Version 6.0.6002] > Copyright (c) 2006 Microsoft Corporation. All rights reserved. > > C:\Users\epc\temp>type foo.f90 > i=998 > write(*,i) 'hello' > assign 999 to i > write(*,i) 'world' > 998 format(1x,a,' 998') > 999 format(1x,a,' 999') > end > > C:\Users\epc\temp>g95 foo.f90 > > C:\Users\epc\temp>a > hello 998 > world 999 > > C:\Users\epc\temp> > > >I would be happy to drop my source off at an FTP drop box. I asked > >about that in the beginning, which is why I ended up posting the whole > >source here. I have no I dea where to post it.Maybe one of the members > >here has a personal FTP server we could use temporarily. > > Do you have some IT support at your academic institution that could help > you? > Some universities do provide their students/staff/faculty with web space. > > Or you could e-mail an archive out on request. > > --- Elliot- Hide quoted text - > > - Show quoted text - IT department here is quite specialied, and they do very little programming. The Comp Sci departmentis pretty good, but they have a very full plate given the state funding situation. I've writen an instructor a few times with things that Ijust don't know how to solve, and he's learned that if he gives me a few days, I figure it out for myself :-) There is both a good and bad side to be highly motivated :- D The IT department did suggest that I need to find a good newsgroup on the net, so here I am :-) Jeff |