Re: Q: DCL IF / NESTED IF-THEN-ELSE - VMS

This is a discussion on Re: Q: DCL IF / NESTED IF-THEN-ELSE - VMS ; "Ken Robinson" wrote on 11/12/2007 10:48:25 AM: > On Nov 12, 2007 10:25 AM, wrote: > > > > > > > > > > "Ken Robinson" wrote on 11/12/2007 10:01:03 AM: > > > > > > > On ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Re: Q: DCL IF / NESTED IF-THEN-ELSE

  1. Re: Q: DCL IF / NESTED IF-THEN-ELSE

    "Ken Robinson" wrote on 11/12/2007 10:48:25 AM:

    > On Nov 12, 2007 10:25 AM, wrote:
    > >
    > >
    > >
    > >
    > > "Ken Robinson" wrote on 11/12/2007 10:01:03 AM:
    > >
    > >
    > > > On Nov 12, 2007 9:39 AM, wrote:
    > > > >
    > > > > Here is a DCL gosub routine to pick a description
    > > > > out of an element list. If it does not find
    > > > > a match in 1-5 is is supposed to set the LL
    > > > > index variable to zero and pick that one.
    > > > > Somehow, the statement to do that is not being
    > > > > executed. DCL_CHECK does not find any error.
    > > > >
    > > > > What am I missing?
    > > > >
    > > > > $FIND_TCODE: !Gosub
    > > > > $ LL=5
    > > > > $LOOPT:
    > > > > $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE)
    > > > > $ THEN
    > > > > $ LL=LL+1
    > > > > $ show sym ll
    > > > > $ IF LL .LE. 5 THEN GOTO LOOPT
    > > > > $ ELSE
    > > > > $ IF LL .GT. 5 THEN LL=0
    > > > > $ ENDIF
    > > > > $ show sym ll
    > > > > $ RDESC=F$ELEMENT(LL,",",TDESC)
    > > > > $ RETURN
    > > >
    > > > The "endif" is in the wrong place. Also, shouldn't "TDESC" be

    "TCODE"
    > > > in "$ RDESC=F$ELEMENT(LL,",",TDESC)"?

    > >
    > > Well, the code certainly behaves as if the endif is in the wrong

    place,
    > > but it isn't. I will try structured if-the-else for all the
    > > if-statements and I'm sure that will fix it, but I suspect I have
    > > uncovered an ambiguity due to backward compatibility allowing
    > > if-then-else to be:
    > >
    > > $if then
    > > $endif
    > >

    >
    > That syntax is illegal
    >
    >
    > > instead of forcing:
    > >
    > > $if
    > > $then
    > > $
    > > $endif
    > >
    > > I would surely like to know what the expected behavior is, and
    > > if this violates the syntax. Too bad Charlie retired.

    >
    > You original "if" block was (annotated by me)
    >
    > $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE)
    > $ THEN
    > $ LL=LL+1
    > $ show sym ll
    > $ IF LL .LE. 5 THEN GOTO LOOPT
    > $ ELSE ! this else goes with the original "IF" not the one above

    it
    > $ IF LL .GT. 5 THEN LL=0 ! this line will only get executed
    > when the original "if" is "false"
    > $ ENDIF
    >


    I simplified it to:

    $FIND_TCODE: !Gosub
    $ LL=5
    $LOOPT:
    $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE)
    $ THEN
    $ LL=LL+1
    $ show sym ll
    $ IF LL .GT. 5
    $ THEN
    $ LL=0
    $ ELSE
    $ GOTO LOOPT
    $ ENDIF
    $ ENDIF
    $ show sym ll
    $ RDESC=F$ELEMENT(LL,",",TDESC)
    $ RETURN

    It was redundent to check for ".GT. 5" and also
    ".LE. 5" for if not one then of course the other.

    The crux of the problem is that within an
    $IF
    $THEN
    $
    $
    $ELSE
    $
    $
    $ENDIF

    that
    $
    should be able to be the (valid) statement
    $IF then

    and that in the complex IF-THEN-ELSE the
    "$THEN"
    must be on it's own line to distinguish
    between the two forms.

    Probably if I had put a replacement statement
    before the $ELSE the parser would have recovered.

    It's better this way, however.

    -Norm

    > Ken
    >
    >
    >
    > >
    > > And no, TDESC should be TDESC. It matches the code in one
    > > element table and move the description from another
    > > element table, but that's not relevent and since I didn't
    > > include that part of the procedure, you can't know that.
    > >
    > >
    > >
    > > >
    > > > Try:
    > > >
    > > > $FIND_TCODE: !Gosub
    > > > $ LL=5
    > > > $LOOPT:
    > > > $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE)
    > > > $ THEN
    > > > $ LL=LL+1
    > > > $ show sym ll
    > > > $ IF LL .LE. 5 THEN GOTO LOOPT
    > > > $ endif
    > > > $ IF LL .GT. 5 THEN LL=0
    > > > $ show sym ll
    > > > $ RDESC=F$ELEMENT(LL,",",Tcode)
    > > > $ sho sym rdesc
    > > > $ RETURN
    > > >
    > > > Ken

    > >



  2. Re: Q: DCL IF / NESTED IF-THEN-ELSE

    norm.raphael@metso.com wrote:
    >
    >
    >
    >
    > "Ken Robinson" wrote on 11/12/2007 10:48:25 AM:
    >
    >> On Nov 12, 2007 10:25 AM, wrote:
    >> >
    >> >
    >> >
    >> >
    >> > "Ken Robinson" wrote on 11/12/2007 10:01:03 AM:
    >> >
    >> >
    >> > > On Nov 12, 2007 9:39 AM, wrote:
    >> > > >
    >> > > > Here is a DCL gosub routine to pick a description
    >> > > > out of an element list. If it does not find
    >> > > > a match in 1-5 is is supposed to set the LL
    >> > > > index variable to zero and pick that one.
    >> > > > Somehow, the statement to do that is not being
    >> > > > executed. DCL_CHECK does not find any error.
    >> > > >
    >> > > > What am I missing?
    >> > > >
    >> > > > $FIND_TCODE: !Gosub
    >> > > > $ LL=5
    >> > > > $LOOPT:
    >> > > > $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE)
    >> > > > $ THEN
    >> > > > $ LL=LL+1
    >> > > > $ show sym ll
    >> > > > $ IF LL .LE. 5 THEN GOTO LOOPT
    >> > > > $ ELSE
    >> > > > $ IF LL .GT. 5 THEN LL=0
    >> > > > $ ENDIF
    >> > > > $ show sym ll
    >> > > > $ RDESC=F$ELEMENT(LL,",",TDESC)
    >> > > > $ RETURN
    >> > >
    >> > > The "endif" is in the wrong place. Also, shouldn't "TDESC" be "TCODE"
    >> > > in "$ RDESC=F$ELEMENT(LL,",",TDESC)"?
    >> >
    >> > Well, the code certainly behaves as if the endif is in the wrong place,
    >> > but it isn't. I will try structured if-the-else for all the
    >> > if-statements and I'm sure that will fix it, but I suspect I have
    >> > uncovered an ambiguity due to backward compatibility allowing
    >> > if-then-else to be:
    >> >
    >> > $if then
    >> > $endif
    >> >

    >>
    >> That syntax is illegal
    >>
    >>
    >> > instead of forcing:
    >> >
    >> > $if
    >> > $then
    >> > $
    >> > $endif
    >> >
    >> > I would surely like to know what the expected behavior is, and
    >> > if this violates the syntax. Too bad Charlie retired.

    >>
    >> You original "if" block was (annotated by me)
    >>
    >> $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE)
    >> $ THEN
    >> $ LL=LL+1
    >> $ show sym ll
    >> $ IF LL .LE. 5 THEN GOTO LOOPT
    >> $ ELSE ! this else goes with the original "IF" not the one above it
    >> $ IF LL .GT. 5 THEN LL=0 ! this line will only get executed
    >> when the original "if" is "false"
    >> $ ENDIF
    >>

    >
    > I simplified it to:
    >
    > $FIND_TCODE: !Gosub
    > $ LL=5
    > $LOOPT:
    > $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE)
    > $ THEN
    > $ LL=LL+1
    > $ show sym ll
    > $ IF LL .GT. 5
    > $ THEN
    > $ LL=0
    > $ ELSE
    > $ GOTO LOOPT
    > $ ENDIF
    > $ ENDIF
    > $ show sym ll
    > $ RDESC=F$ELEMENT(LL,",",TDESC)
    > $ RETURN
    >
    > It was redundent to check for ".GT. 5" and also
    > ".LE. 5" for if not one then of course the other.
    >
    > The crux of the problem is that within an
    > $IF
    > $THEN
    > $
    > $
    > $ELSE
    > $
    > $
    > $ENDIF
    >
    > that
    > $
    > should be able to be the (valid) statement
    > $IF then
    >
    > and that in the complex IF-THEN-ELSE the
    > "$THEN"
    > must be on it's own line to distinguish
    > between the two forms.
    >
    > Probably if I had put a replacement statement
    > before the $ELSE the parser would have recovered.
    >
    > It's better this way, however.
    >
    > -Norm
    >
    >> Ken
    >>
    >>
    >>
    >> >
    >> > And no, TDESC should be TDESC. It matches the code in one
    >> > element table and move the description from another
    >> > element table, but that's not relevent and since I didn't
    >> > include that part of the procedure, you can't know that.
    >> >
    >> >
    >> >
    >> > >
    >> > > Try:
    >> > >
    >> > > $FIND_TCODE: !Gosub
    >> > > $ LL=5
    >> > > $LOOPT:
    >> > > $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE)
    >> > > $ THEN
    >> > > $ LL=LL+1
    >> > > $ show sym ll
    >> > > $ IF LL .LE. 5 THEN GOTO LOOPT
    >> > > $ endif
    >> > > $ IF LL .GT. 5 THEN LL=0
    >> > > $ show sym ll
    >> > > $ RDESC=F$ELEMENT(LL,",",Tcode)
    >> > > $ sho sym rdesc
    >> > > $ RETURN
    >> > >
    >> > > Ken
    >> >



    $IF then is a single line conditional.
    It does not involve or allow ELSE or ENDIF
    there is no $IF then else

    IF-then-else has to me multiple line.
    AND the number of endif statements have to balance the IF statements

  3. Re: Q: DCL IF / NESTED IF-THEN-ELSE

    norm.raphael@metso.com wrote:
    >
    >
    >
    >
    > "Ken Robinson" wrote on 11/12/2007 10:48:25 AM:
    >
    >> On Nov 12, 2007 10:25 AM, wrote:
    >> >
    >> >
    >> >
    >> >
    >> > "Ken Robinson" wrote on 11/12/2007 10:01:03 AM:
    >> >
    >> >
    >> > > On Nov 12, 2007 9:39 AM, wrote:
    >> > > >
    >> > > > Here is a DCL gosub routine to pick a description
    >> > > > out of an element list. If it does not find
    >> > > > a match in 1-5 is is supposed to set the LL
    >> > > > index variable to zero and pick that one.
    >> > > > Somehow, the statement to do that is not being
    >> > > > executed. DCL_CHECK does not find any error.
    >> > > >
    >> > > > What am I missing?
    >> > > >
    >> > > > $FIND_TCODE: !Gosub
    >> > > > $ LL=5
    >> > > > $LOOPT:
    >> > > > $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE)
    >> > > > $ THEN
    >> > > > $ LL=LL+1
    >> > > > $ show sym ll
    >> > > > $ IF LL .LE. 5 THEN GOTO LOOPT
    >> > > > $ ELSE
    >> > > > $ IF LL .GT. 5 THEN LL=0
    >> > > > $ ENDIF
    >> > > > $ show sym ll
    >> > > > $ RDESC=F$ELEMENT(LL,",",TDESC)
    >> > > > $ RETURN
    >> > >
    >> > > The "endif" is in the wrong place. Also, shouldn't "TDESC" be "TCODE"
    >> > > in "$ RDESC=F$ELEMENT(LL,",",TDESC)"?
    >> >
    >> > Well, the code certainly behaves as if the endif is in the wrong place,
    >> > but it isn't. I will try structured if-the-else for all the
    >> > if-statements and I'm sure that will fix it, but I suspect I have
    >> > uncovered an ambiguity due to backward compatibility allowing
    >> > if-then-else to be:
    >> >
    >> > $if then
    >> > $endif
    >> >

    >>
    >> That syntax is illegal
    >>
    >>
    >> > instead of forcing:
    >> >
    >> > $if
    >> > $then
    >> > $
    >> > $endif
    >> >
    >> > I would surely like to know what the expected behavior is, and
    >> > if this violates the syntax. Too bad Charlie retired.

    >>
    >> You original "if" block was (annotated by me)
    >>
    >> $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE)
    >> $ THEN
    >> $ LL=LL+1
    >> $ show sym ll
    >> $ IF LL .LE. 5 THEN GOTO LOOPT
    >> $ ELSE ! this else goes with the original "IF" not the one above it
    >> $ IF LL .GT. 5 THEN LL=0 ! this line will only get executed
    >> when the original "if" is "false"
    >> $ ENDIF
    >>

    >
    > I simplified it to:
    >
    > $FIND_TCODE: !Gosub
    > $ LL=5
    > $LOOPT:
    > $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE)
    > $ THEN
    > $ LL=LL+1
    > $ show sym ll
    > $ IF LL .GT. 5
    > $ THEN
    > $ LL=0
    > $ ELSE
    > $ GOTO LOOPT
    > $ ENDIF
    > $ ENDIF
    > $ show sym ll
    > $ RDESC=F$ELEMENT(LL,",",TDESC)
    > $ RETURN
    >
    > It was redundent to check for ".GT. 5" and also
    > ".LE. 5" for if not one then of course the other.
    >
    > The crux of the problem is that within an
    > $IF
    > $THEN
    > $
    > $
    > $ELSE
    > $
    > $
    > $ENDIF
    >
    > that
    > $
    > should be able to be the (valid) statement
    > $IF then
    >
    > and that in the complex IF-THEN-ELSE the
    > "$THEN"
    > must be on it's own line to distinguish
    > between the two forms.
    >
    > Probably if I had put a replacement statement
    > before the $ELSE the parser would have recovered.
    >
    > It's better this way, however.
    >
    > -Norm
    >
    >> Ken
    >>
    >>
    >>
    >> >
    >> > And no, TDESC should be TDESC. It matches the code in one
    >> > element table and move the description from another
    >> > element table, but that's not relevent and since I didn't
    >> > include that part of the procedure, you can't know that.
    >> >
    >> >
    >> >
    >> > >
    >> > > Try:
    >> > >
    >> > > $FIND_TCODE: !Gosub
    >> > > $ LL=5
    >> > > $LOOPT:
    >> > > $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE)
    >> > > $ THEN
    >> > > $ LL=LL+1
    >> > > $ show sym ll
    >> > > $ IF LL .LE. 5 THEN GOTO LOOPT
    >> > > $ endif
    >> > > $ IF LL .GT. 5 THEN LL=0
    >> > > $ show sym ll
    >> > > $ RDESC=F$ELEMENT(LL,",",Tcode)
    >> > > $ sho sym rdesc
    >> > > $ RETURN
    >> > >
    >> > > Ken
    >> >



    $IF then is a single line conditional.
    It does not involve or allow ELSE or ENDIF
    there is no $IF then else

    IF-then-else has to be multiple line.
    AND the number of endif statements have to balance the IF statements

  4. Re: Q: DCL IF / NESTED IF-THEN-ELSE

    On Nov 12, 10:42 am, norm.raph...@metso.com wrote:
    > "Ken Robinson" wrote on 11/12/2007 10:48:25 AM:
    > > On Nov 12, 2007 10:25 AM, wrote:

    >
    > > > "Ken Robinson" wrote on 11/12/2007 10:01:03 AM:

    >
    > > > > On Nov 12, 2007 9:39 AM, wrote:

    >
    > > > > > Here is a DCL gosub routine to pick a description
    > > > > > out of an element list. If it does not find
    > > > > > a match in 1-5 is is supposed to set the LL
    > > > > > index variable to zero and pick that one.
    > > > > > Somehow, the statement to do that is not being
    > > > > > executed. DCL_CHECK does not find any error.

    >
    > > > > > What am I missing?

    >
    > > > > > $FIND_TCODE: !Gosub
    > > > > > $ LL=5
    > > > > > $LOOPT:
    > > > > > $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE)
    > > > > > $ THEN
    > > > > > $ LL=LL+1
    > > > > > $ show sym ll
    > > > > > $ IF LL .LE. 5 THEN GOTO LOOPT
    > > > > > $ ELSE
    > > > > > $ IF LL .GT. 5 THEN LL=0
    > > > > > $ ENDIF
    > > > > > $ show sym ll
    > > > > > $ RDESC=F$ELEMENT(LL,",",TDESC)
    > > > > > $ RETURN

    >
    > > > > The "endif" is in the wrong place. Also, shouldn't "TDESC" be

    > "TCODE"
    > > > > in "$ RDESC=F$ELEMENT(LL,",",TDESC)"?

    >
    > > > Well, the code certainly behaves as if the endif is in the wrong

    > place,
    > > > but it isn't. I will try structured if-the-else for all the
    > > > if-statements and I'm sure that will fix it, but I suspect I have
    > > > uncovered an ambiguity due to backward compatibility allowing
    > > > if-then-else to be:

    >
    > > > $if then
    > > > $endif

    >
    > > That syntax is illegal

    >


    Yes, it is. In your original code the endif terminates the preceding
    if-then-else, not the one-liner if-then.

    > > > instead of forcing:

    >
    > > > $if
    > > > $then
    > > > $
    > > > $endif

    >


    And that's the way it's working.

    > > > I would surely like to know what the expected behavior is, and
    > > > if this violates the syntax. Too bad Charlie retired.

    >


    You've described the expected behavior.

    > > You original "if" block was (annotated by me)

    >
    > > $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE)
    > > $ THEN
    > > $ LL=LL+1
    > > $ show sym ll
    > > $ IF LL .LE. 5 THEN GOTO LOOPT
    > > $ ELSE ! this else goes with the original "IF" not the one above

    > it
    > > $ IF LL .GT. 5 THEN LL=0 ! this line will only get executed
    > > when the original "if" is "false"
    > > $ ENDIF

    >
    > I simplified it to:
    >
    > $FIND_TCODE: !Gosub
    > $ LL=5
    > $LOOPT:
    > $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE)
    > $ THEN
    > $ LL=LL+1
    > $ show sym ll
    > $ IF LL .GT. 5
    > $ THEN
    > $ LL=0
    > $ ELSE
    > $ GOTO LOOPT
    > $ ENDIF
    > $ ENDIF
    > $ show sym ll
    > $ RDESC=F$ELEMENT(LL,",",TDESC)
    > $ RETURN
    >
    > It was redundent to check for ".GT. 5" and also
    > ".LE. 5" for if not one then of course the other.
    >


    There's still too much code.

    > The crux of the problem is that within an
    > $IF
    > $THEN
    > $
    > $
    > $ELSE
    > $
    > $
    > $ENDIF
    >
    > that
    > $
    > should be able to be the (valid) statement
    > $IF then
    >
    > and that in the complex IF-THEN-ELSE the
    > "$THEN"
    > must be on it's own line to distinguish
    > between the two forms.
    >


    That's the way it works.

    > Probably if I had put a replacement statement
    > before the $ELSE the parser would have recovered.
    >
    > It's better this way, however.
    >


    I disagree.

    You have your answer, but if this code is close to being the actual
    code you use (obviously you don't init LL = 5) but you do have a known
    highest element number (5 in your example), you don't need an ELSE:


    $FIND_TCODE: !Gosub
    $ LL = 0
    $LOOPT:
    $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE)
    $ THEN
    $ LL=LL+1
    $ show sym ll
    $ IF LL .LE. 5 THEN GOTO LOOPT
    $ LL = 0 ! you know what LL is, why test it again?
    $ ENDIF
    $ show sym ll
    $ RDESC=F$ELEMENT(LL,",",TDESC)
    $ RETURN


    or better yet:

    $FIND_TCODE: !Gosub
    $ LL = 5
    $LOOPT:
    $ IF FCODE .NES. F$ELEMENT(LL,",",TCODE)
    $ THEN
    $ LL=LL-1
    $ show sym ll
    $ IF LL .GT. 0 THEN GOTO LOOPT
    $ ! it's zero, you don't need to set it.
    $ ENDIF
    $ show sym ll
    $ RDESC=F$ELEMENT(LL,",",TDESC)
    $ RETURN

    Or, I imagine someone will post an elegant little perl one-liner;-)


+ Reply to Thread