I need the complete cobol code for this from identification division onwards.

I'm sorry, but you are either a person hired as a programmer that has no clue on how to program or, you are a student looking for somebody to "crib" your homework.
Which one is it?
Where is "Heaven"?
Software Engineer?

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.

Which do you need to do? Update a sequential file with data from the table or update the table with data from the sequential file? The above is not coear to me.

When you ask a question is it always a good idea to post what you already have (i.e. your jcl, code, data definitions, what you want the output to look like, etc). The better you define your situation, the better we can provide assistance. If you need something "very quickly" you might say why - we appreciate that sometimes there is a crisis (many of us have dealt with many of them) and it is helpful if we understand your sense of urgency.

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.

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.

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 wrote:

Please explain why you believe COBOL cannot update DB2.

I meen that cobol cannot be able to directly modify the DB2 tables so its needs something external to do so

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.

Quote:

we had to replace EXEC SQL code by cobol CALL state ments.

What kind of CALLs did you replace the SQL with? It may be that the compile jcl is incomplete?

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

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?

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.

yes you are right, From the user point of view there is no difference instead he had to do 2 compiling process one on precompiler and other by cobol compiler. But why IGYCRCTL compiler is unable to compile the EXEC SQL code without precompiler? This itself states that it is a added feature to cobol to make COBOL more useful.

Code:

A pure cobol program can compiled by IGYCRCTL without any other precompiler

Again cobol program cannot update db2 tables but There is a method called embedded sql to add this feature to cobol

dick scherrer wrote:

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.

For those new to cobol and DB2 using a method called embedded sql you can update db2 using cobol but pure cobol will not be able to update db2 tables

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

You are just plain missing the point (or very stubborn and argumentative).
Yes, COBOL can not (yet) directly access DB2.
By your argument, COBOL can't do CICS...CICS also needs pre-compile translation.
By your argument, Assembler can't do I/O....Assembler macros need "translation" too.
COBOL does interact with native access methods, to interact with other more advanced access methods it needs to interface with those access methods; that can be a very complicated task.
CICS and DB2 provide standardized pseudo code that the programmer can use to accomplish what is needed.
That pseudo code gets translated prior to the compile. Do you know why prior? Because all that pseudo code gets converted to COBOL code which needs to be compiled.
If you were good, and understood the interfaces, you could "write a file program to read and then update db2" without need for a pre-compile translation.

Nice to follow your discussion with Dick. I had a pleasent time, reading this. Also in consideration of the fact, that i, also a technical person (Systemprogrammer), who is hired for expensive money from a company hour for hour, could spent time on reading that and getting well payed for it. I hope this is going on, cause I still have to be here a fiew houres till it's weekend.

William for doing something those related to hardware and file system each programming language has to depend on system specific components or other applications which accomplishes the task for them, That is a true and unaltered matter. Here i am try to tell that EXEC statement is not a standard COBOL statement

William Thompson wrote:

If you were good, and understood the interfaces, you could "write a file program to read and then update db2" without need for a pre-compile translation.

That's i dont understand because interfacing with a data base one programming language needs a API .Even java based programming language needs JDBC as a API. So how a COBOL program will do that directly.

Consider PHP it has a statement mysql_connect(host, user name, pass) that will connect with mysql data base. Can you show me any COBOL statement for data base. For example to read a flat file or vsam data set COBOL has it's own native statement's but there is no native statement for data base manipulation that's what i told

And as you told we can write COBOL program to manipulate database without a precompiler , can u please explain it in detail, that will be a good goldmine for us

Here i am try to tell that EXEC statement is not a standard COBOL statement

True, and macros are not a standard Assembler statement.

Quote:

William Thompson wrote:

If you were good, and understood the interfaces, you could "write a file program to read and then update db2" without need for a pre-compile translation.

That's i dont understand because interfacing with a data base one programming language needs a API .Even java based programming language needs JDBC as a API. So how a COBOL program will do that directly.

Moving targets are hard to hit, but I'll try. The EXEC statements are not the API, they are shorthand for communication with the API.[/quote]

Quote:

And as you told we can write COBOL program to manipulate database without a precompiler , can u please explain it in detail, that will be a good goldmine for us

I guess you don't see what is right in front of you, the COBOL code coming out of the translator is still COBOL code, there is no magical programming language imbedded in the COBOL code. There is nothing stopping you from coding the API interface code yourself but your "goldmine" seems more like a "money pit" to me....

guess you don't see what is right in front of you, the COBOL code coming out of the translator is still COBOL code, there is no magical programming language imbedded in the COBOL code. There is nothing stopping you from coding the API interface code yourself but your "goldmine" seems more like a "money pit" to me....

What are you telling . You told that there is some magical methods by which you will show the magic of making cobol update the db2 without the need of precompiler. Now you tells that cobol program comes out of translator is cobol code if u can do that without a translator or precompiler then what is the need of mensioning it. I think that gold mine is a dream that you cares, dont worry try to make it true so that we can get anoyher einstein

What he has said is that when the DB2 pre-compliler processes the EXEC SQL statements, it converts them to standard COBOL source - which is both correct and is the way 1/2 million or more coders use SQL in their COBOL code.

For a bit of understanding and education, i strongly suggest that you embed some simple SQL in a COBOL program and run it through the pre-compiler in use at your location (of the 100+ data centers that i've been involved with over the last 20 years, EVERY one of them uses a pre-compiler for SQL). Then compare the coded EXEC SQL to the generated "standard COBOL" that was generated by the pre-compiler. You will see that, if you so desired, you could write the same thing by hand, but there is no good reason to do so.

This may be way off the mark, but it sounds like you and/or your organization have been awarded or taken on a task that for which you have NO background and/or expertise. If this is correct, someone needs to inform your client and/or management that before you can perform the DB2 work properly, you have to learn the basics.

A couple of times i've asked, recieved no reply, and will now ask again. . .

Quote:

What kind of CALLs did you replace the SQL with?

and

Quote:

What calls did you have to put in your code? Might these be the same thing the pre-compiler generates?