William Lightner

The problem appears to be the expected location of the installation. It is assuming c:;\Unicon. If you install it anywhere else it can't find the interpeter and/or the runtime This happens for both inconx and unicon, and for both 13.1 and 13.2 (all I've tried it on). It is NOT good practice to install ANYTHING in the root (C:) directory in Windows. Nothing is supposed to install there.

I'm seeing this problem, too. And incont files from the command line. I then uninstalled 13.2 and installed 13.1 instead. Now the UI doesn't work (can't find w/wicont), but I can run icont from the command line.

I pulled down the 2.2 release candidate and compiled it with MS/VS 2017 (32-bit. VBVISAM was not available for 64-bit. At least, it wasn't included in the win_prerequisites_vc11.7z). It Worked! First time I've got an MS/VS build to work (I got mingw32 to build for the prior release candidate). Unfortunately, when I tested compiling my WSSORT program (same as above), it still gave me errors for the nested occurs depending on. Setting environment for GnuCOBOL. compile... -conf=c:\devtools\gnucobol\config\ibm.conf...

I pulled the most recent release. Unless I'm doing it wrong (which is possible) it still isn't compiling nested ODOs. I realize this was pulled from the prior release candidate, but I was hoping it would make it into the final product, and somewhere I got the idea that it was in the works. Perhaps I'm just doing it wrong? I'm getting this error: WSSORT.cob: 133: error: reference to item containing nested ODO is not implemented This is my compile command: /cygdrive/e/DevTools/Cobol/gnu-cobol-2.0_rc-2_win/gnu-cobol-2.0/cobc/cobc.exe...

I apologize for the long delay in responding. Yes, I have tried Arnold's build guides. More than once. The build has always failed, for any of several reasons. I eventually ran out of time/patience for diagnosis and filling in the blanks. It mostly comes down to all the things you "just gotta know", that don't always make it into such guides. ...until yesterday, when the most recent source download successfully compiled with CygWin64. Now I am going to try to get the MingW version running, so I can...

Update: The error reported for the COPY/REPLACING was not a compiler error. It was my mistake. The copybooks in question had been "lost" at one time, and in the recreation, one of them was created with the contents of a second one. The tag between the ":" was thus incorrect. If there is a problem with the compiler, it is that it did not report that it couldn't find a match; it reported a character problem with the ":". Another person recently filed a related report, and when I went to make a reply...

I’m afraid I broke protocol and mentioned two bugs (and my personal frustration)....

I’m afraid I broke protocol and mentioned two bugs (and my personal frustration)....