Update to DB2 from COBOL

sunojsm · New User Joined: 21 Jun 2004 Posts: 48 Location: Heaven

Hi,

I have one scenario with me,

I have one file with some records and using JCL I sorted that file by retreiving the required fields from that file and put the results in another file.

Now what I want is, I need a cobol code for the given condition.

I have to first read the records till end of file of the jcl output ie the sortout.

Now I have one table with me in which one column have
the same field that we retrieve from jcl.What I
want to do is to overwrite the sortout fields with the table fields.

For that I need to update the table using cobol code.
I need the complete cobol code for this from identification division onwards.

Can anyone please help me on this.I need it very quickly.
Waiting for your replies.

Thanks

William Thompson · Posted: Sun Feb 18, 2007 3:23 am Post subject: Re: Update to DB2 from COBOL

dick scherrer · Posted: Sun Feb 18, 2007 4:37 am Post subject:

Hello,

You have a bit of a problem with your requirement definition.

sunojsm · New User Joined: 21 Jun 2004 Posts: 48 Location: Heaven

Hi,

I have one file with so many records.I retrieved certain records that have the field value as say AB in 30th position.And I retrieved it using SORT in JCL and I loaded the records that have AB in to sortout file.

Now I have one DB2 table with so many records in which it also have the field as say CD.

Now what i need is a cobol program that will read the sortout file till end and update the table by replacing CD with AB.

I dont need any other alternative ways..

I beleive now it is more clear.Please answer me asap.

Thanks

cobolunni · Posted: Tue Feb 20, 2007 1:27 pm Post subject:

Cobol cannot update db2 tables , I think you need CICS to done your job
Is CICS is permitted in your solution.

Is permitted then write a file program to read and then update db2 that's simple. if you need more explaination or code tell me

dick scherrer · Posted: Tue Feb 20, 2007 8:29 pm Post subject:

Hello,

COBOL CAN and does update DB2 - both in CICS and in batch.

Please explain why you believe COBOL cannot update DB2.

There is NO need to process this requirement in CICS.

cobolunni · Posted: Wed Feb 21, 2007 2:45 pm Post subject:

dick can you please tell how cobol can insert a value to db2 in batch mode
, please add a piece of code if you can

UmeySan · Posted: Wed Feb 21, 2007 3:20 pm Post subject:

Hi Cobolunni !

As Dick said: Batch-Updates of DB2-Tabels are allways possible in Cobol
and Assembler without CICS. There is no difference.

Regards, UmeySan

Here's a little example-section of a Batch-Cobol.

U01-UPDATE-VEDL SECTION.
MOVE 'U01 ' TO FTEXT3
MOVE 'VE_DARL ' TO W-SQLTABL
*-----------------------------------------------------------

EXEC SQL
UPDATE VE_DARL
SET ZUSAG_EDTM = :LI-VE-DARL.ZUSAG-EDTM
WHERE VE_ID = :LI-VE-DARL.VE-ID
AND VON = :LI-VE-DARL.VON
QUERYNO 14
END-EXEC

PERFORM U90-SQL-FEHLER
PERFORM U90-SQL-ZAEHLER

*-----------------------------------------------------------
MOVE SPACES TO FTEXT3.
U01-UPDATE-VEDL-EXIT.

UmeySan · Posted: Wed Feb 21, 2007 3:32 pm Post subject:

Hi sunojsm !

Now, as you figured out your problem, i think it's almost clear to yourself.
So write this little fucking programm. In the time of waiting for response for your answer, you could have almost written it.

Otherways, I agree with Bill.

...Declare Cursor for Update

DoUntil EOF of SeqFile

...Read SeqFile

...Fetch adaquate row
...Update, where current of...

or... use direct Update / where TableKey= :KeyField

EndDo

Regards, UmeySan

cobolunni · Posted: Thu Feb 22, 2007 12:08 am Post subject:

Thanks umaysan,

But Actually EXEC SQL is not a standard cobol statement a cobol compiler eg IGYCRCTL will not able to directly compile this statement, for that we had to replace EXEC SQL code by cobol CALL state ments.

dick scherrer · Posted: Thu Feb 22, 2007 1:47 am Post subject:

Hello,

It is called embedded sql and IS placed "inside" the cobol source. I'm not sure what you mean by "external". The sql is processed by a pre-compiler much like other things (like CICS) and when the smoke clears, you have a COBOL executable with DB2 (or Datacom or IDMS) and/or CICS in the module.

COBOL cannot directly read a disk or a tapee either. It relies on an i/o interface. COBOL specifies 'read', but what "really happens" is never seen by COBOL.

cobolunni · Posted: Thu Feb 22, 2007 11:46 pm Post subject:

Dick ,

VS COBOL 2 specification doesn't have any data base manipulation statements so for that we are using a precompiler. If EXEC SQL is a cobol statement we can directly compile it by IGYCRCTL compiler but we are using a precompiler before compiling by actual COBOL compiler. A precompiler fetches every thing inside (include) EXEC SQL and replaces every thing by a cobol CALL statement. The CALL statement calls a binary form of SQL statements which does the Data base manipulation for COBOL

Actually as a user we sense that COBOL does the data base manipulation but really that is not the case

dick scherrer · Posted: Fri Feb 23, 2007 1:17 am Post subject:

Hello,

I believe that this is just caught up in semantics.

In effect there is no difference between having the code parsed by a pre-compiler, then the compiler and having it all done in the compiler.

The code is written from ID Division to the last statement as one unit and after a successful compile/linkedt, an executable is produced in a loadlib.

If i have one piece of code (a program) that interacts with something external (i.e. DB2) that code is written "in COBOL" and does, if so designed, insert rows in DB2 tables.

A big reason i've continued with this is so that people new to COBOL and/or DB2 do not read the thread and come away with the impression that they cannot work with DB2 via COBOL. What does it matter that EXEC SQL is not a standard cobol statement ? When compile jcl is set up it should NOT be done by each programmer and the "standard" DB2 compile will include the pre-processor - or at least it does everywhere i've supported. . .

What calls did you have to put in your code? Might these be the same thing the pre-compiler generates? If you're saying the EXEC SQL was replaced by the pre-compiler, why mention it - that is the way it is typically done?

Back to

cobolunni · Posted: Fri Feb 23, 2007 2:58 pm Post subject:

William Thompson · Posted: Fri Feb 23, 2007 3:31 pm Post subject: