COBOL on the Pi.

[Heater]

In response to a comment by DougieLawson I was compelled to see if COBOL works on the Pi. I'm glad to report that it does. Here is what I replied to a now deleted thread:

Dougie,

COBOL runs just fine on the Pi:

Code: Select all

$ sudo apt-get install open-cobol
...
$ cobc --version
cobc (OpenCOBOL) 1.1.0
Copyright (C) 2001-2009 Keisuke Nishida / Roger While
Built    Mar 27 2014 21:06:19
Packaged Feb 06 2009 10:30:55 CET
$
$ cat hello.cbl 
       Identification Division.
       Program-ID. sampleCOBOL.

       Data Division.

       Procedure Division.
       Main-Paragraph.
       Display "Hello World!"
       Stop Run.
$
$ cobc -x -o hello hello.cbl 
./hello
Hello World!
$ 

COBOL is like the Dark Matter of the software universe. There is a lot of it about but you never see any. It's very hard to detect. I have only ever spoken to a couple of COBOL programmers and only ever met one face to face in decades of hanging around the software business.

I will still claim that JavaScript is the most widely used language. Every human being with a browser runs JS nearly every day.

Of course, that all rests on a browser written in C++ and sitting on an OS written in C/C++...

Agreed, Python is disgusting.

[DougieLawson]

I see COBOL stuff running every single day in my day job (which involves playing with IMS and DB2 on a couple of large mainframes).

COBOL-92 was a definite improvement over COBOL-74.

[rpdom]

I see COBOL stuff running every single day in my day job (which involves playing with IMS and DB2 on a couple of large mainframes).

COBOL-92 was a definite improvement over COBOL-74.

and COBOL-74 was an improvement over COBOL-68 (although I did like the in-line assembler in the version I used. 36-bit processor anyone?).

I jumped ship to Unix before any of our systems were upgraded to COBOL-85. I never saw '92.

[stephj]

My career in IT started off learning COBOL on both IBM 370 midrange mainframes and DEC VAX 780 machines. Nearly all the systems were written in it, with only a handful of research analysts who knew enough FORTRAN to do the required number bashing on the IBM.

After serious structural changes to the company in the mid to late eighties, (it was split into two), the mainframes went one way and I went the other as part of a small group of developers. With the new half of the business not having the requirement or the budget for a 370 architecture machine, it decided to downsize to an IBM System 38. Most developers were sent on a crash course in RPG, before starting to develop the new systems that had been designed by the analysts from scratch.

At the same time IBM PC XT machines started to emerge. On these new fangled curiosities, COBOL was used at first, because the developers had the required language skills without having to learn something new. The then IBM/MS BASIC just didn’t seem to cut it. Small systems could be developed faster than on the System 38.

Over time, some systems were re-absorbed back into the System 38, some redeveloped, and others migrated to, or developed solely for, Windows, and some using the System 38 data via ODBC connections. By that time the developers had gained some experience of VB/C/C++ etc.

It probably took well over a decade for COBOL to be completely replaced with other languages, and we did not have a lot of it to start with. In much larger enterprises it is probably exponentially harder to do that. When the code is stable and has been running for years………. If it ain’t broke…………….

[Heater]

And now you can run COBOL in your web browser!

https://github.com/ajlopez/CobolScript

Hmmm....That's probably not the best way to do it. Might be better to compile COBOL into intermediate C with open-cobol. Then compile the C into Javascript for the browser.

I feel a very sick and twisted experiment coming on here...

[Douglas6]

Ahhh, Cobol-74 on an IBM Series-1 on Wall Street in the very early eighties. Those were the days.

[hippy]

and COBOL-74 was an improvement over COBOL-68 (although I did like the in-line assembler in the version I used. 36-bit processor anyone?).

PDP-10 by any chance ?

jrst @.

[rpdom]

and COBOL-74 was an improvement over COBOL-68 (although I did like the in-line assembler in the version I used. 36-bit processor anyone?).

PDP-10 by any chance ?

Nope, Honeywell (later Bull) DPS8.

[mnr]

I've been playing a bit with COBOL on the Raspberry Pi. My goal is to read and write to the GPIO. So far, I've been able to blink an LED with the following.

I've been thinking that I should be able to just read and write to "/sys/class/gpio/...." rather than going through a system call.

Your thoughts?
mnr

