Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Programming IBM

IBM Rallies COBOL Engineers To Save Overloaded Unemployment Systems (medium.com) 116

As millions file for unemployment benefits in the United States every week, states' aging computer systems simply cannot keep up. States like New Jersey and Connecticut have said they are desperate for programmers who are still familiar with COBOL, a programming language that debuted in 1960 and is still used in critical computer systems like unemployment databases and banks. But there aren't many who know COBOL programming anymore. IBM, the leading provider of mainframes typically used to compile and run COBOL code, is trying to help bridge that gap. From a report: On Friday, IBM announced it was launching a free training program to teach coders COBOL as well as new forums to match those who know the language with those who need help maintaining their critical systems. The COBOL course will teach coders how to use the language in Microsoft's popular VSCode software and will be available next week. Next month, IBM says it will release a more fully fledged video COBOL course on online learning platforms like Coursera. The two forums that IBM has launched live on the Linux Foundation's Open Mainframe Project website. One of the forums, Calling all COBOL Programmers, has had dozens of engineers sign up in the last 24 hours from around the world. The other forum is more technical in nature, where coders can pose specific COBOL questions and work through projects with experts.
This discussion has been archived. No new comments can be posted.

IBM Rallies COBOL Engineers To Save Overloaded Unemployment Systems

Comments Filter:
  • by pele ( 151312 )

    How many layers does this irony have?

    • by AHuxley ( 892839 )
      Should have change to quality Ada code in some decade past?
    • Re:Nice (Score:5, Insightful)

      by phantomfive ( 622387 ) on Saturday April 11, 2020 @12:37AM (#59931476) Journal
      The kicker will be when people realize COBOL is more concise and flexible than Java or C#.
      • Re:Nice (Score:5, Funny)

        by ShanghaiBill ( 739463 ) on Saturday April 11, 2020 @12:54AM (#59931514)

        The kicker will be when people realize COBOL is more concise and flexible than Java or C#.

        Really. Cobol is not difficult. A competent coder can learn enough to get work done in a week. It was specifically designed so that business people can understand it.

        This all brings back fond memories. Years ago there was a company called Ryan-McFarland that made a Cobol compiler called "RM/Cobol". So the business folks would ask the nerds how to run it, and we would tell them to just type "rm <source-code>". Hee hee. Good times in cubeville.

        • Re:Nice (Score:5, Insightful)

          by thegarbz ( 1787294 ) on Saturday April 11, 2020 @05:25AM (#59931936)

          A competent coder can learn enough to get work done in a week.

          Yeah the problem here though is that we're not trying to get work done. We're trying to debottleneck failing aging systems coded by someone else. For that you're going to need someone with a little more understanding.

          • Deducing business rules from any program is difficult. Especially since they're unlikely to have been properly captured.

            The information density of a Cobol program is quite low. The upside is that it's nearly impossible to obfuscate. It resists any attempts to display cleverness. If you've programmed in any declarative language, Cobol is a trivial (but unattractive) detour. The arcane data declarations will take awhile to get used to though. If the program is organized into overlays, that's another small me

            • Deducing business rules from any program is difficult. Especially since they're unlikely to have been properly captured.

              As someone who's been working on such systems for decades, I've never once seen them captured and have my doubts they are anywhere given the way software is modified over time. People don't keep central design docs then modify those before the code - that would require business people who are competent enough to understand the whole system, which is not a thing. Business people like to say "we should modify this to do x instead of y" then create change requests from that, as a result old systems are all g

        • No worries, it is all ALGOL to me.
        • It is simple to understand but it takes a different mindset to comprehend what the software is trying to accomplish. Also, debugging existing COBOL code is much, much harder than writing code from scratch. additionally, there is likely a JCL component that will likely need to change as well. If the code is running on IBM mainframes.
        • Re:Nice (Score:4, Interesting)

          by cardpuncher ( 713057 ) on Saturday April 11, 2020 @10:55AM (#59932584)

          Really. Cobol is not difficult.

          It really isn't: it's mostly some conditional and looping logic and decimal arithmetic.

          However, most mainframe COBOL programs aren't just COBOL: the COBOL just wraps around macros for accessing databases or interacting with the teleprocessing environment (which queued up the inputs from the terminals, dispatched the appropriate bits of code and then returned the output from the right work unit to the right terminal). Depending on the age of the application, there's probably more of a requirement to understand CICS [wikipedia.org] or IMS [wikipedia.org]. That's where the expertise is likely to be thinner on the ground

      • Re:Nice (Score:4, Informative)

        by znrt ( 2424692 ) on Saturday April 11, 2020 @02:52AM (#59931730)

        concise? i would say cobol is probably the most verbose language in existence. intentionally so, since it was an attempt at mimicking natural language to make it more "user friendly".

        further, what you can express in cobol is not really much, its domain is very narrow: process registers, compute values, sort, collate, output registers. it was designed to handle punched cards. not really flexible.

        it doesn't even compare to a general purpose language like java or c#, it's more in the area of appliances, like report generators.

        • That may have been true in 1960 but now COBOL has functions. My comment was mainly a dig at programmers who keep their practical code to glue code ratio very low.
        • Re:Nice (Score:5, Insightful)

          by znrt ( 2424692 ) on Saturday April 11, 2020 @03:04AM (#59931744)

          furthermore: the problem here isn't to grasp cobol's "syntax", but to learn to move around in its environment, which are mainframes, terminals and likely huge chains of batch jobs, to fix decades old legacy code with a nightmare of layers of business rules most likely undocumented. plus you'll be lucky if you get a relational database.

          those few ibm courses won't be of much help.

          • Re: (Score:3, Insightful)

            by AmiMoJo ( 196126 )

            Back when I was writing COBOL for mainframes one of the worst aspects was trying to edit code on a terminal. Even back then we were used to GUI editors or at least the ability to move the cursor around freely and insert text in the middle of lines etc.

            I wasn't there long so never got to investigating if there was a better option but the guys who had been there for years didn't seem to think so.

            Despite all the hype there isn't much money to be made in COBOL, at least not around here.

            • by dwywit ( 1109409 )

              You take your hand off the keyboard to manipulate the mouse to move the cursor........

              or you keep your hands on the keyboard and use up, down, left, right, shift-up, shift-down, pgup, pgdn, tab, shift-tab, etc.

              I learned to code on 24x80, I wouldn't call GUI editors faster - but I accept that those who learned to code on them would find a text-mode screen frustratingly slow.

              • IntelliJ + VI-keys FTW!

              • by AmiMoJo ( 196126 )

                It's so long ago I can't remember exactly why it was such a pain... I think it was basically a line editor so going back was possible but very fiddly.

                Anyway what I do remember is that the guy showing me how it worked on day one managed to accidentally wipe half his example code while trying to edit it by getting confused as to where in the file he was and entering a load of blank lines.

            • Re:Nice (Score:4, Funny)

              by AntisocialNetworker ( 5443888 ) on Saturday April 11, 2020 @04:34AM (#59931862)

              I thought everyone knew how to inset text in the middle of a line: you inset the old card before a blank one in a copying card punch, copy the first bit, then press hard on the old card while typing the insert, and then copy the rest. Pressing on the old card stopped the pinch wheel moving it on, so it remains in place for the second copy part. But don't do it when the IBM engineer is watching; he'll hate you for putting a flat on the pinch wheel.

            • Och, Ed is the standard editor.
            • Despite all the hype there isn't much money to be made in COBOL, at least not around here.

              This is the problem.....they want volunteers.

          • Oh, you can be sure it will be documented. It may be hard to find, dusty and out of date, but it will be documented. Old school IT shops did process, not agile.

        • by quenda ( 644621 )

          i would say cobol is probably the most verbose language in existence.

          with the obvious exception of German.

      • COBOL is NOT COBOL. Cobol can be learnt in a week. I suggest one solution is train people a 24*80 mono screen still allows efficient data entry. Still works. So said understanding all those INCLUDE statements for datastructures is hard for the lazy. Then SQL statements. Whose does that anymore? Just like any language in big big places there is inline DB2 or DBMS to put it nicely. Those existing applications can handle the load, assuming there are DBMS administrators to manage the indexes and reorgs/ CI/CA
      • by DrXym ( 126579 )
        COBOL is one of the most ridiculously verbose languages around.
      • by plopez ( 54068 )

        Most code I have seen over the yeas has been COBOL in drag.

    • All of them.
  • Comment removed based on user account deletion
    • by ShanghaiBill ( 739463 ) on Saturday April 11, 2020 @12:43AM (#59931486)

      Isn't the issue that the systems aren't handling the load?

      Not necessarily. There may be assumptions in the code about transactions per day. Or data accesses may not be reentrant. There are plenty of reasons software doesn't scale other than slow hardware.

      Surely the solution is some good old fashioned scaling, presumably vertically in the case of these old systems.

      You can't take an old system that was never designed to scale and magically scale it just by throwing hardware at it.

      Optimize 50-year-old code to make it handle the load on the existing hardware? I fucking doubt it.

      You shouldn't doubt it. In the last 50 years, America's population has gone up 50%. Meanwhile computing capacity has gone up a million-fold. It is unlikely the problem root problem is slow hardware.

      • by dwywit ( 1109409 )

        There comes a point - at least for the IBM minicomputers I used to deal with - where annual maintenance costs become uneconomical, i.e. it's cheaper to move up to the latest iteration of the machine than it is to keep paying maintenance on that old monster.

        I imagine it's the same for mainframe systems. IBM want people buying or leasing the latest and greatest, so they structure annual maintenance accordingly. Trouble is, those systems are incredibly resilient and long-lived. We used to joke about having for

        • Yes there is a point where the economics change, unfortunately it's not just a hardware change. In the time that has elapsed politics and requirements change a lot as well, so it's no longer a re-implemenation - it's a new system and migration.

          In the UK we have been replacing several "uneconomical" benefit systems (health, housing, employment etc) into one system: "Universal Credit" that helps people see their benefit records online.

          It's already several years late, with a budget that has ballooned from

          • by dwywit ( 1109409 )

            Sounds like the move in Oz to move as much as possible online, under one end-user login to access multiple govt services.

            I can appreciate the scale of effort needed - centrelink (unemployment benefits, student allowances, parenting payment, etc), tax, medicare, child support, and others all under one portal. You can scan or photograph and upload a benefits application form (with a few exceptions), and have it all processed without visiting a centrelink office - which IME isn't nearly as painful as trying to

            • Yes, it looks similar in scope. I marvel at countries like Estonia where they've been using such services for years. Most people file tax returns online now, and it works pretty smoothly to its credit.

              One of the "funniest" parts of the documentary was seeing all the story cards on a 20 metre long wall. One of them read:

              "Pay people the right amount, on time"

              Project MD's comment: "we've been trying to do that for 30 years"

      • You can't take an old system that was never designed to scale and magically scale it just by throwing hardware at it.

        In case of code written thirty or more years ago, you often probably can. The machines that IBM has now are orders of magnitude faster than they had when this software was written. And the tapes and disks are now flash memories instead. So it many cases, it *should* work, as long as only the transaction volume is the problem.

      • You can't take an old system that was never designed to scale and magically scale it just by throwing hardware at it

        Sure you can. Just buy some more sorters, and hire some more comptometer operators. (I go waaay back.)

    • I'm guessing the need for COBOL developers is mostly related to changes in business logic. Lots of states have changed eligibility rules, deadlines, disbursement schedules, etc. and that logic now needs to be implemented in software.

    • Isn't the issue that the systems aren't handling the load?

      The issue is mainly the $600/week from the federal government.

    • IBM's new mainframes will still run native binaries from the S/360 era.

      • by vbdasc ( 146051 )

        IBM's new mainframes will still run native binaries from the S/360 era.

        As will Raspberry Pi and everything else, if using Hercules.

        • by dwywit ( 1109409 ) on Saturday April 11, 2020 @04:42AM (#59931874)

          Much as I love my RPi, running S/360 (or later) binaries doesn't mean anything beyond curiosity value. It's not a valid comparison.

          Once again - there are reasons that certain industries still use mainframe technology. Within those industries, ARM and x86-based systems simply can't compete. Otherwise, why haven't the folk that still use mainframes moved to cheaper commodity x86 hardware? It can't do the job for a competitive price.

          • In many cases, software licensing could be the issue.
          • Within those industries, ARM and x86-based systems simply can't compete.

            Why?

            • by dwywit ( 1109409 ) on Saturday April 11, 2020 @07:50AM (#59932152)

              Because the sheer amount of data, and transactions on those data, can't be performed by x86 within the time constraints required at a competitive price.

              x86 is all about the CPU, and not about the most efficient movement of data into and out of that CPU. We've seen the comparatively recent introduction of L1, L2, and L3 cache for x86 (I also mean x86-64, here). Mainframes are designed like that, from the ground up, not as an add-in or enhancement or improvement. Many of the x86 feature announcements over the last 2 or 3 decades were ho-hum to mid-range and mainframe people.

              I worked AS/400s in the 1980s and 1990s. It was a 32-bit multi-user, multi-tasking system when the x86 world was just discovering 32-bit - the 80386. There's a price/performance point where x86 runs out of puff.

              Car analogy time:
              It's like pulling loads with cars. At some point, it's simply cheaper to buy a truck.

  • by phantomfive ( 622387 ) on Saturday April 11, 2020 @12:36AM (#59931472) Journal
    Grace Hopper can be proud: [wikipedia.org]

    It is rather unlikely that Cobol will be around by the end of the decade.
    --Anonymous, June 1960

  • by Baby Yoda's Daddy ( 6413160 ) on Saturday April 11, 2020 @12:46AM (#59931494)
    I worked at a Japanese company in the 1990's. The new vice president was from the mainframe division. He was disappointed that none of us were COBOL programmers (we used TCL instead). I should've taken that as a hint to learn COBOL. All those years of missed opportunities.
  • All these _volunteer_ Cobol programmers for these states that are desperate for volunteer maintainers!

    Provided for so generously by IBM!

    • by edis ( 266347 )

      I would consider joining, given Universal Basic Income. If it's new times, then be it.

    • This is the part that is most astonishing to me--after literally decades of being too much of a cheapskate to update ancient critical systems, now New Jersey is asking for VOLUNTEERS to keep it running.

      That's what the actual web form asks--how qualified you are, and if you are willing to work for free.
      They are claiming that they don't have the time right now to go through the process of appropriating money to spend to keep this system running--so they want people to do it for no pay.


      ..."We're hirin
  • Still clueless 20 years after Y2K
  • by vbdasc ( 146051 ) on Saturday April 11, 2020 @03:15AM (#59931754)

    preserving the old mainframe skills, they should be more friendly to the hobbyists. They should allow licensing their mainframe software for cheap or free to individuals for running on emulated hardware for non-production use. They already make lots of the old documentation accessible for free, which is a good first step.

    • by gtall ( 79522 )

      And they should stop axing older workers.

      • And they should stop axing older workers.

        They don't want you till they need you.

      • by vbdasc ( 146051 )

        And they should stop axing older workers.

        Sorry if this sound cynical, but relying indefinitely on older workers only isn't a sustainable solution. BTW, I'm an "older worker" myself. And my brain just can't click quite as fast as it did 30 years ago.

  • I honestly don't get this. It should take a couple of weeks for any competent programmer to become proficient in a new language providing it's not wildly complex and COBOL is certainly not that.

    It would be more of a challenge to learn the arcane and baroque mainframe they run on. And that's probably where the performance issues lie, more so some dumb batch job written in COBOL that turns an input into an output.

    • by dwywit ( 1109409 )

      "learn the arcane and baroque mainframe they run on"

      That's not the programmer's job. It's the sysadmin/operator's job.

      Programmer - "Here - this program needs to run nightly, after program A but before program B"

      Sysadmin - "Got it. I'll schedule it accordingly."

      • No, the programmer has to understand the system as well, since the JCL required to run the code is very hardware specific.You need to know very specific details of all the parameters or you will abend pretty harshly.

    • Baroque, arcane? Unix is only 5 years younger than OS/360. We're talking mid-sixties for both and nothing much has changed since then.
      • by DrXym ( 126579 )
        The slight difference is that Unix is a widely adopted, widely understood and very immediate / interactive operating system. Whereas System/360 and successors are not. Perhaps if Linus Torvalds had produced a Linus/360 that would be a different story but he didn't.
        • by bws111 ( 1216812 )

          Congratulations! In an article full of ignorant posts, yours is the most ignorant. S/360 and its successors are not widely adopted? Is that why most of the world's largest companies and governments still use it? It is not 'very immediate/interactive'? Is that why virtually all credit card transactions are processed by it?

          And btw, S/360 and successors are HARDWARE. Hardware that quite happily runs Linux.

    • by edis ( 266347 )

      It's not about getting outlook of the language commands, it is about getting into the structures of the application theme and existing code competently, changing and adding as an expert.

  • Must be a lot and none of it will trickle down to the actual programmers.

  • by nateman1352 ( 971364 ) on Saturday April 11, 2020 @05:53AM (#59932002)

    While it's good to see the immediate problems with processing unemployment claims getting solved, don't for a moment think that IBM is doing this out of the goodness of their hearts. It would be very bad for IBM if people started to realize they needed to modernize old business applications like this unemployment claim processing system. IBM makes an obscene amount of money providing computers that can run software written in the 1960s/1970s.

    Considering hardware alone, performance per $ on commodity Xeon/EYPC x86 servers cost about 90% less than a IBM z mainframe. Don't forget that IBM charges an arm and a leg for software licenses on mainframe vs. inexpensive Linux on x86. The high availability of mainframes isn't a differentiator anymore either. You can get 99.999% uptime on x86 with virtualization, clustering, microservices, docker, kubernetes, etc. AWS is living proof of that. The only reason to spend $300,000 on a small z series instead of $30,000 on a small x86 rack is because hiring 10-20 software engineers for 5 years to modernize your business software costs ~$10,000,000 fully burdened. Software like this tends to be so tightly customized to a specific business workflow that lots of custom code is involved and updating the system is non-trival.

    • by dwywit ( 1109409 )

      That must be why banks, insurance companies, stock traders, and airlines are moving away from mainframes.

      And they have been for 20 years.

      Real soon now.

    • by bws111 ( 1216812 )

      A whole lot of bullshit in there. IBM has been trying to move customers off the old software for quite a while. Yes, they still support 24 and 31 bit COBOL applications, but keeping that support adds to the cost of mainframes. Are you aware that the price of an 'engine' that runs only Java applications is about HALF the cost of one that runs COBOL? Or that an IFL (Linux) engine is priced similar to a Java engine? More that half of the mainframe capacity in use is LINUX. They even sell Z series machines

  • by h33t l4x0r ( 4107715 ) on Saturday April 11, 2020 @08:04AM (#59932170)
    Did I ever tell you about the time I baby-sat Alan Turing and gave him his first abacus?
    • by leonbev ( 111395 )

      Don't look at me... COBOL was already considered to be an obsolete language when I was in college. Java was the new hotness at the time, so they taught that as well.

      I never wrote a line of commercial COBOL code in my life, though.

  • Understanding programs written in COBOL is a bitch. That's why there's so much legacy COBOL; it's stuff that works but the cost of understanding what it does is prohibitive.

    COBOL was designed by a bunch of programmers, and had for its time a number of interesting features, but it was designed to make writing programs easier. At that very early date they didn't really understand how important communicating your intent to other programmers (including your future self) was. The computer itself doesn't care wh

    • by bws111 ( 1216812 )

      You have this completely backwards. COBOL wasn't written to make it easier for 'novice programmers' to WRITE programs, it was to make it easier for the owners of the business processes (accountants, auditors, etc) to READ the programs to make sure the logic was implemented correctly.

      Understanding the reasoning for the business logic is pretty much language independant. No kid who learned Python last week is going to know that the reason this line of code exists (and must not be removed) is because the tax

      • by hey! ( 33014 )

        I've been hearing COBOL defenders for decades talk about its supposed self-documenting properties, but I don't see it. Its resemblance to natural language -- even supposing that *was* a good thing -- is only superficial. It uses more or less the same procedural programming constructs as every other other programming language.

        • by bws111 ( 1216812 )

          Really? Let's take some trivial examples.

          x = x + 1
          balance = balance - withdrawal

          What do those two statements mean? If you are a normally educated person who has never seen a computer program (like virtually everyone in the early 1960s), the first statement is clearly an error, since it solves to 0=1. The second statement solves to withdrawal = 0.

          But if you are a programmer, those statements mean something completely different: add 1 to x, and subtract withdrawal from balance.

          Now, how could you write those

          • But that's where the incredible verbosity of original COBOL came in. For a simple formula like that it's fine. But you had to decompose more complex formulas into a sequence of statements, each of which performed one operation. COBOL later added a COMPUTE statement that uses expressions similar to the ones in Fortran, C, Java, and nearly all modern computer languages.
  • To read your whole COBOL code in a robotic voice.
    If there is a language that sounds like a sci-fi robot, it's COBOL.

    • Want it fixed quickly and properly? Pay me more than the prevailing average, a lot more. I'm willing to fix your shit, but I need to wash the smell off too. These old systems run on expensive maintenance plans and dishwasher wage workers - that is backwards and has caused the problem.

  • I've mentioned this in previous posts but COBOL is still widely used. The problem is that it's not taught in schools anymore so none of the young-ins are learning it. If you happen to land a job with a place like IBM they will train you on it.

    Learning COBOL is not terribly difficult but it's a very verbose language. It takes thousands of lines of code to produce a relatively simple program. It is similar to SQR, if any of you have used that before. At least when I used it last, it was largely a procedural l

  • When you start a new job doing software maintenance, the problem isn't learning whatever language it's written in. People can learn a language itself, quickly and easily. But then there's the batteries-included libraries and frameworks (which some might see as part of the language, but it depends), the batteries-not-included libraries, and then all the application code (which can be enormous and spread out, some well-traveled and some covered in cobwebs), how it's organized, wtf it does (which is probably t

  • Are they giving you COBOL tutorials and some lab-scale problems? Great. But, I can also pick up a 1980 Cobol textbook from any mid-size University library and get the same.

    Are they giving away virtual 3270 sessions to a machine with MVS or VM/CMS, CICS, JCL, IMS, DB2, and some large existing codebases to study and decently large fixture data sets to work with and learn from?

    Definitely not. The only way you're getting any of that second set is by working in a mainframe shop. Someone who has the former an

  • These systems have been around for a very long time. Are they broken now? Still have bugs in them? Or do the current crop of bureaucrats insist on changing stuff that wasn't broken?

    • Two things are going on that have precipitated the problem. One is that COVID-19 has caused a huge spike in unemployment claims; they have risen by a factor of 10 in a very short time. The other is that the government response to COVID-19 resulted in changes to eligibility rules and payment amounts that need to be implemented far more quickly than such changes usually are.
  • Really. You *guys* should be ashamed.

    First off, whoever said that you don't get much performance by improving the hardware: I worked an Rdb/ACMS optimation for DEC in the mid 90's. The end result? The customer pitched our work, and threw more money at memory and disc. Remember the RSTS/E OOM message? "Buy more memory..." Seeing that on an LA-120 for 2 hrs. brings back fond memories. But I digress.

    Second off: There are classic Knuth sorting/searching jobs. Some of them can be refactored. The bitch is that Co

    • by bws111 ( 1216812 )

      You are making the same mistake as many others on here. The performance problems are simply overloaded hardware. Mainframes are typically sized to run at very high utilization, so when usage suddenly jumps there is not enough capacity. Adding capacity to these is trivial, and can be done with no outages. That is not why programmers are needed.

      The programmers are required for a completely separate issue. The rules for getting unemployment have changed, and someone has to make those changes. Throwing ha

    • You spew misinformation. Compiled COBOL is as fast as C. COBOL can do any sort as fast as C can. The mainframes that run COBOL use POWER derived architecture that blows x86 wintel crap away.

      • by bws111 ( 1216812 )

        Close, except that mainframes do not use POWER derived architecture.

        • yes they do, they are cousins.

          "The z10 processor was co-developed with and shares many design traits with the POWER6 processor, such as fabrication technology, logic design, execution unit, floating-point units, bus technology (GX bus) and pipeline design style, i.e., a high frequency, low latency, deep (14 stages in the z10), in-order pipeline." -- wikipedia

          • by bws111 ( 1216812 )

            None of that stuff is POWER architecture. That is some components and implementation details for a processor. Those same details may be used on multiple processors, but that does not mean one processor is based on the other. If you are going to use the fact that they use some of the same components to say one is based on the other, then you could just as easily say POWER processors are based on Z Architecture.

            And if you are going to quite Wikipedia, at least continue to the next paragraph which points out

            • There are common design elements unique to POWER/Z10 and not to any other processor on earth, they were designed in parallel. I know people that worked on them.

              Yes, there are differences too, that's what the next paragraph is about.

              • by bws111 ( 1216812 )

                Yes, I understand that. The problem is, when people say 'mainframes use POWER derived architecture' is gives the impression that somewhere in the design of a Z processor is a POWER processor, and there is not.

                Look up what defines 'POWER architecture'. It is things like instruction set, coprocessor attachments, etc. And absolutely NONE of that architecture appears in any Z processor. What is explicitly EXCLUDED from the definition of POWER architecture is things like "fabrication technology, logic design,

A consultant is a person who borrows your watch, tells you what time it is, pockets the watch, and sends you a bill for it.

Working...