EXEC CMD - END-EXEC statement in IF Statement or EVALUATE STATEMENT

follow text is correct?

1.
IF  SQLCODE = ZERO
MOVE  VARA       TO  VARC
EXEC SQL INCLUDE 'SAMPLE.INC' END-EXEC.
MOVE  VARA       TO  NBM
END-IF.

2.
IF  SQLCODE = ZERO
MOVE  VARA       TO  VARC
EXEC SQL INCLUDE 'SAMPLE.INC' END-EXEC
MOVE  VARA       TO  SAMPLE
END-IF.


3.
IF  SQLCODE = ZERO
MOVE  VARA       TO  VARC
EXEC SQL SELECT A FROM B  END-EXEC
MOVE  VARA       TO  VARC
END-IF.

4.
IF  SQLCODE = ZERO
MOVE  VARA       TO  VARC
EXEC SQL SELECT A FROM B END-EXEC.
MOVE  VARA       TO  VARC
END-IF.


My question's point is "EXEC CMD  -- END-EXEC" statement must end wiht "."..
( all cobol compiler..case.)

On 12 Mar 2005 00:36:39 -0800, apknight@gmail.com (apknight) wrote:

>follow text is correct?
>
>1.
>     IF  SQLCODE = ZERO
>         MOVE  VARA       TO  VARC
>         EXEC SQL INCLUDE 'SAMPLE.INC' END-EXEC.
>         MOVE  VARA       TO  NBM
>     END-IF.
>
>2.
>     IF  SQLCODE = ZERO
>         MOVE  VARA       TO  VARC
>         EXEC SQL INCLUDE 'SAMPLE.INC' END-EXEC
>         MOVE  VARA       TO  SAMPLE
>     END-IF.
>
>
>3.
>     IF  SQLCODE = ZERO
>         MOVE  VARA       TO  VARC
>         EXEC SQL SELECT A FROM B  END-EXEC
>         MOVE  VARA       TO  VARC
>     END-IF.
>
>4.
>     IF  SQLCODE = ZERO
>         MOVE  VARA       TO  VARC
>         EXEC SQL SELECT A FROM B END-EXEC.
>         MOVE  VARA       TO  VARC
>     END-IF.
>
>
>My question's point is "EXEC CMD  -- END-EXEC" statement must end wiht ".".
.
>( all cobol compiler..case.)

That used to be true with Oracle's Pro*Cobol. It is not now.

apknight wrote:
> follow text is correct?
>
> 1.
>      IF  SQLCODE = ZERO
>          MOVE  VARA       TO  VARC
>          EXEC SQL INCLUDE 'SAMPLE.INC' END-EXEC.
>          MOVE  VARA       TO  NBM
>      END-IF.

Assuming that's valid SQL syntax, and all the variables (VARA, VARC, and
NBM, for this one) are defined in working-storage, then this one is fine.

> 2.
>      IF  SQLCODE = ZERO
>          MOVE  VARA       TO  VARC
>          EXEC SQL INCLUDE 'SAMPLE.INC' END-EXEC
>          MOVE  VARA       TO  SAMPLE
>      END-IF.

Same as the above for this one.

> 3.
>      IF  SQLCODE = ZERO
>          MOVE  VARA       TO  VARC
>          EXEC SQL SELECT A FROM B  END-EXEC
>          MOVE  VARA       TO  VARC
>      END-IF.

This one will give you some problems.  From within COBOL, you'll need to
give the SQL statement a "host language variable" for each data item you
are going to retrieve.  If the item can be null, you should give it an
"indicator variable" as well.  For example, assume "A" is a nullable
varchar(20) field in your database.  To make this work, somewhere in
working-storage you'll need a "declare section", like this...  (column 8
is the margin of this e-mail)

Exec SQL  Begin Declare Section  End-Exec.
01  A-Variable     pic X(20).
01  A-Indicator    pic S9.
Exec SQL  End Declare Section   End-Exec.

Then, change your "EXEC SQL" to look something like this...

