Live data from Hacker News

Hello World on z/OS

medium.com

51–60 of 123 posts

Re: Hello World on z/OS

#51
post #33

This is a nice reminder about how one feels when one meets a piece of technology for which one's intuition can't offer anything useful, many "common sense" assumptions end up incorrect, and you don't even know the right words to feed to a web search engine. I'll try to memorize this feeling, and remember it every time I try to explain something technical to people outside that field. Maybe it will help me explain bet…

My introduction to z/OS mirrors the posters. A week of trying to google random keywords, copy JCL, waffle about the system trying to get anything done. Eventually copied out some JCL from a frame of a paused youtube video, and another four hours to track down a system library I needed. But the entire system is fascinating and it kept me going. The once unappealing 600page manual on IBM Enterprise Cobol became the defacto documentation, reading Redbooks and listening to the Terminal Talk podcast became valuable sources of information and the acronym soup started to be a little less fuzzy. Stack Overflow became nearly useless.

Then I found Master The Mainframe and got to play with a properly maintained LPAR with some (admittedly handhold-y guides). Joy! Non-crusty versions of z/OS. Did you know you can generate JSON with Cobol and I've managed to bolt this on to a webservice that interfaces with DB2? I sure as hell didn't! (z/OS Connect is a better way to do this though).

It's only been a month or two, but the amount of time I spend going against my intuition is beautiful. It's really made me reconsider the way I use/design computing facilities in other avenues. I'm not a professional or employed programmer, but this is the most fun I've had since playing with distributed computing, and in Cobol nonetheless. I even set up a 3270 styled blog due to it.

[1] https://iebdg.tumblr.com/

Re: Hello World on z/OS

#52

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 dom…

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

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

Re: Hello World on z/OS

#53
post #30

Earlier quoted context omitted.

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

> 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.

Re: Hello World on z/OS

#54
post #7

In the 'Allocate New Data Set' screenshot, it says - for the expiration date field - that the formats are 'YY/MM/DD, YYYY/MM/DD, YY.DDD, YYYY.DDD in Julian form, DDDD for retention periods in days or blank'. (I added some commas, which I assume are supposed to be there, but are just line breaks in the screenshot.) Does that mean z/OS supports the Julian calendar?

It does, In a similar vein Cobol has the ACCEPT DATE (YYMMDD) and ACCEPT DAY (YYDDD) constructs for retrieving the date. There's an optional argument for supporting four digit year codes however. Julian dates pop up in some wonky places across the system.

Re: Hello World on z/OS

#55
post #27

Missed my favourite part of learning the mainframe: where the enter key is. Return and enter and two different keys, but, on most modern systems, they perform a similar function. On z/OS Return moves down a line (similar to Tab, but ignoring all entries on the current line) and Enter actually sends to data off. Once you get used to it, it's really no different to the Linux or Windows command lines. It's certainly dat…

The ISPF editor is actually more than decent. About 20 years ago my father was writing COBOL (on both AS/400, now iSeries, and PC) using SPFPC, an MS-DOS editor inspired by ISPF. The line command/primary command mechanism is really no more quirky than vi's movement and insert modes, and it makes a lot of sense for languages like COBOL.

Re: Hello World on z/OS

#56
post #2

I demember doing virtualisation/containerisation for Linux on various platforms (including s/390 and z/VM but also VMware and Xen) at IBM. No matter what the platform was, the PMs would refer to the VM/container as an 'LPAR' (logical partition). Fun times.

Me too! I setup a couple of Linux LPAR on AS/400 - iSeries running OS/400. The distro was RedHat for PowerPC. One LPAR was for a Linux/Apache/PHP stack that used the DB2/400 database on the iSeries, and the other was to host an Oracle 8i instance. DB2/400 was a great RDBMS but there was an application requirement for an Oracle database, so the director of IT at the time said that if a DB is required then it must go o…

Hah I ran Fedora PPC on a Mac Mini around the same time. It was super cool because could could read all the firmware info - serial numbers, memory slots etc - as files in /proc rather than using 'dmidecode' like an Intel machine. Felt way more Unixy.

Re: Hello World on z/OS

#57
post #33

This is a nice reminder about how one feels when one meets a piece of technology for which one's intuition can't offer anything useful, many "common sense" assumptions end up incorrect, and you don't even know the right words to feed to a web search engine. I'll try to memorize this feeling, and remember it every time I try to explain something technical to people outside that field. Maybe it will help me explain bet…

I still remember how weird it was to learn Unix. It took me like four years to figure that "man pages" did not have anything to do with manliness. ;-)

Re: Hello World on z/OS

#59
post #21

Earlier quoted context omitted.

One of my older coworkers told me that IBM used to have a travelling mainframe demo in the back of a truck. As part of this demo, they would start a big computation, and then reach into the mainframe and start pulling out RAM and entire CPUs straight from the sockets, while the thing kept right on computing.

ZFS developers like to do this with hard drives :) But how did IBM do that with RAM ? Do mainframes have… redundant RAM? Like literally sticks mirroring others?

I have seen one PC-based server that had redundant RAM. I never tried pulling out RAM modules, but I guess there is not much point in having a RAID1-like arrangement for RAM if the machine cannot handle random RAM modules dying without crashing the OS. And it wasn't even a super high-end system.

Re: Hello World on z/OS

#60
post #47

Earlier quoted context omitted.

FWIW, you could do the same thing with a Spark cluster. It might not handle it quite as gracefully, since you'd be taking down entire compute nodes, and probably some of the data storage along with them, but the computation would also be able to continue.

spark clusters still have a spof as far as I understand the architecture.

Two of them, I believe - the master for the cluster as a whole, and, for any individual job, its driver.

I wasn't really meaning to say that a Spark cluster is as robust as a mainframe (though maybe someone's figured out some tricks), more that I could totally see some sales folks conducting the same demo using something like Spark.

Post reply on HN