More Debugging Issues
in [Cobol]
|
Prev: Day of Any Week
Next: ANN: OpenCOBOL Programmer's Guide
From: Derek Schrock on 6 Feb 2010 16:43 Any idea how I can debug cobol that has been generated by Oracle's ProCOBOL. We're running these compiled objects with Oracle's rtsorta32. Now I can simply animate with anim and the .int file however when it comes to a CALL that is part of the Oracle runtime I get an error. I understand why this this happening so I thought maybe I could link the Oracle libs along with the cobol file. $ORACLE_HOME/ lib32/ among A LOT of other libs. This seems like a bad way of doing this. Can I load the libraries that are part of rtsorta32 when I run anim? Do I need to build a shared object (not an execuatable ELF such as the rtsorta32 binary) of the Oracle libs?
From: Pete Dashwood on 6 Feb 2010 19:29 Derek Schrock wrote: > Any idea how I can debug cobol that has been generated by Oracle's > ProCOBOL. We're running these compiled objects with Oracle's > rtsorta32. Now I can simply animate with anim and the .int file > however when it comes to a CALL that is part of the Oracle runtime I > get an error. I understand why this this happening so I thought maybe > I could link the Oracle libs along with the cobol file. $ORACLE_HOME/ > lib32/ among A LOT of other libs. This seems like a bad way of doing > this. > > Can I load the libraries that are part of rtsorta32 when I run anim? > Do I need to build a shared object (not an execuatable ELF such as the > rtsorta32 binary) of the Oracle libs? There are a few things you need to consider here: 1. Unless the generated PROCobol code is compiled with symbols in it (debugging option) you will not be able to step through it in Animator. 2. Similarly, uness the ORACLE libraries have been compiled with symbols in them (and they won't have been for a production release) You can't step through those in Animator either. 3. Do you really want to make changes to the Oracle RunTime libraries? Isn't it enough to just step OVER those calls and check the results? You didn't mention what the "error" is that you get, but I would try stepping OVER and seeing if it still occurs... 4. You are right that linking the Oracle libs with the COBOL file is not a good idea, and if the libs have no symbols, you will be no further ahead. 5. You probably COULD build a shared object of the Oracle libs, but, again, without the symbols included there is no point. The general idea is to take the Oracle runtime as read. Debug your application around it. Pete. -- "I used to write COBOL...now I can do anything."
From: Richard on 6 Feb 2010 23:54 On Feb 7, 10:43 am, Derek Schrock <derekschr...(a)gmail.com> wrote: > Any idea how I can debug cobol that has been generated by Oracle's > ProCOBOL. We're running these compiled objects with Oracle's > rtsorta32. It is likely that this file was built using Microfocus 'cob' to build a runtime executable from the MF runtime modules plus the Oracle libraries. Running Animator uses a different runtime execute, the standard MF one won't have the Oracle libraries. You probably need to build a special animator runtime that includes the Oracle libraries > Now I can simply animate with anim and the .int file > however when it comes to a CALL that is part of the Oracle runtime I > get an error. I understand why this this happening so I thought maybe > I could link the Oracle libs along with the cobol file. $ORACLE_HOME/ > lib32/ among A LOT of other libs. This seems like a bad way of doing > this. > > Can I load the libraries that are part of rtsorta32 when I run anim? > Do I need to build a shared object (not an execuatable ELF such as the > rtsorta32 binary) of the Oracle libs? Details of what is required should be in the User Guide for your system.
From: Derek Schrock on 6 Feb 2010 23:55 On Feb 6, 7:29 pm, "Pete Dashwood" <dashw...(a)removethis.enternet.co.nz> wrote: > Derek Schrock wrote: > > Any idea how I can debug cobol that has been generated by Oracle's > > ProCOBOL. We're running these compiled objects with Oracle's > > rtsorta32. Now I can simply animate with anim and the .int file > > however when it comes to a CALL that is part of the Oracle runtime I > > get an error. I understand why this this happening so I thought maybe > > I could link the Oracle libs along with the cobol file. $ORACLE_HOME/ > > lib32/ among A LOT of other libs. This seems like a bad way of doing > > this. > > > Can I load the libraries that are part of rtsorta32 when I run anim? > > Do I need to build a shared object (not an execuatable ELF such as the > > rtsorta32 binary) of the Oracle libs? > > There are a few things you need to consider here: > > 1. Unless the generated PROCobol code is compiled with symbols in it > (debugging option) you will not be able to step through it in Animator. > 2. Similarly, uness the ORACLE libraries have been compiled with symbols in > them (and they won't have been for a production release) You can't step > through those in Animator either. > 3. Do you really want to make changes to the Oracle RunTime libraries? > Isn't it enough to just step OVER those calls and check the results? > You didn't mention what the "error" is that you get, but I would try > stepping OVER and seeing if it still occurs... > 4. You are right that linking the Oracle libs with the COBOL file is not a > good idea, and if the libs have no symbols, you will be no further ahead. > 5. You probably COULD build a shared object of the Oracle libs, but, again, > without the symbols included there is no point. > > The general idea is to take the Oracle runtime as read. Debug your > application around it. > > Pete. > > -- > "I used to write COBOL...now I can do anything." Sorry maybe I wasn't very clear in the first post. 1. I am compiling for debugging. 2. I don't need to step in to the Oracle calls, I only need anim (the animator command) to execute the Oracle CALLs. This where the error lies. When I try to animate the .int file and I hit an Oracle CALL ("CALL SQLADR" I think that's one of them) I'll get something along the lines "Can't find program or method." I knew this was going to happen because all of the library calls are in rtsorta32 binary (the Oracle runtime). So I need to figure out how to allow anim to CALL them since Oracle didn't (or doesn't) provide an animator program. 3. No, I don't want to make any changes to that runtime. I just need to animate cobol generated by the ProCOBOL preprocessor. 4. Ok we agree linking the Oracle runtime to each cobol program is a bad idea. 5. Like above I don't need to step into these; I just need anim to execute them.
From: Pete Dashwood on 7 Feb 2010 03:02
Derek Schrock wrote: > On Feb 6, 7:29 pm, "Pete Dashwood" > <dashw...(a)removethis.enternet.co.nz> wrote: >> Derek Schrock wrote: >>> Any idea how I can debug cobol that has been generated by Oracle's >>> ProCOBOL. We're running these compiled objects with Oracle's >>> rtsorta32. Now I can simply animate with anim and the .int file >>> however when it comes to a CALL that is part of the Oracle runtime I >>> get an error. I understand why this this happening so I thought >>> maybe I could link the Oracle libs along with the cobol file. >>> $ORACLE_HOME/ lib32/ among A LOT of other libs. This seems like a >>> bad way of doing this. >> >>> Can I load the libraries that are part of rtsorta32 when I run anim? >>> Do I need to build a shared object (not an execuatable ELF such as >>> the rtsorta32 binary) of the Oracle libs? >> >> There are a few things you need to consider here: >> >> 1. Unless the generated PROCobol code is compiled with symbols in it >> (debugging option) you will not be able to step through it in >> Animator. >> 2. Similarly, uness the ORACLE libraries have been compiled with >> symbols in them (and they won't have been for a production release) >> You can't step through those in Animator either. >> 3. Do you really want to make changes to the Oracle RunTime >> libraries? Isn't it enough to just step OVER those calls and check >> the results? >> You didn't mention what the "error" is that you get, but I would try >> stepping OVER and seeing if it still occurs... >> 4. You are right that linking the Oracle libs with the COBOL file is >> not a good idea, and if the libs have no symbols, you will be no >> further ahead. >> 5. You probably COULD build a shared object of the Oracle libs, but, >> again, without the symbols included there is no point. >> >> The general idea is to take the Oracle runtime as read. Debug your >> application around it. >> >> Pete. >> >> -- >> "I used to write COBOL...now I can do anything." > > Sorry maybe I wasn't very clear in the first post. > > 1. I am compiling for debugging. > > 2. I don't need to step in to the Oracle calls, I only need anim (the > animator command) to execute the Oracle CALLs. This where the error > lies. When I try to animate the .int file and I hit an Oracle CALL > ("CALL SQLADR" I think that's one of them) I'll get something along > the lines "Can't find program or method." I knew this was going to > happen because all of the library calls are in rtsorta32 binary (the > Oracle runtime). So I need to figure out how to allow anim to CALL > them since Oracle didn't (or doesn't) provide an animator program. > > 3. No, I don't want to make any changes to that runtime. I just need > to animate cobol generated by the ProCOBOL preprocessor. > > 4. Ok we agree linking the Oracle runtime to each cobol program is a > bad idea. > > 5. Like above I don't need to step into these; I just need anim to > execute them. Fair enough. Sorry, I misunderstood. You can't be the first whowants to do this. Richard suggested checking the docs. Sound like a good idea, but I expect you already did? What about a web search? I found this: http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28428/pcoawin.htm Pete. -- "I used to write COBOL...now I can do anything." |