Exec SQL
Select A
Into :A-Variable  :A-Indicator
From B
End-Exec

A note about the indicator variable - if the item is null, it will be
negative (and, the host variable contents are undefined - some may blank
it out, others may leave it untouched).  Additionally, if the retrieval
is truncated (in this case, imagine someone changed the database, and we
now have 25 characters to bring in), the indicator variable will be
positive, and the number therein represents the number of characters
that could not be transferred.  (For this reason, some folks like
defining them as more than one digit.)

(If you need more help, look up the terms in quotes above...)

> 4.
>      IF  SQLCODE = ZERO
>          MOVE  VARA       TO  VARC
>          EXEC SQL SELECT A FROM B END-EXEC.
>          MOVE  VARA       TO  VARC
>      END-IF.

This one also has a problem - the period/full stop after the End-Exec.
Compilers that I've used have not required that (and, requiring that
would make it nearly impossible to nest these sorts of things).  Also,
unless this is an environment with which I am unfamiliar, the "move vara
to varc" twice is redundant, as the SQL statement does not modify either
of them.

Hope that helps...


--
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        Live from Montgomery, AL!       ~
~  /     \/       o  ~                                        ~
~ /      /\   -   |  ~          daniel@thebelowdomain         ~
~ _____ /  \      |  ~      http://www.djs-consulting.com     ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e    ~
~ h---- r+++ z++++                                            ~
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

apknight wrote:
> follow text is correct?
>
> 1.
>      IF  SQLCODE = ZERO
>          MOVE  VARA       TO  VARC
>          EXEC SQL INCLUDE 'SAMPLE.INC' END-EXEC.
>          MOVE  VARA       TO  NBM
>      END-IF.
>

<snip>.....

As I recall you ARE using Micro Focus. From your IDE (the Main
development screen), from the main menu bar - can you select "Tools"
which will then give you a dropdown menu listing and perhaps an entry
"Open ESQLAssistant"

If so, then on-line you can access a Database manual, including this SQL
feature. It takes a little patience to understand what you have to do -
but is not difficult.

From your pre-designed database tables it will generate copy files.
Using the SQL Assistant you can make queries and it generates the code
between EXEC SQL........... and END-EXEC. You can then copy/paste the
coded entry into your source program.

Jimmy

Thank's your answer. My Question's point is that period was proof.

hum... You answer 1,2 is fine but 3 was syntax proof ( real is
error..anyway ) and 4 is error.

1's period is correct?

LX-i <lxi0007@netscape.net> wrote in message news:<4830a$42337171$45491f85$25452@KNOLOGY.NE
T>...
> apknight wrote: 
>
> Assuming that's valid SQL syntax, and all the variables (VARA, VARC, and
> NBM, for this one) are defined in working-storage, then this one is fine.
> 
>
> Same as the above for this one.
> 
>
> This one will give you some problems.  From within COBOL, you'll need to
> give the SQL statement a "host language variable" for each data item you
> are going to retrieve.  If the item can be null, you should give it an
> "indicator variable" as well.  For example, assume "A" is a nullable
> varchar(20) field in your database.  To make this work, somewhere in
> working-storage you'll need a "declare section", like this...  (column 8
> is the margin of this e-mail)
>
>      Exec SQL  Begin Declare Section  End-Exec.
> 01  A-Variable     pic X(20).
> 01  A-Indicator    pic S9.
>      Exec SQL  End Declare Section   End-Exec.
>
> Then, change your "EXEC SQL" to look something like this...
>
>      Exec SQL
>          Select A
>            Into :A-Variable  :A-Indicator
>            From B
>      End-Exec
>
> A note about the indicator variable - if the item is null, it will be
> negative (and, the host variable contents are undefined - some may blank
> it out, others may leave it untouched).  Additionally, if the retrieval
> is truncated (in this case, imagine someone changed the database, and we
> now have 25 characters to bring in), the indicator variable will be
> positive, and the number therein represents the number of characters
> that could not be transferred.  (For this reason, some folks like
> defining them as more than one digit.)
>
> (If you need more help, look up the terms in quotes above...)
> 
>
> This one also has a problem - the period/full stop after the End-Exec.
> Compilers that I've used have not required that (and, requiring that
> would make it nearly impossible to nest these sorts of things).  Also,
> unless this is an environment with which I am unfamiliar, the "move vara
> to varc" twice is redundant, as the SQL statement does not modify either
> of them.
>
> Hope that helps...
>
>
> --
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
> ~   /   \  /         ~        Live from Montgomery, AL!       ~
> ~  /     \/       o  ~                                        ~
> ~ /      /\   -   |  ~          daniel@thebelowdomain         ~
> ~ _____ /  \      |  ~      http://www.djs-consulting.com     ~
> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
> ~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
> ~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e    ~
> ~ h---- r+++ z++++                                            ~
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

