From: e p chandler on
"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

"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

"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
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
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