Arnold Trembley

I do not think this is a true bug, because I don't believe the CBL routines were used properly. I will attach images of the GnuCOBOL programmer's guide pages. In order to APPEND records to a file using CBL_WRITE_FILE, I believe that at Step 9 above you must open the file in input/output mode, then perform CBL_READ_FILE with the FLAG argument set to 128 to request the size of the file in bytes. That should be returned in the OFFSET parameter if CBL_READ_FILE completes successfully. The size of the...

I do not think this is a true bug, because I don't believe the CBL routines were used properly. I will attach images of the GnuCOBOL programmer's guide pages. In order to APPEND records to a file using CBL_WRITE_FILE, I believe that at Step 9 above you must open the file in input/output mode, then perform CBL_READ_FILE with the FLAG argument set to 128 to request the size of the file in bytes. That should be returned in the OFFSET parameter if CBL_READ_FILE completes successfully. The size of the...

Would it be appropriate to truncate the displayed filename to 80 characters (or some similar limit) if the filename is longer than the limit? Would that be a difficult or expensive change for the maintainers?

That certainly sounds like a very reasonable idea for a requested feature for the wishlist. The requirements probably need to be specified with a little more detail. How do we specify when to apply this feature and what is the affect on the two alternate ways to use the ASSIGN clause? How should GnuCOBOL verify the presence of the environment variable at runtime? Should that verification also attempt to validate the correctness of the path/filename in the environment variable, since the path could...

STATUS CODE always '00' -fassign-clause=ibm or -fassign-clause=mf

GnuCOBOL is behaving as documented in the programmer's guide. If there is no Environment Variable SET for the file's ASSIGN name in the SELECT clause, the ASSIGN name is either the literal file name, or the name of a working-storage variable containing the path/filename. Ralph Linkletter is working on code to check for the existence of the environment variable, for the IBM JCL processor for his WINZOS product. He requested this bug to be closed.

Here's a sample program based on ANE5TEST that shows a possibly simpler way to check for the presence of an environment variable.

If you absolutely need to verify that an environment variable named SYSUT2 exists, you could get the value of it before trying to open the file ASSIGN'ed to that environment variable. See section "7.8.1.3 ACCEPT FROM ENVIRONMENT" in the GnuCOBOL Programmer's Guide. ACCEPT identifier-1 FROM ENVIRONMENT literal-1 // "SYSUT2" ON EXCEPTION imperative-statement-1 NOT ON EXCEPTION imperative-statement-2 END-ACCEPT You could even isolate this in a callable subprogram if it creates conflict with Microfocus...