Hacker News Reader

Comment by userbinator | Hacker News Reader

The reason why things are the way they are on mainframes, and how you should think intuitively, becomes a lot clearer once you realise that they are a long-evolved version of the very first mechanical punched-card processors:

https://en.wikipedia.org/wiki/Unit_record_equipment

In fact, I'm almost willing to bet that the foreignness of mainframes to the average developer is due to mini/microcomputers having become dominant and taken a very different evolutionary path; Linux and DOS/Windows have far more in common with each other than mainframe OSes, despite their huge differences, because they evolved from mini/microcomputers and UNIX.

View on HN

> Linux and DOS/Windows have far more in common with each other than mainframe OSes, despite their huge differences, because they evolved from mini/microcomputers and UNIX.

Surely Linux and the Windows NT line (don't confuse the Windows 9x line, which evolved indirectly from DOS with the Windows NT line) have much more in common with each other than mainframe OSes, but Windows did not evolve from UNIX:

The Windows 9x line evolved indirectly from DOS (cf. [1]). DOS was inspired a lot by CP/M.

The Windows NT line is a spiritual succesor to VMS (cf. [2]). The kernels of both operating systems were designed by Dave Cutler, who did not like UNIX (cf. [3]). Indeed, Windows NT has I/O Completion Port (IOCP, [4]) as an - in my opinion - better I/O system than the UNIX process input/output model.

[1] https://blogs.msdn.microsoft.com/oldnewthing/20071224-00/?p=...

[2] https://www.itprotoday.com/management-mobility/windows-nt-an...

[3] https://en.wikipedia.org/w/index.php?title=Dave_Cutler&oldid...

[4] https://en.wikipedia.org/w/index.php?title=Input/output_comp...

MS/PC/DR-DOS was also inspired by Unix. It's where the handle-based API, the hierarchical directory structure, and indeed ioctl, came from that appeared in MS/PC-DOS version 2.

> The Windows 9x line evolved indirectly from DOS

Not sure what you believe to be 'indirect' about that relationship. That Windows codebase started out running on DOS and ultimately wound up so closely coupled that they shipped together in the same box as the same product.

> Windows did not evolve from UNIX:

Windows, through its DOS lineage, does indeed have some roots in the Unix tradition. (This should be unsurprising, since Microsoft was one of the more successful Unix licensees in the early 80's.)

https://blogs.msdn.microsoft.com/larryosterman/2005/06/24/wh...

To put Cutler's dislike of Unix into perspective, DOS (and Windows) had close to a decade of development prior to his involvement. (DOS shipped in 81, Cutler got involved in ~88, his first product shipped in ~93, and the old DOS-based Windows wasn't fully deprecated until 2001-1.)

DOS commands and hierarchical file paths were based on DEC’s TOPS-10, via CP/M, both of which Cutler would have been familiar with.

DOS was at best a mongrel mash-up. It no more evolved from Unix than AmigaOS did.

> DOS commands and hierarchical file paths were based on DEC’s TOPS-10, via CP/M, both of which Cutler would have been familiar with.

I'm sure he was, but DOS got pathnames in March of 83 and Cutler didn't join until 6 years later.

Solaris has event ports which are equivalent to Windows IOCP. So not all *NIX systems are deficient in that regard :)

> Solaris has event ports which are equivalent to Windows IOCP. So not all *NIX systems are deficient in that regard :)

I know, but IOCP badly fits into the "UNIX philosophy", i.e. in this case how input/output is "typically" organized under UNIX.

On top of it, the Linux ecosystem has evolved in cloud space to be more like VMS with things like metering, more security restrictions, clustering, and so on. The "unnecessary" stuff that was integrated with VMS ground up got bolted onto Linux's later.

Sure, that's certainly important to keep in mind. But that doesn't mean IBM shouldn't invest in usability.

They and others have.

There are ways to develop in Eclipse that can target z/OS.

https://developer.ibm.com/zsystems/documentation/java/jzos/j...

https://www.ikanalm.com/solutions/devops-and-toolchain-orche...

However, the people who develop for z/OS are often people who are familiar with Interactive System Productivity Facility (ISPF). It's a bit like whether people who are proficient in Vim or Emacs really benefit that much from an IDE.

There is also a unix shell with a z/OS interface:

https://www.ibm.com/support/knowledgecenter/zosbasics/com.ib...

