configuration error: default.conf: No such file or directory

[TriAttack]

Hello again. Well, cobc works... for --help and --version. When it comes actually compiling a program, it doesn't seem to work. Some background may be needed.
I have very little experience with shells and configuring programs, so after a few frustrating days of trying to configure and install the course code I just downloaded the 3.1.2 binary from here: https://www.arnoldtrembley.com/GnuCOBOL.htm

After messing with some path environment variables on my Windows 10 device, cobc was recognized. However, whenever I actually try to compile a file in vscode or the cmd window, it throws the error was shown in the title. What should I do? I've already tried changing the windows environemtn seetings within vscode by pasting the answer found here: https://stackoverflow.com/questions/56204914/how-to-compile-with-gnucobol, but the json checker is throwing up error "Incorrect type. Expected one of string, null" on nearly every line. I'm at the end of my rope, i cannot figure out what is happening for the life of me. Any help would be appreciated.

[Arnold Trembley]

What does your COB_CONFIG_DIR environment variable point to?

Did you run the set_env.cmd script to set PATH and environment variables for the GnuCOBOL compiler?

I am way behind on updating this guide, but it might help you with getting started:
https://www.arnoldtrembley.com/Using-MinGW-GnuCOBOL-Guide-draft-V2.pdf

[TriAttack]

Thank you for responding! I could not have gone as far as I did without your binary executable and instructions. I did in fact run set_env.cmd, which I'm pretty sure is part of how cobc --version works in the first place. However, I do not know what the COB_CONFIG_DIR environment variable is, or where to find it.

[Arnold Trembley]

If you view or edit the set_env.cmd script, you can see all the environment variables it sets, and the change it makes to your PATH. The thing to remember is that all those changes are forgotten when the cmd.exe window is closed. While it is possible to make permanent changes to your cmd.exe default PATH and environment variables, I do NOT recommend that because it is difficult to change them later. And it will be necessary to change them when you upgrade to a newer version or simply want to change the name or path of the compiler folder.

Once you install the GnuCOBOL binary, open a cmd.exe window and navigate to that folder. Then run the testgc.cmd script. It calls set_env.cmd. The script will compile and a test program two different ways and execute it. The test programs are created as temp files and automatically deleted, but it's a way to verify the compiler is installed correctly.

There is also a supplied bat file named gcx.cmd for compiling COBOL programs.

You can click on the "set_env.cmd" file and "send to" the desktop. That will make a shortcut that will open a cmd.exe window, run set_env.cmd, and leave the window open. Then you can CD (change directory) to a folder that contains your .cob or .cbl source files and compile. You can use any text editor with GnuCOBOL.

I strongly recommend keeping your source and object code in your own folders, and NOT in the GnuCOBOL compiler folder.

I have not figured out yet how to integrate GnuCOBOL into VS Codium, but I have been able to open a cmd.exe window in VS Codium, and switch between editing, compiling, and testing.

Good luck, and feel free to keep asking questions in the forum.

[TriAttack]

wow, that's brilliant! Although you might be a bit late on the "dont permanantly change the path variables" because I did the same thing for mingGW and now gnuCobol to get cobc to work in the first place. however, I will definitely be using the window. I am looking forward to vscode integration, if it ever comes. Thanks again.

[Simon Sobisch]

If you want to run that in vscode just start set_env.cmd, then start vscode from there. This way you have everything set up and can use cobc/cobcrun from anywhere, including it's integrated terminal and possible extensions.