apknight wrote:
> Thank's your answer. My Question's point is that period was proof.
>
> hum... You answer 1,2 is fine but 3 was syntax proof ( real is
> error..anyway ) and 4 is error.
>
> 1's period is correct?
>
> LX-i <lxi0007@netscape.net> wrote in message news:<4830a$42337171$45491f85
$25452@KNOLOGY.NET>...
> 
The EXEC ... END-EXEC lines are parsed by the pre-processor, not the
COBOL compiler proper. I suspect the period does not get seen by COBOL
compiler proper at all. Therefore the full-stop will not interfere with
the if statement.
It might be simpler to think of this source as being in two languages,
each with their own syntax, grammar and lexical rules.

Or perhaps as equivalent to an alternative, more powerful COPY statement. :)

apknight wrote:
> Thank's your answer. My Question's point is that period was proof.
>
> hum... You answer 1,2 is fine but 3 was syntax proof ( real is
> error..anyway ) and 4 is error.
>
> 1's period is correct?

Oops - I missed that.  No, 1 should have the period removed after
End-Exec as well.
 


--
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        Live from Montgomery, AL!       ~
~  /     \/       o  ~                                        ~
~ /      /\   -   |  ~          daniel@thebelowdomain         ~
~ _____ /  \      |  ~      http://www.djs-consulting.com     ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e    ~
~ h---- r+++ z++++                                            ~
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

The answer is that there is no single answer for
"( all cobol compiler..case.)"

Some SQL pre-/co-processors allow/require the period (full stop).  Some will
pass it along to the compiler - which will cause an error if found nested in
side
an IF/End-IF

Some will work one way for
EXEC SQL SELECT
and another way for
EXEC SQL INCLUDE

Bottom-Line:
Read your vndorS (compiler and SQL) documentation.

--
Bill Klein
wmklein <at> ix.netcom.com
"apknight" <apknight@gmail.com> wrote in message
news:95895e6d.0503120036.64bf1cdf@posting.google.com...
> follow text is correct?
>
> 1.
>     IF  SQLCODE = ZERO
>         MOVE  VARA       TO  VARC
>         EXEC SQL INCLUDE 'SAMPLE.INC' END-EXEC.
>         MOVE  VARA       TO  NBM
>     END-IF.
>
> 2.
>     IF  SQLCODE = ZERO
>         MOVE  VARA       TO  VARC
>         EXEC SQL INCLUDE 'SAMPLE.INC' END-EXEC
>         MOVE  VARA       TO  SAMPLE
>     END-IF.
>
>
> 3.
>     IF  SQLCODE = ZERO
>         MOVE  VARA       TO  VARC
>         EXEC SQL SELECT A FROM B  END-EXEC
>         MOVE  VARA       TO  VARC
>     END-IF.
>
> 4.
>     IF  SQLCODE = ZERO
>         MOVE  VARA       TO  VARC
>         EXEC SQL SELECT A FROM B END-EXEC.
>         MOVE  VARA       TO  VARC
>     END-IF.
>
>
> My question's point is "EXEC CMD  -- END-EXEC" statement must end wiht "."
.
> ( all cobol compiler..case.)