Debugging with Visual Cobol 8, Visual Studio 2022, and Oracle Instant Client

I'm about to create a support case regarding this. Before I do I'm just curious if anybody has gotten this to work?

On a clean Win10 install

visual studio 2022, version 17.6.2
visual cobol 8 with PU07
oracle instant client 32 and 64-bit, versions 19 and 21

What I'm trying to do is this:

Simple program using cobol and procob with oracle instant client
Program reads db name, user name, and password from environment variables
Connects to database
Reads System Context
Updates client info

No other dependencies, only copy used is sqlca

Before starting Visual Studio two directories are added to the front of PATH

instantclient_xx_xx\\sdk - location of procob.exe, installed as c:\\oracle32\\instantclient_19_18\\sdk or c:\\oracle64
instantclient_xx_xx - location of oracle dll:s

The solution is int/gnt, debug as console application

Compiling isn't a problem. Procob is found, source code is OK.

Setting up a 32-bit project and a 64-bits project.

Testing four different instant clients two 32-bit and two 64-bit (19 and 21) since there has been some changes in version 21.

No combination of clients with different config runs the program to completion.

With 32-bit projects and clients the common error is RTS173 at connect to database.

Quick aside, the normal way we have this configured in the current setup of VS 2019, VC 7, instant client 19 32-bit is to make a copy of the file orasql19.dll as orasql8.dll this enabled things to work without the need of any extra configuration. Even though the normal recommendation is using a procedure pointer or the initcall directive.

Some results, client 19.18 32-bit

no extra config, RTS173 program ORASQL8 at connect
with a copied orasql8.dll in the instantclient dir, RTS173 program ORASQL8 at connect
procedure pointer ORASQL19, RTS173 program ORASQL8 at connect
procedure pointer ORASQL8, RTS173 program ORASQL8 at connect
initcall"ORASQL19", RTS173 program ORASQL19 at debug start
initcall"ORASQL8", RTS173 program ORASQL8 at debug start

With client 21.07 basically the same results, we use entry point ORASQL instead of ORASQL19, but RTS173 is the error

Moving to client 19.18 but 64-bit the results are a bit different. At connect we get SQLCODE -1 which should be unique constraint violated, but when running the tests with connection trace activated we can see that no attempt to connect to the remote server is made. The error is internal to the client. A clue is in the error message which is "ORA-00001: unique constraint (%s.%s) violated" i.e an incomplete error message

Results with client 19.18 64-bit

no extra config, RTS173 program ORASQL8 at connect
with a copied orasql8.dll, SQLCODE -1 at connect
procedure pointer ORASQL19, SQLCODE -1 at connect
procedure pointer ORASQL8, RTS173 program ORASQL8 at connect
procedure pointer ORASQL8 with copied orasql8.dll, SQLCODE -1 at connect
initcall"ORASQL19", at debug start RTS114 Attempt to access item beyond bounds of memory
initcall"ORASQL8", at debug start RTS173 program ORASQL8
initcall"ORASQL8" with copied orasql8.dll, SQLCODE -1 at connect

With client 21.09 basically the same results.

A fairly large number of tests with 32 and 64-bit clients, and different suggested methods to connect to oracle. None works. A mix of RTS173, RTS114, and SQLCODE -1

I'm unable to come up with any additional test and will submit at much wordier entry as a support case. But I cannot help to be curious about if anyone else has tried this and found a workable solution.

Someone at MF really should write a white paper about how to configure visual cobol and pro*cobol/instant client ON WINDOWS since today the information is spread out in different forum posts and knowledge base articles. With a lot of it being quite old or for unix/linux. Not the most fun of subjects but one that needs some love and a document that is current.

TL;DR If you're using VS 2022 and VC 8 with Oracle Instant Client 32 or 64-bit and it's working flawlessy compiling and debugging. How on earth did you do it?

In confusion,

Robert