As an alternative don't call cobc from vscode, but a wrapper script instead (that's how I did this when doing it), the gcx.cmd may be usable for this (I don't know).

In vscode you'd install a COBOL extension, bitlang.gnucobol would be at least useful and also provides an error matcher for cobc. This can be used to not (only) compile via the terminal of vscode, but via a task: then ctrl+b and the program compiles and you see any issues in the problem pane of vscode and in your editor, too.

[TriAttack]

Ok, well, the solution from Arnold kind of works, but there's something going wrong. Right after a restart it opens. But after some point it and the other cmd files will opne and close very quickly without and apparent reason. Trying to open these files in another terminal reveals and an error: "'find' is not recognized as internal or external command, operable group program, or batch file". Opening up set_env shows that there is exactly one "find" command, and it looks pretty important. However, if I click the .cmd file fast enough, it opens a command window that closes if I type anything. The mystery deepens, though I suspect that it thinks there's already another instance of the program running. Any help would be greatly appreciated.

[TriAttack]

An interesting property is that running the program as an administrator makes it work perfectly, so it may be something with the permissions granted.

[TriAttack]

AND, running as administrator allows me to open multiple instances. So there's definitely something with the check going on.

[Arnold Trembley]

I find that it works better to run the GnuCOBOL compiler as administrator, but then I am the only user of my Windows PC.

[Arnold Trembley]

"find" is a built-in command in the cmd.exe shell, and should always be there, even if you are running a powershell window. So I am not sure what is going wrong.

The set_env.cmd script uses "find" in its end logic:

:: Compiler version output
:cobcver
echo.
:: new cmd to stay open if not started directly from cmd.exe window 
echo %cmdcmdline% | find /i "%~0" >nul
if %errorlevel% equ 0 (
  cmd /k "cobc --version"
) else (
  cobc --version
)

Basically, it's looking for the special environment variable "%~0" to see if set_env.cmd was entered at the command line or started from a windows shortcut. "cmd /k" starts a command window to run the "cobc --version" command and Keeps the cmd.exe shell open. Otherwise, it starts a cmd.exe session to run the "cobc --version" command and returns to the calling cmd.exe shell.

It's possible that you may have set some permanent default environment variables or PATH updates that conflict with the temporary ones. This is another reason to be very careful when adding permanent defaults to your cmd.exe USER and SYSTEM variables.

When you run set_env.cmd, these are the critical updates it makes:

COB_CFLAGS=-I"C:\GC31-BDB\include"
COB_CONFIG_DIR=C:\GC31-BDB\config
COB_COPY_DIR=C:\GC31-BDB\copy
COB_LDFLAGS=-L"C:\GC31-BDB\lib"
COB_LIBRARY_PATH=C:\GC31-BDB\extras
COB_MAIN_DIR=C:\GC31-BDB\
Path=C:\GC31-BDB\bin;C:\Program Files\Common Files\Microsoft Shared\Windows Live;...etc.

In this example, my compiler is in a folder named C:\GC31-BDB. Your "COB_MAIN_DIR" may have a different name. The important part to add to the front of your path is the path to the \bin folder in your COB_MAIN_DIR.

You can type "SET | MORE" in your cmd.exe shell to view your entire set of environment variables. Or you can type commands like this (or build them into a bat/cmd file):
ECHO cob_main_dir = %cob_main_dir%

@echo off
rem cls
echo.
echo Check for GnuCOBOL PATH and Environment variables 
echo.
echo COB_MAIN_DIR          = %COB_MAIN_DIR% 
echo COB_LIBRARY_PATH      = %COB_LIBRARY_PATH% 
echo COB_CONFIG_DIR        = %COB_CONFIG_DIR% 
echo COB_COPY_DIR          = %COB_COPY_DIR% 
echo COB_CFLAGS            = %COB_CFLAGS% 
echo COB_LDFLAGS           = %COB_LDFLAGS%
echo COB_SCREEN_ESC        = %COB_SCREEN_ESC%
echo COB_SCREEN_EXCEPTIONS = %COB_SCREEN_EXCEPTIONS%
echo.
path
echo.

If you have made permanent changes to your defaults that you need to undo, then refer to that PDF in my earlier posting. There is a Windows tool for updating USER and SYSTEM variables, or you can update them in the registry. But first you have to find the permanent defaults.

Good Luck!

[TriAttack]

Ok, I've tried two more things so far. First, I found the control panel app and removed the path I added. Now cobc is no longer recognized.

Next, I tried doing the above terminal commands, but the terminal returned them verbatim so nothing really happened. Unfortunately, set_env is still not opening.

[Arnold Trembley]

So, either you need to click on the set_env.cmd shortcut to open a cmd shell, or you open a cmd.exe shell and run set_env.cmd (either by navigating to the GnuCOBOL folder where it's installed, or by CALLing it using its full path name). The set_env.cmd script must be run in the folder where it resides in order to to pick up the current location of the compiler.

Remember, every time you close the cmd.exe shell, you lose all your session environment variables. They go away. So you always need to run set_env.cmd when you start a cmd shell when you want to run the compiler or need the GnuCOBOL environment variables to find the runtime libraries.

If set_env.cmd is not opening, it's possible the file has been corrupted. You might need to reinstall it or restore from a backup.

[TriAttack]

yep, set_env.cmd is simply not working, and the other .cmd files aee not working wither. I think I need to start from scratch and download again.

[TriAttack]

additionally, for some reason going directly to the folder with gnucobol allows for compilation but not execution. as said before, I'm just going to wipe the slate clean and bring gnucobol into opencobol.

[TriAttack]

Last try before I go to sleep. The program isn't working in MingGW either. Specifically, when I try to compile this program:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. Experiment_1.
       DATA DIVISION.
       FILE SECTION.
       WORKING-STORAGE SECTION.
           01 Response Pic A(5).
           01 CurrentTime.
               02 CurrentHour PIC 99.
               02 CurrentMinute PIC 99.
               02 CurrentSecond PIC 9(4).
           01 Num1 PIC 9 VALUE 2.
           01 Num2 PIC 9 VALUE 3.
           01 Num3 PIC 9 VALUE 6.
           01 Num4 PIC 9V9.
       PROCEDURE DIVISION.
       MAIN-PROCEDURE.
            DISPLAY "How are you doing?"
            ACCEPT Response
            DISPLAY "'",Response, "'"
            DISPLAY "One fish, " WITH NO ADVANCING
            DISPLAY "Two fish, "
            DISPLAY "Red fish, " WITH NO ADVANCING
            DISPLAY "Blue fish"
            ACCEPT CurrentTime FROM TIME
            DISPLAY "Hour is " CurrentHour
            DISPLAY "Num1: " Num1 SPACE WITH NO ADVANCING
            DISPLAY "Num2: " Num2 SPACE WITH NO ADVANCING
            DISPLAY "Num3: " Num3 SPACE WITH NO ADVANCING
            MOVE 0 TO Num4
            DISPLAY "Num4: " Num4
            ADD Num1 to Num2 GIVING Num4
            DISPLAY "Num4: " Num4
            SUBTRACT Num2 FROM Num3 GIVING Num4
            DISPLAY "Num4: " Num4
            DIVIDE Num3 by Num2 GIVING Num4
            DISPLAY "Num4: " Num4
            MULTIPLY Num2 BY Num4
            DISPLAY "Num4: " Num4
            COMPUTE Num4 = (3/2)
            *>Apparently, the compiler does not recognize the + and -
            *>symbols in COMPUTE
            DISPLAY "Num4: " Num4
            STOP RUN.

       END PROGRAM Experiment_1.

The MingGW shell throws this error:

fatal error: libcob.h: No such file or directory
12 | #include <libcob.h>
| ^~~~~~~~~~
compilation terminated.</libcob.h>

I'm pretty sure this means it's reading a c program, when it should probably be reading the cobol file first. Honestly, this has only become more and more confusing as this has gone on.

[Arnold Trembley]

If you only installed MinGW because you wanted GnuCOBOL, you can uninstall it. Unless you use MinGW to build C programs for windows, you don't need it to run the prebuilt GnuCOBOL binaries. I only use MinGW to build the GnuCOBOL compiler.

It can definitely cause conflicts if you have both MinGW AND GnuCOBOL installed. It is possible to have both installed at the same time, but you need to be very careful managing your setup and environment variables.

The GnuCOBOL compiler has an embedded version of the MinGW GCC compiler in it, because GnuCOBOL translates COBOL to C, and MinGW/GCC compiles it.

So unless you plan to use MinGW to build the GnuCOBOL compiler, OR to build C programs for Windows, I recommend uninstalling MinGW and just using the prebuilt GnuCOBOL binary.

I hope that helps!

[TriAttack]

oh, I use MinGw for the c compiler, so its not going anywhere soon. But I did not sinder the possibility of a conflict. Is it a bad tome to say that I also have the open cobol ide which has an earlier version of gnucobol?

[Arnold Trembley]

Well, having MinGW, GnuCOBOL, and OCIDE installed on the same Windows box does increase the opportunities for conflicts. But it is possible to make them all work without breaking each other.

Some people really like OCIDE, and it is definitely possible to connect it to newer versions of MinGW GnuCOBOL, including the MSYS2 64-bit versions.

[TriAttack]

without vscode integration that might be the way to go.

[Simon Sobisch]

It could produce a conflict, but only if you have those in PATH.... which is a reason to use either starter scripts for switching those, it to use wrapper scripts (cobc.cmd instead of calling cobc.exe) calling them by their full path.

But for "just C" you can even use the GnuCOBOL mingw package for that, as it has GCC included.

The easiest way to use OCIDE with a newer version is to rename the GnuCOBOL folder contained in it and put the newer version in there with the same name - just works.
Otherwise you can go to it's compiler some and adjust the path.

[TriAttack]

I think I'm going to do that woth a fresh download, great idea!

[Arnold Trembley]

Once you get your GnuCOBOL setup sorted out, that program should compile successfully. Here are the results I got:

Microsoft Windows [Version 10.0.19044.1645]  Sat 05/07/2022   2:00:09
C:\COBOL>experiment-1
How are you doing?
ok
'ok   '
One fish, Two fish,
Red fish, Blue fish
Hour is 02
Num1: 2 Num2: 3 Num3: 6 Num4: 00
Num4: 50
Num4: 30
Num4: 20
Num4: 60
Num4: 15

Microsoft Windows [Version 10.0.19044.1645]  Sat 05/07/2022   2:00:36
C:\COBOL>

[TriAttack]

Ok, so I've finally arrived at a solution. Straight up replacing the openCobol version in OCIDE does just work as Simon suggested, except I just recompile my files(well, the two files). Deleting MinGW seems to have made the command prompt about GCC, and cobc still doesn't work in the terminal, but since it works perfectly im the ide I'm pretty much good. In fact, the tree view of the sectiona of the program makes it better than extension-less vscode. Thank you all for your help and patience with my technicals. Now, time to find a community to help me with the language.

[Simon Sobisch]

Now, time to find a community to help me with the language.

looks like you're already there ;-)