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?