Just a few suggestions to help diagnose the root cause...

Have you tried debugging to the line of code where the 173 occurs? If so what module is being called.

Perhaps you can confirm with certainty what the PATH is at the time of the call...Add this to your code:

In working Storage:

01 EnvVal pic x(8092).
01 EnvName pic x(32).

..

In Procedure division:
move "PATH" to EnvName
display EnvName upon environment-name
accept EnvVal from environment-value *> After this statement EnVVal will contain the value of PATH at the runtime
display EnvVal

Also, you could try adding the oracle directories to the project properties "Application tab->Environment" prior to running or debugging to see if the PATH is correct when using the IDE:

Apologies, if you've already tried these with no success.

I'm about to create a support case regarding this. Before I do I'm just curious if anybody has gotten this to work?

On a clean Win10 install

visual studio 2022, version 17.6.2
visual cobol 8 with PU07
oracle instant client 32 and 64-bit, versions 19 and 21

What I'm trying to do is this:

Simple program using cobol and procob with oracle instant client
Program reads db name, user name, and password from environment variables
Connects to database
Reads System Context
Updates client info

No other dependencies, only copy used is sqlca

Before starting Visual Studio two directories are added to the front of PATH

instantclient_xx_xx\\sdk - location of procob.exe, installed as c:\\oracle32\\instantclient_19_18\\sdk or c:\\oracle64
instantclient_xx_xx - location of oracle dll:s

The solution is int/gnt, debug as console application

Compiling isn't a problem. Procob is found, source code is OK.

Setting up a 32-bit project and a 64-bits project.

Testing four different instant clients two 32-bit and two 64-bit (19 and 21) since there has been some changes in version 21.

No combination of clients with different config runs the program to completion.

With 32-bit projects and clients the common error is RTS173 at connect to database.

Quick aside, the normal way we have this configured in the current setup of VS 2019, VC 7, instant client 19 32-bit is to make a copy of the file orasql19.dll as orasql8.dll this enabled things to work without the need of any extra configuration. Even though the normal recommendation is using a procedure pointer or the initcall directive.

Some results, client 19.18 32-bit

no extra config, RTS173 program ORASQL8 at connect
with a copied orasql8.dll in the instantclient dir, RTS173 program ORASQL8 at connect
procedure pointer ORASQL19, RTS173 program ORASQL8 at connect
procedure pointer ORASQL8, RTS173 program ORASQL8 at connect
initcall"ORASQL19", RTS173 program ORASQL19 at debug start
initcall"ORASQL8", RTS173 program ORASQL8 at debug start

With client 21.07 basically the same results, we use entry point ORASQL instead of ORASQL19, but RTS173 is the error

Moving to client 19.18 but 64-bit the results are a bit different. At connect we get SQLCODE -1 which should be unique constraint violated, but when running the tests with connection trace activated we can see that no attempt to connect to the remote server is made. The error is internal to the client. A clue is in the error message which is "ORA-00001: unique constraint (%s.%s) violated" i.e an incomplete error message

Results with client 19.18 64-bit

no extra config, RTS173 program ORASQL8 at connect
with a copied orasql8.dll, SQLCODE -1 at connect
procedure pointer ORASQL19, SQLCODE -1 at connect
procedure pointer ORASQL8, RTS173 program ORASQL8 at connect
procedure pointer ORASQL8 with copied orasql8.dll, SQLCODE -1 at connect
initcall"ORASQL19", at debug start RTS114 Attempt to access item beyond bounds of memory
initcall"ORASQL8", at debug start RTS173 program ORASQL8
initcall"ORASQL8" with copied orasql8.dll, SQLCODE -1 at connect

With client 21.09 basically the same results.

A fairly large number of tests with 32 and 64-bit clients, and different suggested methods to connect to oracle. None works. A mix of RTS173, RTS114, and SQLCODE -1

