7 ms·

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 yo

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?

tyingq 3y ago
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 3y ago
  And there's file system stuff: https://stackoverflow.com/questions/28640159/what-is-the-difference-between-a-variable-blocked-format-and-a-fixed-blocked-for https://stackoverflow.com/questions/28640159/what-is-the-dif...
  - tyingq 3y ago
    Ah, yep. The original nosql. Variable and fixed length record based storage, that comes with the OS.
    - p_l 3y ago
      The parts that are standardised in COBOL (k/v storage) are implemented in GNU COBOL using gdbm/Berkeley DB.
__d 3y ago
ISPF was my first, and most abiding shock, having come from a Unix environment.
- nxobject 3y ago
  And then you find an innocuous menu item called “MVS OpenEdition”, you open it, and your jaw drops in horror…
Smoosh 3y ago
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 3y ago
  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 3y ago
    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.
SonOfLilit 3y ago
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 3y ago
  > 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 3y ago
    Check out the moshix mainframe YouTube channel. You’ll get a great flavor of mainframe dev in an approachable style.

tyingq 3y ago

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 3y ago
And there's file system stuff: https://stackoverflow.com/questions/28640159/what-is-the-difference-between-a-variable-blocked-format-and-a-fixed-blocked-for https://stackoverflow.com/questions/28640159/what-is-the-dif...
- tyingq 3y ago
  Ah, yep. The original nosql. Variable and fixed length record based storage, that comes with the OS.
  - p_l 3y ago
    The parts that are standardised in COBOL (k/v storage) are implemented in GNU COBOL using gdbm/Berkeley DB.

__d 3y ago

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

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

Smoosh 3y ago

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 3y ago
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 3y ago
  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.

SonOfLilit 3y ago

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 3y ago
> 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 3y ago
  Check out the moshix mainframe YouTube channel. You’ll get a great flavor of mainframe dev in an approachable style.