Return codes and If statments - Protocols

This is a discussion on Return codes and If statments - Protocols ; Hello, I am modifying a C-Kermit script I have to not continue processing if a call to another script does not return a value of 1 (We are doing this for fail over testing). Here is the C-Kermit code in ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Return codes and If statments

  1. Return codes and If statments

    Hello,


    I am modifying a C-Kermit script I have to not continue processing
    if a call to another script does not return a value of 1 (We are doing
    this for fail over testing).

    Here is the C-Kermit code in question:

    # run the db_status script in the CRON directory
    run db_status

    # See if the ret value is != 1
    # If it != 1 tell user we are not on the primay server and then
    exit).

    if != \v(pexitstat) 1
    {
    echo Return code != 1 ... Not the primary server
    echo return code = \v(pexitstat)
    exit

    }
    # otherwise we are on the primary server so continue processing
    ....
    ....
    ....

    When I run this on the Secondary server it works (since the result
    returned from the db_status script is a 2 since it is not the primary
    server).

    However, when I test this on the primay server the code exits (meaning
    it executes the body of the if statment above) despite the fact that
    the return code from db_status is 1.

    Any suggestions, as to what I'm doing wrong?

    Many thanks in advance

    Peter Vasseur

  2. Re: Return codes and If statments

    On 2004-09-21, Peter V. wrote:
    : I am modifying a C-Kermit script I have to not continue processing
    : if a call to another script does not return a value of 1 (We are doing
    : this for fail over testing).
    :
    : Here is the C-Kermit code in question:
    :
    : # run the db_status script in the CRON directory
    : run db_status
    :
    : # See if the ret value is != 1
    : # If it != 1 tell user we are not on the primay server and then
    : exit).
    :
    : if != \v(pexitstat) 1
    : {
    : echo Return code != 1 ... Not the primary server
    : echo return code = \v(pexitstat)
    : exit
    :
    : }
    : # otherwise we are on the primary server so continue processing
    : ...
    : ...
    : ...
    :
    : When I run this on the Secondary server it works (since the result
    : returned from the db_status script is a 2 since it is not the primary
    : server).
    :
    : However, when I test this on the primay server the code exits (meaning
    : it executes the body of the if statment above) despite the fact that
    : the return code from db_status is 1.
    :
    : Any suggestions, as to what I'm doing wrong?
    :
    My first suggestion is to use the recommended format for grouping statements:

    if != \v(pexitstat) 1 {
    echo Return code != 1 ... Not the primary server
    echo return code = \v(pexitstat)
    exit
    }

    If that doesn't help, then check to see what the subprocess actually
    returns as its exit code (OK, you say it is 1 but...). If so, then make sure
    you are running the current version of C-Kermit, which is 8.0.211. If you
    are, then we're in for some debugging; contact kermit-support@columbia.edu.

    - Frank

  3. Re: Return codes and If statments

    Frank da Cruz wrote:
    > On 2004-09-21, Peter V. wrote:
    > : I am modifying a C-Kermit script I have to not continue processing
    > : if a call to another script does not return a value of 1 (We are

    doing
    > : this for fail over testing).
    > :
    > : Here is the C-Kermit code in question:
    > :
    > : # run the db_status script in the CRON directory
    > : run db_status
    > :
    > : # See if the ret value is != 1
    > : # If it != 1 tell user we are not on the primay server and then
    > : exit).
    > :
    > : if != \v(pexitstat) 1
    > : {
    > : echo Return code != 1 ... Not the primary server
    > : echo return code = \v(pexitstat)
    > : exit
    > :
    > : }
    > : # otherwise we are on the primary server so continue processing
    > : ...
    > : ...
    > : ...
    > :
    > : When I run this on the Secondary server it works (since the result
    > : returned from the db_status script is a 2 since it is not the

    primary
    > : server).
    > :
    > : However, when I test this on the primay server the code exits

    (meaning
    > : it executes the body of the if statment above) despite the fact

    that
    > : the return code from db_status is 1.
    > :
    > : Any suggestions, as to what I'm doing wrong?
    > :
    > My first suggestion is to use the recommended format for grouping

    statements:
    >
    > if != \v(pexitstat) 1 {
    > echo Return code != 1 ... Not the primary server
    > echo return code = \v(pexitstat)
    > exit
    > }
    >
    > If that doesn't help, then check to see what the subprocess actually
    > returns as its exit code (OK, you say it is 1 but...). If so, then

    make sure
    > you are running the current version of C-Kermit, which is 8.0.211.

    If you
    > are, then we're in for some debugging; contact

    kermit-support@columbia.edu.
    >
    > - Frank



    Frank's suggestion will help. This is another case of if { } else { }
    constructs that only work if written in certain ways.

    I've mentioned this before, but the document

    http://www.columbia.edu/kermit/ckermit70.html

    contains several examples of if/else coding in section 7.20.1. The
    first four of these are

    Example 1:

    IF condition { command1, command2 } ELSE { command3, command4 }

    Example 2 (same as Example 1):

    IF condition {
    command1
    command2
    } ELSE {
    command3
    command4
    }

    Example 3 (same as 1 and 2):

    IF condition {
    command1
    command2
    }
    ELSE { command3, command4 }

    Example 4 (same as 1-3):

    IF condition {
    command1
    command2
    }
    ELSE {
    command3
    command4
    }

    In examples 3 and 4, various problems occur in execution of the ELSE
    clause when the condition is false. This change happened somewhere
    between 8.0.201 and 8.0.206 due to changes in the handling of
    "immediate macros". This is illustrated by the following.

    fog: {14} $ cat kt3
    # Example 1:

    IF false { .theday := \v(day), show macro theday } ELSE { .thedate :=
    \v(date), show macro thedate }

    # Example 2 (same as Example 1):

    IF false {
    ..theday := \v(day)
    show macro theday
    } ELSE {
    ..thedate := \v(date)
    show macro thedate
    }

    # Example 3 (same as 1 and 2):

    IF false {
    ..theday := \v(day)
    show macro theday
    }
    ELSE { .thedate := \v(date), show macro thedate }

    # Example 4 (same as 1-3):

    IF false {
    ..theday := \v(day)
    show macro theday
    }
    ELSE {
    ..thedate := \v(date)
    show macro thedate
    }
    fog: {15} $ kermit
    Executing /home_mo/msapiro/.kermrc for UNIX...
    Executing /home_mo/msapiro/.mykermrc...
    Good Evening.
    C-Kermit 8.0.212 Dev.00, 10 May 2004, for HP-UX 11.00
    Copyright (C) 1985, 2004,
    Trustees of Columbia University in the City of New York.
    Type ? or HELP for help.
    (/home_mo/msapiro/) C-Kermit>take kt3
    thedate = 21 Sep 2004
    thedate = 21 Sep 2004
    thedate = \v(date)
    thedate = \v(date)
    (/home_mo/msapiro/) C-Kermit>

    I have trained myself to always code if/else in the "recommended
    format", but it would be nice if the examples that no longer work were
    removed from the documentation.

    --
    Mark Sapiro msapiro at value dot net The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan


  4. Re: Return codes and If statments

    Frank and Mark,

    thank you both for your advice. I am sticking to recommended format
    Number 2, and that seems to have done the trick.

    Once again, thanks.

    Peter Vasseur

    "Mark Sapiro" wrote in message news:<1095827419.338981.28270@k26g2000oda.googlegroups.c om>...
    > Frank da Cruz wrote:
    > > On 2004-09-21, Peter V. wrote:
    > > : I am modifying a C-Kermit script I have to not continue processing
    > > : if a call to another script does not return a value of 1 (We are

    > doing
    > > : this for fail over testing).
    > > :
    > > : Here is the C-Kermit code in question:
    > > :
    > > : # run the db_status script in the CRON directory
    > > : run db_status
    > > :
    > > : # See if the ret value is != 1
    > > : # If it != 1 tell user we are not on the primay server and then
    > > : exit).
    > > :
    > > : if != \v(pexitstat) 1
    > > : {
    > > : echo Return code != 1 ... Not the primary server
    > > : echo return code = \v(pexitstat)
    > > : exit
    > > :
    > > : }
    > > : # otherwise we are on the primary server so continue processing
    > > : ...
    > > : ...
    > > : ...
    > > :
    > > : When I run this on the Secondary server it works (since the result
    > > : returned from the db_status script is a 2 since it is not the

    > primary
    > > : server).
    > > :
    > > : However, when I test this on the primay server the code exits

    > (meaning
    > > : it executes the body of the if statment above) despite the fact

    > that
    > > : the return code from db_status is 1.
    > > :
    > > : Any suggestions, as to what I'm doing wrong?
    > > :
    > > My first suggestion is to use the recommended format for grouping

    > statements:
    > >
    > > if != \v(pexitstat) 1 {
    > > echo Return code != 1 ... Not the primary server
    > > echo return code = \v(pexitstat)
    > > exit
    > > }
    > >
    > > If that doesn't help, then check to see what the subprocess actually
    > > returns as its exit code (OK, you say it is 1 but...). If so, then

    > make sure
    > > you are running the current version of C-Kermit, which is 8.0.211.

    > If you
    > > are, then we're in for some debugging; contact

    > kermit-support@columbia.edu.
    > >
    > > - Frank

    >
    >
    > Frank's suggestion will help. This is another case of if { } else { }
    > constructs that only work if written in certain ways.
    >
    > I've mentioned this before, but the document
    >
    > http://www.columbia.edu/kermit/ckermit70.html
    >
    > contains several examples of if/else coding in section 7.20.1. The
    > first four of these are
    >
    > Example 1:
    >
    > IF condition { command1, command2 } ELSE { command3, command4 }
    >
    > Example 2 (same as Example 1):
    >
    > IF condition {
    > command1
    > command2
    > } ELSE {
    > command3
    > command4
    > }
    >
    > Example 3 (same as 1 and 2):
    >
    > IF condition {
    > command1
    > command2
    > }
    > ELSE { command3, command4 }
    >
    > Example 4 (same as 1-3):
    >
    > IF condition {
    > command1
    > command2
    > }
    > ELSE {
    > command3
    > command4
    > }
    >
    > In examples 3 and 4, various problems occur in execution of the ELSE
    > clause when the condition is false. This change happened somewhere
    > between 8.0.201 and 8.0.206 due to changes in the handling of
    > "immediate macros". This is illustrated by the following.
    >
    > fog: {14} $ cat kt3
    > # Example 1:
    >
    > IF false { .theday := \v(day), show macro theday } ELSE { .thedate :=
    > \v(date), show macro thedate }
    >
    > # Example 2 (same as Example 1):
    >
    > IF false {
    > .theday := \v(day)
    > show macro theday
    > } ELSE {
    > .thedate := \v(date)
    > show macro thedate
    > }
    >
    > # Example 3 (same as 1 and 2):
    >
    > IF false {
    > .theday := \v(day)
    > show macro theday
    > }
    > ELSE { .thedate := \v(date), show macro thedate }
    >
    > # Example 4 (same as 1-3):
    >
    > IF false {
    > .theday := \v(day)
    > show macro theday
    > }
    > ELSE {
    > .thedate := \v(date)
    > show macro thedate
    > }
    > fog: {15} $ kermit
    > Executing /home_mo/msapiro/.kermrc for UNIX...
    > Executing /home_mo/msapiro/.mykermrc...
    > Good Evening.
    > C-Kermit 8.0.212 Dev.00, 10 May 2004, for HP-UX 11.00
    > Copyright (C) 1985, 2004,
    > Trustees of Columbia University in the City of New York.
    > Type ? or HELP for help.
    > (/home_mo/msapiro/) C-Kermit>take kt3
    > thedate = 21 Sep 2004
    > thedate = 21 Sep 2004
    > thedate = \v(date)
    > thedate = \v(date)
    > (/home_mo/msapiro/) C-Kermit>
    >
    > I have trained myself to always code if/else in the "recommended
    > format", but it would be nice if the examples that no longer work were
    > removed from the documentation.


  5. Re: Return codes and If statments

    On 2004-09-22, Peter V. wrote:
    : thank you both for your advice. I am sticking to recommended format
    : Number 2, and that seems to have done the trick.
    :
    I realize it might be a big counterintuitive for C programmers, but it
    should be recalled that Kermit differs from C not only in being interpretive
    rather than compiled, but also it's an interactive command language, and
    therefore necessarily line-oriented: each command is one line. Thus the
    true format of a compound IF-ELSE statement is:

    if { command, command, ... } ELSE { command, command, ... }

    Prior to C-Kermit 7.0, if you wanted to break such a statement onto multiple
    lines, you had to use line continuation:

    if { -
    command, -
    command, -
    ... -
    } ELSE {
    command, -
    command, -
    ... -
    }

    Version 7.0 added several tricks to the parser to give more natural
    syntax: (a) If a line ENDS with "{" (ignoring whitespace) it is continued
    and begins a block; (b) if a line BEGINS with "}" (ignoring whitespace) it
    ends a block; (c) if a block is active, the end of each line implies a
    comma (which is used to separate statements within blocks). Once a block
    is opened at top level, these tricks are used until the block is closed,
    and naturally, they persist through any level of nesting. This explains
    why a construction like:

    IF {
    command
    command
    }

    works, but:

    IF
    {
    command
    command
    }

    doesn't. The first line is an incomplete command with no indication of
    continuation. The documentation:

    http://www.columbia.edu/kermit/ckermit70.html#x7.20

    does not list the latter form as a possibility.

    - Frank

  6. Re: Return codes and If statments

    Frank da Cruz wrote:

    > IF {
    > command
    > command
    > }
    >
    > works, but:
    >
    > IF
    > {
    > command
    > command
    > }
    >
    > doesn't. The first line is an incomplete command with no indication of
    > continuation.


    Adding the working example of

    IF -
    {
    command
    command
    }

    might make this a bit clearer.

    Jeffrey Altman


    --
    -----------------
    This e-mail account is not read on a regular basis.
    Please send private responses to jaltman at mit dot edu

  7. Re: Return codes and If statments

    On 2004-09-22, Jeffrey Altman wrote:
    : Adding the working example of
    :
    : IF -
    : {
    : command
    : command
    : }
    :
    : might make this a bit clearer.
    :
    Good idea, done:

    http://www.columbia.edu/kermit/ckermit70.html#x7.20.1

    (new material in red).

    - Frank

  8. Re: Return codes and If statments

    Frank da Cruz wrote:
    > On 2004-09-22, Peter V. wrote:
    > : thank you both for your advice. I am sticking to recommended

    format
    > : Number 2, and that seems to have done the trick.
    > :
    > I realize it might be a big counterintuitive for C programmers, but

    it
    > should be recalled that Kermit differs from C not only in being

    interpretive
    > rather than compiled, but also it's an interactive command language,

    and
    > therefore necessarily line-oriented: each command is one line. Thus

    the
    > true format of a compound IF-ELSE statement is:
    >
    > if { command, command, ... } ELSE { command, command,

    .... }
    >
    > Prior to C-Kermit 7.0, if you wanted to break such a statement onto

    multiple
    > lines, you had to use line continuation:
    >
    > if { -
    > command, -
    > command, -
    > ... -
    > } ELSE {
    > command, -
    > command, -
    > ... -
    > }
    >
    > Version 7.0 added several tricks to the parser to give more natural
    > syntax: (a) If a line ENDS with "{" (ignoring whitespace) it is

    continued
    > and begins a block; (b) if a line BEGINS with "}" (ignoring

    whitespace) it
    > ends a block; (c) if a block is active, the end of each line implies

    a
    > comma (which is used to separate statements within blocks). Once a

    block
    > is opened at top level, these tricks are used until the block is

    closed,
    > and naturally, they persist through any level of nesting. This

    explains
    > why a construction like:
    >
    > IF {
    > command
    > command
    > }
    >
    > works, but:
    >
    > IF
    > {
    > command
    > command
    > }
    >
    > doesn't. The first line is an incomplete command with no indication

    of
    > continuation. The documentation:
    >
    > http://www.columbia.edu/kermit/ckermit70.html#x7.20
    >
    > does not list the latter form as a possibility.


    That is true, but that was not my point in my prior post in this
    thread. My point is that ever since 8.0.206. The forms of examples 3
    and 4 in the referenced documentation do not always produce the same
    results as the forms of examples 1 and 2.

    In particular, consider example 2 - the preferred form

    IF condition {
    command1
    command2
    } ELSE {
    command3
    command4
    }

    vs. Example 3 (same as 1 and 2):

    IF condition {
    command1
    command2
    }
    ELSE { command3, command4 }

    and Example 4 (same as 1-3):

    IF condition {
    command1
    command2
    }
    ELSE {
    command3
    command4
    }

    As far as I can tell, example 2 always works as expected, but in the
    case where condition is False and command3 and or command 4 contains a
    Macro reference, the macro reference will not be expanded in example 3
    and 4 as it is in example 2.

    This is illustrated by the following:

    # Example 2 (same as Example 1):

    IF false {
    ..theday := \v(day)
    show macro theday
    } ELSE {
    ..thedate := \v(date)
    show macro thedate
    }

    # Example 3 (same as 1 and 2):

    IF false {
    ..theday := \v(day)
    show macro theday
    }
    ELSE { .thedate := \v(date), show macro thedate }

    If this is run today, example 2 will output

    thedate = 24 Sep 2004

    but example 3 will output

    thedate = \v(date)

    This behavior was introduced by changes in the way immediate macro's
    are handled in ckuusr.c, 23 Aug 2002.

    These changes were intended to solve a problem that might more properly
    have been addressed by escapes in the command.


+ Reply to Thread