I'm unable to come up with any additional test and will submit at much wordier entry as a support case. But I cannot help to be curious about if anyone else has tried this and found a workable solution.

Someone at MF really should write a white paper about how to configure visual cobol and pro*cobol/instant client ON WINDOWS since today the information is spread out in different forum posts and knowledge base articles. With a lot of it being quite old or for unix/linux. Not the most fun of subjects but one that needs some love and a document that is current.

TL;DR If you're using VS 2022 and VC 8 with Oracle Instant Client 32 or 64-bit and it's working flawlessy compiling and debugging. How on earth did you do it?

In confusion,

Robert

Whenever I have tried Pro*COBOL, I have done the following -

When running a 32-bit Pro*COBOL application, ensure that the folder containing the 32-bit Oracle client DLLs is on PATH before starting Visual Studio.

Likewise, when running a 64-bit Pro*COBOL application. ensure that the folder containing the 64-bit Oracle client DLLs is on PATH before starting Visual Studio.

Adding both to PATH results in failures in one of the configurations as the first one on PATH will be found, which will fail to load if it is not the correct bitism.

Whenever I have tried Pro*COBOL, I have done the following -

When running a 32-bit Pro*COBOL application, ensure that the folder containing the 32-bit Oracle client DLLs is on PATH before starting Visual Studio.

Likewise, when running a 64-bit Pro*COBOL application. ensure that the folder containing the 64-bit Oracle client DLLs is on PATH before starting Visual Studio.

Adding both to PATH results in failures in one of the configurations as the first one on PATH will be found, which will fail to load if it is not the correct bitism.

Yes I am perfectly aware of this. Visual Studio was restarted and the PATH changed to the client to be tested before each run of tests.

That's why we've opened a support case, and why I'm writing here to see if somebody has actually done it.

I'm at the moment, after the first reply to our support case, in the camp of "this hasn't been tested at all"

But at the same time, more than happy to be proven wrong since this is our future target platform.

Just a few suggestions to help diagnose the root cause...

Have you tried debugging to the line of code where the 173 occurs? If so what module is being called.

Perhaps you can confirm with certainty what the PATH is at the time of the call...Add this to your code:

In working Storage:

01 EnvVal pic x(8092).
01 EnvName pic x(32).

..

In Procedure division:
move "PATH" to EnvName
display EnvName upon environment-name
accept EnvVal from environment-value *> After this statement EnVVal will contain the value of PATH at the runtime
display EnvVal

Also, you could try adding the oracle directories to the project properties "Application tab->Environment" prior to running or debugging to see if the PATH is correct when using the IDE:

Apologies, if you've already tried these with no success.

Yes I did not post the source code to the test program. Adding things to environment settings can be useful when compiling but our problem is only with debugging.

The error occurs at one of two points, regardless of 32/64-bit and oracle client version.

* when you start debugging, i.e. before the first statement

* at the oracle connect statement, ie.

exec sql connect :w900-ora-user identified by :w900-ora-passwd using :w900-ora-db end-exec

and since the *module* in question is in the oracle client it is hard to debug any further.

This has really been extensively tested on our side with no success which is why we've opened a case to see MF's opinion on this, plus posting here to see if someone has managed to put together a recipe for VS2022/VC8/Instant Client that actually works.

I mean it works in our current setup of VS2019/VC7/Instant Client so either there something obvious were missing or nobody has done it.

Yes I did not post the source code to the test program. Adding things to environment settings can be useful when compiling but our problem is only with debugging.

The error occurs at one of two points, regardless of 32/64-bit and oracle client version.

* when you start debugging, i.e. before the first statement

* at the oracle connect statement, ie.

exec sql connect :w900-ora-user identified by :w900-ora-passwd using :w900-ora-db end-exec

and since the *module* in question is in the oracle client it is hard to debug any further.

This has really been extensively tested on our side with no success which is why we've opened a case to see MF's opinion on this, plus posting here to see if someone has managed to put together a recipe for VS2022/VC8/Instant Client that actually works.

