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

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. 

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 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?

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.

1. set global PATH to the client being tested, base dir and sdk dir, without any other oracle directories in there.
2. start VS2022
3. open a solution, 32 or 64-bit
4. debug the test program
5. 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.

1. set global PATH to the client being tested, base dir and sdk dir, without any other oracle directories in there.
2. start VS2022
3. open a solution, 32 or 64-bit
4. debug the test program
5. 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. 

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.

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

Hi Robert, Sorry, I was under the mistaken impression that the reported problem happens in 64-bit as well as 32-bit so I only tested 64-bit. When I test with 32-bit I get the same behavior that you are reporting so it is a bug. If I start Visual Studio from a Visual COBOL command prompt with 'devenv' then it works correctly.

What is the support incident number that you have open?

The Case Number is 02610282