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
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 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?
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 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.
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?
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.
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 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 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?
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?
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?
Strange. Are you using V2.3? Try setting it in the project properties and see if it does make a difference.
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?
No, 2.2. And setting dd_CNV in the Project Properties>Environment didn't help.
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?
Leaving for the day.
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'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?
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 would recommend that you upgrade to 2.3 as it does appear to be fixed. If you still have a problem in 2.3 then contact Supportline and we will take a look.
Thanks.
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?
OK ... downloading. Will let you know.
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?
That was it. The "problem child" program is now running as expected.
Thank you for your time and help!
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?
Found this in the Micro Focus Visual COBOL 2.3 for Visual Studio Release Notes>Resolved Issues>Library:
"Using a dd_ environment variable to specify the path used in CBL_LOCTE_FILE now works as expected."
Apparently the bug was in code shared by multiple call-by-name library routines, like CBL_CHECK_FILE_EXIST.
And we now have closure. :-)
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?
Excellent! Remember that you will also need to upgrade your COBOL Server product to the same 2.3 level when you are ready to deploy.
Thanks.