Code: Select all

       IDENTIFICATION DIVISION.
       PROGRAM-ID. HELLOWORLD.

       DATA DIVISION.
       WORKING-STORAGE SECTION.
        01 WS-GPIO-INIT PIC x(40) VALUE 'echo "21" > /sys/class/gpio/export'.
        01 WS-GPIO-DIR PIC x(80) VALUE 'echo "out" > /sys/class/gpio/gpio21/direction'.
        01 WS-GPIO-ON PIC x(80) VALUE 'echo "1" > /sys/class/gpio/gpio21/value'.
        01 WS-GPIO-OFF PIC x(80) VALUE 'echo "0" > /sys/class/gpio/gpio21/value'.
        01 WS-GPIO-ClR PIC x(80) VALUE 'echo "21" > /sys/class/gpio/unexport'.        
        
        PROCEDURE DIVISION.
        display "This is COBOL running on a Raspberry Pi".
        display "Here's how to call GPIO from COBOL".
        CALL "SYSTEM" USING WS-GPIO-INIT.
        CALL "SYSTEM" USING WS-GPIO-DIR.
        PERFORM FLASH-LITE 3 TIMES.
        CALL "SYSTEM" USING WS-GPIO-CLR.
        STOP RUN.
   
        FLASH-LITE.
        CALL "SYSTEM" USING WS-GPIO-ON.
        CALL "C$SLEEP" USING 1.
        CALL "SYSTEM" USING WS-GPIO-OFF.
        CALL "C$SLEEP" USING 1.
           
        END PROGRAM HELLOWORLD.

[DougieLawson]

I've been thinking that I should be able to just read and write to "/sys/class/gpio/...." rather than going through a system call.

You may need to run as root (sudo) in that case. But it would be more in keeping with the way COBOL works and the way I write COBOL.

[mnr]

I've been thinking that I should be able to just read and write to "/sys/class/gpio/...." rather than going through a system call.

You may need to run as root (sudo) in that case. But it would be more in keeping with the way COBOL works and the way I write COBOL.

I see your point. It is a stylistic sort of thing.

Regarding reading the state of an input pin, I read somewhere that a gnuCOBOL system call can't return a value. Instead, the code needs to be set up to read the contents of a file. Is that your understanding as well?

MNR

[mwrich4]

My curiosity is piqued.

COBOL offered many platform-specific methods for IO via Linkage or system calls. I'd be surprised if the Linux version doesn't have any.

PC variants from the solo DOS days had ways to do these things. ( REALIA )

It doesn't surprise me that you may need to run as root unless you make a group that offers hardware permissions. I haven't looked yet, do the Raspian drivers offer /dev hooks for IOCTRL functions in C. If so, the COBOL vendor ought to provide a similar path.

[DougieLawson]

I've been thinking that I should be able to just read and write to "/sys/class/gpio/...." rather than going through a system call.

You may need to run as root (sudo) in that case. But it would be more in keeping with the way COBOL works and the way I write COBOL.

I see your point. It is a stylistic sort of thing.

Regarding reading the state of an input pin, I read somewhere that a gnuCOBOL system call can't return a value. Instead, the code needs to be set up to read the contents of a file. Is that your understanding as well?

MNR

I've not tried, but I'd expect reading a /sys/class/gpio/... directly to return PIC S(9) DISPLAY or a PIC S(9) COMP value.
I don't like the sysfs stuff much, because it's slow.

The CALL "SYSTEM" stuff appears to be fire off a command and assume it's worked (which is bonkers). On mainframes those sorts of call usually have two parameters one with the command you're attempting and one with a working storage data area or linkage section (if it returns a pointer) where the system returns the results.

[Heater]

Great to see my old COBOL thread revived.

Things have progressed, we can now flash a LED from COBOL!

This is just the break through required to enable COBOL to break into the world of IoT and robotics.

[mnr]

Running from root is a sysfs sort of thing. I suspect if I bothered to read up on connecting COBOL to a c library such as wiringpi (deprecated!) or BCM2835 ( https://www.linkedin.com/learning/rasp ... l-of-gpio ) I could then run it without root. But if you do it from BASH, you still need to root. So be it.

As to performance, you are probably correct that a c library would run faster. However, we are talking about a Raspberry Pi running a compiled language on top of Linux. That's a lot of performance hoops to jump through and if you're really needing signal processing speeds, perhaps your application ought to be implemented closer to the board.

Don't get me wrong - RPi is a fantastic tool. But personally, I've never had a situation where the GPIO response time was a gating factor in my design. More often, it's the speed of the processor itself.

MNR

[hippy]

Just to note that GPIO sysfs has been deprecated for some time now. I recall reading it was scheduled for removal in 2020, so its disappearance is at least on the horizon.