My employer has been around 40 nearly 50 years. We still run COBOL for 90% of our business operations. Day-to-day employees work in bluescreens built in RM/COBOL and RM/PANELS.
As recently as the 2010s, we used to emit HTML out of COBOL, but fell short of it directly responding to HTTP requests. Instead, we licensed an RPC layer that sits behind Apache and translates HTTP calls through CGI to a listener on the COBOL side that then invokes COBOL programs. Those programs send back HTML strings through the CGIRPC interface and, well, out comes a webpage in your browser.
We're still using it to serve XML and have turned it into a makeshift web service that helps power a traditional web application.
* Columns 73-80 for programmer comments or whatever notes you like
All the columns are undoubtedly a bit taxing to the modern developer and their tools, so 'free mode' which discards all the above is the suggested default.
But, I think fixed mode is very charming, and if you're going to write COBOL in 2025, you may as well try to get the most authentic experience!
Early versions of Fortran also had a fixed column layout, although the columns were different. The only commonality thst I can find right now is ignoring columns 73 to 80 to make space for card sequence numbers.
I never wrote a program on punch cards, but I'd definitely drop card stacks accidentally or get them into a jumble somehow. Having numbered cards and a card sorting machine (radix sort in hardware!) would be extremely helpful then.
Old-timer tip: take a marker and draw a diagonal line across the top of your card deck, from the column 1 left side edge of the first card to the column 80 right side edge of the last card. When you drop the deck, just reassemble the line.
It's interesting to see just about every line in the code commented. Makes you re-examine the assumptions made when people say "the code should be self documenting."
Namely, that the code will be read by someone who knows the language. And arguably that the code should be capable of being "self-documenting." Although perhaps people well-versed in COBOL would argue COBOL can be, and I just don't know it.
yep. the comments are for folks who have never tried to read cobol before, which is probably 99% of people looking at the project. this way they can understand a familiar idea expressed in a language that is probably wildly different from what theyre used to.
"Namely, that the code will be read by someone who knows the language. " Most of the time I think it depends on the context. If you're writing code as a learning exercise, either for yourself or for others, it makes sense to use comments to expand on what lines actually do.
If you're in the context of a professional environment, where you chose the team, it makes sense to be more dogmatic about it to enforce a better overall architecture, and you can safely assume that the next reader at least knows the language already.
I know this is a ‘joke’, but it sparked in me actual questions that I am sure some folks here will know the answers to:
What are the security guarantees with writing in COBOL? Like, does COBOL allow out-of-bounds memory access? How does it compare to C or Rust as far as allowing ‘accidental’ security lapses?
> Like, does COBOL allow out-of-bounds memory access?
Modern COBOL compilers will catch this with an error; if you do manage to compile and run, you'll get a runtime error or immediate crash.
> How does it compare to C or Rust as far as allowing ‘accidental’ security lapses?
COBOL has reference modification that can easily be purposefully used to reference memory outside the bound of the original data you target. It isn't memory safe, it's just very restrictive so many errors/misuses get weeded out during compiling.
I wondered about that as well while looking into the http handler. I think a missing space between method and path overruns the buffer (haven't tried running it though).
In the late 90's I had a girlfriend who worked for a shop that made web pages in COBOL. I thought those were COBOL's death throes, but apparently I was mistaken...
I've always wanted to learn Cobol. So, I of course did what I sometimes do and bought the standard. Of course, it then turned out that the standard used inaccessible diagrams instead of any kind of decently modern syntax notation like EBNF, so I could at most only get scraps from the syntax parts and nothing actually useful. I wasn't entirely sure if even learning it would be worthwhile or be something I would be able to do, but I thought eh, why not give it a go?
My employer has been around 40 nearly 50 years. We still run COBOL for 90% of our business operations. Day-to-day employees work in bluescreens built in RM/COBOL and RM/PANELS.
As recently as the 2010s, we used to emit HTML out of COBOL, but fell short of it directly responding to HTTP requests. Instead, we licensed an RPC layer that sits behind Apache and translates HTTP calls through CGI to a listener on the COBOL side that then invokes COBOL programs. Those programs send back HTML strings through the CGIRPC interface and, well, out comes a webpage in your browser.
We're still using it to serve XML and have turned it into a makeshift web service that helps power a traditional web application.
But, honestly, this is way cooler.
Love to see fixed format mode in use :)
For those who are unaware — you can use COBOL in two modes: free mode and fixed format mode.
Fixed format mode is (afaik) the original, based on punch card affordances, and specifies specific columns for specific purposes:
* The first 6 columns for line numbers
* Column 7 for the indicator character (notably: * for comments as you can see here https://github.com/jmsdnns/webbol/blob/main/file-structs.cpy )
* Column 8-11 for special division markers, though they can extend beyond (visible in this file: https://github.com/jmsdnns/webbol/blob/main/webserver.cbl)
* Columns 12-72 for ordinary COBOL statements
* Columns 73-80 for programmer comments or whatever notes you like
All the columns are undoubtedly a bit taxing to the modern developer and their tools, so 'free mode' which discards all the above is the suggested default.
But, I think fixed mode is very charming, and if you're going to write COBOL in 2025, you may as well try to get the most authentic experience!
Cols 73-80 were sometimes used for sequence numbers so when you spilled your cards on the floor you could run them through the sorting machine.
This may help you get the feel (pick the COBOL card at the top). [0]
For an even more authentic experience, write the program on a coding form first, then give it to an assistant for keypunching. [1]
[0] https://www.masswerk.at/keypunch/
[1] https://www.mainframestechhelp.com/tutorials/cobol/coding-sh...
Early versions of Fortran also had a fixed column layout, although the columns were different. The only commonality thst I can find right now is ignoring columns 73 to 80 to make space for card sequence numbers.
I never wrote a program on punch cards, but I'd definitely drop card stacks accidentally or get them into a jumble somehow. Having numbered cards and a card sorting machine (radix sort in hardware!) would be extremely helpful then.
Old-timer tip: take a marker and draw a diagonal line across the top of your card deck, from the column 1 left side edge of the first card to the column 80 right side edge of the last card. When you drop the deck, just reassemble the line.
I liked this too, but interesting that the Makefile uses the `-free` flag for cobc
I assume fixed is a subset of free? So perhaps a few lines somewhere aren’t perfect.
the code is similar to fixed format, but the location of the comments gives away that it is actually in free format.
* comments use *> at start of line, though I'm not sure i'll keep that
* indentation is flexible, but i prefer how fixed looks
* no column restrictions
People say “pick the best tool for the job” and then refuse to pick COBOL for their COmmon Business Oriented probLems
They don't refuse to pick COBOL, they refuse to consider COBOL.
They even forget that COBOL could run on their computers and servers.
Why and when is the the "best tool for the job"?
Whoosh
It's interesting to see just about every line in the code commented. Makes you re-examine the assumptions made when people say "the code should be self documenting."
Namely, that the code will be read by someone who knows the language. And arguably that the code should be capable of being "self-documenting." Although perhaps people well-versed in COBOL would argue COBOL can be, and I just don't know it.
See commit d9a5e3e, “Added comments to the code to help curious folks understand what each line is doing”.
yep. the comments are for folks who have never tried to read cobol before, which is probably 99% of people looking at the project. this way they can understand a familiar idea expressed in a language that is probably wildly different from what theyre used to.
for example IT IS YELLING AT US THE WHOLE TIME
"Namely, that the code will be read by someone who knows the language. " Most of the time I think it depends on the context. If you're writing code as a learning exercise, either for yourself or for others, it makes sense to use comments to expand on what lines actually do.
If you're in the context of a professional environment, where you chose the team, it makes sense to be more dogmatic about it to enforce a better overall architecture, and you can safely assume that the next reader at least knows the language already.
I heard people at a bank claim that COBOL code is basically natural language and thus self-documenting. I almost laughed out at that.
Bank teller: "And how can I help you?"
Customer: "PERFORM 500-DEDUCT-ACCOUNT-BALANCE"
Bank teller: "Ok, great, and how much?"
Customer:
"01 TRANSACTION RECORD
MOVE 100.00 TO TRANSACTION-AMOUNT"I know this is a ‘joke’, but it sparked in me actual questions that I am sure some folks here will know the answers to:
What are the security guarantees with writing in COBOL? Like, does COBOL allow out-of-bounds memory access? How does it compare to C or Rust as far as allowing ‘accidental’ security lapses?
> Like, does COBOL allow out-of-bounds memory access?
Modern COBOL compilers will catch this with an error; if you do manage to compile and run, you'll get a runtime error or immediate crash.
> How does it compare to C or Rust as far as allowing ‘accidental’ security lapses?
COBOL has reference modification that can easily be purposefully used to reference memory outside the bound of the original data you target. It isn't memory safe, it's just very restrictive so many errors/misuses get weeded out during compiling.
I wondered about that as well while looking into the http handler. I think a missing space between method and path overruns the buffer (haven't tried running it though).
I'd love to learn more about what `CALL "socket"` is doing. CALL is for running subprograms, but it's not clear to me where "socket" is?
I've thought about a COBOL webserver before, but didn't get beyond reading the GnuCOBOL FAQ that mentions it's possible with CGI https://gnucobol.sourceforge.io/faq/gcfaq.html#id1126
I'm definitely going to dig into this project more later. This is very neat!
Could simply be the `socket` system call.
yep, it calls the external c function. same with setsockopt, bind, and listen further down.
In the late 90's I had a girlfriend who worked for a shop that made web pages in COBOL. I thought those were COBOL's death throes, but apparently I was mistaken...
that's it. you get the reward for the weirdest gf ever.
Love this!!! Any tips for learning cobol?
Some things are COBOL aren't too bad - eg:
I thought I could program in any language. But: that Cobol project makes Assembly language look clean and elegant.
I applaud Jms Dnns! This project really makes you think.
thank you!
Now we are one step closer to fully realize the vision of Cobol on Cogs
http://www.coboloncogs.org/INDEX.HTM
See also:
Cobol on Cogs: http://www.coboloncogs.org/HOME.HTM
Cobol on Wheelchair: https://github.com/azac/cobol-on-wheelchair
I've always wanted to learn Cobol. So, I of course did what I sometimes do and bought the standard. Of course, it then turned out that the standard used inaccessible diagrams instead of any kind of decently modern syntax notation like EBNF, so I could at most only get scraps from the syntax parts and nothing actually useful. I wasn't entirely sure if even learning it would be worthwhile or be something I would be able to do, but I thought eh, why not give it a go?
IDENTIFICATION DIVISION. PROGRAM-ID. WEBSERVER.