
Interviewing my mother, a mainframe COBOL programmer - Svenskunganka
https://medium.com/@Svenskunganka/interviewing-my-mother-a-mainframe-cobol-programmer-c693d40d88f7#.66qbnhd8p
======
c-smile
Nice article.

Reminded me my own experience of creating bank software system for a State
Bank of one of republics that was in the middle of separating from former
USSR. "Perestroika" they named that process.

No mainframes, where we would get those at that time? Only i386 as a server
and PC XTs as terminals. Connected by ropes essentially, but NetBIOS was
working over them. Plus 1200 bod or so modems to connect with other banks in
the republic.

But we (team of two developers) did it in 9 months.

Excellent Zortech C++ by Walter Bright (creator of D language).

Editor - MultiEdit the Great. What we would do without it - I don't know.

Database - dbVista (later known as dbRaima).

Everything was working on PTDOS (Russian MSDOS alike thing)

Yet multitasking C library providing cooperative multitasking (same execution
model Node.js is using).

And everything in 640k of RAM that "should be enough for anybody".

We were young and nobody hadn't even a chance to tell us that this is "too
serious", "impossible" and the like.

A lot of manual input by operators, so usability requirements were
surprisingly high: [http://www.terrainformatica.com/2016/02/ui-usability-
solutio...](http://www.terrainformatica.com/2016/02/ui-usability-solution-i-
am-especially-proud-of/)

:)

~~~
duncan_bayne
I would _love_ to read a writeup of that project.

~~~
c-smile
Hard to recall actually, many waters had flown away since that time.

Just one fact: the system survived monetary reform in USSR of 1991 when in
three days the whole country suddenly changed all banknotes (
[https://en.wikipedia.org/wiki/Monetary_reform_in_the_Soviet_...](https://en.wikipedia.org/wiki/Monetary_reform_in_the_Soviet_Union,_1991)
). History of USSR is just one big social experiment of things like this.

Number of transactions in these three days was astonishing as you can imagine.
We've spent all three days in the bank worrying mostly about hardware. 12
keyboards and 3 workstations from twenty-something were lost in the battle :)

But the most crazy thing that I saw was on the next day after the reform. It
was January 26th, and it was snowy all three days. Plaza in front of bank's
building was covered by snow and banknotes on top of it, surreal. People who
were late or exceeded exchange quota were just throwing money away.

But our system did handle it surprisingly well.

My pardon for hijacking the COBOL topic. C++ rulez forever!

~~~
duncan_bayne
Thank you for the details :)

------
agentgt
My grandmother who is in her 80s was one of the US military's first female
programmers... and she was a widow... and she was German expatriate (as you
can imagine the difficulty of that post WWII). They programmed in punch cards
and drank a lot of coffee.

If it sounds like I am bragging.. I am.. I am very proud of her. What I'm not
proud of is not spending enough time with her to extract more details. I did
ask her a similar question about being a German widow working with
predominately males and she basically had the same answer as the articles
mother... "no problems what so ever".

This article is a great reminder that I need to call my grandmother more often
:)

~~~
clifanatic
Was her name Grace Hopper?

~~~
agentgt
No it was not. I wish I could provide an official link of her work but I can't
seem to google anything. She isn't famous by any means and is exceedingly
humble (hence the difficulty on finding details indirectly).

Interestingly though she absolutely loves all things sci-fi. She records
almost everything the SyFy channel produces and loves Babylon 5, Dr. Who,
etc...

She is exceedingly good at board games. Even ones she has never played before
she often wins. I remember brining Chinese checkers once to her with my wife.
She had never played before but she absolutely trashed my wife and me in
multiple games.

She grew up in Germany and I have often wondered if that had any affect on her
non-traditional-gender hobbies and likes. Or maybe it is just her personality
(as I love board games and SciFi as well).

------
mikejmoffitt
"We used to have personal desks, but now we have this “pick whatever spot is
available” open area. I dislike it a lot."

This fits in line with what nearly everybody I know thinks. Does anyone
_actually_ like open-plan offices without dedicated desks? How long until that
trend passes?

~~~
irrational
When we were moved to an open office plan they were quite open about it - the
one and only reason for doing so is they can squeeze more people into a
smaller footprint. All the garbage about "facilitating communication" is just
that, garbage.

~~~
rhizome
Don't forget about open-back seating, so everybody can see what you're working
on.

~~~
kpil
I don't particularly mind that people see my monitors. If you work in a decent
place, no one would care if you read some news once in a while. If someone
spends the day idling, then it's noticed anyway.

