From: Derek Schrock on
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
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
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
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
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."


 |  Next  |  Last
Pages: 1 2 3
Prev: Day of Any Week
Next: ANN: OpenCOBOL Programmer's Guide