I must admit that when this email crossed my desk, I was inclined to think it was a joke. After checking the calendar (no, it wasn't April Fools' Day) and the company's Web site, I was convinced it was real, and I became intrigued with Deskware's CobolScript.
For while the elders of the hacking world have nothing but scorn for COBOL, I'm one of those who grew up reading the Jargon File rather than living it. I must confess now to a secret desire to know what COBOL is like ... to program in APL ... to learn Ada! My Y2K experience has slaked my thirst for this knowledge in small part, but it has (un)fortunately been limited to DEC FORTRAN with light PDP/11 macro assembler. I've had no experience with COBOL.
So I recognized that this was my big chance to discover the truth of Edsger W. Dijkstra's oft-quoted fortune:
The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense.
COBOL's wordiness is legendary: they say it has more lines of source code than generated machine instructions. Like FORTRAN, it's designed to be read in on 80-column cards. It has a built-in function for calculating the present value of an investment, but no variable scope. Thinking about programming in COBOL gives me the same feeling as thinking about the joke language INTERCAL: entering a world where any minor achievement -- like adding two integers -- has hack value because it is so difficult to do.
Why CobolScript
Not everyone is like me, of course -- most people's interest in COBOL is less frivolous. It may come as a surprise to some of you, but the COBOL market is not small. In fact, Matt Dean, the president and CEO of Deskware, estimates that as many as 2.5 million programmers have primary skills in COBOL. That's a lot of programmer training potentially going to waste in these days of computing languages with beans. A job market as tight as IT is today can't afford to waste that much talent.
COBOL programmers are habitually undervalued by management. The general attitude seems to be that they're old, and expensive: it would be better if they just disappeared. Although COBOL is enjoying a brief resurgence as a result of Y2K conversions (did you expect to see COBOL for Dummies published in your lifetime?) -- it seems obvious that people will go back to their former attitudes about COBOL and COBOL programmers after Y2K work is done.
But language snobbery is silly. To look down at COBOL and COBOL programmers is to be as childish as the "Real VMS Programmers" who to this day look down on Unix and Unix programmers.
Besides, COBOL programmers are not dinosaurs! They may be nearing (or even past) retirement age -- but they are Real Programmers. They are among the first generations of programmers -- those who got into the field because they loved it, and not (like many undergraduates today) because they'd seen people five years older than them retire with $20 million dot-com.
And as they do move into retirement, most COBOL programmers will probably continue to tinker with computers for the love of it, creating a huge pool of idle programming talent. Think of another 2.5 million programmers working on open-source projects: people with extensive systems programming backgrounds, experience on realtime operating systems, and lots of free time. Irrespective of the success of COBOL on Linux, we should try to interest these programmers in Linux as a free operating system to use, modify, and share.
CobolScript allows them to leverage their COBOL skills in a new space, and Deskware is deliberately targeting this group as its primary market, positioning CobolScript as a COBOL-like scripting language with support for Internet protocols.
You want they should use Windows?
Deskware is also targeting mainframe shops that still use COBOL as their primary language. For those shops, getting on the Web may seem prohibitively difficult: they'd have to move to new hardware running new operating systems and new languages. With CobolScript, they have a familiar language, and it will no doubt be easier to port their existing code to the Web server.
Consider the case of a mainframe shop that's going to install a PC as a Web server. If COBOL is the language that its employees are most comfortable with, shouldn't they look for COBOL implementations on the various systems they're considering? CobolScript on Linux makes Linux and other free software solutions (such as Apache or Perl) more appealing.
More COBOL
It's obvious that I'm not a COBOL programmer. But if you are, do please let me know if I have managed to accurately portray the situation regarding COBOL today.
For more and better arguments, you might also want to read the "Why COBOL?" pages at AcuCorp (see Resources). AcuCorp is another company that provides modern support for COBOL (how many of these guys are there?!).
|
Flame us not!
We know that Deskware and AcuCorp are not the only companies creating modern tools for COBOL! If you send us a brief description and a URL for your favorite COBOL product, we'll list them here in this box for the whole world to see. We looked up a few with Archie to get us all started:
- AcuCorp changes "legacy" to "leading edge" with its COBOL-extending ACUCOBOL-GT Development Suite. You can access RDBMSs, embed SQL, interface to MS Windows, access the Internet -- and present it all to your users with a beautiful GUI you whipped up in nanoseconds, thanks to AcuCorp's WYSIWYG GUI screen painter.
http://www.acucorp.com/Products/
Figure out what the heck your COBOL programs are actually doing with automated PowerStructure III flowcharts from CyberMetrics (version 4.0 is coming soon!)
http://www.usflowchart.com/
You will be writing dynamic cross-platform COBOL programs using powerful technologies such as ORB, CCI, TCP/IP, and plug-and-play networking in no time at all with the Object COBOL Developer Suite for UNIX from Merant.
http://www.merant.com/ads/dc/products/ocux.asp
Create client/server applications that furnish fast access to distributed enterprise data -- including most commercial databases -- with Fujitsu COBOL for Unix (also available for Win9x/NT). (Yes, it apparently is that Fujitsu!)
http://www.adtools.com/products/unix/cobolux.htm
Merant's NetExpress,
the best selling PC COBOL development tool out there, will
also allow you to
develop web pages -- not with a COBOL-like tool -- but with good old COBOL.
It
is available for Unix or (gasp!!) NT.
http://www.merant.com/ads/dc/products/netex30.asp
|
For me, playing with COBOL is a history lesson: COBOL was the first widely used high-level language for business, and sources say there may be more existing lines of code in COBOL than in any other language (and that isn't only because COBOL is so wordy ...)
The first standard version of COBOL was COBOL-60; it has evolved all the way up to COBOL-85. You can see the levels of revision as old features were rethought and new ones added to the language. While that history lesson is harder to spot in CobolScript than in straight COBOL, you can still see it.
CobolScript, meanwhile, is basically what its name implies -- a COBOL-like scripting language. It's a new implementation based on ANSI85 COBOL, so that old-COBOL arithmetic operations (like MULTIPLY UNIT-COST BY COUNT GIVING TOTAL-COST.) have been updated to what I'd call a natural-expression syntax: COMPUTE TOTAL-COST = UNIT-COST * COUNT.
Keep in mind that when COBOL was designed, its programmers weren't trying to write the book on the elements of obscurity for generations to come. On the contrary -- COBOL, or COmmon Business Oriented Language -- was an attempt to create a programming language that was easy to use because it was like natural English. The obscurities came about because the programmers were shooting in the dark, and few had ever created a high-level language before. Can the same be said for other languages' obscurities?
Download and installation
CobolScript is available for online purchase from Deskware for $49.95. It runs on Windows 9x/NT, Solaris and FreeBSD -- and Linux, of course. After filling out the online purchase form, you can download the product and install it, either in three parts or as one large tarball. I downloaded the full version, including the interpreter, sample scripts, and manual (about 5 MB). I created a subdirectory for CobolScript and unpacked the distribution into it. Then I unpacked the sample scripts into another subdirectory:
$ cd /usr/local/bin/
$ mkdir cobol
$ cd cobol
$ tar xf ../linuxcob.tar
$ mkdir samples
$ cd samples
$ tar xf ../ucbsampl.tar
$ cd ..
$ /bin/su
Password:
# install cobolscript.exe -o root -g root -m755 /usr/local/bin/cobolscript.exe
install is a useful command. In the incarnation above, it does a copy, chown, and chmod all in one! While it's used mainly in installation scripts, it's so darn handy I use it all the time for other things too. In this case, I installed cobolscript.exe from the current directory into /usr/local/bin, chowned it to root, chgrped it to root, and chmoded it to 755 (rwxr-xr-x).
Deskware recommends pointing your PATH at the directory where you've installed the CobolScript interpreter, but as you can see, I installed it in /usr/local/bin/. That's because Deskware also recommends that you install the interpreter into your cgi-bin directory -- which is a big security no-no. You'll see what steps I took to solve the problem later in this article.
Even though I installed CobolScript and its interpreter in /usr/local/bin/, I still had to run my CobolScript scripts by explicitly invoking the interpreter: for example, cobolscript.exe foo.cbl. To save me this agony, the Linux facility binfmt_misc allowed me to use the following command to associate all files having the extension .cbl with cobolscript.exe:
# echo ':CobolScript:E::cbl::/usr/local/bin/cobolscript.exe:' > /proc/sys/fs/binfmt_misc/register
Note that I was still in superuser mode when I did that.
To discover binfmt_misc for yourself and use it <!-- for your own nefarious purposes --> to register filetypes to be automatically run by a specific interpreter, first see if it isn't already installed on your system (look in the /proc/sys/fs/binfmt_misc directory); to read more about it, consult the kernel documentation in /usr/src/linux/Documentation/binfmt_misc.txt.
CobolScript features
CobolScript provides the basic tools necessary to get the job done. Programming-language basics such as arithmetic operations, output formatting, data structures, and file input/output (topics covered in Kernighan and Ritchie's "C Programming Language"; see Resources) are all there and easy to use. The manual is complete and precise, but it's an Adobe PDF document, which makes it difficult to grep.
|
COBOL syntax for the new user
|
|
CobolScript provides a subset of ANSI85 COBOL. COBOL experts probably know what
that means, but since this was my first experience with COBOL, I just read the manual and used what was documented there. Here's a quick glossary for the COBOL
newbie:
|
| COBOL-to-C glossary |
|
| COBOL |
C |
| Assignment and Arithmetic |
MOVE 1 TO i. |
I = 1; |
ADD a TO b GIVING c. |
c = a + b; |
ADD 1 TO i GIVING i. |
i++; |
|
|
| Looping and Control |
|
IF expr THEN
block1 |
if (expr) {
block1 |
ELSE
block2 |
} else {
block2 |
END-IF |
} |
PERFORM UNTIL i > 20
block |
while (! (i > 20) ) {
block |
END-PERFORM. |
}; |
PERFORM VARYING i FROM 0 BY 1 UNTIL i >= 10
block |
for(i=0;i<10;i++) {
block |
END-PERFORM |
} |
|
|
| Function Calls: |
|
PERFORM 0001-FOO. |
foo(); /* function call */ |
GOBACK. |
exit(0); |
|
|
| Variable Declarations: |
|
DATA DIVISION. |
|
WORKING-STORAGE SECTION. |
|
COPY WWW-VARS.CPY. |
#include "www-vars.h" |
01 WS-BUF PIC X(100). |
char ws-buf100]; |
01 WS-NUM PIC 99.99999. |
(no equivalent -- no fixed-point numbers) |
(no equivalent: no floating-point numbers) |
float f; |
01 WS-GROUP-FOO
02 WS-BAR PIC X(10).
02 WS-BAZ PIC X(10). |
struct ws-group-foo {
char ws-bar[10];
char ws-baz[10];
} ws-group-foo; |
|
(That last example isn't really equivalent, because in C you can use the definition of struct ws-group-foo to declare more than one structure, but in COBOL, as in Highlander, There Can Be Only One.)
|
|
CobolScript includes some useful extensions, as well as providing some "fancy" features (which would require external libraries) as part of the basic language. A variety of financial, unit-conversion, and combinatorial functions are part of the standard language. CobolScript also provides integrated libraries for some Internet protocols: POP, SMTP, FTP, and HTTP. There's also a direct TCP/IP interface so you can implement other protocols.
One thing lacking in CobolScript is the ability to extend the language with libraries -- those written in CobolScript itself or in other languages. However, CobolScript is a young product, and we'll see what comes in the future. It's certainly possible to do a lot of things with CobolScript now: for example, you can implement a program that fetches mail from your POP server, parses it for URLs, and fetches any referenced URLs for offline browsing.
Mind you, there's no benefit to doing all this in CobolScript instead of Perl or Java -- it's that you can do it, which is both amazing and enticing (especially if you're a COBOL programmer).
Caveat Webmaster: CobolScript and security
As I mentioned earlier, the placing of interpreters in a cgi-bin directory is widely regarded as a security vulnerability. If the interpreter can be misused or tricked into executing code passed in on the command line, you will be in trouble.
You can avoid putting the CobolScript executable in the cgi-bin directory by using the Linux binfmt_misc module. While I know of no vulnerabilities in cobolscript.exe that would allow it to be misused for such a purpose, it's always better to be safe. So either use binfmt_misc or configure your Web server to execute files that have a .cbl extension with cobolscript.exe; don't put cobolscript.exe in your cgi-bin directory.
The good news: (Probably) no more unsightly buffer overruns!
One nice thing about CobolScript as a CGI language is that all its variables are safely fixed-width, so you can code in the year value with just two digits (ha ha). This also means that in CobolScript you can copy a 100-byte string onto a 10-byte string and the interpreter will copy only the first 10 bytes. In C, that same operation might well smash the stack and compromise your Web server.
What's more, with CobolScript your strings are never bigger than you think they are, so you're also not likely to overallocate system memory.
More bad news: Potential risks with ACCEPT DATA FROM WEBPAGE
On the other hand, there is a flaw in the model that CobolScript uses for handling CGI variables. The basic method is to execute the command ACCEPT DATA FROM WEBPAGE. That parses the HTTP POST request, and for each <variable>=<value> pair in the input stream, assigns the <value> to the CobolScript variable of the same name.
That is a neat idea -- except that there's no restriction on which variables can be overwritten.
For example, take this excerpt from Deskware's sample CGI script hello3.cbl:
WORKING-STORAGE SECTION.
01 WS-VARIABLES.
05 my-variable PIC X(40).
05 WS-CONTENT-LENGTH PIC 9(05).
PROCEDURE DIVISION.
0000-MAIN.
GETENV USING `CONTENT_LENGTH` WS-CONTENT-LENGTH.
IF WS-CONTENT-LENGTH IS GREATER THAN 0 THEN
ACCEPT DATA FROM WEBPAGE
END-IF.
DISPLAY `Content-type: text/html`.
DISPLAY LINEFEED.
DISPLAY `<HTML><BODY>`.
DISPLAY `<CENTER>Hello World</CENTER>`.
DISPLAY `my-variable: ` & my-variable.
* comments and rest of program omitted
If the ACCEPT DATA FROM WEBPAGE is executed and the POST data section contains the string my-variable=hello, the generated Web page will display "my-variable: hello".
Fine so far, but the ACCEPT DATA FROM WEBPAGE command is not picky about which variables it writes on. Take the following example:
IDENTIFICATION DIVISION.
PROGRAM-ID. INSECURE.CBL.
AUTHOR. MIKES.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE COMPUTER. LINUX.
OBJECT COMPUTER. LINUX.
DATA DIVISION.
FILE SECTION.
FD `/tmp/httpd/ls.output` RECORD IS 100 BYTES.
01 WS-VARIABLES.
05 file-rec PIC X(100).
05 WS-EOF PIC X(1).
05 ws-content-length PIC 9(5).
01 WS-COMMAND-GROUP.
02 cmd PIC X(20) VALUE `/bin/ls -l `.
02 dir PIC X(50).
02 redirect PIC X(3) VALUE ` > `.
02 target-name PIC X(40) VALUE `/tmp/httpd/ls.output`.
01 WS-COMMAND PIC X(113).
PROCEDURE DIVISION.
*****************************************************************
* MODULE: 0000-MAIN *
*****************************************************************
0000-MAIN.
GETENV USING `CONTENT_LENGTH` WS-CONTENT-LENGTH.
IF WS-CONTENT-LENGTH IS GREATER THAN 0 THEN
* expect to read variable "dir" here
ACCEPT DATA FROM WEBPAGE
END-IF.
DISPLAY `Content-type: text/plain`.
DISPLAY LINEFEED.
* omitted code here -- clean up "dir", remove unsafe characters
MOVE WS-COMMAND-GROUP TO WS-COMMAND.
CALL WS-COMMAND.
OPEN `/tmp/httpd/ls.output` FOR READING.
PERFORM UNTIL WS-EOF = `Y`
READ `/tmp/httpd/ls.output` INTO file-rec AT END MOVE `Y` TO WS-EOF
IF WS-EOF NOT = `Y` THEN
DISPLAY file-rec
END-IF
END-PERFORM.
CLOSE `/tmp/httpd/ls.output`.
GOBACK.
The code snippet above is a contrived example, but it illustrates the problem. It expects the variable dir as input, removes unsafe shell metacharacters (that step is omitted), and constructs a command of the form /bin/ls -l $dir > /tmp/httpd/ls.output, then writes out the contents of ls.output to the user. Leaving aside the safety of using /tmp/httpd to store the results temporarily, we have an even greater problem. Suppose some evil crackers know the source code and want to subvert the script. All they need to do is call the CGI script with a POST operation, and specify a new value for cmd, like so:
$ echo "cmd=/bin/cat+/etc/passwd" | POST http://yourhost.com/cgi-bin/insecure.cbl
And out comes your password file.
There is a simple workaround: don't rely on initializations in the WORKING-STORAGE section. Instead, include ACCEPT DATA FROM WEBPAGE as the first command in your CGI scripts that have parameters. Then do run-time initializations from literals on the variables that aren't CGI variables.
It is true that people attempting such an exploit without knowing your source code are likely to trigger lots of wordy messages like "CobolScript Error Number: 0273 CobolScript Error Message: A CGI variable in the submitting form does not have a matching CobolScript variable" while they are hunting for an exploitable variable. But you should not depend on this kind of security through obscurity in a production environment. Doing so would be as silly as depending on the unlikelihood of anyone's ever guessing that you are running a language as obscure as CobolScript.
Deskware has been notified of this problem and is working on a fix.
A cool concept, but it needs work
CobolScript has some good adaptations for Web scripting. First among them are its verbose, well-formatted error messages, which are displayed in the browser window. (If only there were hyperlinks to the manual!) The TCP/IP commands are useful here, too -- for example, CobolScript has all you need to set up a free email service like HotMail. Unfortunately, CobolScript falls down for Web scripting in one rather important area: database support. For now, Deskware recommends using shell scripts as helpers for database applications, but I find that unsatisfactory. Support for ODBC (the Open Database Connectivity standard) is planned for CobolScript Professional, due out "soon."
CobolScript is indeed a pretty cool concept, but I wouldn't turn to it for my daily scripting needs. I'm too familiar with getting things done in Perl for CobolScript to have won me over. On the other hand, I do think that it would be fun to have some exotic CGI COBOL scripts on a personal Web page. So I may return to CobolScript of my own accord sometime in the future.
But I think that COBOL programmers the world over will rejoice at the chance to write modern Web-based applications in a familiar language. As the era of Y2K wanes and the age of the ASP waxes, the potential pool of users for such applications approaches infinity. In other words, Deskware provides these guys with a gateway to the happy land of nth-tier enterprise middle beanlets. Just consider how many of the original COBOL programs must be in the public domain by now!
The current version of CobolScript is mature enough for prototyping
and internal use. Because of the security concerns noted above, I
cannot recommend using CobolScript in a production environment to
anyone not already versed in security, though the next patch should meet those concerns. Companies or individuals interested in stronger
database-access functionality will want to wait until the forthcoming
CobolScript Professional is released.
Resources