Once in a while I get a sensitive or confidential email, but that usually
happens when the computer is connected to a big screen in a conference room
full of people anyway...

I DO mind not finding anywhere to sit, not knowing where people are when I
want to talk to them, not having two or three huge monitors to work on, and
not having my Model-M to type on...

~~~
rhizome
Wait, are you saying there are still companies attempting to hotdesk, "not
finding anywhere to sit?"

~~~
kpil
Yes? A rather large telecom company for example.

I guess there are some stools and tables available somewhere, and technically
you can sit on the floor I suppose, but people that are late more or less have
to go home again.

They are kind of in a downwards spiral anyway, so maybe it will sort it self
out.

------
nevi-me
Interesting article! I've sometimes wondered if I should learn more COBOL. I'm
26, one of my gigs was to reverse-engineer loads of COBOL code whose
functionality was being migrated to something modern.

There was a few of these very long scripts, written in the 70's. At the top
was "Here be Dragons".

It felt cool after I figured out what interest calculations it was performing,
I ended up leaving a comment "Dragon Slayer was Here" at the end of the
script.

~~~
unexistance
you should learn the domain knowledge there while the experts is still around,
then migrate it out to ruby or .NET or whatever

~~~
nevi-me
I think most if not all Mainframes run Java, so I think saner would be to
learn so I can port to Java.

There are still younger guys in our banks who COBOL, but the domain expertise
sits with the much older guys. It's lately common for the older guys who go on
pension to come back as "independent consultants". They earn a lot of course.

~~~
unexistance
eh, modern mainframe even runs Linux, so not really a problem there
technically

Just find one of the experts that are willing to answer whatever question you
have on the legacy COBOL code

------
ams6110
The COBOL programmer shortage is solvable if they simply pay people enough
money. COBOL programmers do not make SV salaries, far from it. Yet the code
they write generally is handling more critical tasks than most of the stuff SV
startups are producing (bank balances, payroll, insurance claims, etc.)

Though I found it to be stifling, I would work with mainframes again if the
price was right.

~~~
swiley
It's well known that Financial companies are generally among the worst places
for programmers to work. Learning COBOL just sets you up for a lot of that.

~~~
clappski
Finance is a very very broad industry. Everything from Xero to your local
credit union/building society to bulge bracket investment banks fall into
'finance'. I work for a bulge bracket IB, and all of the developers enjoy
their work because it's what you would expect working at a technology company;
maintaining an in house document store, implementing complex mathematical
models and implementing distributed graph based pricing systems for real time
data are all things I've had the opportunity to do here, and everyone is payed
at market rate or higher for their experience.

It's a great industry to be in if you work in the right area, just like any
industry.

------
lumberjack
You know you have job security when you fuck up so badly the government steps
in and you still don't get fired. Most of us can only dream of ever achieving
that kind of job security.

Very nice article. Captivating read. I was interested about what kind of
'previous computer experience' your mom had. That era of computing is
completely alien to me.

~~~
Smurf4
Also comes down to Sweden having a "how do we fix this and make sure it never
happens again" culture rather than a US-style blame culture. You can get fired
in Sweden if you're grossly negligent or disloyal, but not for a simple
mistake that anyone could have made.

~~~
pm90
This is a very good attitude. In general, the impression I get of Nordic
countries is of a more egalitarian social contract with people looking out for
each other rather than the culture of personal progress at any cost that we
see elsewhere.

~~~
gaius
I suspect the climate has something to do with it, over hundreds if not
thousands of years.

------
mywittyname
>I can only imagine the fat paycheck a 20-year old mainframe programmer would
get though, because your age in this case would be invaluable.

I have a sneaking suspicion that this is not the case. Companies that want top
talent and are willing to pay for it are not shy about that fact. Seeing a
legit job posting for a position that pays double your current salary is a
solid incentive to apply.

I'm guessing that the subject of this interview probably makes a less-than-
competitive salary. Programmer pay has handily out-paced inflation for decades
now. She probably started at around $30,000/yr in 1991, if she managed to get
a 3% raise every year, that would only bring her to like $63,000/yr.

Naturally, I'd love to be wrong about this. This woman has a demanding and
important job and deserves a generous salary for it.

~~~
clifanatic
You're not wrong. COBOL programmers aren't paid well AT ALL.

~~~
Taylor_OD
I've got a uncle whose a COBOL solutions architect at a large company and he
makes less than 125K. It's a decent living but he doesnt really have the
ability to make a move like many of his .net based colleagues.

~~~
toomanybeersies
> It's a decent living

