I worked on a mainframe for a major airline over 20 years ago. I always found it amusing that Sabre detailed my programs/jobs to cost the airline almost 7 figures a year; I never knew if that was real dollars or price to be negotiated down. Most of my programs was to repackage yesterday's flights and passenger data into CSV files so an external program can pick them up and ETL into a data warehouse. At the time, there was no utility like ODBC. I had to use JCL and SAS and my own created utilities. I even had to write a utility to output to CSV (there was none offered out of the box by IBM or SAS).
The IBM mainframe: How it runs and why it survives
61–70 of 195 posts
Re: The IBM mainframe: How it runs and why it survives
#62> Mainframes descended directly from the technology of the first computers in the 1950s. Instead of being streamlined into low-cost desktop or server use, though, they evolved to handle massive data workloads. I think the first sentence is 100% correct, but the second one not so much: current desktops and servers (not to mention laptops, tablets, smartphones etc. etc.) evolved from the first microcomputers introduced…
It's still somewhat true. Desktop CPUs have hardware acceleration for things like video decoding, mainframes have hardware acceleration for things like encryption / decryption, compression / decompression, fixed-decimal arithmetic, etc.
Plenty of x86 CPUs have had crypto instructions in the last decade or so.
Re: The IBM mainframe: How it runs and why it survives
#63I ran Internet banking for a small bank in the early 2000's. We had our IBM mainframe right next to a bunch of HP/UX servers. It was just massive and had a nice red button which they warned all of us to stay clear from. I recall that was around the time running Linux on the mainframe was becoming a thing and we tried to run Websphere and our J2EE app on it. It was not successful (too slow) and we kept running on HP/UX.
Re: The IBM mainframe: How it runs and why it survives
#64Earlier quoted context omitted.
Inline SQL is something I've always missed elsewhere. Not sure it's viable when you've got a billion different incompatible databases supported on a platform, so some of the limitations of mainframes have advantages.
Check out C# LINQ, or Haskell postgresql-typed. https://learn.microsoft.com/en-us/dotnet/csharp/programming-... https://hackage.haskell.org/package/postgresql-typed-0.6.2.4...
Re: The IBM mainframe: How it runs and why it survives
#65Earlier quoted context omitted.
It persists in many places due to the deeply ingrained belief that, for one reason or another, it would be technically, practically, or economically impossible to migrate functionality off the mainframe. Somehow the people in charge of these systems have managed to convince large enterprises of this for decades . And now we are in a situation where their long held beliefs have become true because nobody is around tha…
Migrating a suite of programs written w/ COBOL, CICS, DB2 from z/OS to Linux is fairly straightforward. MicroFocus COBOL compiles IBM COBOL, DB2 runs on Linux or you can swap out another RDBMS. The CICS part requires a simple runtime easily implemented in C plus a new scanner to replace the calls in your programs. I was part of a 4 person team that knocked this out in under a year. 1,000's of mainframe programs runni…
What replaces JCL?
Re: The IBM mainframe: How it runs and why it survives
#66> Communication is through Kafka events or Java Messaging Services, and new server instances can be spun up in seconds in AWS or Azure clouds to provide additional capacity, which is needed for high-volume processing.
I'm honestly surprised that a bank would agree to run anything even remotely serious on someone else's infrastructure.
Re: The IBM mainframe: How it runs and why it survives
#67Earlier quoted context omitted.
It persists in many places due to the deeply ingrained belief that, for one reason or another, it would be technically, practically, or economically impossible to migrate functionality off the mainframe. Somehow the people in charge of these systems have managed to convince large enterprises of this for decades . And now we are in a situation where their long held beliefs have become true because nobody is around tha…
The greatest hurdle for a project to be replaced is that if its works. I assure you that the users of IBM mainframes would be looking at at least a multi million dollar project to perform a decommission and if even approved it would be first on the chopping block to pause / eliminate the project.
You are correct. There was a time when companies ran projects to replace their mainframes. They all largely failed. The trend now is to integrate around the mainframe. Build new functionality on modern systems and leverage the mainframe where it makes sense.
I worked at one company that is trying to replace their mainframe. The project is now in its second decade. The company has the burden of supporting the mainframe application and now the 'modern' application. The project is still a few years away from being able to completely shut off the mainframe.
Oh and the modern application is also showing its age as the business has changed and the modern system built assumption in from the mainframe system and in many ways is just as inflexible to change as the mainframe app was.
This is why companies aren't scrambling to replace their mainframe systems. They are happy to continue paying for the high cost of compute on these systems because its still cheaper and less risky than replacing the system.
Re: The IBM mainframe: How it runs and why it survives
#68Earlier quoted context omitted.
It persists in many places due to the deeply ingrained belief that, for one reason or another, it would be technically, practically, or economically impossible to migrate functionality off the mainframe. Somehow the people in charge of these systems have managed to convince large enterprises of this for decades . And now we are in a situation where their long held beliefs have become true because nobody is around tha…
Migrating a suite of programs written w/ COBOL, CICS, DB2 from z/OS to Linux is fairly straightforward. MicroFocus COBOL compiles IBM COBOL, DB2 runs on Linux or you can swap out another RDBMS. The CICS part requires a simple runtime easily implemented in C plus a new scanner to replace the calls in your programs. I was part of a 4 person team that knocked this out in under a year. 1,000's of mainframe programs runni…
> DB2 runs on Linux
The DBA's I interned with would yell at you for this claim. They'd say UDB runs on Linux, but DB2 only runs on z/OS.
I worked with both DB2 & UDB during my internship 2 decades ago, and while largely compatible with core SQL functionality, that changed quickly after you got off the "normal" path. UDB was released at a much faster cadence, and if you developed to the latest features of UDB, you'd often find yourself unable to deploy against DB2.
A few of my last projects as an intern: 1) storing BLOB objects in DB2 from a .Net app and 2) porting an "interactive" batch-processed COBOL app to ASP.Net form 3) getting DB2 Connect clustering on windows working (I never did get this working despite spending an entire summer on the phone with IBM support).
I've some fond memories of working with the mainframe. Like the time I managed to crash the entire development LPAR with a specific SQL query that broke the DB2 query optimizer... The phone call from the NOC was immediate and went something along the lines of "I don't know what you did, but don't do it again, you just took down all of development". Development was something like +10k users...
Re: The IBM mainframe: How it runs and why it survives
#69> Communication is through Kafka events or Java Messaging Services, and new server instances can be spun up in seconds in AWS or Azure clouds to provide additional capacity, which is needed for high-volume processing. I'm honestly surprised that a bank would agree to run anything even remotely serious on someone else's infrastructure.
Re: The IBM mainframe: How it runs and why it survives
#70Earlier quoted context omitted.
Migrating a suite of programs written w/ COBOL, CICS, DB2 from z/OS to Linux is fairly straightforward. MicroFocus COBOL compiles IBM COBOL, DB2 runs on Linux or you can swap out another RDBMS. The CICS part requires a simple runtime easily implemented in C plus a new scanner to replace the calls in your programs. I was part of a 4 person team that knocked this out in under a year. 1,000's of mainframe programs runni…
What replaces JCL?
perl scripts. sorry