Name list and Entry Points

I have some legacy programs that I am using to test ftn95. I'm having trouble getting the combination of subroutine entry points and Namelist data inputs working. I get a runtime error 112.

Below is a simple test program that generates the error. If I use subroutines instead of entry points, it works. I am far from an experienced programmer and would like to know what the issue is. Any insight would be appreciated - i'm sure it's something silly on my part.

Thanks

  program test
  include 'all.inc'
  namelist /STEP/ D1

  open(1, file='six.at2')
  rewind (1)
  read (1, nml=STEP)
  print*, d1
  call printsubinit
  call myprint
  print*,d1
  end program test

  subroutine myprint
  include 'all.inc'
  namelist /prt/ xy
  print*, \'test output\'
  return

cc end

  entry printsubinit

cc subroutine printsubinit cc include 'all.inc' cc namelist /prt/ xy print*,'herehere' rewind (1) print*,'hereherehere' read (1, nml=prt) print*,'999',5d1 print,xy return end

  COMMON /ALL/ d1,xy   !include file

&STEP !DATA FILE D1=.0025 d1=9. /

&prt xy=120. /

I don't have time to check this out at the moment but if at all possible you should avoid entry points in the code.

'hgratt':

Please note that NAMELIST and ENTRY are now used infrequently, and the compiler may still have unreported/not-yet-fixed bugs in how it handles these features of the language. See, for example, the post https://forums.silverfrost.com/Forum/Topic/3332 . The bug reported there is still present in the 8.51 compiler.

In some respects I have been lucky, as the first compilers I used did not support either NAMELIST or ENTRY, and I’ve therefore not become hooked on either. The code that *hgratt *posted and described (incidentally, it is a good idea to tag it with ‘code’ so it stands out) shows how ENTRY is used instead of 2 separate subroutines simply to avoid making declarations twice, as there isn’t any shared code. Personally, I would prefer the two subroutines usage, as there are several ways round the lengthy declaration of variables, including: Using IMPLICIT type Using COMMON Using INCLUDE Using MODULEs Using a subprogram parameter and using IF inside the subprogram Some of these won’t appeal to everyone, but ENTRY is not actually one of those constructs that are difficult to do without.

As far as NAMELIST goes, it does require that the user has some idea of the variable names used inside the program, which is obvious if one is programming for oneself, but far from obvious if one is programming for others. Indeed, NAMELIST probably means that the program comes with a hefty user manual defining those names. Using a Windows type of interface through the use of (say) ClearWin+ probably means that NAMELIST loses some of its purpose or importance.

Nevertheless, it is always an irritation that something that used to work no longer does so in the interests of 'progress', and especially with Fortran, as one of its strengths is that it handles legacy code!

Eddie

Eddie, your comments are quite apt, but note that the test code also uses a COMMON block to enable some variables to be shared. The presence of COMMON makes it more difficult to use some of the alternatives that you suggested, especially when the same block may have different member names in different declarations of the block.

Thanks for the replies. A couple of comments:

1. I'm aware that use of Namelist and Entry points are considered to be a 'faux pas' in the age of structured programming. I was just hoping that legacy programs would compile and run with minimal tinkering.

2. The test program did run correctly if I replaced the entry point construct with the appropriate initialization subroutine constructs (the current commented out code). I guess this appears to be the minimum effort mods that need to be made.

Anyway, at this point from the responses, it appears to be a possible compiler issue. Anymore additional insight or conclusions would still be appreciated.

Thanks, Harvey

Mecej4 - the options were a short list. I was talking about using COMMON to shorten the repeat declaration of variables in the multiple SUBROUTINE approach, not that it was something the original post omitted.

If you need to re-write huge chunks of legacy code to get it to run, then one major advantage of Fortran, which is that it does compile legacy code with minimal rewriting is lost. That was all.

Eddie