It's over double the average family income in the USA.

~~~
morgante
So?

Developers straight out of college can sometimes make _triple_ the average
household income.

~~~
amyjess
Depends on where you live. In SV, sure, but they have the highest cost of
living in the world.

In Dallas, a fresh out of college CS grad can probably expect a salary in the
lower 40s. And the cost of living is cheap enough you can afford a house on
that.

~~~
CoachRufus87
Where in DFW can you purchase a nice home on 40k?

~~~
amyjess
I'm talking about renting, not purchasing.

------
diiq
I'd love to have heard some actual quotes from your mother; how did she get
into it, what are the best/worst/strangest parts of her day, how does she
think the future will look given the lack of young COBOLists, etc.

~~~
Svenskunganka
You are right, I apologize, I'll ask her about how her days looks like and her
best/worst/strangest parts. I'll add that directly to the post and reply to
you when it's done!

EDIT: I've added some Q&A at the bottom, will add more as more questions come
in.

~~~
stuaxo
The q and a bit was my best part, it sounded more life direct quotes.

------
SilasX
Hm, my mom programmed on a mainframe with the pre-Fortran "Michigan Analog
Decoder", is that interview-worthy?

~~~
nickpsecurity
I found lots of analog companies Googling for it but no references to Michelin
being in the business. So, yeah, I'd be interested in a link about it and/or
the story.

~~~
SilasX
K, turns out it was actually Michigan _Algorithm_ Decoder:

[https://en.wikipedia.org/wiki/MAD_(programming_language)](https://en.wikipedia.org/wiki/MAD_\(programming_language\))

So, not quite as old-school as the analog days :-p

~~~
nickpsecurity
I was trying to imagine how an analogue component could be anything but a
sensor for a mainframe in a factory or something. A programming language
called MAD makes so much more sense. :)

------
Animats
It's not that COBOL is particularly good or bad. It's that COBOL-era database
technology is painfully-obsolete. Flat files, ISAM, and IMS are all pre-SQL,
and old shops are likely to still be running some of that stuff. DB2 isn't too
bad; it speaks SQL and runs on various platforms including Linux.

With the older systems, the database update logic and the business logic are
in the same programs. This is not good.

~~~
gaius
_Flat files, ISAM, and IMS_

Those were all good ideas at the time.

Infact IMS was such a good idea the hipsters just reinvented about 1% of its
functionality and called it MongoDB!

~~~
selimthegrim
I was explaining NoSQL to an older coworker of mine who bemusedly humored me
for 20 minutes or so before explaining she'd started her career off with Pick
in the 1970s...

~~~
unexistance
this?

