3 ms·

Once in a while I decide I want to play with COBOL, so I install GNU COBOL, dig out my old test code and try to use it to do something interesting. So, most re

Once in a while I decide I want to play with COBOL, so I install GNU COBOL, dig out my old test code and try to use it to do something interesting. So, most recently I wanted to simply read a file, do some simple processing and then write an output file. Very basic, right? Not so much with COBOL. First you have to statically declare the files you want to use. Let's say you want to read from "foo.txt": environment division. input-output section. file-control. select foo0 assign to "foo.txt" organization is sequential access mode is sequential file status is fs0. You then need to declare (statically again, of course) the structure of the records in the file. You can think of this as global variables that gets filled in when reading from the file: data division. file section. fd foo0. 01 foo0-rec. 02 foo-name pic x(40). 02 foo-value pic x(20). You also need to declare the "fs0" variable: working-storage section. 01 fs0 pic 99. Then, you need to open the file. That's not too hard: open input foo0. Then you want to read from it. You can do that using the command: read foo0. After the read, the variable "fs0" will be 0 when you've reached the end of the file, so you need a loop that, I presume (I never got this part to work right), would look something like: perform with test before until fs0 = 0 read foo0 * foo-name and foo-value now contains data from the file end-perform After all of this, I decided I wanted to do something different. I wanted to call a web service to load some information over HTTP. I dropped that project really quickly once I realised that the only way to do that was to use libcurl and directly access it using FFI. The FFI that is provided by GNU COBOL isn't really easy to work with, as evidenced by this discussion: https://stackoverflow.com/questions/26367026/how-to-make-http-requests-from-cobol https://stackoverflow.com/questions/26367026/how-to-make-htt... If you look at the code that is linked from that page, you'll rather quickly realise why COBOL is not such a great idea for general purpose computing.

tolle 9y ago
10 is EOF, 0 is successful read. Not that it actually matters, your point is perfectly valid. You can use sort off boolean operators thats toggled on based on the value in variables. Outgoing web requests are usually done via either a program in some other language that you call from the COBOL application, or via DB2s built in functionality by running it as an embedded SQL section in your program. Why the heck web requests are handled by the relational database is.. Well I mean it feels odd, but by doing it that way they added the functionality to both zOS and IBM i at once. And old developers don't have to learn all to much new stuff to do it. Also, while the COBOL program works with a static set of files with static filenames. Those names can point to any file by various overrides done in either JCL on the mainframe or CL on the IBM i/AS400. Regarding the file formats, you can read the file into different working-storage defined variables, so each row doesn't have to be identical field length/position. In short, COBOL is just one part of the solution. Various "scripting" languages play a large part in defining what files go in and out. And none of them are available outside of the actual mainframe/midrange environments. Most data is gathered from relational databases anyway nowdays, and embedded SQL, just like in PHP webpages of yesterdays web, is whats used in newly developed programs. But all in all, yes it's a rather cumbersome language, for any sort of sane string handling you have to revert to embedded SQL. But most problems you have to write programs to solve can usually be broken down into smaller problems. Then just chain programs to handle it. The language itself is usually just a bit of a bother, but the age old programs written 20-30 years ago written by developers of varying degrees of sanity who had no requirements on them to document their work is what makes the job a pain.
waltman 9y ago
It's certainly true that there's a lot of boilerplate verbosity involved in reading files in COBOL. But once you've done that, parsing out the fields will likely be much simpler than in most modern languages. Records like this are still produced at government agencies such as the US Census Bureau. I've often wondered if it might be simpler to do the parsing in COBOL and then pipe it to another language to do the rest of the processing.
- tolle 9y ago
  On IBM i all files are are also databases, so you could just define the length of all the fields in the file, then it's a SQL database ready for use. No need for a program to parse it. Just define a file, copy the incoming file to that file. Ready to be handled with SQL. Fixed length records are trivial on the platform.

tolle 9y ago

10 is EOF, 0 is successful read. Not that it actually matters, your point is perfectly valid. You can use sort off boolean operators thats toggled on based on the value in variables. Outgoing web requests are usually done via either a program in some other language that you call from the COBOL application, or via DB2s built in functionality by running it as an embedded SQL section in your program. Why the heck web requests are handled by the relational database is.. Well I mean it feels odd, but by doing it that way they added the functionality to both zOS and IBM i at once. And old developers don't have to learn all to much new stuff to do it. Also, while the COBOL program works with a static set of files with static filenames. Those names can point to any file by various overrides done in either JCL on the mainframe or CL on the IBM i/AS400. Regarding the file formats, you can read the file into different working-storage defined variables, so each row doesn't have to be identical field length/position. In short, COBOL is just one part of the solution. Various "scripting" languages play a large part in defining what files go in and out. And none of them are available outside of the actual mainframe/midrange environments. Most data is gathered from relational databases anyway nowdays, and embedded SQL, just like in PHP webpages of yesterdays web, is whats used in newly developed programs. But all in all, yes it's a rather cumbersome language, for any sort of sane string handling you have to revert to embedded SQL. But most problems you have to write programs to solve can usually be broken down into smaller problems. Then just chain programs to handle it. The language itself is usually just a bit of a bother, but the age old programs written 20-30 years ago written by developers of varying degrees of sanity who had no requirements on them to document their work is what makes the job a pain.

waltman 9y ago

It's certainly true that there's a lot of boilerplate verbosity involved in reading files in COBOL. But once you've done that, parsing out the fields will likely be much simpler than in most modern languages. Records like this are still produced at government agencies such as the US Census Bureau. I've often wondered if it might be simpler to do the parsing in COBOL and then pipe it to another language to do the rest of the processing.

tolle 9y ago
On IBM i all files are are also databases, so you could just define the length of all the fields in the file, then it's a SQL database ready for use. No need for a program to parse it. Just define a file, copy the incoming file to that file. Ready to be handled with SQL. Fixed length records are trivial on the platform.