• bvs23bkv33 (unregistered)

    Article.isFristComment = !"frist".equals(1);

  • LCrawford (unregistered)

    In b4 those who will claim that Mainframes destroy the environment as part of the natural process and there is nothing to worry about.

  • (nodebb)

    TRWTF is using multiple technologies. If there's .NET involved, why use the mainframe anymore? Ditto for Advent Geneva which uses Unix and Windows (.NET/SQL) stacks. Why??!!!!

  • Bees (unregistered)

    This is why mocking frameworks exist.

  • (nodebb) in reply to Mr. TA

    If there's .NET involved, why use the mainframe anymore?

    Dunno, maybe there's a whole huge pile of business-related data in the mainframe (that needs to be kept up to date, blah blah blah), or warehouse management integration that runs on the mainframe, or a whole host of other reasons.

    Or turn the question on its head: If there's an existing mainframe, why use .NET?

  • RLB (unregistered) in reply to Mr. TA

    Because there are things a mainframe does better, and there are things .NET does better. If you can't grasp that, better stick to Arduino-for-everything.

  • (nodebb) in reply to Steve_The_Cynic

    "Or turn the question on its head: If there's an existing mainframe, why use .NET?"

    Exactly. Why? If you don't plan to decommission the mainframe, there's no need to complicate things by adding .NET to the mix.

  • (nodebb) in reply to RLB

    Exactly what do mainframes do better?

  • Tinkle (unregistered) in reply to Mr. TA

    There is no need to complicate things by doing things on the mainframe that are more suitable to being done in .NET

    They might not even have the source code/developer skills/licencing rights to update the software on the mainframe.

  • Tinkle (unregistered)

    The real WTF is not having a test environment where 99% of the testing can be done. Admittedly you do need production when there is hardware involved that can not be accessed from the test environment - but that should have a known API that can be simulated to a degree.

  • Ruts (unregistered)

    TRWTF is commenters here that just have to decry mainframes, often without even knowing WTF they are!

  • Raj (unregistered) in reply to Mr. TA

    What mainframes do better than . net? Transactions, security, real multitasking, and usually a 30 or 50 years track record of keeping the business running.

    For instance, right now around 85% of all credit card transactions are processed by mainframes, and most advanced fraud detection mechanisms run on Z series.

    Since .net apps have a shorter shelf life than Chinese farmed fish it's unlikely we'll witness a huge transition to windows for banking anytime soon.

    Keep working on your SharePoints and razr shopping carts, and let serious people handle serious money on serious tech.

  • my name is missing (unregistered)

    We have a single test environment into which every team's stuff is dumped ready or not, and everything is interdependent: what can possibly go wrong.

  • (nodebb) in reply to Raj

    Every thing you listed can be handled by modern software stacks, including WINS: "Transactions, security, real multitasking". I agree that for legacy reasons, mainframes handle certain workloads. What I don't get is the lack of managerial foresight. It goes like this, somebody heard .NET, wants to add it to their resume, and there's no thought given to how the system will function eventually. It's more of a monkey level thinking, heard a buzzword now, react to it now.

  • (nodebb) in reply to Raj

    I particularly love the disdain you have for .NET. If you want a technology to hate, there are PHP and Python for that. Get on with the times.

  • Guest (unregistered) in reply to Mr. TA

    The company spent X million dollars on a system back in 1979 and it still works. They also want to have interfaces that don't look like they came from 1979 for their employees to use. So you have a mainframe on the back end and put together a web or C# or whatever front end.

    This is probably the majority of software development that is done today - people writing new systems that have to communicate with "legacy" systems. Especially for banks and insurance companies - who know how to squeeze every single penny out of investments that they make.

  • Klimax (unregistered) in reply to Raj

    You don't need mainframes for any of that. Hilarious that you included "real multitasking". Nowadays the only reason for mainframes to exist is for their vendors to print money from contracts with forgotten companies.

  • Paul Neumann (unregistered)

    I thought Snoofle retired. Do we have to get the self aggrandizing from Remy now?

  • Bob (unregistered) in reply to Raj

    87% of CC transactions according to IBM. I'm amazed, I didn't even realise they still MADE mainframe systems. A local business I did work experience with had a mainframe, they sold it's time off to other local businesses to do stuff like payroll, I still remember the room it was in - hollow sounding floor with both floor/ceiling ventilation. A monster.

  • (nodebb)

    The main reason legacy systems exist: A lot of hard-coded business logic. No generics. If you need a slightly different type of contract (imagine insurance), they did it in the legacy times by copying the original contract (i.e. a bunch of Cobol programs) into new ones and modifying them as needed. Over time, tens of thousands of programs accumulate.

    To modernize the system means to exactly reproduce all those behaviors on a modern system. Which means understanding all those tens of thousands of Cobol programs, and designing a system which reproduces all those results. Often business requirements are as strict as saying "if something is invalid for two reasons A and B, the existing system reports only one reason, say B, and the new design should not report both A and B or just A. It should exactly report B. Because --- business.". Even those bugs have to be reproduced which have become the specification.

    Once in every few years, somebody says "let's modernize!", a team spends a couple of years, and finally gives up when the funds dry up.

    In the beginning there was ONE Cobol program, and She was all powerful. She made all other Cobol programs in Her image. But She also gave them Free Will, so that each one will be a little different.

  • Fordom Greeman (unregistered)

    Enum enviroments { TEST, PROD, FILE_NOT_FOUND }

  • Raj (unregistered) in reply to Mr. TA

    Dude you asked at what mainframe are better. I told you. Now if you feel the need to throw in lower quality alternatives as a replacement we're no longer in the same discussion, you're just trying to hard sell your favorite technology.

    There's a lot of stuff in mainframe hardware that has no equivalent in the wintel world, so regardless of the programming language you use, there's areas like multitasking and crypto where hardware is a showstopper.

  • (nodebb) in reply to Mr. TA

    I like C# too but Raj isn't wrong about these applications having extremely short shelf lives. Here in PA state government, where they're determined to clear out every last in-house developer or application, we're stuck in an endless cycle of having apps "modernized" by H1Bs every two or three years. The new apps always use ten times the resources to do half as much. And because "agile" or "devops" is the new buzzword management knows but doesn't understand, it's a two or three year buildup to that minimal level of functionality before the next rewrite scraps it all to start over again. Now I understand why the mainframe people push back so hard. If they didn't, nothing would ever fucking work.

  • (nodebb) in reply to Zenith

    I'm well aware of this, and the problem is not the technology stack but humans: managers who only care about getting budgets and head counts, and H1Bs from Kerblekistan who are happy regardless of what they do.

  • UnderSampled (unregistered)

    I thought someone would mention VW emissions testing.

    The thought of needing a "testing" flag because there's only one environment is far less scary than the thought of having two different environments but have special code that fakes a good test if you're not in prod.

  • isthisunique (unregistered)

    Working out how to configure the environment is not the only place where anti-patterns can occur. Unfortunately, if env is prod do this else do that is extremely common. Virtually ever software development setup has some different runtime environments, production, test, development, demonstration, benchmark, staging, etc. It's very common to see this.

    You should never have something like if dev show data, instead you should have options like show verbose. You can have some default options for each environment after the fact. Code should not be environment aware, but configuration might be.

Leave a comment on “Destroying the Environment”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article