[https://en.m.wikipedia.org/wiki/Pick_operating_system](https://en.m.wikipedia.org/wiki/Pick_operating_system)

~~~
selimthegrim
Yes

------
cafard
At the end of the 1980s, I was in a systems administration class for a now
gone minicomputer line. There were two women in it who seemed quite mature,
but must have been younger than I am now. One told a story about her
introduction to computing that has stuck with me. She passed an aptitude test
to become a programmer: by now I have forgotten whether she worked for a
computer manufacturer or a customer the size of a utility company. Whichever
it was, the company had a machine room with a glass window opening onto a busy
street in Manhattan. In those days, programs mostly resided on punch cards,
and data mostly resided on tapes. One would bring one's cards and I suppose
tapes to the operators. They would hang the tapes, run the cards through the
reader, and the tapes would commence to spin back and forth. If all went well,
the program ended with the tapes spinning on back to the reel. In case of an
ABEND, everything stopped, and every New Yorker on the sidewalk could say that
the program didn't work. It struck me as being far more public a test than
most of us my age and younger have ever had to deal with.

------
jhallenworld
The statements about batch processing are interesting. For example, when you
transfer money to someone at a different bank, one way is for the banks to
have correspondent accounts with each other, so the transfer is just within
accounts at one bank. When one of the correspondent accounts is out of money,
they have to do a real inter-bank transfer, probably via the fed or some
larger bank.

Bottom line is that there is parked money in these accounts. The banks should
have every incentive in the world to minimize this parked money (either to get
access to their own money or to avoid paying interest on someone else's). So
there should be pressure to make the systems as real-time as possible, not
batched.

~~~
nevi-me
Banks already do some of that locally and internationally.

In South Africa we have BankServ, which is a local interchange and clearing
house. Transactions are still in batches, but the settlement between banks
happens nett between the local banks.

Internationally, MasterCard, VISA, Amex etc. manage the clearing. Banks then
have to pay within 2 days via Swift to either other banks or their designated
international settling bank.

Going back to your suggestion, it could work because the banks could just pay
each other when they run out of funds. The challenge becomes fraud and other
legal issues, which often mandate settling houses.

The real-time problem is a legacy hardware problem as well as the settling
issue. On your last point, money is normally parked at the Central Banks,
mostly as a legal requirement. From my experience, banks in healthy financial
economies like mine don't keep a lot more than the minimum cash reserve with
the Central Bank.

~~~
Smurf4
> Transactions are still in batches, but the settlement between banks happens
> nett between the local banks.

Same thing in Sweden, I believe. Cleared through Bankgirot.

[https://en.wikipedia.org/wiki/Bankgirot](https://en.wikipedia.org/wiki/Bankgirot)

------
bpyne
First off, great post.

It's very nostalgic for me because the author is fascinated by the technology
of the day. COBOL, hierarchical databases, batch processing were still a norm
in IT when I got into the field. My first programming job was around 1992-93
on a Vax using SQR and PL/SQL for an accounting department. We also had to be
able to read COBOL. By contrast, my friend got into the field 5 years ahead of
me and was hired into an insurance company. His IT department was just
switching from assembly and IMS on an IBM mainframe to the "newfangled" COBOL
going against DB2.

I left IBM after a year, stayed in my first programming job for a year, and
then started a 5-year stint with startups. When I hit the startup scene I
realized how a new norm was developing. Small servers, C/C++, relational
databases, and OLTP were the dominant paradigm in smaller organizations.

The author did a nice job describing this period in the history of computing.

------
peterjlee
If you're interested in knowing how banking works between banks, Planet Money
had a podcast on it few years ago. Apparently bankers met at a parking lot in
New York and traded bags of paper checks back in the days.

[http://www.npr.org/sections/money/2013/10/04/229224964/episo...](http://www.npr.org/sections/money/2013/10/04/229224964/episode-489-the-
invisible-plumbing-of-our-economy)

------
tcopeland
Andrew Turley has given a nice COBOL talk; the title alone - "What We Can
Learn from COBOL" \- is worth the price of admission:

[http://confreaks.tv/videos/goruco2014-what-we-can-learn-
from...](http://confreaks.tv/videos/goruco2014-what-we-can-learn-from-cobol)

------
alexhawdon
Really interesting! Thank you both.

I would love to know what a 'typical day' and the general working environment
are like. (A vague question, I know, but sort-of on purpose.)

------
jhallenworld
My mother indirectly used COBOL in the microcomputer era: she used Real World
Accounting on 68000 based Radio Shack Model-16's under something called Ryan
McFarland COBOL Operating System (RM/COS). Eventually this became available on
Xenix and SCO UNIX on PCs.

My one and so far only COBOL program was an ASCII-graphics game of checkers
for the TRS-80 model 16.

~~~
nickpsecurity
That's interesting because (a) it's first I've heard of COS and (b) I cant
find jack on it. A bunch of ComputerWorld articles and a patent reference it
with a description it's a custom OS for COBOL apps. A web site says it's for
an abstract, C machine but nothing to confirm. BitSavers doesnt have anything
that stands out to me. Checked jnder Tandy as adds indicated it was licensed
to them.

I'd be interested in links to guides on this product or scanned pages that
show whether OS itself was COBOL. I'll put it on Wikipedia's Timeline of
Operating Systems list if I get the info. I got quite a few added there so
far.

Edit: Some paydirt showing ghe company along with at least compilers absorbed
by MicroFocus. Tech might still live on somehow.

[https://en.m.wikipedia.org/wiki/Digitek](https://en.m.wikipedia.org/wiki/Digitek)

Looking with Digitek, MicroFocus, and Liant still didnt get me jack. This is
some phantom of a product.

~~~
jhallenworld
Search for "rm/cos 68000"

I remember a little about it:

You could set up "partitions", which mean reserve fixed amounts of RAM for
different applications.

It ran on the (8 MB I think) external hard drive for the TRS-80 model 16.

An advantage compared with Xenix is that it was smaller (used less of the hard
drive).

Also it had just a single directory, but had a form of hierarchy in that you
could use any number of '.'s as separators: like usr.bin.ls. The total name
could be long. I think OS-360 worked something like this.

I think the last line of the screen was always the command line, and the other
lines were for command (or cobol menu screen) output and worked like a pager.

You could definitely hook up serial terminals.

I found this:

[https://books.google.com/books?id=05wAGZQlo9QC&pg=PA694&lpg=...](https://books.google.com/books?id=05wAGZQlo9QC&pg=PA694&lpg=PA694&dq=rm/cos+68000&source=bl&ots=gesmgDuQyt&sig=yiG4elq9cIWxcQua_Nxgf1YUOX8&hl=en&sa=X&ved=0ahUKEwin6qbqi_bNAhWEeSYKHTOwBDAQ6AEIHzAA#v=onepage&q=rm%2Fcos%2068000&f=false)

[http://www.1000bit.it/ad/bro/altos/Altos-68000-Systems.pdf](http://www.1000bit.it/ad/bro/altos/Altos-68000-Systems.pdf)

It's the same as "COS990", but for 68K.

~~~
nickpsecurity
Thanks! That last link is helpful! It's actually quite an interesting and
capable OS. Has file & software protection mechanisms. I recall UNIX having
about no reliability at the time. Also, coding, compiling, and directly
running without linking the apps is closer to a LISP machine than regular OS
of the time.

Might give it at least a brief Wikipedia article with these links.

------
jbgreer
I think you are overgeneralizing IMS performance. "IMS is extremely old and
very slow. Searching for data can take hours." Especially when you later point
out that they have 10TB of DB2 data and probably more than that in IMS. Not
all IMS databases are slow. Not all MySQL / Postgres, etc. databases are fast.

~~~
Svenskunganka
Definitely not! I'm mostly quoting what she said, but IBM has a lot of nice
tech, but you have to understand that these are very old versions of IMS and
the volume of data they have does not make the case better. Hierarchical
databases are not always slow, but once you want to find stuff at the very
bottom of the hierarchy, it'll start take some time.

~~~
SSLy
Um, what about indexes?

~~~
giardini
These older databases often allow the use of indexes as an option. Of course
ISAM (Indexed Sequential Access Method) is indexed. But also it is often
possible to add indexes to the networked database internal structures. An
alternative is to use hash tables with overflow. In any case you must usually
periodically scan through the database reorganizing the indices and/or
location of records, which can take up a lot of time and usually requires
taking the database offline. Here's a good read(first is PDF):

[https://www.google.com/url?q=http://advsys.net/ghs/publicati...](https://www.google.com/url?q=http://advsys.net/ghs/publications/DBReorgPAP.pdf&sa=U&ved=0ahUKEwiznqms3vTNAhVC7GMKHdpyC7cQFggUMAA&usg=AFQjCNGMpZbH9wAWbDq-6FiMhtn1fBIg4w)

or the same paper at Google Books:

[https://books.google.com/books?id=YqM3pqFVt8IC&pg=PA8&lpg=PA...](https://books.google.com/books?id=YqM3pqFVt8IC&pg=PA8&lpg=PA4&ots=ehTAPwbseo&focus=viewport&dq=CODASYL++REORG)

------
Matt3o12_
Not compeltely related to article but I've often heard that banks argue that
COBOL is more reliable and maintainable then any "modern" language.

I've always wondered why this is the case. Is it because people are way more
careful when entering code? The article points out that their IDE is connected
to the Mainframe directly which makes me believe an error is much more severe.
I'm more confident that the compile and unit tests can catch my mistake than
I'm in my own coding skills (which is why I am not always afraid of changing
tightly coupled systems). And even if worse comes to worse, i'd still be
confident that some system will detect that change and roll back my commit
before all goes south.

With COBOLT (in such old environments), it seems that things must not break at
any point so developer are a lot more careful with what they do, which makes
the code do what it is designed for very well. The problem with such an
approach is of course upgradability (I would not want to touch undocumented
code that has not been updated for 20 years because some government decided to
replace an old "protocol".

Or maybe, COBOLT is considered more reliable (by Banks, etc) because managers
just see the fact "this system has been running for 15 years" while ignoring
the problems that come with it.

But I'd like to hear your opinion about it.

~~~
delinka
COBOL development had (has?) a completely different development and deployment
experience. Sure, you keyed your code directly into the mainframe, but your
code and your session were isolated - you, the developer, had limited
privileges. Only once your code took the prescribed input and produce the
prescribed output was it allowed near "production" data.

That said, the language itself was (is?) so limited in scope and ability that
stability was nearly guaranteed. You READ and PRINT using tape or disk and
printers, but the programmer didn't worry about what devices were available -
some system admin pointed these devices at a job, and READ came from that tape
and PRINT went to that printer. The setup and management of the jobs that ran
your code was a very manual process. No pointers, no memory management ...
nothing low-level at all. Just high-level abstraction.

Then there's hardware reliability. As an example: you can walk inside the
mainframe, pull a CPU, and the thing keeps working. Replace that CPU, and the
system makes use of it. None of the system's users ever know that it happened.

~~~
sedachv
> Then there's hardware reliability. As an example: you can walk inside the
> mainframe, pull a CPU, and the thing keeps working. Replace that CPU, and
> the system makes use of it. None of the system's users ever know that it
> happened.

From what I understand, until Tandem came along and started to seriously eat
away at the market in the late 1970s and forced all the other manufacturers to
follow, mainframes were not known for reliability.

~~~
nickpsecurity
Im still looking for data myself on reliability over time. I recall one OS for
IBM mainframes bragging about its reliability because it ran six months or so
without a reboot. I was think, "Wow... some good numbers there..."

------
js8
I am sad to see the mainframe platform go away. There are still some things
that modern platforms could learn from, my biggest favorite is probably the
heavy system instrumentation that comes with it (system traces, SMF and RMF).
And WLM is also neat.

I am afraid it became a victim of its own success. IBM and other SW companies
got used to so huge margins so they stopped innovating enough, in order to
protect the revenue.

------
jxramos
I remember a professor at Stanford for an early CS class (I'm pretty sure it
was Jerry Cain) mentioning COBOL programming and drawing a graph with salary
vs time for a given language that manages to be adopted widely. First when the
language is rare there's a great ascent up, then as more people gain knowledge
the rates drop to some minimum as the knowledge supply broadens. Then as the
language shifts into a legacy context the graph ramps up again. If I remember
right he claimed the ramp exceeded the initial peak in the earliest days of
the language. I forget what the context was but I think it started out with a
question about what languages paid the most. I think I recall him quoting a
$300/hr figure for COBOL because it's so old school and the knowledgeable
population so small. Then come to think of it I think he said the rates
essentially drop to zero when the language is all but abandoned and
transitions to modern equivalents have befallen.

~~~
davidjnelson
It's funny what most of us consider "a lot of money". An uber driver yesterday
mentioned overhearing two organ replacement surgeons talking at his gym in
Palo Alto. One said, "man, the pay sucks. It's only $13,000,000 a year :-(".
And the other one responded "sheesh, come work for us and we could at least
get you up to $19,000,000 a year." Kind of puts things in perspective...

~~~
jxramos
Yah, the free market is an amazing thing where free individuals freely agree
upon rates even as astounding as those figures. The even cooler thing is that
there even exist institutions that can fit that into their payroll! Maybe
cooler still is that economies exist that even hold institutions such as
those.

I remember going to this Bay.net talk with Juval Lowy who beat down on
everyone calling devs code monkeys who got paid peanuts. Haha, ~100K range is
definitely peanuts compared to a seven figure salary. What a world.

~~~
dangerlibrary
Almost nothing about healthcare in the United States resembles a functioning
market, much less one worth marveling at because of all the freely available
choices being made.

------
Shivetya
We have the full suite of IBM systems at work, z, i, and p, plus a multitude
of other VM systems and windows servers. They have been talking about retiring
the z-series for the last twenty years yet have yet to do so. The reason is
probably similar to that of the banks, not that there isn't sufficient talent
to do so but just because it works, works well, and damn if every silly
project a portion off the z, i, or p, doesn't go wrong in some form or
another.

the new thing is wrappers, extending the life of the applications and their
data but allowing modern interfaces via the web and hand held devices. if
anything its the best example of code reuse there is.

on another note, I don't know if we have anyone under fifty who knows COBOL
well enough to do new work but a few can do maintenance just fine

------
krylon
Very interesting article, thank you very much!

I spent about 9 months in total in a mainframe team during my training, but
that team mainly took care of hooking up the mainframes to the corporate
network, so I did not do any coding except for small Perl script. (I came
close to having to code in REXX, but I dodged that bullet. I played around
with REXX at home and did not like it very much.)

But it was very interesting to see all the examples of parallel evolution in
the mainframe world, at least where the terminology was concerned. A reboot
was an IPL (also used as a verb), the OS kernel was a nucleus (a term I really
liked), they also had a term for network interfaces I forgot about.

A strange but interesting world, it's a shame those beasts are so expensive.

------
FatAmericanDev
Was expecting a Question and A...

~~~
Svenskunganka
Yeah, sorry about that! I'll add some direct Q&A at the bottom of the post!

~~~
devuo
Yeah, please do! Here's some questions I would ask:

1\. How/when did you decide you wanted to be a programmer?

2\. What were the challenges you've faced as a female programmer that started
in the 90's?

3\. You've been working for the same entity and possibly the same code base
for more than 20 years. Does it ever gets old?

4\. How scary is it to write code for a bank?

I'm certain I would have 100's more questions to ask, but I'll be satisfied
with at least these :-)

~~~
Svenskunganka
There! I've added those to the post at the bottom, with one more quite funny
story that I didn't knew about myself. Thank you all for asking questions,
there are many questions that I couldn't come up with myself that I'm very
happy to get answers from!

------
akeruu
About the IMS to DB2 migration, intuitively I would try to write a translation
layer between the two databases. Do you know if this was already attempted or
deemed undoable (or silly) from the beginning ?

~~~
saint_fiasco
DB2 is a relational database and IMS is not.

The programs that use IMS probably do lots of things that are just _not done_
in relational databases for good reason, so if you just translate it you will
either get errors in relational constraint or you will configure DB2 to stop
enforcing relations, losing most of the advantages DB2 has in the first place.

------
niftich
Interesting personal perspective, thanks for posting!

It sounds like other than the very slow database, the biggest impediment in
this space is the lack of new talent familiar with the environment.

~~~
zcdziura
Absolutely. In many cases, universities can't afford their own IBM mainframe
environment to allow students to learn how to use it. Many folks, such as
myself, have to have on-the-job training in order to learn COBOL and how to
use the IBM mainframe itself.

~~~
niftich
Is that environment something that could be virtualized, were it not for
intellectual property reasons?

Almost seems to be more of a vendor lock-in issue than an a mere 'old and
scarce platform' issue, albeit that's significant also.

~~~
drabiega
There's already an emulator called Hercules, but you need a license from IBM
to run the operating system all of this runs on top of.

~~~
gkya
Maybe telling IBM about your interest would lead to them licence it free to
emulators. They wouldn't like their platform to die because nobody knows how
to use it.

~~~
raesene9
you'd think that wouldn't you , instead they've sued them in the past
[http://arstechnica.com/information-technology/2010/04/ibm-
br...](http://arstechnica.com/information-technology/2010/04/ibm-breaks-oss-
patent-promise-targets-mainframe-emulator/)

~~~
gkya
That's because they've been a bit naughty though, not because of mere
corporate evil. Quoting the article you linked:

\-----8<\-----

A well-designed System Z emulator that allows users to migrate their own
mainframe applications to commodity hardware would obviously pose a serious
threat to IBM's mainframe business, but IBM's software licensing terms have
historically prevented such a threat from materializing.

...

In many ways, the project arguably benefits IBM by encouraging interest in the
mainframe platform. [...] What brought about IBM's change in perspective was
an unexpected effort by the TurboHercules company to commercialize the project
in some unusual ways.

TurboHercules came up with a bizarre method to circumvent the licensing
restrictions and monetize the emulator. IBM allows customers to transfer the
operating system license to another machine in the event that their mainframe
suffers an outage. Depending on how you choose to interpret that part of the
license, it could make it legally permissible to use IBM's mainframe operating
system with Hercules in some cases.

Exploiting that loophole in the license, TurboHercules promotes the Hercules
emulator as a "disaster recovery" solution that allows mainframe users to
continue running their mainframe software on regular PC hardware when their
mainframe is inoperable or experiencing technical problems. This has
apparently opened up a market for commercial Hercules support with a modest
number of potential customers, such as government entities that are required
to have redundant failover systems for emergencies, but can't afford to buy a
whole additional mainframe.

\-----8<\-----

~~~
raesene6
Sure naughty or not naughty though, having IBM be actively hostile to the only
cheap way to get access to a mainframe like environment is disasterous for
their skill pool.

So if they don't like herculeas' efforts they should've brought out their own,
or come to some kind of arrangement with them.

------
chmaynard
From a technology perspective, the mainframe software described in this
interview is clearly an evolutionary dead-end. It was written in an era when
every bank had its own programmers and wrote its own proprietary software.

Because of the widespread use of these homegrown systems in the banking
industry, however, it appears that management is not yet ready for a total
break with the past. The investors that own these companies need to demand
change and indicate they are willing to pay the cost.

------
fiatjaf
Where is the interview? I want the interview!

------
wingerlang
Is it possible to get into COBOL still? I don't know anything about it, most
people seem to say it is horrible to use. Would it be career suicide? Will it
be totally gone in X years?

Given the chance, I'd probably jump onto the opportunity to work with it.

For reference I do iOS development now and I have ZERO experience with COBOL.

------
ank_the_elder
I love this article. My own stepmother just retired from a 30+ year old career
as a COBOL programmer. One of my first gigs was actually doing a bit of COBOL
myself - it's an interesting language in that the database access is built
into the language itself, rather than being a library or add-on.

------
webwanderings
There are tons of (young) Mainframe programmers and experts from India. Banks
are facing no such problems. And no, they don't necessarily earn fat
paychecks.

And I think you have broken a security rule if your screen shot of ISFP is
from her bank. This whole article seems risky for her job.

~~~
Svenskunganka
That's not her ISFP, she got much nicer colors! That's an image I found of an
ISFP.

------
robkwok
Awesome story, thanks for sharing! It's important to take a step back and
appreciate history.

~~~
diiq
I'm not sure it's fair to call it history -- it is _because_ of history (what
isn't?), but what is described is the way things are _right now_ , eh?

------
anabis
Japan's Mizuho bank is notorious for struggling with the system update. Big
mergers bring big office politics.

They were in news in 2002, 2011, and also right now, where they are struggling
to finally merge the 3 systems of their pre-merge banks together.

------
sbierwagen

      I can only imagine the fat paycheck a 20-year old 
      mainframe programmer would get though, because your age 
      in this case would be invaluable.
    

As long as you're on the topic of compensation, how much does she make right
now?

~~~
slowmotiony
Not OP; but working in an investment bank in Western Europe as we speak. The
mainframe guys next to me are making around 1-2k EUR a day as contractors.

------
module0000
Thank you for writing this! This was a very fascinating read - very
insightful.

------
david-given
You _can_ interface Cobol with modern technologies. See, for example, this web
framework:

[http://www.coboloncogs.org/](http://www.coboloncogs.org/)

------
jetcata
This tech stack is basically the same as what most insurance companies in
Australia use! IBM mainframes, IMS, DB2, Endeavour etc. there's a lot of this
type of work still out there.

------
jason_slack
Is there really a market for my COBOL knowledge still? It was one of my
favorite languages and honestly it is what got me into SQL and other data
analysis languages.

------
jdiez17
Thank you for sharing this. Off topic, but I thought the article was very well
written!

------
macjohnmcc
I studied Fortran, COBOL and RPG II later doing RPG II programming on IBM S/36
computers for 4 years until I went to the PC.

------
bitmapbrother
>There’s nothing wrong with the language itself, the problem is that barely
anyone knows it — at least not in the context of mainframe programming.

What data did you use to determine that barely anyone knows mainframe COBOL?
There are a significant amount of companies that still use it because it just
works and they're in no need to upgrade to current technologies.

~~~
scottwhudson
I don't have any data for that point, but I get the sense that this shortage
of labor is caused more by aging workforce than obscurity. My dad is an
engineering manager for a large credit card processor that uses a very similar
mainframe setup, and they're constantly putting enormous pressure on their
offshore contracting firms to provide young COBOL programmers because they can
barely find them here. It's a job that pays people enough that they can retire
well if they're good with money, and they're retiring constantly. At 57, he's
one of the youngest on the team.

~~~
raesene9
unfortunately even assuming the outsourcer can find people who really have
COBOL experience there's a world of difference between knowing COBOL and being
able to maintain the 30+ years of hacks that many large companies will have
built up in these systems.

Unfortunately the alternative (re-write the mainframe/COBOL systems in a more
modern platform) is a risky and costly process....

~~~
rodgerd
> being able to maintain the 30+ years of hacks that many large companies will
> have built up in these systems.

It's not even the hacks. It's that "how the business works" was automated into
COBOL 30 or 40 years ago, everyone in the "business" who knew how and why
things happened retired or got laid off, and the COBOL programmers are the
only ones who remember the business rules.

------
shiggerino
I can understand why the big banks are reluctant to re-write the big systems
now that they have painted themselves so far into the corner, but what I don't
understand is why they seemed so disinterested in the massive advances that
were made in the 1970s that would have made COBOL and IMS long obsolete
already then.

~~~
gaius
Reinventing the wheel is not the same as advancing.

------
smegel
I knew someone who just retired from being a mainframe programmer (not just
COBOL). She reckons she could have kept working for another 20 years if she
wanted.

------
jeffcaijf
nice to see such interview, especially it's from parent

------
peter303
COBOL is one of the "big 3" compiled languages developed in the late 1950s;
the other two FORTRAN and LISP. All three are still in use.

COBOLs fortee was you instructed the computer in English-like sentences and
paragraphs.