I mean it works in our current setup of VS2019/VC7/Instant Client so either there something obvious were missing or nobody has done it.

Adding the oracle directory to the Environment on the application tab actually updates the environment (in this case PATH) for running/debugging so a DLL can be resolved/found.

It wasn't clear to me from your response if you checked the value of PATH just before the EXEC SQL CONNECT (using the DISPLAY/ACCEPT code above). For certain with the 173 errors, some module in the oracle client is not being resolved or the correct one is not being picked up.

Yes I am perfectly aware of this. Visual Studio was restarted and the PATH changed to the client to be tested before each run of tests.

That's why we've opened a support case, and why I'm writing here to see if somebody has actually done it.

I'm at the moment, after the first reply to our support case, in the camp of "this hasn't been tested at all"

But at the same time, more than happy to be proven wrong since this is our future target platform.

Hi Robert,

I just set up a Windows 10 VM environment using the same versions of everything as you are, using the Oracle Instant Client 19 for 64-bit and I when I use the set procedure-poiinter method it works and when I use the copy to orasql8.dll method it also works.

I have the PATH set to point to the precompiler directory and then the Instant Client directory.

You might want to run a procmon trace to see where it is trying to load these .dlls?

Hi Robert,

I just set up a Windows 10 VM environment using the same versions of everything as you are, using the Oracle Instant Client 19 for 64-bit and I when I use the set procedure-poiinter method it works and when I use the copy to orasql8.dll method it also works.

I have the PATH set to point to the precompiler directory and then the Instant Client directory.

You might want to run a procmon trace to see where it is trying to load these .dlls?

That's were we are in the support case, i.e. running procmon.

The problem are that we've tested 32 and 64-bit clients without success, i.e.

set global PATH to the client being tested, base dir and sdk dir, without any other oracle directories in there.
start VS2022
open a solution, 32 or 64-bit
debug the test program
fail, repeat

Support say they have this working and you have this working. This tells me were doing something wrong but since there isn't any official documentation from Micro Focus about how to set up Visual Cobol and Pro*Cobol using Instant Client on Windows there is nothing to compare to. This is my biggest complaint about the entire experience, trying to find forum posts and old knowledge base articles that discuss parts of the solution and often with much older versions of the products.

I have no idea how many VC users are using Pro*cobol and at the same time looking at using the latest versions. Perhaps you should just stay on something old that works. Again, the lack of documentation is probably an indication of the number of users.

One fun difference in all this is that if we start a VC command prompt, set our environment variables, and run.exe the int file created in VS2022/VS8 from the prompt the program works. But try to debug it... and no

So we have no ideas left and hope that support can come up with something.

That's were we are in the support case, i.e. running procmon.

The problem are that we've tested 32 and 64-bit clients without success, i.e.

set global PATH to the client being tested, base dir and sdk dir, without any other oracle directories in there.
start VS2022
open a solution, 32 or 64-bit
debug the test program
fail, repeat

Support say they have this working and you have this working. This tells me were doing something wrong but since there isn't any official documentation from Micro Focus about how to set up Visual Cobol and Pro*Cobol using Instant Client on Windows there is nothing to compare to. This is my biggest complaint about the entire experience, trying to find forum posts and old knowledge base articles that discuss parts of the solution and often with much older versions of the products.

I have no idea how many VC users are using Pro*cobol and at the same time looking at using the latest versions. Perhaps you should just stay on something old that works. Again, the lack of documentation is probably an indication of the number of users.

One fun difference in all this is that if we start a VC command prompt, set our environment variables, and run.exe the int file created in VS2022/VS8 from the prompt the program works. But try to debug it... and no

So we have no ideas left and hope that support can come up with something.

If it works when you run your program from a VC command prompt, it may be worth setting COBSW=+A before running, or executing run (+A) your .int program. That will dynamically attach the debugger to your running program.

