Cobol On Linux
Riitta Palazzo
Though its popularity has waned, COBOL is still powering business critical operations within many major organizations. As the need to update, upgrade and troubleshoot these applications grows, so may the demand for anyone with COBOL development knowledge.
Fedora ships with a minimal version of Vim, but it would be nice to have some of the extra features that the full version can offer (such as COBOL syntax highlighting). Run the command below to install Vim-enhanced, which will overwrite Vim-minimal:
At this point, you are ready to write a COBOL program. For this example, I am set up with username fedorauser and I will create a folder under my home directory to store my COBOL programs. I called mine cobolcode.
There are numerous resources available on the internet to consult, however vast amounts of knowledge reside only in legacy print. Keep an eye out for vintage COBOL guides when visiting used book stores and public libraries; you may find copies of endangered manuals at a rock-bottom prices!
It is also worth noting that helpful documentation was installed on your system when you installed GnuCOBOL. You can access them with these terminal commands:
Hi donnie,
the last time I heard of COBOL was in the year before the millennium. There in Europe even seemingly dead COBOL programmers were resurrected, because the financial services industry was trembling before the turn of the millennium. What is your motive to deal with this extinct species again today. IBM, Siemens, Mainframes Computer, Government Agencies, Banks?
All of the above. Those are all examples where COBOL is still in use. I hope there will be readers interested in learning enough to keep the final critical applications online (while prioritizing a migration to replacement solutions written in a more modern technology stack!)
If you are interested in having a significant post-retirement payday, I hope you will keep an ear out for the news! I suspect it will not be long before another major organization finds itself with a major COBOL problem; giving you a unique position to set the price.
I am 46 and I was a COBOL programmer for four years. I was quite good in CICS tp monitor too. Right after my high school diploma, I took a one-week course and the week after I was in Florence working for a big italian bank. Of course, I could only get a grasp of it, but you have to start somewhere. I appreciated this article, it made me think about the old days, and I will try to catch up! Can you get paied $100 for hour? Well, good for you, genius! But do not lecture anyone here, try to be supportive!
This article (to personal opinion) would be better if presented as either virualizing the COBOL code to put it in a specimen tube before having it converted into something for a more civilized age, like C or Rust or a discussion of how to convince others to leave COBOL behind after showing how much more functional and easy it would be to simply reprogram in another language.
ole ole memories are coming up. It must be 2005 when i was involved in a Host/IMS Project and my jobs was to design and implement a piece of code, that should allow a bank-application to access a UNIX based services.
Incredibly, an old host application running in a IMS transaction should access a UNIX service. I still had some knowledge in COBOL and was an expert in server programming using UNIX socket. The question was, is a IBM Host able to call the socket api?
So i developed a COBOL application on Linux, that performed some asynchronous socket operation. Since the previous gnu-COBOL project was a neverending story i tried cob2c from Keisuke Nishida. It was a success at all, i was able to code proper COBOL code. The colleague compiled it on his host and finally we were able to access the UNIX-services on a Solaris ES.
ole ole memories are coming up. It must be 2005 when i was involved in a Host/IMS Project and my job was to design and implement a piece of code, that should allow a bank-application to access a UNIX based services.
Incredibly, an old host application running in a IMS transaction should access a UNIX service. I still had some knowledge in COBOL and was an expert in server programming using UNIX sockets and TLI. The question was, is an IBM Host able to call the socket api? (Yes it was! ?
So i started to develop a COBOL application on Linux, that used some asynchronous socket operations. Since the previous gnu-COBOL project was a never ending story i tried cob2c from Keisuke Nishida. It was a success at all, i was able to code proper COBOL code. The colleague compiled it on his host and finally we were able to access the UNIX-services on a Solaris ES.
After I graduated from college in 1983, the first job required me to write a data management program on a CDC Cyber 170 in any standardized programming language. I picked COBOL due to two needed features: (1) indexed sequential access file, and (2) arbitrary precision numbers. I finished the assignment way ahead of the deadline. Prior to that, I wrote FORTRAN, Pascal, and Basic in college. None of these languages had the two features built-in. Thanks COBOL.
55 years ago, I was a cobol programmer. My work as programmer was on an IBM 360 computer complex. The mainframe computer knew about packed decimal, binary, and floating point. The mainframe did not have string operations.
A good programmer aligned the fields in structures and records so as to begin and end on word boundaries.
The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat. Fedora Magazine aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. The Fedora logo is a trademark of Red Hat, Inc. Terms and Conditions
I need 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.
DB would be migrated from NonStop SQL to Oracle.Pathway applications should be either totally or partially rewritten.
For what concerns the scobol user interface, it could be rewritten as
a web application.
The problems come when we want to interface the presentation tier with
business servers (Pathway SEND call) and
define transactions not only at DB level (in this case we need a TP
monitor).What are, according to your experience, suitable TP monitors for
Unix/Linux ?
What problems do you think we have to solve to develop a framework
that emulates (the main features of) a Pathway environment. The main
items to be addressed I see should be $RECEIVE emulation and
transaction management as mentioned above.Is anybody of you facing, or is going to, a similar challenge ?Thanks for your help,
Peter
Here are my suggestions based on a pilot project I did a few years back.1) BEA Tuxedo is very similar in concept to Pathway. It's not that hard
to migrate the COBOL85 request/reply messages and $RECIEVE processing to
Tuxedo FML messages etc. Available on leading UNIX & Linux.2) Micro Focus COBOL is a good migration platform for COBOL85 (assumming
you are not using many Tandem extensions). Available on leading UNIX &
Linux.3) I believe Oracle still support using an Embedded SQL compiler for
COBOL. I think it is the migration of the SQL code that will cause the
most difficulties.
BEA Tuxedo + Micro Focus COBOL + Oracle sure isn't low cost though! The
pilot proved that it was more cost effective to keep the application
were it was.
>What problems do you think we have to solve to develop a framework
>that emulates (the main features of) a Pathway environment. The main
>items to be addressed I see should be $RECEIVE emulation and
>transaction management as mentioned above.
Micro Focus Cobol may be a good Cobol environment, and we had been
very satisfied with it for a longer time. But some time ago they
introduced a new runtime licensing scheme, which does not fit to
transactionmonitors at all. You have to license every running
executable. This means for a transaction monitor with 500 running
programs (tuxedo servers), like our's, that you have to pay for each
running program, although you do not really use it actually.And you can not mix the cheaper runtime licenses with developer
licenses in one Cobol installation (COBDIR). This means, you may have
to pay for 500 expensive developer licenses)For me as a C programmer it is very strange at all to pay for running
executables. Because of this problem we have lost 1,5 Years with our
migration problem. We are forced to stay with good old tuxedo 6.5,
MqSeries 5.1 and the old Microfocus compiler.We could not just replace one part of our installation, because of the
introduction of threading in the runtime we are forced to update all
of our components, so that they work together.For visualisation of screens we use a small mask-interpreter with own
language + converting tools. This is made by a smaller company, but
work pretty well in our production with 3000 workers. Sorry, the page
about this product is just in german: -online.de/produkt.htmSo my advice:
Do not use this Cobol compiler. Maybe, you could jump onto the Java
train and take legacy J or such. (I'm very angry.) Or do not migrate
at all. And think of all the interdependencies you will have with
different products.And:
If anybody may have a clue for an alternative cobol compiler running
on HP-UX, Tuxedo and Oracle, you are very welcome!--
Martin