Docker High-Values Low-Values

We are running Visual COBOL 5.0 compiled to native code and running on Windows 10 with a DB2 database hosted on AIX.  When we run that code, SQL queries using HIGH-VALUES and LOW-VALUES moved into host variables  work as expected.  When we try to run the same executables/workload bound against the same db running in a Windows Docker container, the values for high-values and low-values  or incorrect and queries using those COBOL values fail.  How do we configure our Windows Docker environment for consistent use of low-values and high-values?

There should be no difference when running the same application within a Docker container if it has been compiled using the same set of directives. LOW-VALUES and HIGH-VALUES refer to the characters in the lowest and highest ordinal position, respectively in the program collating sequence. This would normally be X"00" and X"FF".

Can you provide an example of how your program is using these figurative constants in relation to your database queries and how they are failing?

What values are being used instead of the expected ones?

Under what OS are you running your Docker container?

Thanks for the reply  .  The SQLCODE is zero and the query executes without error, but the expected value is not returned.  When we examined the contents of the variables holding CTRY-CD and ENDBR-CTRY-CD they did not contain the expected values.  The fields, both high and low,  appeared to contain spaces when run within Docker (we aren't yet set up to remotely debug Docker) .  When run outside of Docker, the variables appear to contain the expected ASCII collating sequence boundary values. 

We're using Visual COBOL 4.0 (not 5.0) for Docker running in a base image ltsc2019 (LTSC) docker pull mcr.microsoft.com/windows/servercore:ltsc2019 .

In the snippet below,  WAPPL-CO-ID is set up earlier.

So you are saying that the following fails:

    BETWEEN  :WAPPL-CTRY-CD AND :WAPPL-ENDBR-CTRY-CD

because these two data items both contain spaces at the time of the SELECT even though you are initializing them with LOW-VALUES and HIGH-VALUES respectively?

Are you using the DB2 directive to compile or are you using OpenESQL with an ODBC driver?

How are these host variables defined in the program?

How are you determining that these data-items = spaces?

 , yes that code fails when run in Docker.  If we hard code our own values to replace the low and high values, the query works running inside or outside Docker.

The host variables are defined as shown below.  We are using DB2 and not OpenESQL .  We don't yet have remote debugging working, so I don't know what the values are within COBOL.  Once represented on the web browser of the consuming app, they look to be spaces.    

We're thinking it's a code page issue.  We're connecting to a DB2 LUW instance on an AIX server created with code page 1252.

The application works when run outside of Docker on Windows 10 with the following settings:

 Inside Docker, the evaluation of High Values/Low Values seems affected.  The settings in Docker dictated by the base Windows Image and ,apparently, not  easily changed are as follows:

Is using the "program collating sequence" clause of the "object computer" paragraph a possible solution?

We're working on pre-compiling, compiling, and binding the COBOL program with embedded SQL within the container in which it is to execute to see if this makes a difference.  Previously, the executables were created on a separate build server.  A formal support incident has been created.

My understanding is that if you run docker with hyper-v isolation then this is true.

If however, you use process isolation aka "--isolation=process" it is not.

We moved our Docker to Windows 2019 to run there in process isolation mode in order to have the container's default encoding set to 1252 in line with how our application's DB2 database was encoded. This had no effect on how DB2 client derived the codepage it used. It looks like DB2 client continued to use UTF-8 (1208) despite the encoding shown in Docker. Against IBM's recommendation (see https://www.ibm.com/support/pages/setting-db2codepage1208-may-result-incorrect-character-data-insertion-sql0191n) , we set the DB2CODEPAGE registry value to 1252 and tried our application again. HIGH-VALUES was then evaluated correctly within embedded SQL and our application started to work as expected.  The application works in Docker with the forced DB2codepage both with in Windows 2019 with process isolation and also Windows 10 build 17763.

We don't yet know if forcing the DB2CODEPAGE will introduce other issues, but, so far, so good!