That's were we are in the support case, i.e. running procmon.

The problem are that we've tested 32 and 64-bit clients without success, i.e.

set global PATH to the client being tested, base dir and sdk dir, without any other oracle directories in there.
start VS2022
open a solution, 32 or 64-bit
debug the test program
fail, repeat

Support say they have this working and you have this working. This tells me were doing something wrong but since there isn't any official documentation from Micro Focus about how to set up Visual Cobol and Pro*Cobol using Instant Client on Windows there is nothing to compare to. This is my biggest complaint about the entire experience, trying to find forum posts and old knowledge base articles that discuss parts of the solution and often with much older versions of the products.

I have no idea how many VC users are using Pro*cobol and at the same time looking at using the latest versions. Perhaps you should just stay on something old that works. Again, the lack of documentation is probably an indication of the number of users.

One fun difference in all this is that if we start a VC command prompt, set our environment variables, and run.exe the int file created in VS2022/VS8 from the prompt the program works. But try to debug it... and no

So we have no ideas left and hope that support can come up with something.

I have not looked thru documentation to see if there is any specific documentation for VC/VS 2022 and Oracle Instant Client.

I imagine if there was, from an execution and debugging standpoint it wouldn't be any different than any other customer library or 3rd party library...i.e. ensure the directory of the library is on the PATH and there are no conflicts on the PATH that take precedent in your and your environment. That seems to be the issue here and the process you are going through now is seeing where these conflicts could be coming from.
Can you verify the complete value of PATH is correct using ACCEPT/DISPLAY ENVIONMENT-NAME ENVIRONMENT-VALUE as I suggested above. The fact that you can run from the command line suggests the environment is different than it is when using the IDE.

Adding the oracle directory to the Environment on the application tab actually updates the environment (in this case PATH) for running/debugging so a DLL can be resolved/found.

It wasn't clear to me from your response if you checked the value of PATH just before the EXEC SQL CONNECT (using the DISPLAY/ACCEPT code above). For certain with the 173 errors, some module in the oracle client is not being resolved or the correct one is not being picked up.

You were correct in that there is a difference, but perhaps not in the way you imagined.

When you wrote about checking PATH in the program I was testing a 64-bit solution and saw what I expected in the PATH.

But when I revisited the 32-bit solution there is a difference. With PATH system-wide containing the two directories for a 32-bit instant client and TNS_ADMIN set system wide as well. No variables in the Application/Environment tab.

Compiling works with pre-compiler as expected. When debugging though the expanded PATH is this, when displayed to stodout,

Info: j9connect, PATH: c:\\projects\\test32bit\\bin\\x86\\debug\\;C:\\Program Files (x86)\\Micro Focus\\Visual COBOL\\Microsoft\\VC\\Tools\\MSVC\\14.16.27023\\bin\\Hostx86\\x86;C:\\Program Files (x86)\\Micro Focus\\Visual COBOL\\Microsoft\\SDK\\10\\Bin\\10.0.19041.0\\x86;C:\\Program Files (x86)\\Micro Focus\\Visual COBOL\\bin\\;C:\\Program Files (x86)\\Micro Focus\\Visual COBOL\\binn\\;C:\\Program Files (x86)\\Micro Focus\\Visual COBOL\\AdoptRedis\\;C:\\Program Files (x86)\\Micro Focus\\Visual COBOL\\bin\\;C:\\Program Files (x86)\\Micro Focus\\Visual COBOL\\binn\\;C:\\Program Files (x86)\\Micro Focus\\Visual COBOL\\AdoptRedis\\;C:\\Program Files (x86)\\Micro Focus\\Visual COBOL\\Microsoft\\VC\\Tools\\MSVC\\14.16.27023\\bin\\Hostx86\\x86;C:\\Program Files (x86)\\Micro Focus\\Visual COBOL\\Microsoft\\SDK\\10\\Bin\\10.0.19041.0\\x86;%PATH%

