Having written and delivered several hundred thousand lines of COBOL code to end-users, I am concerned about the ability to support COBOL products in the field. GNUCOBOL's function, EXCEPTION-FILE returns the Select Name, which may not be helpful in determining the actual name of the file in error as it is known to the filesystem. Looking at the runtime library, it appears that the choice of select_name was intentional, but it should definitely be the real filename instead. The following patch resulted...
Thank you, Simon. I have been looking into libcob/fileio.c and libcob intrinsic.c for ways to replace select_name with filename. If I can get a FILE pointer or the fd number, I can use the realpath() function to determine the file name. // some random file FILE *fp = fopen("make.out", "r"); // now that the FILE is open, we can get the filename printf("filename: %s\n", fpfname(fp)); char fpfname(FILE fp) { int fd; char ProcPath[32]; if (fp) fd = fileno(fp); if (fd > 0) { sprintf(ProcPath,"/proc/self/fd/%d",fd);...
// In the alternative, simple code such as the following (pseudo-code) could provide a // down-and-dirty method of matching filenames with fd's or Fp's. // We know for sure that Linux isn't going to do it, so it will have to be tracked inside // the runtime libraries. // Mostly in libcob/fileio.c char file_open_name[COB_FILE_MAX]; char error_filename[COB_FILE_MAX]; struct { char filename; int Fd; FILE Fp; } Fn_tbl[COB_MAX_FILES]; uint32_t Fn_tbl_idx=0; FILE Fp; int Fd; const char fmode; mode_t mode;...
// libcob/common.h // contains a structure which is partially represented below // it contains a file descriptor (int fd) and org_filename // which are two of the fields I need for exception handling. // Why not clean this code up, remove some unnecessary free(filename) // code and add a pointer to a FILE data structure so it could // be matched to get the filename? typedef struct __cob_file { const char select_name; / Name in SELECT / unsigned char file_status; / FILE STATUS / cob_field assign;...
I think I should come clean relative to my comment that "most of my code compiled without errors." In reviewing my journal of source code modifications, I couldn't find any that resulted from a failure of GNUCobol. All were a result of configuration errors or modifications I have made to my software to upgrade known deficiencies. The only incompatibility I found was when calling GNUCobol from C, I had to provide parameters as an array (cob-argv) as opposed to a scalar in RMCobol. In other words,...
Thank you. The --debug directive helped a lot. Compiling with --debug, the following statements return the program name and line number, the COBOL verb, an error number, and the variable Sysdates-File as specified in the select statement. I don't use a hard-coded file specification in the select statement because the software doesn't have a fixed directory structure. This allows users to create data directories to handle multiple business entities. open i-o Sysdates-File. if Fs1 not = "00" display...
I recently downloaded and built GNUCobol-3.3, and I couldn't be more impressed. The build and install went without a hitch. I dug up some code that my company had written in the late 1980s using RM Cobol85, and Micro Focus. GNUCobol compiled most of my programs without error using the -std=rm directive. The software is a scheduling and accounting suite consisting of more than 270,000 lines of COBOL in more than 300 programs. Here's where I think i messed up. Currently my error handling is ad hoc...