Cobol Windows 10 64 Bit

[Jens Loco]

Ineed a program I wrote in a .cobc file to be compiled to a windows executable file.The file is called main.cobc

Compiling it with: cobc -x -free *.cobc -o main

makes it a linux executable which is ok, but can't be run directly on windows.

I have gnucobol (OpenCOBOL installed on my linux ubuntu VM.

Please help. Is there a way I could compile it in a way that it's windows compatible?

That's not the question that is in the title, so answering that first.

Can you do it from Ubuntu?

Yes, ... as cobc uses an underlying C compiler and you can do cross-compiling with C compilers (you'll likely use gcc-mingw-w64-i686 or gcc-mingw-w64-x86-64).

That's the "long question". Yes, and very easy.

When you do have a Windows environment and want to generate an executable for that - no need for doing this in a separate VM (or WSL) in the first place, just get the official ready-to-use MinGW packages for GnuCOBOL (available for both 32 and 64bit) and compile directly on the Windows machine.

On the home 1803 rm-cobol 7.0 runs like a champ, whereas on the Pro version 1803, RM 7.0 will not run. When I execute the batch to run the software the command line window appears, but the runtime does not appear as a process unless I 'X" the window. The machine will run any program that does no screen i-o. Also the compiler will compile but will not open a window.

Let me add this: On the pro machine, the runtime will run (for a example a print-only program) if there is no screen i-o. As if it will not create a window. I should point out that this is a standard windows 10 machine with no special display options. The RM runtime ran perfectly until the introduction of build 1709 of Windows 10. This problem arose at that time and persists with build 1803.

In the past it was normal tu use > to redirect DISPLAYs to a file like runcobol myprogram > myoutput.txt, but this is not working anymore under Windows. Is it possible to redirect the output to a file on Windows like on Linux?

Graphical Windows programs like the RM/COBOL runtime don't have the concept of terminal I/O redirection. Redirection is possible in UNIX and Windows console programs because the console/screen/command window is just another stream device that data is written to. So it's simple to redirect the output to a different device and send the data to a file instead of the screen.

It is possible for Windows programs to internally simulate this kind of redirection, but RM/COBOL for Windows has never done that. You'd have to go back to the DOS Extender-based version 6 to get this feature and I doubt it would run on any version of Windows.

The reason to use output redirection is for QA purposes, to check functions and then analize the content of the file to look for fails in it. It seems RM is the only one that does not support this under Windows. It works with Acu and MF. I will think on a way to capture those displays.

will produce an empty output.txt file. The reason is that Windows CMD.EXE parses the command line, redirects standard the standard output file handle into output.txt (creating or overwriting the file), then launches RUNCOBOL.EXE as a GUI program. GUI programs do not have access to these file handles so the file remains empty.

I believe that ACU does provide a console runtime system on Windows that presumably uses stdin/stdout/stderr; RM/COBOL includes a console-mode compiler but not a runtime system.

Thank you for answering me. Base on your answer, I understand that :

1. If I want to run a Cobol program in windows but need it returns the same result as when running on the Mainframe, there is no other way to run on Mainframe Emulator such as Hercules, ... Is it right ?

2. There are some cases where it is not necessary to run on the Mainframe Emulator, still returning the same results as when running on the Mainframe Emulator. Is it right ? If right, which are the cases that can return correct result (such as simply arithmetic calculation, ....) and which are the cases that can return incorrect results (?, ...) ?

For more details, I would like to present more : my case is i've got some Cobol files ( cbl, cpy). These files are in one of big program which is running in mainframe, but now i need to migrate these files to JAVA (run on windows and linux) and compare 2 output (cobol in Visual Cobol IDE, JAVA) to make sure the migration is correct.

When people mention COBOL, it's usually either met with a snort or groan. I don't know much about COBOL, but I've seen some programs written in it. I can see that it's wordy, and to uninitiated eyes such as mine, unintelligible. But, really, aren't all programming languages complete gibberish to a lay person?

COBOL was one of the first languages I learned - if you ignore countless versions of Basic, three or four assembler languages and a variant of Forth, then it was in my first five, and learned concurrently with Pascal. IOW, I'm answering from personal experience using the language.

EDIT I should say ancient experience. I never used the language after the end of the 80s, though I did buy a new book (to replace the old one I threw away in disgust) so that I had something to refer to so my horror stories wouldn't get too distorted. But I have no idea how the language has evolved in at least the last 20 years.

Obviously, for many people, it is just that "old is bad" view that jonsca has already described - and also much more a third-hand pass-me-down attitudes thing. But there are real issues underlying that.

Being too wordy is a real problem - there's too much clutter in the way of understanding the code. This is by far the biggest issue. People who look at the MOVE, ADD and MULTIPLY etc statements in horror have a slightly exaggerated view of this, true - the COMPUTE statement is closer to the assignments in other languages. But there's still a lot of clutter in all those divisions and sections. One of the first things I learned in COBOL was to always start by copying a standard page-of-A4-long SKELETON.COB.

COBOL does have some interesting features, but those features (e.g. the PIC thing) tend to be things that are now more part of the DBMS rather than the programming language, and that seems to me to usually be a better way to separate those responsibilities. Also, some libraries in other languages use something comparable to PIC (e.g. printf and scanf in the C standard library). Arguably, the best has been kept, but the worst dropped.

Also, for every nice feature, there was at least one intolerable one. For example, no matter how trivial a loop is, you have to move the body into a separate procedure. The PERFORM ... UNTIL ... and similar statements are single statements - not block structures. In a sense, COBOL was a taste of structured programming from before structured programming was invented - there was a GO TO, but it's use was discouraged (at least when I used COBOL), but looping in particular just wasn't handled that well.

In fact, the language that I used after COBOL that most reminded me of it was... dBase. As in Ashton-Tate dBase III+. These days, people are more likely to remember all the now-dead-or-dying clones (Clipper, FoxPro etc) that led to the generic name xBase - and there is still a living descendant in xHarbour. The point is that these were database languages, but nothing like SQL.

Even then, where every COBOL program operating on a particular database needs to include a copy of the specification of that database (and the copies could end up inconsistent), that isn't really the case in xBase where the database knows it's own structure.

Taking that into account, then, COBOL is not so terrible if you accept it for what it is. But what it isn't is a language for writing data structures. Which may be why COBOL suffered a lot back in the times of the C vs. Pascal holy wars - both sides could agree that COBOL was no good for reinventing the binary tree yet again.

Oh - and one thing I'll never forget is how my first COBOL textbook didn't describe the SORT command, saying that it was outside the scope of the book - apparently, either the author couldn't cope with the idea of sorting, or considered it to be more than the tiny little minds of COBOL students could cope with [see edit at end]. That kind of thing made it very difficult to take COBOL seriously.

An odd aspect of this was Jackson Structured Programming, which I also was forced to learn at around the same time, and specifically for use with COBOL. Part of this was drawing a structure diagram for the input, then a structure diagram for the output, then drawing the in-between structure diagram for the code. Sorting was clearly expected to be an already-solved problem - you couldn't derive a sorting algorithm in this way. So it was odd to be told by the recommended text-book that the whole concept of sorting was beyond my tiny little mind, while at the same time being taught something like a dozen different sorting algorithms and how to implement them in Pascal.

The problems that JSP can handle are probably a good guide for the things that COBOL can do relatively well. But even then, that doesn't necessarily mean that either JSP or COBOL are good ways to handle those problems.

The book I originally used as the recommended text when learning COBOL was "Methodical Programming in COBOL" by Ray Welland. This doesn't cover COBOL 85 (though there was a later edition "Methodical Programming in COBOL-85" which I've still never seen).

kindall comments below that "You were supposed to sort the input files before reading them, or sort the output file after generating it, using the sort utility that came with the OS". From my reply to that, I missed the "came with the OS" point. Kindall was suggesting something akin to the Unix philosophy AFAICT, with COBOL used for the bits it's good for, OS utilities such as a sort utility used for some other things, and presumably using a batch/scripting/shell language to glue the bits together. This makes much more sense in an ancient world where interactive software was rare to non-existent, so you'd be submitting batches of work (hence "batch language") anyway.

3a8082e126