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?

Parents
  • 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.

     

    ***************** 2102-SELECT-MIN. ***************** MOVE LOW-VALUES TO WAPPL-CTRY-CD. MOVE HIGH-VALUES TO WAPPL-ENDBR-CTRY-CD. MOVE ZERO TO WS-FUNCTION-NI. EXEC SQL SELECT MIN(CTRY_CD) INTO :WAPPL-MIN-CTRY-CD :WS-FUNCTION-NI FROM TAPPL WHERE CO_ID = :WAPPL-CO-ID AND CTRY_CD BETWEEN :WAPPL-CTRY-CD AND :WAPPL-ENDBR-CTRY-CD END-EXEC.

     

     

     

  • 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.    

    05 WAPPL-KEY. 354 10 WAPPL-CO-ID PIC X(02). 355 10 WAPPL-CTRY-CD PIC X(02). 356 10 WAPPL-CRCY-CD PIC X(02). 357 05 WAPPL-ENDBR-KEY. 358 10 WAPPL-ENDBR-CO-ID PIC X(02). 359 10 WAPPL-ENDBR-CTRY-CD PIC X(02). 360 10 WAPPL-ENDBR-CRCY-CD PIC X(02). 361 05 WAPPL-MIN-VALUES. 362 10 WAPPL-MIN-CTRY-CD PIC X(02).




  • 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:

     

     

    PS C:\WINDOWS\system32> [System.Text.Encoding]::Default IsSingleByte : True BodyName : iso-8859-1 EncodingName : Western European (Windows) HeaderName : Windows-1252 WebName : Windows-1252 WindowsCodePage : 1252 IsBrowserDisplay : True IsBrowserSave : True IsMailNewsDisplay : True IsMailNewsSave : True EncoderFallback : System.Text.InternalEncoderBestFitFallback DecoderFallback : System.Text.InternalDecoderBestFitFallback IsReadOnly : True CodePage : 1252

     

     

     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:

     

     

    [System.Text.Encoding]::Default BodyName : utf-8 EncodingName : Unicode (UTF-8) HeaderName : utf-8 WebName : utf-8 WindowsCodePage : 1200 IsBrowserDisplay : True IsBrowserSave : True IsMailNewsDisplay : True IsMailNewsSave : True IsSingleByte : False EncoderFallback : System.Text.EncoderReplacementFallback DecoderFallback : System.Text.DecoderReplacementFallback IsReadOnly : True CodePage : 65001

     

     

    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.

  • Thx , I think you have put us on the right track. Process isolation just became an option for Windows 10 Pro yesterday with the 2004 release. We are switching POC work to Windows Server 2019 in the meantime and will try running with isolation there.
Reply Children
  • 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!

     

  • IBM's documentation is cautious because it says by default the codepage is picked up from the OS.

    I think the documentation is trying to protect/warn against the unexpected change of the codepage, for example:

    If you create your data in one codepage and "forcefully" set the codepage to something, it may not work as you expect.