> Part of the reason I took the job was the opportunity to get paid to work on compilers, but also because I have a fascination with older computer technology.
> It's surprisingly easy to cross the border of native z/OS and the USS border. In fact, there's no border there at all. z/OS is one operating system with two different interfaces. So apart from normal problems and hiccups, you'll probably find that the biggest problem accessing the various services will be getting used to the difference in vocabulary between USS and native z/OS.
You can run IBM old OS/360 and many other mainframe OSes using hercules-390 [1], which emulates old and new mainframe architectures and has an active community [2].
Curious about his point about virtualisation; sure you can't run a VM locally but those mainframe OSs have had excellent support for VMs since the 1960s and are still in many ways far ahead of more mainstream hypervisors.
> Part of the reason I took the job ... because I have a fascination with older computer technology.
I was also thinking about going the mainframe route, also because general impression is that the mainframe developer earns big bucks. However, when I started exploring the job offers I was surprised that salaries were not that high at all.
So why is that impression still around, and do mainframe developers really earn significantly more money than a full stack enterprise web developer?
It depends on what the role is and many other things, the same as it is in any field. Of course, highschooler in Brazil who recently read a half of 'COBOL for dummies' in two weeks would not earn much more than other who choose 'J2EE for dummies'.
Deep knowledge and experience could bring significant profit, but the same is true for almost any other industry - maybe J2EE performance consulting for z/OS with CICS would pay more than J2EE performance consulting for AIX with TXSeries but not too much more.
Mainframe is possibly the most offshored field there is in enterprise technology. There are masses of roles in India and to a lesser extent China and Phillipines where is offers a stable decent paying career for these countries. That's where the base-line and critical mass of roles are.
Very true. Because these skills are in high demand, my experience has been that employee turnover in the mainframe sector offshore is extremely high. We had a tremendous problem retaining offshore mainframers through the big BPO companies like Wipro, Cognizant, US Technologies, etc. Go through the effort to train them up, and they would get poached in no time because their skills were in such high demand, and the training cycle starts over again.
Turnover can be high, often depends on industry and country.
I know/do banking with staff in China, around 300 mainframe engineers, with average tenure around 5 years, which is miles ahead of India. If you'd like pointers for mainframe in China, drop me a mail.
Furthermore, lately IBM has literally bought Mainframe developers off of other companies. My employer several years ago pink-slipped their entire AS400 work force. Immediately, IBM showed up with job offers for all of them at a severe price cut as contractors. Then, for 5 years, they laid off 25% of them until all that was left were the cheapest, unmotivated code drones that would bill maximum hours and not ask for raises.
I've heard similar stories all over from companies on Mainframe/AS400 platforms. It's totally anecdotal, but at this point it's pretty in character from IBM these days.
The more i learn about mainframes (and minicomputers) the more i feel that the PC world is basically rediscovering old ideas as ICs become ever more potent.
I worked as a CPU logic designer on several mainframes of different architectures before moving to Sili Valley. The "look what I just invented" arrogance I encountered astounded me. When I said something like: "You know, Seymour Cray invented that around 1959, right?" the cognitive dissonance was more than they could handle -- I was usually ignored. So, no, they aren't re-implementing, they are genuinely re-creating history and being proud of themselves for it.
It's everywhere these days. That would be very naive to expect from NoSQL 'inventors' to be familiar with IBM IMS and ADABAS, CODASYL Data Model, the history of pre-relational databases, or at least MUMPS or GemStone/S.
What exactly is a "mainframe" in a modern sense? I thought it exclusively referred to old-fashioned big iron. Is it a cluster? Or are we actually talking about quarter-century-old monoliths running ancient, indispensable code?
These are completely disconnected from commodity hardware. They are descendents of System/360, with a completely custom architecture and "mainframe processors" which only run specific types of code (Java, XML, DB2).
sort of. The run z/Architecture CPUs which implement a lot of backwards compatibility.
In the old days you had various modules you connected with dedicated CPUs for certain tasks, you'd pay more for them. These days they have a bunch of CPUs and the amount of money you pay IBM determines what those CPUs can do.
There's no physical difference between the Linux CPU, the DB2 CPU and the Java CPU, they're all the same as the main CPUs. IBM just charge you more for general purpose CPUs.
Ahh, I recall that we ordered an upgrade of the system hardware because we needed 4 more CPUs, and this was accomplished by sending a code that unlocked extra CPUs that had been sitting in our basement all along since the day they installed that system.
IBM do the same for P series as well. You get the privilege of purchasing an 8 core server but you only get the rights to use 4 cores. It's your responsibility to pay IBM when comes the time to be able to use all the 8 cores. Organized crime of sorts... like democracy
Actually, if the prices are pre-agreed, it's a sweet deal. If I have a big box serving my users, being able to enable additional on premises capacity in minutes is nice.
Last time I did it, Dell took several weeks to deliver the new machine.
We didn't try but being speaking with the vendor it seemed that enabling extra cores could take about a week from raising a purchase order to the activation code coming through. Maybe larger customers who run hundreds of these may have a quicker turn around time dealing directly with IBM.
And it's not that IBM deliver an entire server like in your case. For most practical applications, it's merely the case of adding CPUs to the pool of CPUs available to the PowerVM hypervisor. If you need to provision additional memory or IO, that needs to be accounted in as well.
That hypervisor is weird on it's own. It's part firmware part software.
If you have big box serving your users who solely rely on CPU cycles then yes, it's a sweet deal. And consider yourself very lucky if you have users who will immediately see better performance if you throw more CPU cycles at them.
I remember one case where the activation code was in a sealed envelope. If used, the machine would acknowledge that through its direct line with IBM and billing would proceed. The unlocked resources would become available immediately.
That was in the early 90's and a lot could have changed since then.
It refers basically only to the IBM z/Architecture machines. (I think no one else makes them any more. There were some IBM compatible (heh) Japanese ones recently). You can call a cluster of PCs a supercomputer, but you cant call it a mainframe.(But you can run a cluster, or sysplex, of mainframes. It sounds over the top but it is actually quite common.) They are particularly considered mainframes when they run z/OS and work in batch mode especially running CICS or IMS based applications. As soon as it runs linux, or web services, or more interactive things, the same zSeries machine is slightly less mainframy. (Using USS is less mainframy than using TSO or ISPF btw heh)
Aside from embedded systems, mainframes are the natural state of computers. That is, over time, computers tend to converge on either embedded controllers for appliances, or big racks in back rooms doing big calculations.
"There are a lot of little things that don't match up with what I would consider to be standard development practice, but I'd like to think I'm mature enough to not assume it is wrong simply because it is different from what I know. Injecting some different approaches and learning a lot along the way is part of the enjoyment."
That's something that I keep running into...just because something is different from what you are most comfortable with doesn't mean its wrong. It's just different. It may even have something for you to learn.
By the way, z/OS is not the only way to run IBM mainframes.
There's TPF (Transaction Processing Facility) "because a real operating system is too high level and therefore too slow for real transaction processing needs".
Current users of TPF include Sabre, VISA, American Airlines, American Express, HP SHARES (formerly EDS), Holiday Inn, Alitalia, KLM, Amtrak, Marriott International, Travelport, Citibank, Citifinancial, Air Canada, Delta Air Lines, Japan Airlines and many others.
47 comments
[ 4.5 ms ] story [ 109 ms ] threadIt may be worth re-reading the article.
Still, mainframes...
http://www.ibm.com/developerworks/aix/library/au-bordercross...
https://www.youtube.com/watch?v=Xfl4spvM5DI
[1] http://www.hercules-390.eu
[2] http://groups.yahoo.com/group/bercules-390
I was also thinking about going the mainframe route, also because general impression is that the mainframe developer earns big bucks. However, when I started exploring the job offers I was surprised that salaries were not that high at all.
So why is that impression still around, and do mainframe developers really earn significantly more money than a full stack enterprise web developer?
I know/do banking with staff in China, around 300 mainframe engineers, with average tenure around 5 years, which is miles ahead of India. If you'd like pointers for mainframe in China, drop me a mail.
I've heard similar stories all over from companies on Mainframe/AS400 platforms. It's totally anecdotal, but at this point it's pretty in character from IBM these days.
Me too. Sounds fun. Plus, I liked the 3278 a lot.
I worked as a CPU logic designer on several mainframes of different architectures before moving to Sili Valley. The "look what I just invented" arrogance I encountered astounded me. When I said something like: "You know, Seymour Cray invented that around 1959, right?" the cognitive dissonance was more than they could handle -- I was usually ignored. So, no, they aren't re-implementing, they are genuinely re-creating history and being proud of themselves for it.
To be fair, Atari and Commodore computers already had that.
And the marvelous 1403 printer would often be driven by a 1401.
These are completely disconnected from commodity hardware. They are descendents of System/360, with a completely custom architecture and "mainframe processors" which only run specific types of code (Java, XML, DB2).
Or that's what I gather from wikipedia anyway.
In the old days you had various modules you connected with dedicated CPUs for certain tasks, you'd pay more for them. These days they have a bunch of CPUs and the amount of money you pay IBM determines what those CPUs can do.
There's no physical difference between the Linux CPU, the DB2 CPU and the Java CPU, they're all the same as the main CPUs. IBM just charge you more for general purpose CPUs.
Last time I did it, Dell took several weeks to deliver the new machine.
And it's not that IBM deliver an entire server like in your case. For most practical applications, it's merely the case of adding CPUs to the pool of CPUs available to the PowerVM hypervisor. If you need to provision additional memory or IO, that needs to be accounted in as well.
That hypervisor is weird on it's own. It's part firmware part software.
If you have big box serving your users who solely rely on CPU cycles then yes, it's a sweet deal. And consider yourself very lucky if you have users who will immediately see better performance if you throw more CPU cycles at them.
That was in the early 90's and a lot could have changed since then.
http://www.winestockwebdesign.com/Essays/Eternal_Mainframe.h...
Plug: I wrote the above.
That's something that I keep running into...just because something is different from what you are most comfortable with doesn't mean its wrong. It's just different. It may even have something for you to learn.
"Building Go for Linux on z System"
https://github.com/linux-on-ibm-z/docs/wiki/Building-Go
> The HostBridge JavaScript Engine (HB.js) is server-side JavaScript for CICS® applications and IBM z Systems™ data assets
> HB.js runs inside CICS and supports:
> CICS terminal-oriented (visual) transactions (Orchestrate CICS terminal-oriented transaction micro flows as single services)
> BMS, non-BMS, 3270, and CA application types
> COMMAREA (non-visual) programs (Orchestrate and aggregate transactions, programs (e.g., COMMAREA), and data into single composite services)
> DB2®, VSAM™, DL/I, Datacom®, and other data assets
> Connectivity via HTTP, LINK/EXCI, Enhanced WebSphere MQ Extended Multi-Region Operation (MRO)
https://www.hostbridge.com/index.php/products/javascript-web...