Having written some COBOL while consulting for a bank:
The language is not interesting at all without the ecosystem, which is this fully flushed alien alternative universe of computation. If you want to dive into COBOL, don't try to run it on x86, get yourself a mainframe account.
Or any of the companies that can run mainframe COBOL and provide all the ecosystem. heirloom computing is of course the best (i am cto) but Micro Focus, lzlabs etc all enable you to run off mainframe with a full ecosystem.
Do not know about our competitors but you can run our product for free on a raspberry pi if you just want to play around.
If I recall, microfocus recompiles while lzlabs emulates on a layer.
With microfocus JCL become bash scripts and have similar tools to mainframe. Unsure if lzlabs translates jcls.
My favorite unanswered question when someone told me take the 70.000 component core banking to cloud is “ok, on which language you can assure will run in 10-15 years?” As that’s the bare minimum the new CBS has to last.
If we had followed the crowd, we would have built it as microservices, then as event-driven architecture, then as Mini-monoliths, on auto generated Java that turns one cobol program into an object but is not designed as an OO platform…
I understand companies should not be tied to the past but running off a precipice full speed on is not smart either…
I enjoyed my decade working with mainframes probably the most out of anything in my career, but I suspect my opinion would be different had I been an application developer forced to work in COBOL.
There's a lot of very cool and technically interesting stuff to explore on the platform. Tons of great computing history, you really feel a bit like you are peering back in time going decade by decade as you move inward towards the core of the operating system. It's helpful to remind yourself that it's a direct descendent of the first successful commercial virtual memory implementation, and the core of the operating system has pieces that predate that. You can see the outlines of the world before that and how things adapted afterwards, how the modern process model slowly evolved out of DAT and time sharing, how things were handled in a fully vertically integrated system before the concept of device drivers was fully realized. How batch led to time sharing and transaction monitors and how all of that slowly turned into the web. And of course all the different tricks programmers used to be productive in that kind of a world.
It's impossible to fully realize all that we take for granted in modern computing when you haven't seen any of that.
Unfortunately the vast majority of people that work on mainframes never get to see that side of things.
I've been intrigued enough to pull down Gnu COBOL and attempt to write some simple programs, and found it to be quite an alien universe in and of itself. Can you give any examples of the fully-fledged mainframe world differing from running it on x86/arm?
All the surrounding ecosystem for batch scheduling (JCL, Tivoli), databases (IDMS, IMS, Adabas, DB2, etc), something like what we would call an app server (CICS), role based access control (RACF), and others I've missed.
IBM Enterprise COBOL decouples the file definition in the program from the physical file via a DDNAME. Thus the physical file to be used can vary at runtime. This is normally accomplished via JCL, meaning the program is run not from your terminal session, but in a job submitted for batch processing.
I’ve never touched big iron. Can you contrast that with a script that calls a program with command-line arguments, perhaps with a cron job? I get that there’s more to it than that, but I don’t know what I don’t know.
Not sure if I mentioned it, but files on the mainframe are usually called datasets. [lots of generalising and simplification follows]. There are different types, the most common are now sequential files, indexed sequential (VSAM) files and libraries (formerly partitioned datasets).
The datasets are mostly allocated on a per user basis. The name is made up of segments of up to 8 characters, for example, SMOOSH.USER.COBOL might be my COBOL library. And I would create a file SMOOSH.PROJECT1.INPUt.FILE to feed to a program which would output SMOOSH.PROJECT1.NEW.DATA. Apart from the first level, the naming is usually free-form, but there are site conventions. Access is controlled by the RACF system software.
Now to try to more directly answer your question. I open my terminal program. I would login to TSO and invoke ISPF where I will spend the rest of my day. I go top option 2 = edit. And put in the name of the file I wish to edit. In this case, SMOOSH.USER.JCL(MYJOB). The part in brackets is the member name - library datasets have members. I’m in edit mode where I make some minor changes to the JCL then from within edit I use the SUBMIT command to submit the current file for immediate batch execution. I then swap to another logical screen in ISPF and use the SDSF utility to check the job is on the input queue. It isn’t because it has already finished, so I check the output queue. The job listed there along with other recent jobs I have run. I select it and view the job log and output messages. Everything looks good, so I jump to ISPF option 1 (browse) and enter the name of the output file. I press enter and get a scrollable full-screen (text) viewer to check the file.
Since it is good I want to run the job again tonight using a different input file. I jump to the scheduler system software option. This is IWS (IBM Workload Scheduler) but Control-M is popular too. Using the screens there I set up a schedule to have it submit the job at a specified time tonight - the equivalent of cron. There are many other options though for stringing together multiple Jon’s in one run, the have dependencies and waits and check return codes before proceeding.
I don’t know if this has helped or just confused you. I would make an instructional video, but my employer wouldn’t allow it. I’d better stop now and go to bed. I’ll not well, and the iPad is autocorrecting me so much that this probably doesn’t make sense.
Whoa! That's way more information than I'd even hoped for! Thank you very much for a peek into a world I know next to nothing about.
I confess: my first impression is that it sounds painful. From a Unixy point of view, it seems like a heavy layer on top of some processes that just pipe information around in a needlessly complex way. I also admit this is due to my own ignorance of the matter. Lots of huge shops like what you're describing, so I'm sure there's something to it.
I know I'm not the first person to say this, but I really wish there were a way I could play with a modern system without investing lots of money or time into the experience. I don't know what I'm missing, and I'd like to find out.
Not easily, as they are so very different.
There are different ways to connect and logon. One is CICS, a transaction processor. This is what was used for online systems (banks, airlines etc). A short transaction code is entered followed by the required parameters. For example CANC 1234,231024 might be a cancel transaction on client 1234 for the date 2023-10-24. CICS is configured to invoke a particular COBOL (or other) program for the CANC transaction and pass it the parameters. The program starts up, receives the transaction and parameters from CICS via the equivalent of an API call. It then processes, probably confirming the client number exists, that the date is valid etc, reads the database, and updates the record there. Then when it finishes, it can emit a CICS screen to display or another (probably different) transaction. Thus processing may be chained together, or different programs invoked to guide the user through the processing. But that’s just CICS - more used for a user interface for systems.
If you are a developer you probably logon with TSO (Time Sharing Option). This gives you a command line where basic commands may be issued. There are a bunch of built-in system commands but they are mainly for managing datasets. You can write scripts in CLIST (Command LIST) language. These are the equivalent of shell scripts, being able to manipulate datasets and invoke programs. There is also REXX which is a much more sophisticated language.
Now as someone else commented, the IBM 327x terminal is not a glorified teletype, because IBM realised way back in the day that it would be much more efficient to only interrupt the computer when something happened, so it doesn’t use constant polling and communication but only interact when the mainframe sends data or the terminal sends an ENTER key (also function keys and some other special ones). This means that when you are typing away you can write a whole screen and the computer doesn’t know about it. When you press ENTER the whole screen is sent and processed and then the response is sent back. There is no live interaction.
Which brings me to ISPF. If you are a developer and working on the mainframe (not in an IDE) you will be using ISPF (Interactive System Productivity Facility). This is basically a menu system which makes the computer easier to use than the command line (a proto-gui a bit like the early CPM menu systems?). But ISPF is a lot more than just some menus. It includes an editor (have you ever used a full screen line-oriented editor? It has it’s charms.) and access to the compilers, and functions for allocating datasets, submitting jobs, monitoring jobs etc. Whatsmore, you can write your own ISPF screens and processing.
The other wild thing is that screens are defined with fields. Not only for colour, highlighting etc, but for display-only text (no overtyping) or for output or for input. You tab between input fields and enter the required text. This becomes fast and natural which is why those CICS screens in old systems are efficient. It is hard for people used to guis to come to grips with, as you have to understand where you can and can’t type on different screens.
Mainframe ecosystems include things like non-relationship databases and other I/O abstractions that may or may not be in use.
It resembles a combination of every Microsoft component (IIS, SQL), alongside dozens of separate proprietary products that are a fever dream of products to do simple tasks like write "files" to disk.
Suffice to say, you don't just go download your favourite open-source operating system in the mainframe world. You pay IBM a shitload of money for their proprietary one.
There is linux-on-Z but that's a completely different environment, intentionally. It's basically running linux in a virtualized environment (the only kind of environment on a mainframe) so that stuff expecting POSIX can run on the same hardware as mainframe jobs.
Hehe. I put together Cobol on Cogs ... decades ago. Funny to see it pop up again every couple of years :) I'm amazed everything still seems to work (apart from the F-Key based navigation, may need to put some work in.)
The language is not interesting at all without the ecosystem, which is this fully flushed alien alternative universe of computation. If you want to dive into COBOL, don't try to run it on x86, get yourself a mainframe account.