Data file mapping in Visual COBOL

We are migrating a native Windows application from Net Express 5.1.  In it we use several of the file handling call-by-name library routines and we've hit a snag with the first program that uses one, specifically CBL_CHECK_FILE_EXIST.  The scenario:

User environment variable dd_CNV defined with a value of C:\NEAS\Files\CNV.  The COBOL source code is "CALL "CBL_CHECK_FILE_EXIST" USING JOIN-BUFFER, FILE-DETAILS."  At the time of execution in both the Net Express 5.1 and Visual COBOL 2.2 IDEs the value JOIN-BUFFER is "CNV\WYP46D01.228     ", and a file WYP46D01.228 exists in C:\NEAS\Files\CNV.  Net Express 5.1 works, returning zero in RETURN-CODE.  Visual COBOL 2.2 gets a non-zero value in RETURN-CODE that translates to 9/13, RTS error/file not found.

Do the file handling call-by-name library routines NOT do file mapping in Visual COBOL like they do in Net Express?

  • I tested this here with VC 2.3 and it works fine but the environment variable name must be preceded by a $, i.e $CNV\WYP46D01.228    

    Thanks

  • I took the following from the web-based documentation "Micro Focus Visual COBOL 2.3 for Visual Studio 2013 > Programming > Data Access > File Handling > File Handling Guide > Filenames"

    When presented with a filename (which may be a literal, the contents of a data item, or, in the case of the ASSIGN TO EXTERNAL syntax, an external reference), the File Handler follows this procedure:

    1.Isolates the first element of the filename, that is, all the text before the first slash character (\), all the text if the name does not include such a character or nothing if the filename starts with a slash character.

    2.If the first element begins with two dollar characters ($$), indicating that the file is located on a Fileshare server, switches the search process to that Fileshare server, and continues the filename mapping process with the next element.

    3.Removes the leading dollar character ($) if it is present, prefixes the characters "dd_" to this first element and searches for an environment variable with this name.

    4.If it does not find this environment variable and either the ASSIGN EXTERNAL syntax was used or the element began with a dollar character, looks for an environment variable with the same name as the element (minus the leading dollar character if present).

    5.If the search is unsuccessful, leaves the element unchanged, except in the case where the element begins with a dollar character and the whole filename contains at least one slash character. In this case, the whole of the first element, together with the first slash, is removed from the name.

    I believe #3 represents our case.  The documentation appears identical to that in Net Express, in which our code works "as is" (no leading $ in JOIN-BUFFER).

    But I gave it a try with JOIN-BUFFER containing "$CNV\WYP46D01.228   " and got the same error.  

    Only when I edited the contents of JOIN-BUFFER immediately prior executing the library call to contain the expanded/absolute path did I get a zero RETURN-CODE value.

    It's as if the filename mapping now only occurs for COBOL IO statements and not for the File and Filename Routines, or at least CBL_CHECK_FILE_EXIST.

    Do you think an Incident Report is warranted?

  • I tested this under Net Express 5.1 and Visual COBOL 2.3 and it works perfectly with the preceding $. Without the $ it fails in both as it will not know that CNV is an environment variable so will not expand it.

    I tested using the following program where I am setting CNV=C:\temp\ in Net Express project properties-->IDE and in Visual COBOL under Project Properties-->Application-->Environment Variables. The file chris.txt exists in C:\TEMP

           identification division.
           program-id. Program1.
    
           environment division.
           configuration section.
    
           data division.
           working-storage section.
           01 buffer   pic x(256) value "$CNV\chris.txt".
           01 cblt-fileexist-buf.
              03 cblte-fe-filesize        pic x(8) comp-x.
              03 cblte-fe-date.
                  05 cblte-fe-day         pic x comp-x.
                  05 cblte-fe-month       pic x comp-x.
                  05 cblte-fe-year        pic x(2) comp-x.
              03 cblte-fe-time.
                 05 cblte-fe-hours        pic x comp-x.
                 05 cblte-fe-minutes      pic x comp-x.
                 05 cblte-fe-seconds      pic x comp-x.
                 05 cblte-fe-hundredths   pic x comp-x.
    
           procedure division.
    
               call "CBL_CHECK_FILE_EXIST" using buffer
                  cblt-fileexist-buf
               display return-code
               goback.
    
           end program Program1.
    

  • The failure in Net Express when no $ is present is because, according to step/rule #3 in the File Handler's file mapping process, the check is for an environment variable named dd_CNV.  You have just CNV, which is the environment variable name checked according to rule #4.  We are using the "dd_" form for ALL of our environment variable names.

    Please change the environment variable names to dd_CNV in both projects, remove the $ from both programs, and try it again.

  • I just changed this to use dd_ in env variable and removed $ from filename in program and it works in Net Express 5.1 and Visual COBOL 2.3 native code. It does however fail in a managed code .NET project so there is an incompatibility.

    Are you using a managed code .NET project?

  • We aren't.  We're building our batch application solution one project at a time using only Native>Console Application and Native>Link Library COBOL project templates.  Debug configuration, x86 platform.  And BTW, our dd_CNV is set as a User environment variable vice an IDE/Project-assigned environment variable.  But that shouldn't make a difference?

  • Strange. Are you using V2.3? Try setting it in the project properties and see if it does make a difference.

  • No, 2.2.  And setting dd_CNV in the Project Properties>Environment didn't help.

  • I'm back.

    OK.  Still VC 2.2 for VS 2013.  Created new solution, new COBOL native Console Application project, Debug/x86, and created 2 environment variables in the Project Properties>Application>Environment:

    dd_CNV set to C:\NEAS\Files\CNV

    CNV set to C:\NEAS\Files\CNV

    Cut and pasted relevant COBOL statements into the .cbl generated by VC when the project was created:

          identification division.

          program-id. Program1.

          environment division.

          configuration section.

          data division.

          working-storage section.

         *

          01  JOIN-BUFFER                 PIC X(90)   VALUE

              "CNV\TestCheckFileExist.dat    ".

         *

          01  FILE-DETAILS.

              10  FILE-SIZE               PIC X(8)    COMP-X.

              10  FILE-DAY                PIC X(1)    COMP-X.

              10  FILE-MONTH              PIC X(1)    COMP-X.

              10  FILE-YEAR               PIC X(2)    COMP-X.

              10  FILE-HOUR               PIC X(1)    COMP-X.

              10  FILE-MINUTE             PIC X(1)    COMP-X.

              10  FILE-SECOND             PIC X(1)    COMP-X.

              10  FILE-HUNDREDTH          PIC X(1)    COMP-X.

          procedure division.

              CALL "CBL_CHECK_FILE_EXIST" USING JOIN-BUFFER,

                                                FILE-DETAILS.

              DISPLAY RETURN-CODE.                                      

              goback.

          end program Program1.

    Created the TestCheckFileExist.dat file referenced in JOIN-BUFFER in C:\NEAS\Files\CNV folder.

    Built the program and set a breakpoint at the DISPLAY statement.

    Started Debugging and examined RETURN-CODE at the breakpoint.  Value was 000014605.

    Added "$" to front of JOIN-BUFFER's value, now reads "$CNV\TestCheckFileExist.dat    ".

    Saved, built, and started debugging again.  RETURN-CODE value at the breakpoint is 000000000.

    So, for me and my partner's installations at least (his PC is where we hit this problem first), step/rule #3 of the File Handler's File Mapping process appears to be broken.

    Chris, what do you recommend; upgrade to VC 2.3 for VS 2013 (because you can't seem to reproduce this problem there), or open an incident with SupportLine?