ECAP bug

[gah4]

Well, I found an actual bug in ECAP, running it with gfortran.

Note the IF statement that goes to the CONTINUE at the end of the DO loop.  And I checked the 1130 Fortran manual to be sure that it isn't allowed.

There are a few others that I haven't verified aren't "extended range of the DO", and so legal.

  400 IF( NLZMS  ) 445, 445, 401                                        AC461300
  401 DO 445 N = 1, NEZIM                                               AC461310
      NR = IROWM( N )                                                   AC461320
      NC = ICOLM( N )                                                   AC461330
      DO 445 I = 1, NMAX                                                AC461340
      IF( I - NR ) 445, 410, 445                                        AC461350
  410 CURRL = FLM( N ) * EPHA( NC ) * OMZNV                             AC461360
      CURIM = -(FLM( N ) * E( NC )) * OMZNV                             AC461370
      IF( NINIT( I ) - K ) 421, 430, 421                                AC461380
  421 IF( NFIN( I ) - K ) 445, 440, 445                                 AC461390
  430 ASZRL  = ASZRL  + CURRL                                           AC461400
      ASZIM  = ASZIM  + CURIM                                           AC461410
      GO TO 445                                                         AC461420
  440 ASZRL  = ASZRL  - CURRL                                           AC461430
      ASZIM  = ASZIM  - CURIM                                           AC461440
  445 CONTINUE                                                          AC461450

[Tom Watson]

You can always go to the "continue" statement that terminates a do
loop. That's the reason the continue statement exists. The problem
happens if you are outside of the do loop and then go to the continue,
that isn't allowed.

In my fortran programming, I always used continue statements as it was
easier to think about it.

As for continue statements outside of do loops, you can go to them any
time you like.

Note that in this context, "go to" includes anything that branches, go
to, computed go to assigned goto, three statement if's, and go to's
that are the object of logical if's (the latter aren't supported on the
1130).

Gfortran likes to complain about three statement if's in general, as
they are in the "not recommended" list (there are other things as
well).

You might want to check the actual error message, gfortran usually has
very specific messages.

Good luck.
--
Tom Watson <t...@johana.com>

> --
> You received this message because you are subscribed to the Google
> Groups "IBM1130" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to ibm1130+u...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ibm1130/49408d39-78a4-4658-b3b8-61acc090efd6n%40googlegroups.com
> .

[gah4]

Yes.  The one shown is an IF statement right before the DO.

That one I found as it went into a loop until some memory error occurred.

In Fortran 66, "extended range of DO" is allowed, where you can go out,

not modify the DO variable or DO parameters, and go back in.

(Mostly it allows for internal subroutines based on assigned-goto.)

There are a few others that gfortran finds, and are not so obvious as the one above.

They might be legal "extended range", but I haven't traced them all the way through.

[gah4]

OK, I now have it running pretty much the way it is supposed to.  There are some features that are in the S/360 version but not this one.

Also, as I told Carl, the DC analysis programs have all the COMMON statements wrong (as in different from the rest). 

Copying the others over, and making  a few changes, and those are now working.

The main change needed is due to the use of integer constants for character EBCDIC values.

I put in Hollerith constants, mostly in BLOCK DATA, as the variables are in COMMON.

It might be that the 1130 Fortran doesn't have BLOCK DATA, though.

It is based on the ability to chain between programs, where COMMON variables stay.

As I don't have that, I instead write all the variables out, and then read them in to the next program.

And as I noted above, there are places where it branches into a DO loop.  Some might be legal

(in Fortran IV and 66) extended range of the DO, but at least one isn't.  So far, the rest seem to work.

[Eddy Quicksall]

Yea, like if you do that then what would the value of  I or N take on? Then how would the compiler know which loop to continue? I wonder what the DNA Fortran would do. I will try that sometime.

 

Eddy

--