Re: COBOL/DB2 Date edit question

Gentlemen,
Thanks - will work on what you've said.
MP!ZADATEI is a field on a CICS screen, populated from a column in a
row from a DB2 table. The user changes it and now it needs editing. I
thought my EXEC SQL was a winner - clearly not.
Peter - I did say it was VisualAge COBOL 2.2, DB2 V7.2 - didnt mention
the word 'IBM':-). Sorry.
graham

On Sun, 12 Aug 2007 13:37:06 +1200, "Pete Dashwood"
<dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:



"Graham Hobbs" <ghobbs@xxxxxxxxxxx> wrote in message
news:pltrb3hf2o0ujn52tqnd8tk5nsn5ars8uj@xxxxxxxxxx
Help please.
The following code fails - think I've missed something simple.
Table and column exist, database is connected.
I thought I could get a field off screen and edit it via the
SQL below but I get a compile error. I get the same error for
Time and Timestamp fields.
Might there be an 'industry standard' for dealing with these
types of fields?
My docs give little guidance on this and since I work in
isolation there's no-one to ask.
Environment is Visualage Cobol 2.2, DB2 V7.2

02 MP1ZADATEI PIC X(00010).

*------------------------------
E1-ADATE.
*------------------------------
IF MP1ZADATEL NOT = ZERO
EXEC SQL DATE(MP1ZADATEI) END-EXEC
IF SQLCODE = -180
..ETC

--------------------------------------------------------------------
SQL0060W The "COBOL" precompiler is in progress.
83 SQL0062W Starting INCLUDE of file
"E:\conrad\edi1\THEBOOK.cbl".
83 SQL0063W Completed INCLUDE of file "THEBOOK.cbl".
1057 SQL0104N An unexpected token "DATE" was found following
"BEGIN-OF-STATEMENT". Expected tokens may include:
"SELECT". SQLSTATE=42601

Any help or code examples appreciated. please, thanks.


Your problem here is that you are not referencing a host variable to the SQL
DATE function.

As long as your RDBMS supports the function, it is OK to use it in COBOL,
but you need to be clear about what is a field on your database and what is
a field in your program.(Michael was not quite right about that.)

This is addressed by using Host Variables. Host variables must be declared
with an SQL DECLARE statement, and prefixed with a symbol whenever they are
referenced in EXEC SQL statements. (Often the symbol is a colon, but it
varies on different systems.)

It would also be very helpful if, when posting here, you told us what COBOL
and what RDBMS you are using. Believe it or not, but despite
standardization of both COBOL and SQL, there are actually differences
between different systems! (Shock! Horror!)

Consult your documentation regarding the use of Host Variables and all will
be revealed.

Robert Jones has posted a code example.

HTH,

Pete.


--
Posted via a free Usenet account from http://www.teranews.com

.

Relevant Pages

  • Re: Dynamiv SQL and multi-row access SQL from COBOL... some quick questions
    ... EXECUTE IMMEDIATE is for one time dynamic SQL. ... Perhaps you were referring to something other than host variables. ... COBOL using ACCESS 2003. ...
    (comp.lang.cobol)
  • Re: COBOL/DB2 Date edit question
    ... Table and column exist, database is connected. ... SQL below but I get a compile error. ... SQL0060W The "COBOL" precompiler is in progress. ... This is addressed by using Host Variables. ...
    (comp.lang.cobol)
  • Re: Dynamiv SQL and multi-row access SQL from COBOL... some quick questions
    ... EXECUTE IMMEDIATE is for one time dynamic SQL. ... Perhaps you were referring to something other than host variables. ... COBOL using ACCESS 2003. ...
    (comp.lang.cobol)
  • Re: COBOL stored procedure for DB2
    ... Regarding how you precompile the app, you must specify target mfcob to db2 prep, rather than target ibmcob. ... Have you also confirmed that, prior to executing the CALL statement, the host variables specified within the client app have the appropriate values? ... MODIFIES SQL DATA ... confirm the cob command used for creating the SP module. ...
    (comp.lang.cobol)
  • Re: Definition of FACTORY
    ... > taking different elements in the record to create keys. ... COBOL provided nice syntactic file access support initially. ... the SQL part. ... > At a later stage, as need arises, I can include SQL syntax in other ...
    (comp.object)