[shawa_a_a]

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?

[SonOfLilit]

They don't use ASCII, they use EBCDIC, which has its elegant parts and its horrors (English letters are not contiguous in code-space).

The screen isn't treated as an infinite-scroll dot matrix printer, it's treated as a... as a very old visual text editor, with stencil masks, I guess.

The UI is very unified by alien conventions.

Files are not files, they are record stores.

There's a weird batch language that you use for everything.

If you're not writing a batch program, you'll be writing on top of CICS, which is a framework for, uh, realtime message processing programs and GUIs.

The DBs have their own idiosyncrasies. Etc' etc.

[bradrn]

> The UI is very unified by alien conventions.

I’ve heard of some of the other stuff before, but I’d be very interested in hearing more about how this works!

[414techie]

Check out the moshix mainframe YouTube channel. You’ll get a great flavor of mainframe dev in an approachable style.

[tyingq]

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.

[nsxwolf]

And there's file system stuff: https://stackoverflow.com/questions/28640159/what-is-the-dif...

[tyingq]

Ah, yep. The original nosql. Variable and fixed length record based storage, that comes with the OS.

[p_l]

The parts that are standardised in COBOL (k/v storage) are implemented in GNU COBOL using gdbm/Berkeley DB.

[Smoosh]

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.

[kstrauser]

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.

[Smoosh]

Part 2:

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.

[kstrauser]

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.

Hope you feel better soon!

[Smoosh]

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.

[__d]

ISPF was my first, and most abiding shock, having come from a Unix environment.

[nxobject]

And then you find an innocuous menu item called “MVS OpenEdition”, you open it, and your jaw drops in horror…