Look at the end there! Instead of the expanded system PATH you have a reference to the variable %PATH%

The connection attempt in the 32-bit program fails with RTS173 ORASQL8

So it seems that here is one explanation why I've been seeing different results between testing 32 and 64-bit.

Adding a PATH variable with the instantclient directories to Application/Environment solves that particular problem but the PATH you get isn't exactly what you expect. The first dir in the PATH above is missing for instance.

But one step forward to getting a working environment.

I have not looked thru documentation to see if there is any specific documentation for VC/VS 2022 and Oracle Instant Client.

I imagine if there was, from an execution and debugging standpoint it wouldn't be any different than any other customer library or 3rd party library...i.e. ensure the directory of the library is on the PATH and there are no conflicts on the PATH that take precedent in your and your environment. That seems to be the issue here and the process you are going through now is seeing where these conflicts could be coming from.
Can you verify the complete value of PATH is correct using ACCEPT/DISPLAY ENVIONMENT-NAME ENVIRONMENT-VALUE as I suggested above. The fact that you can run from the command line suggests the environment is different than it is when using the IDE.

We now have a working solution for instant client 19.19, 32 and 64-bit

The problems encountered have been a wonderful combination of a bug in 32-bit solutions plus a one character error in an configuration variable that wasn't really needed for the test program but added out of habit.

As seen in the original post we had a number of different tests with various ways to find the oracle routines and connect to the database. We started with 32-bit tests since that is what we are running today on VS2019/VC7/instant client 19.13

We followed the current config by adding two instant client dirs to the beginning of the global PATH plus setting TNS_ADMIN globally as well. So with 32-bit tests we added c:\\oracle32\\instantclient_19_19\\sdk and c:\\oracle32\\instantclient_19_19 to global PATH and set TNS_ADMIN to c:\\oracfg\\network\\admin to point to tnsnames.ora

Here we encountered what looks to be a bug in 32-bit solutions. Building works fine, procob.exe is found and the program compiles. But when debugging the global PATH isn't appended instead the end of the PATH variable, if read from the program, ends with the string %PATH%

This causes all connection attempts, regardless of variant, to fail with RTS173 since no oracle directories are found.

Adding the directories to a PATH variable on the Application/Environment tab fixes connection errors but the PATH produced differs from what is expected and could possibly cause other issues.

When we then moved on to 64-bit solutions the problem with the PATH does not exist. Instead we were derailed by an error in the environment variable NLS_LANG. This wasn't strictly needed for the test program since it didn't display any non-ascii data. But habit added it, plus a simple one character error, instead of SWEDISH_SWEDEN.WE8MSWIN1252 the value was given as SWEDISH.SWEDEN.WE8MSWIN1252, i.e. a period instead of an underscore between SWEDISH and SWEDEN.

In the 64-bit solution, with a 64-bit instant client the connect failed with SQLCODE -1. We did connection logging and saw that the server was never contacted, so the error was local. Apart from that - no clues that the cause was a _spelling error_

When the error was discovered, and fixed, the connect worked in 64-bit.

We tested doing the same NLS_LANG error in 32-bit. There the connect fails with RTS114 attempt to access item beyond bounds of memory.

So neither give the real reason for what's wrong and they fail in different ways. Nice.

We still need to test instant client 21, 32 and 64-bit that have other differences (the death of ORASQL8 ?) but for now we can connect to a database during a debug session with VS2022/VC8/instant client 19.19 both 32 and 64-bit.

The support case will probably end with a defect report for 32-bit solutions that do not seem to expand the PATH correctly.

I stand by my opinion that this really needs official documentation to help other avoid the pain of having thing blow up in different ways without a good explanation.

So to sum this up - in VS2022 and VS8 use 64-bit solutions and make sure you enter your NLS_LANG settings correctly.

/Robert