Skip to main content

visual cobol 3.0 cancel programs

  • September 13, 2024
  • 3 replies
  • 2 views

M Carmen De Paz

Hi, we have found a different behavior between a program compiled with VC 3.0 and  VC 8.0

In both compilations whe have set default_cancel_mode=0 (Physical cancels: any program canceled during run-time will be freed from memory, making more memory available.) in the cobconfig file but, In VC 3.0 we can access the addresses of a variable of a program that has been canceled, but in VC 8.0 we cannot.

How is this possible? Was there a bug in version 3?

According to the documentation the default_cancel_mode appears in Visual COBOL 2.3 release

Is there a compiler directive in VC 8.0 that allows us to access the addresses of a variable of  a program that has been canceled as in VC 3.0, but that frees the memory?

3 replies

Chris Glazier
Forum|alt.badge.img+2
  • Moderator
  • 3697 replies
  • September 13, 2024

Hi, we have found a different behavior between a program compiled with VC 3.0 and  VC 8.0

In both compilations whe have set default_cancel_mode=0 (Physical cancels: any program canceled during run-time will be freed from memory, making more memory available.) in the cobconfig file but, In VC 3.0 we can access the addresses of a variable of a program that has been canceled, but in VC 8.0 we cannot.

How is this possible? Was there a bug in version 3?

According to the documentation the default_cancel_mode appears in Visual COBOL 2.3 release

Is there a compiler directive in VC 8.0 that allows us to access the addresses of a variable of  a program that has been canceled as in VC 3.0, but that frees the memory?

Hello,

Under what operation system are you running?
What type of executable are you running: linked executable, .int, .gnt, separate executable and .dll (or .so)?

I tested this here under Windows using our latest product release V10.0 and when physical cancel is set and the called program is dynamically loaded (.dll, .so, int, or gnt)  the memory will no longer be accessible, after a cancel, because the program is removed from memory. If the two programs are linked together into the same executable file, the addresses of data items in the canceled program will still be accessible, but in this case it doesnt actually do a physical cancel.

However, I would not depend on this behavior, always working like this.

A physical cancel of a program containing a data item defined as EXTERNAL in both the called and callee, these data items will still be available in the calling program.

I have not tested with 3.0 yet until I know under which OS you are running?


M Carmen De Paz
  • Author
  • Participating Frequently
  • 11 replies
  • September 13, 2024

Hello,

Under what operation system are you running?
What type of executable are you running: linked executable, .int, .gnt, separate executable and .dll (or .so)?

I tested this here under Windows using our latest product release V10.0 and when physical cancel is set and the called program is dynamically loaded (.dll, .so, int, or gnt)  the memory will no longer be accessible, after a cancel, because the program is removed from memory. If the two programs are linked together into the same executable file, the addresses of data items in the canceled program will still be accessible, but in this case it doesnt actually do a physical cancel.

However, I would not depend on this behavior, always working like this.

A physical cancel of a program containing a data item defined as EXTERNAL in both the called and callee, these data items will still be available in the calling program.

I have not tested with 3.0 yet until I know under which OS you are running?

Hi Chris , we are running on a POWER server under AIX 7.2  (UNIX).

we run  executables.gnt and data are not external defined, 


Chris Glazier
Forum|alt.badge.img+2
  • Moderator
  • 3697 replies
  • September 16, 2024

Hi Chris , we are running on a POWER server under AIX 7.2  (UNIX).

we run  executables.gnt and data are not external defined, 

It seems to me like under V3.0, even though the tunable was set for physical cancels that perhaps a logical cancel was actually being done.

Are you certain this was actually doing a physical cancel? Could you see that memory was released after the CANCEL was issued?