Earlier quoted context omitted.
Very inefficient though. But solid!
Actually it's 100% efficient in terms of converting electricity into heat. Anything that consumes electricity is near 100% efficient at generating heat. If you tried really hard you could build a very efficient laser and send heat outside the room, so not 100% would end up in the room. Even then the majority of heat will be dissipated in the room.
Buying an IBM Mainframe
101–110 of 111 posts
Re: Buying an IBM Mainframe
#102Earlier quoted context omitted.
Note: is anyone interested in using something like this? If so, let me know! I'm curious as to how I can make it useful for people in the field.
As I understand it, the field is going in the other direction, namely JVM/CLR COBOL. This means that companies can migrate their COBOL codebases to “commodity hardware”, save on mainframe costs, and then progressively refactor into Java/.NET replacing bits of COBOL piecemeal. The main company I’ve heard of doing this is MicroFocus, they have all the dev tooling for it for the major IDEs, compilers, etc. One of the ma…
Re: Buying an IBM Mainframe
#103Earlier quoted context omitted.
Actually it's 100% efficient in terms of converting electricity into heat. Anything that consumes electricity is near 100% efficient at generating heat. If you tried really hard you could build a very efficient laser and send heat outside the room, so not 100% would end up in the room. Even then the majority of heat will be dissipated in the room.
It’s 100% efficient, but you can do better than the 100% without breaking thermodynamic Laws with a heat pump.
Not to mention heat pumps require somewhere to pump to/from, you can't just put one in your basement, plug it into the wall, and heat up the basement. Also heat pumps work best with mild differences, like say 40F inside and 60F inside if you want to heat.
Heat pumps reduce to space heater efficiency if it's sub-zero Fahrenheit outside I believe.
Re: Buying an IBM Mainframe
#104Earlier quoted context omitted.
Would you have liked the project more if the price was not disclosed?
Oh I love the project. I'm just in awe of spending that much money for something you don't have a clear and present need for.
Re: Buying an IBM Mainframe
#105Earlier quoted context omitted.
It’s 100% efficient, but you can do better than the 100% without breaking thermodynamic Laws with a heat pump.
Right, but it was being compared to a space heater, not a heat pump. Not to mention heat pumps require somewhere to pump to/from, you can't just put one in your basement, plug it into the wall, and heat up the basement. Also heat pumps work best with mild differences, like say 40F inside and 60F inside if you want to heat. Heat pumps reduce to space heater efficiency if it's sub-zero Fahrenheit outside I believe.
Although in the UK most people use gas to heat their homes, because its cheaper. I worked out once that gas and heat pumps cost the same in the end for the amount of energy. Although what I love about heat pumps is how quick they get a place warm compared to radiators.
Granted heat pumps need installation, or you can probably run a tube out the window with one of those adapters.
It's a silly hypothetical discussion, because for the price of this mainframe you could get a heat pump and a set of solar panels and a battery storage, and have some money left over for some Hawaiian shirts to wear once you've heated the place up.
For financial efficiency (environment be damned) a set of crypto miners would be better than either the mainframe or the heat pump.
Re: Buying an IBM Mainframe
#106Earlier quoted context omitted.
As I understand it, the field is going in the other direction, namely JVM/CLR COBOL. This means that companies can migrate their COBOL codebases to “commodity hardware”, save on mainframe costs, and then progressively refactor into Java/.NET replacing bits of COBOL piecemeal. The main company I’ve heard of doing this is MicroFocus, they have all the dev tooling for it for the major IDEs, compilers, etc. One of the ma…
Hmm. I'm interested in making a compile-to-COBOL language only because that way a company could incrementally migrate an old COBOL codebase to the new language. In other words, the new code (which compiles to COBOL) and the old code (written in COBOL) would be fully interoperable, sharing the same data types, calling conventions, etc.
COBOL and mainframes have quite a different programming and system administration model to what we expect with servers. Lots of concepts are quite different, built up from a world of mainframes and terminals, tapes, batch processing, etc. Concepts like users, operating systems, files, networking, parallelism, programs, databases, are all quite different, and all of these differences cause companies problems in training users, and creating nice new software that works in ways people expect now.
Creating a, for example, JavaScript to COBOL compiler is probably not fully possible. You may be able to transliterate it, but you would essentially be writing a COBOL program in JavaScript syntax – not using Node libraries and writing React components. This reduces many of the benefits.
The alternate approach is that you take your COBOL and compile it to work in the JVM. You get a JAR out that you can run on your regular servers that are already running your other JVM software. There is probably a significant runtime built into that by the compiler that translates some mainframe concepts into modern concepts, but that's fine because you haven't had to rework your COBOL. Then, you can progressively pull out modules, rewrite in Java, and reference those from the old COBOL code. You don't need lots of training in mainframe concepts, you don't need to spend millions of dollars a year on your mainframe, and you can write new code in Java.
The US Department of Defence have taken this approach one step further, and are actually writing a compiler from COBOL to Java. It's not fully automated, but with not too many developer-hours, they can turn significant chunks of COBOL into reasonably good quality Java, over the course of several stages.
Your idea is a good one, and worth experimenting with maybe, but I think the best approach for the migration away from COBOL for large businesses (and only large businesses use it) is the other way around.
Re: Buying an IBM Mainframe
#107What kind of problems do you hope to solve? Are there anything in particular you will use it for?
Re: Buying an IBM Mainframe
#108Earlier quoted context omitted.
Can't you get to that uptime with a well-configured cluster? I tried to find more information but couldn't find any other reasons why mainframes would still be the best option for a newly designed system?
Also, with Mainframe, you’re not only using a different machine but also a different “everything”. You need specialized storage, you need to use an “exotic” programming language, you need people who know JCL, RACF, DB2 etc., for a lot of “middleware” (CD pipeline, access management, version control) you have limited vendors to choose from so you’ll pay a lot for that too. So if you are also running something else (Li…
Re: Buying an IBM Mainframe
#109Re: Buying an IBM Mainframe
#110Earlier quoted context omitted.
If you want to dabble with mainframe. Another option is the IBM zPDT. It is an emulator that runs on AIX or Linux. It does require a physical USB hardware key. It is kind of pricy about $5K from IBM, but there might be discounts. I believe that also get the z/OS and z/VM software and licenses also.
Yes that entitles you to a lot of software, so it is a good deal for professional use. If you are just curious on the software side at home, Hercules is an amazing project. For students IBM does a "Master the Mainframe" contest where you can get remote access to an environment and see what it is like as a user and developer.
Very much recommended for anyone who is curious.