Well, this is funny. I just turned 30 and I've worked with mainframes (among other things) up until 4-years-ago. I'm like a unicorn in the tech field. (You can thank the GMail app on my phone for notifying me about straight-to-archive e-mails, heh.)
I'm a lead developer (/ tech manager) and I've worked with everything from system security (win/*nix/RACF), Mainframes/CICS, homegrown Perl sysadmin tools, web crawlers / distributed processing with Hadoop / Java, crazy search / text indexing problems, and now front/back-end web development (Ruby on Rails). I'm generally quite familiar with what I'm talking about! It's hard to put all of my thoughts about the Mainframe into a concise e-mail, but I'll try. But to summarize: "The Mainframe" is in a vegetative state. It's dead and will never come back. The only question is, which of the risk-averse mega-corp-CTO's will no longer be able to kick the can on pulling the plug? Here's why: -- The economics of the Mainframe are laughably F'd up and unfit for the modern era. When IBM was trying to sell us another terrible product, they bragged that it was written in Assembler (thankfully the former IBM exec, now our then-CTO, signed a fat check for it). I was the only one in the room to point out how horrible and shameful that is. By billing in terms of CPU usage, and not the cost of the stupid hardware, the value system becomes warped. Hardware is pennies, human capital is massive. Yet IBM has no interest in giving up on their lucrative billing strategy, so people do *fucked up* things like write full-blown applications in Assembler. I was not allowed to use Java on the Mainframe for this reason. Don't waste my time trying to request the Java co-processor. So insanely, laughably stupid. -- IBM is a parasite and has nothing to lose / everything to gain with the desperate situation. (Until startups begin to eat their customer's lunch) Outsource everything to India? Sure, why not! Cause disastrous mistakes that lose companies millions as a matter of routine? Fuck it! IBM pollinated their middle managers and sent them off to be CTO's. They signed contracts without batting an eye, and flee the company before things blow up hard. When you're making automobiles or piling up interest for trust funds, there's a new million $$ every day for IBM to experiment with and set fire to. -- COBOL is dead. REXX was ahead of its time and I appreciated it. That's dead too. I understand that COBOL code, compiled 4-decades-ago, is still running somewhere. You will not find the "best and brightest" to write any more of it. It's just not a good language, and the last 55-years have given the world an immensely powerful set of tools for solving business problems. Edsger Dijkstra summarized it correctly. The world will continue to rotate without new COBOL programmers. If Bank of America collapses into a void, as 2008 has shown, there are plenty of people who are eager to take its place (like Simple!). I can go on, but I'm running low on beer -- which is the fuel for my cynicism. I love what I do and you'd have to more than double my salary for me to even consider coming back to help liberate a company from their Mainframe. (Then again, this Silicon Valley bubble is doing wonderful things to my paycheck. Why leave?) Cheers, - Scott On Wed, Mar 26, 2014 at 8:16 PM, Ze'ev Atlas <[email protected]> wrote: > Steve > Nobody will make fun of you... I am now an expert in that stuff and I > still make mistakes because, let's say it as it is, dealing with C could > be, mmm.... tricky. > > Please send me your code since, as I've stated earlier, I am contemplating > on creating a bearable user interface for that in parallel to my work on > PCRE. > > Thank you > > Ze'ev Atlas > > > > > ________________________________ > From: Steve Comstock <[email protected]> > To: [email protected] > Sent: Wednesday, March 26, 2014 9:03 AM > Subject: Re: Another Article On Lagging Mainframe Skills > > > On 3/26/2014 6:24 AM, Tony Thigpen wrote: > > Just to be clear, I really do understand, and respect, your feelings. > > It's a tool you would like to continue using because you are familiar > > with it. > > My opinion is just that, my opinion. And, in my shops I can enforce my > > opinion. :-) > > I was not criticizing the port, just tying to explain why it might not > > be of interest to many mainframe programmers. And why nobody bothered to > > download it. By saying why I was not interested in it. > > > > Now, as to COBOL, we normally deal with non-text based numbers. > > Everything in the file is stored packed or binary, not as text. Once it > > is passed the "input program", the only need is to convert it back to > > text for reports. And we have simple PIC clauses to hand that conversion. > > As to the "input program", these have traditionally worked with input > > fields that do not have all the dashes, commas, and such. We started > > with keypunches (where the special characters were removed by the > > keypunch operator). We then moved to BMS screens (for CICS) where CICS > > had a built-in de-edit function. (Of course many shops wrote their own.) > > But, even then, we normally expected the return value to be just digits. > > Even as we move from CICS to Web, it's still under CICS with the > > existing tools already in place. > > We have been working this way for 30+ years. Regular expressions is > > relatively young. > > > > Do we need regular expressions in COBOL? I don't think so. Can you, and > > others, continue to try to evangelize about regular expressions? Yes you > > can. Maybe, some day, I will change my mind. I just doubt it. :-) > > > > Maybe you should start a thread: Why COBOL needs Regular Expressions. > > > > Tony Thigpen > > I actually started experimenting with this a couple of > years ago. Since COBOL is LE based and you can call C > functions directly from COBOL, I did some work with the > C functions 'regcomp' and 'regexec' - calling them from > COBOL programs. > > The goal was to match strings based on patterns, of course. > Since modern COBOL has so many new capabilities I was > thinking of doing dynamic dataset allocation based on > patterns in DDnames, analyzing text coming in as replies > to a dialog (maybe in a COBOL CGI), etc. > > But I never had the time to get it working to my satisfaction. > And, of course, no one was asking for it. > > If anyone is interested in getting my eight COBOL programs > that are experiments (nothing works quite right, I don't > think, but they provide a starting point), if you promise > not to make fun of my rudimentary code, I'd be happy to > ship them to you. Good to find a home for them. > > Kind regards, > > -Steve Comstock > > > > > > > -----Original Message ----- > > From: [email protected] > > Sent: 03/26/2014 07:54 AM > >> I share your sentiment about vi which I consider to be a bug, not a > >> feature. I agree that there could have been a better way to do > >> pattern matching. The reality is that there are alternatives for vi, > >> ranging from ISPF all the way to Notepad++ and many options in > >> between, but in the same reality, if you need to do serious pattern > >> matching, and I need to do it all the time, there is no viable > >> alternative. The regex methodology is the one that took an hold on > >> the world and became the Lingua Franca, the de-facto language of the > >> trade. > >> I came to the world of pattern matching when this was already a fact > >> of life with I real chance to change it. > >> Now, the reality is also that the only major programming languages > >> that do not have access to regex functionality are COBOL and PL/1. > >> All other major languages have this capability. And it is that > >> deficiency that I intended to resolve . I am encouraged by those who > >> expressed more positive feelings and will continue to push it. > >> ZA > >> >