But again, the people who program mainframe learn it through that environment. It would be interesting to hear from people who have used these sorts of set ups.

I've been working on Mainframes for the passed 8 years full time, and several internships before that. I often go several days with out needing to use ISPF. I use https://compuware.com/workbench-mainframe-modernization/ for dataset editing, job submission, etc. I find the Unix shell you access through ISPF to be very difficult to use. Luckily SSH is available on z/OS, so if I need to do Unix stuff I can just SSH in with the client of my choice. The biggest difficulty I had when getting started was understanding JCL. I had come from a Linux background, so was used to executing commands with arbitrary file names, looping, etc. It took me a while to understand how JCL worked. Once I understood that you have to define datasets with things such as space allocation and disposition before using them, and that JCL was a series of sequential steps with the output from a prior step available to a later step a switch flipped and I went from struggling with JCL to fairly comfortable in a couple days. I'm not sure how much of this was the fact that I was an intern at the time so didn't have a lot of programming experience and how much of it is the platform. I find that once you get comfortable with the basics of JCL the structure it forces you into actually makes it easier, even though it is limiting in some ways. The issue I still have with the Mainframe is documentation. Unlike most programming questions a google search does not turn up Stackoverflow results. I find I spend a lot of time going through random forums or reading the IBM doc. I don't find IBM doc easy to understand, but the more I have to deal with it the easier it gets.

> The issue I still have with the Mainframe is documentation. Unlike most programming questions a google search does not turn up Stackoverflow results. I find I spend a lot of time going through random forums or reading the IBM doc. I don't find IBM doc easy to understand, but the more I have to deal with it the easier it gets.

You're not alone my friend, those IBM docs certainly are not easy to read/understand.

> You're not alone my friend, those IBM docs certainly are not easy to read/understand.

Just as for Unix, Linux, Windows, and so on, there's an IBM "culture" (terminology, conventions, etc.) that you have to get used to. (It often helps to know some of its history, too.) But since I grew up professionally with one foot in the IBM world I usually don't have much trouble at all reading their docs.

> I find the Unix shell you access through ISPF to be very difficult to use.

Hehe, I once ran tail(1) and forgot to enter the file name, so tail read from stdin, and Ctrl+D did not work, so my shell was stuck waiting for input until the system was IPL'ed. Fun times... ;-)

This is just between you and me, OK, but a couple of years back I managed to do something similar on an IBM i, in its QShell (AIX) environment. And it felt bad, too, because such an unrecoverable glitch is almost unheard of in iSeries land!

FYI, https://www.reddit.com/r/mainframe is a thing, as is http://terminaltalk.net .

> that doesn't mean IBM shouldn't invest in usability.

For whom? They shouldn't necessarily spend a bunch of effort adapting their product towards the Unix world, particularly to the extent it compromies their product for their primary customer base.

Part of the problem about mainframes is that it has become really difficult for companies to find employees familiar with the environment. And learning the environment makes learning Unix look like a cakewalk.

I've managed to make do with VSCode, sshfs, reading the iconv manpage and using the USS Submit command for job cards. The current workflow has SDSF open in c3270 to the left and VSCode loaded with Cobol extensions to the right. Saving, compiling and running my code is only a few keystrokes and it's not too hard. There's even full IDEs and integration packages as other users have mentioned.

It's usable, but a little different. I mean the guys at Rocket Software have ports of some of the basic unix packages for z/OS including the Bash Shell, just adding that to USS improves quality of life tenfold. Many features are doable through USS but ISPF will always be the main interface.

I wonder why they haven't developed a more human-friendly successor to JCL. I get that IBM's all about backward compatibility, but would it kill them to add a more accessible alternative?

I once spent three days figuring out how to deal with an invocation that did not fit in an 80-character line. sigh

There was OCL on the IBM S/34 and S/36 back in the day, and there's CL on the IBM i today, which dates back to the earliest S/38 days (circa 1978). It's been some decades now since I've dealt with JCL, but as I recall both of those other languages make JCL look like child's play in comparison. Also, don't forget about Rexx!

Ugh, I tried to learn Rexx and I really did not like it. Maybe it is more "at home" on a mainframe, but playing with Regina Rexx on my desktop was no fun.

(Rexx has since developed an object oriented dialect, that might be more convenient to use.)

Reply on news.ycombinator.com