[HN Gopher] Introductory-level educational COBOL materials with ...
___________________________________________________________________
Introductory-level educational COBOL materials with modern tooling
Author : mooreds
Score : 63 points
Date : 2022-09-20 12:51 UTC (10 hours ago)
(HTM) web link (www.openmainframeproject.org)
(TXT) w3m dump (www.openmainframeproject.org)
| [deleted]
| meken wrote:
| No comment about the content itself, but the "modern tooling"
| part made me expect the website would look modern, but it feels a
| bit stuffy and outdated.
| mooreds wrote:
| I think the reference to "modern tooling" is primarily a VSCode
| reference.
| neverartful wrote:
| To see just how modern the tooling is, one should look into
| the procedure for compiling, running, and debugging. Editing
| the source code is the easy part.
| anta40 wrote:
| So, there are new systems which are being developed in COBOL?
| eru wrote:
| I hope not. But lots of legacy systems that need maintenance
| and the occasional new feature?
| elliekelly wrote:
| I remember at the beginning of the pandemic state
| unemployment systems using COBOL and a lack of qualified
| developers was blamed as the bottleneck for processing
| claims. It was all over HN for weeks.
| GartzenDeHaes wrote:
| A lot of states have replaced their UI mainframe systems
| through outsourcing to companies such as FAST
| https://www.fastenterprises.com/. Last I checked, FAST had
| WA, MT, OR, and a couple of other states. This is in
| addition to their primary business of state tax systems
| replacement.
|
| Changes typically require 7 figures, so they require a long
| lead time that coincides with the state's budget cycle.
| GartzenDeHaes wrote:
| Their UI customers, in case anyone is interested (CA, IL,
| MI, WA, MT).
|
| https://www.fastenterprises.com/solutions/fastui/
|
| Also, the cost of one of these replacement projects is
| about $80 million over 3 years plus 10-20 million a year
| maintenance. Averaged over 10 years, this about 2-5 times
| the cost of the old systems, depending on how you want to
| count.
| jmt_ wrote:
| Were the salaries offered by these states also to blame?
| i.e are there enough qualified developers out there but
| unwilling to take jobs at the salaries offered by states? I
| suspect a bit of both - a lot of the old-heads in the space
| are retiring/dying, reducing the # of qualified developers,
| but I also suspect states want to cheap-out on hiring those
| that remain.
| freedomben wrote:
| I have heard that a developer willing to learn COBOL can land a
| massive salary. Is this actually true? What companies are
| hiring/looking for people and is there a place to get realistic
| numbers?
| markdoubleyou wrote:
| COBOL is used in industries that view IT and software
| development as cost centers. As such, these departments have
| been subject to decades of ruthless cuts and offshoring.
|
| So now the chickens have come home to roost, and there's a
| skill shortage. You'd probably end up at Fiserv, or maybe at a
| big bank or some gov't agency that'll drop you at the first
| opportunity. You'd get a decent salary, but not a massive one.
|
| You'd be better off working at a place that views your
| development effort as something that generates revenue. Rewards
| tend to be higher. And wherever that ends up being, they almost
| certainly won't be using COBOL.
| giraffe_lady wrote:
| It's not the knowing cobol that does this, it's the being a
| domain expert in a complex system that happens to run cobol
| that does it.
|
| That said it's largely a fake idea yes. "There's a shortage of
| cobol devs" sounds a lot better than "we spent decades
| undervaluing, outsourcing, and not supporting mentorship in
| this critical niche and now we're experiencing the
| consequences."
| oweiler wrote:
| Have a look at the offers on Glasdoor. Only slightly above the
| typical Java Dev salary.
| jmt_ wrote:
| It's always been my understanding that many COBOL applications
| are highly coupled to some sort of old-school mainframe-type
| server. So while a programmer can probably pick up the language
| with enough time, the mainframe knowledge will be much more
| difficult to acquire. Therefore, I assumed those earning the
| highest salaries in this space have deep knowledge of both. To
| those with experience writing enterprise COBOL - is this really
| the case? Is someone with only COBOL-the-language experience
| ready to work on real-world COBOL applications at most
| companies? Or would they need mainframe experience to be
| competitive enough?
| neverartful wrote:
| I think you're right about needing both the language part and
| the mainframe knowledge. When I worked in an enterprise with
| a heavy mainframe presence, the COBOL was divided into 2
| parts: online (3270 and CICS) and nightly batch. All of it
| was on z/OS (formerly MVS) and largely made use of DB2 and
| some VSAM. To do anything useful in z/OS you need to be
| comfortable with JCL (Job Control Language) and it's fairly
| archaic. Traditional z/OS views files as 'datasets' on
| secondary storage. There are catalogued and uncatalogued
| datasets. In old-school MVS, when you create a dataset you
| have to pre-allocate it by specifying low-level storage
| slices like number of disk cylinders. This is the perspective
| of the traditional CKD/ECKD storage. It's probably been
| smoothed over somewhat over time, but I'd expect there to
| still be a great many archaic things to wrestle.
| jmt_ wrote:
| Yeah, this is the exact sort of thing I was picturing. So
| for, say, a recent CS graduate, the common methods of, say
| manipulating files/data e.g file descriptors, sockets,
| databases etc, don't seem to really apply within the kind
| of environment you describe, which makes me question how
| much knowledge a 'typical' programmer can easily port over
| to working on real-world COBOL systems or at least how fast
| said programmer can start making meaningful contributions
| to the codebase. I'm not sure how much effort any given
| company looking for COBOL devs would want to invest in
| teaching new programmers how to work in the environment and
| are probably preferring people who already understand the
| mainframe they're using, which would exclude most working
| developers. Even if the company is willing to teach you,
| that skillset probably won't be useful at your next job,
| unless you want to start a career as a COBOL dev.
|
| tl;dr learning COBOL as just a programming language doesn't
| seem to prepare you for an actual COBOL job in most cases,
| unless the company is willing to invest in teaching you.
| guessbest wrote:
| You hit the nail on the head, but I'd say that things are
| more proprietary and thus secret than simply being archaic.
| For instance some places still use MARK-IV, but build out
| new features using Cobol. And then there is a whole field
| of job scheduling language like Jobtrac. It is a vast
| ecosystem with its own security system language like TOPS
| which also has it s competitors.
|
| Also, overnight batch processing may not be automated but
| require an operator initializing each job in the schedule
| or schedule in the schedule with runsheet instructions. I
| think dialogs are created with ISPF and software for moving
| software from test to production, but I'm no expert on the
| mainframe.
|
| https://en.wikipedia.org/wiki/MARK_IV_(software)
|
| https://en.wikipedia.org/wiki/TOPS
|
| The mainframe has a large ecosystem that is needs
| maintenance and feature additions and the work doesn't pay
| so bad if you don't mind the system. I know Mainframe DBA's
| make $110k in Dallas/Austin.
| ghaff wrote:
| Furthermore, to the degree that someone is making big
| bucks, they probably _also_ have a wealth of domain and
| possibly organizational knowledge. Pretty much no one is
| walking out of a CS degree--which is mostly irrelevant to
| maintaining generally legacy mainframe systems--plus some
| COBOL courses and expect to be showered with highly
| lucrative offers, if indeed someone want to hire them to
| work on mainframes at all.
| albroland wrote:
| I'd say you've heard very wrong. If your concern is maximizing
| your income I'd highly recommend not going the mainframe route.
| The only people commanding SF/NYC gargantuan salaries will be
| old guard who retired to do contracting and get brought on to
| un-fuck situations at incredibly high rates under short term
| contract. IME you're likely to see MAYBE 80-100k as a midlevel
| COBOL dev as you're competing primarily against offshored pay -
| I would expect bootcamp front end devs to make as much or more
| than COBOL devs.
|
| Also as others have insinuated, COBOL itself isn't a challenge
| (nor PL1 or HLASM or any other language really), it's the
| zOS/360 mainframe environment, understanding the nuance behind
| how all these disparate systems work together, being a JCL
| wizard, knowing all the IBM yellow books off the top of your
| head from 40 years of working in the industry, understanding
| how to use IBM IMS db efficiently, etc. Also the entire
| ecosystem of stuff you might take for granted, like
| IDEs/debuggers/deployment/etc, are all quite ancient on zOS
| systems and take years to get proficient in.
| rtev wrote:
| I've heard it isn't. From what I've heard, the salaries aren't
| that outstanding, and the people getting them are being paid
| for their experience with the environment, not the language.
| yucky wrote:
| I don't have actual numbers for you, I will say that the work
| environment at a COBOL gig would be considerably different than
| you may envision when you think of a life of a programming.
|
| These are legacy systems that need long term maintenance. If
| you like building cool new things and working in a laid back
| environment, the salary may not be worth it.
| buscoquadnary wrote:
| My understanding of is that the problem isn't "learning COBOL"
| it's learning all of the environment that surrounds COBOL, the
| IBM Z Mainframes, learning JCL and what not.
|
| In fact it seems this is the case with every language, Java was
| the first language I picked up, I did it through school, I am
| familiar with syntax and how it works under the hood, yet I don't
| feel comfortable on Java projects, not because I have any problem
| with Java it's because I don't know the entire environment around
| it, there's DI frameworks, finding the magic Spring config to
| make things work the way you want, etc. As an engineer I don't
| really have an ability to see what is going on in an application
| and really trace the code start to finish because there are three
| or four layers wrapping, abstracting, surrounding, or smothering
| any code that anyone has actually written on my team.
|
| Same thing with .Net I've tried picking it up since .Net core
| came out, but it just seems that figuring out how to string all
| the packages, and dependencies and figuring out how the build
| tooling works is more effort than the language itself.
|
| Repeat for JS, you can know Node and JS and in this environment
| that will get you a nickle and a piping hot cup of Jack Squat
| because you can't just know JS, you need to know JS, and React or
| Angular, and in order to work with those tools you also need to
| use Webpack or Babel, and a transpiler and all the tutorials that
| go "step by step" seem to consist of "install these packages
| don't ask why just do it and then add 4 lines of code".
|
| The problem isn't nor has it ever been the langauge, so far I've
| picked up Perl, Python, Java, C#, JS, TS, Ruby, AWK, and a
| handful of other languages with ease (The only one I've struggled
| with thus far is LISP) it is the environment that surrounds each
| of these things, and I only forsee it getting worse as we
| continue to move things to a higher and higher level, we think we
| are simplifying but it feels more like we are building a leaning
| tower on a foundation of sand, where soon coding will become more
| of a priesthood than anything, where the right incantations will
| produce a certain effect but no one will really know how or why
| because no one person knows or understands what the 14 layers of
| abstraction we are running on do. Which inevitably ends up
| reinventing the wheel at every layer of the stack as teams try to
| solve problems within the area they understand not realizing how
| much easier it would be to solve in another layer, and we'll just
| end up running around in red robes chanting prayers to the
| Omnissiah.
|
| 01010000 01110010 01100001 01101001 01110011 01100101 00100000
| 01110100 01101000 01100101 00100000 01101111 01101101 01101101
| 01101110 01101001 01110011 01110011 01101001 01100001 01101000
| FearNotDaniel wrote:
| When you stop jumping from one language to the next, endlessly
| searching for an environment that matches your idea of
| 'purity', and decide instead to invest some serious time and
| effort into learning a specific platform, and use that
| knowledge to actually achieve something practical that delivers
| value to your fellow humans; then you are just _beginning_ to
| understand what it means to be a software engineer. Every
| platform has its flaws, every ecosystem has its design
| mistakes, and yet here we are, thousands upon thousands of
| people working in an industry that barely existed fifty years
| ago, creating things which at least some other humans are
| prepared to spend money on. A subset of those things actually
| enrich the lives of others in significant ways. Why not choose
| to be part of that? I suggest for the sake of your own
| wellbeing, complaining less and learning more. Dig deep into
| the history of those frameworks and environments that you hate
| so much, remember Chesterton 's Fence and start asking
| questions about why things are the way they are, what problems
| have others encountered that needed to be solved. Perhaps when
| you fully understand what motivated people to put all that crud
| out there, you could find better and more elegant solutions
| that will make all of our lives better. Or not. There are
| plenty of other rewarding ways to spend your days, if software
| is not for you then perhaps something completely unrelated will
| be more satisfying.
| buscoquadnary wrote:
| I'm not upset with it, jaded and cynical maybe, but I still
| make a decent living and enjoy when I do get to make things,
| I just would enjoy it more if I spent more time building and
| creating and less fighting with my tools.
|
| I make it a point to jump from environment to environment to
| learn to grow, to see the new things and the new tradeoffs,
| and find out what they play out like.
|
| That being said, I don't need to find or build a better or
| more elegant solution. I use Emacs ;)
___________________________________________________________________
(page generated 2022-09-20 23:02 UTC)