Internal read behavior IVF

[salbruce]

I have found that one form of internal read that I used with CVF and DVF does not work the same IVF. Is there an alternate form for this statement that would return the integer 1?

Notes:
- I'm using IVF 11.1 update 3
- Windows Vista
- Have tried replacing the blanks in the string below with nuls, but that returns an error.

With the following code, CVF yielded NNODE=1 but IVF returns NNODE=10000000. I would like it to be interpreted as a 1.

Thanks in advance for your suggestions,
Bruce
------------------------

[plain]! TestInternalRead.f90
      CHARACTER*8 LABEL
      CHARACTER*1 NUL
      INTEGER NNODE
      
      OPEN (23,FILE='JUNK.TXT', STATUS='UNKNOWN')
      WRITE (23,*) 'Test internal read'
      
      NNODE=0
      LABEL='1       '
      
      READ (LABEL,'(I8)',ERR=3,END=3) NNODE  ! Internal read
      WRITE (23,*) 'No error from internal read.'
      WRITE (23,*) NNODE,'=NNODE'
      GOTO 2

3     WRITE (23,*) 'Error from internal read.'
      WRITE (23,*) NNODE,'=NNODE'

2     CLOSE (23,STATUS='KEEP')
      END
[/plain]

[Paul_Curtis]

READ (label(1:LEN_TRIM(label)),'(I)') nnode

[jparsly · Accepted solution]

Don't have IVF handy to try this at the moment, but what happens if you change the

(I8) to (BN,I8) ?

Looks like IVF default is BZ (treat blanks as zero). CVF default is BN (ignore imbedded and trailing blanks).

[salbruce]

This worked, thanks.
-Bruce

Quoting - jparsly

Don't have IVF handy to try this at the moment, but what happens if you change the

(I8) to (BN,I8) ?

Looks like IVF default is BZ (treat blanks as zero). CVF default is BN (ignore imbedded and trailing blanks).

[salbruce]

I agree that it looks like this should work, but the READ fails and NNODE stays at zero.
-Bruce

Quoting - Paul Curtis

READ (label(1:LEN_TRIM(label)),'(I)') nnode

[Steven_L_Intel1]

I tried this and it worked correctly in IVF 11.1 Update 3 - NNODE was 1. IVF and CVF have the same default of BN for internal reads, as dictated by the F77 standard.

Can anyone else reproduce the other behavior?

[salbruce]

Here are my compiler settings. Steve, what were your settings?
Thanks,
Bruce

[plain]/nologo /arch:IA32 /vms /module:"Release" /object:"Release" /libs:static /threads /c[/plain]

Quoting - Steve Lionel (Intel)

I tried this and it worked correctly in IVF 11.1 Update 3 - NNODE was 1. IVF and CVF have the same default of BN for internal reads, as dictated by the F77 standard.

Can anyone else reproduce the other behavior?

[Steven_L_Intel1]

Ah, /vms. Didn't think of that one. Remove /vms and you'll see the behavior you want. CVF behaved the same way with /vms. Here's what the documentation says:

Treatment of blanks in input

The vms option causes the defaults for the keyword BLANK in OPEN statements to become 'NULL' for an explicit OPEN and 'ZERO' for an implicit OPEN of an external or internal file.

This option is mainly for compatibility with VAX Fortran 77.

[salbruce]

Hmm... that puts me in a bind. I don't really want the /vms switch, but was forced to do that to correct the end-of-file behavior. See the topic "EOF handling in IVF vs. DVF"

Any suggestions on how to deal with those two problems simultaneously?

Thanks,
Bruce


Quoting - Steve Lionel (Intel)

Ah, /vms. Didn't think of that one. Remove /vms and you'll see the behavior you want. CVF behaved the same way with /vms. Here's what the documentation says:

Treatment of blanks in input

The vms option causes the defaults for the keyword BLANK in OPEN statements to become 'NULL' for an explicit OPEN and 'ZERO' for an implicit OPEN of an external or internal file.

This option is mainly for compatibility with VAX Fortran 77.

[Steven_L_Intel1]

Put BN at the beginning of your format.

[salbruce]

I can do that, but would rather dump the /vms switch. Any chance that the EOF behavior will be fixed so that I don't need the /vms?

I have internal reads sprinkled through 30 different projects, so it would be nice not to have to track them down and change each one.


Quoting - Steve Lionel (Intel)

Put BN at the beginning of your format.

[Steven_L_Intel1]

I do not expect that other issue to be fixed soon, though I have pinged the developers on it. However, I have to ask - how are you creating these input files with ENDFILE records in them?

Sorry, I don't know another workaround other than compiling only the files that read from this input file with /vms - the others can be compiled without /vms.

[salbruce]

OK, thanks.

The input files are being written by someone else's exe. That exe is in Delphi Pascal -- I don't know if that is default behavior when it writes a text file, but omitting the EOF mark might be another solution.

Quoting - Steve Lionel (Intel)

I do not expect that other issue to be fixed soon, though I have pinged the developers on it. However, I have to ask - how are you creating these input files with ENDFILE records in them?

Sorry, I don't know another workaround other than compiling only the files that read from this input file with /vms - the others can be compiled without /vms.