bobbydreamer

Life is short. Don't try to change people. Try understanding them taking a step back, just observing. It's better than a movie.

Why people want to move from firebase? Any reasons. It's a good db

Oh yeah. They would be already thinking about it and would have plans by now

Yep. The same approach my org uses as well. There is a team, who deals with all orgs docs maintain it. There is a internal portal to submit and you start getting mails 2 months before expiry.

Respective team meetings, it's a agenda to talk about what needs to be updated, after updating a draft will be sent and later uploaded in the portal.

Ego is the Enemy by Ryan Holiday

So true

Developers eventually go on to make their own site and paste the same content there.

That will be the end game.

Not sure how much they earn behind the wall.

I have one file called Worknotes.txt been using that for last 10yrs. All my notes are there inbetween I tried keeping separate notes for separate projects but it's hard to remember in folder and where. So got back to one file itself. It's easy for searching back. I keep date format consistent so it's easy.

Top of the file has all zoom/ mobile numbers of people i need to contact during emergency or support in production.

EoD marked by 20-30 hyphens next line start with date.

I wish i had learnt mark down 10yrs back. Thinking again what's the point. This serves the purpose.

Some common lines you hear from mainframers.

Deprecation is a new term in mainframe.

Don't fix what's not broken

------

It's a common saying that mainframers don't try to learn new tech. Well that saying goes two ways, person saying has really tried to learning mainframe and work on it for a month. Actually there isn't much to learn other than couple of languages COBOL, REXX, JCL and SAS. Other than that it's just ISPF interfaces.

Mainframers actually have to learn tech once and then go on to learn business logics and business domain. Isnt that actually good when comparing to always learning new tech and writing migrating programs to support existing interface in new Lang but not too much about business you are working on.

On the other hand mainframers do spend on learning and upskilling but in mainframe itself. There are lots of IBM Usergroups like IDUG for instance which is related to Db2, being a DBA that's a very useful training programme for me.

COBOL codes are highly modularized to do one or couple of functions to my knowledge and there are definitely coding standards each shop maintains.

Having a bunch of nodeJs cloud functions i get an email from Google saying that I need to migrate my NodeJs or it will stop functioning and while trying to migrate i find couple of modules are not longer supported and I need recode. Here I am not adding any new features just trying to make it work as before with new library which I have to find, learn, test and analyse does it suit then recode. All this costs time which you don't have to do in mainframe. You can say why not run in a VM, then what's the point running in cloud.

Mainframe is not a legacy system. IBM introduces a new machine every 3-4 years and send their sales team to visit corps and run presentations :) . Currently IBM has changed their billing style, it's not flat or peak hour, it's custom. It's the smallest footprint in your data center.

What mainframe actually did is, job separation. So in a career a person will sort of become an expert in their line or software. He will know all the ins and outs. For example a RACF security person will not know about Db2 and how it functions only part he knows is what interfaces with RACF. Same with CICS, MQ.... From application/dev team they get to know business like in a requirement meeting when business talks devs will be mapping business with program modules they had to make a change.

In mainframe people get to specialize.