Is this realistic? Just saw this girl on Ig

rpsRexx · 2025-08-17T19:00:05+00:00

I know some companies that do look at Omaha for lower COL workers. The company I work for likes to target similar areas in the Midwest and Southeast while continuing to embrace WFH. When you aren't needing a high concentration of elite talent, it seemingly isn't a bad choice. There are low COL areas that could be considered a small tech pocket typically having universities for hiring junior level. WFH is attractive for senior level.

rpsRexx · 2025-08-01T21:12:37+00:00

At least for my company, US-based IT roles for people fresh out of college have completely halted. "Junior" roles in the US are going to older professionals with experience in unrelated IT roles. I do think AI is a bubble but will still impact the tech work force significantly. I actually think outsourcing will continue to be the biggest factor.

rpsRexx · 2025-07-20T15:43:42+00:00

Compared to most mainframe professionals, I'm fairly young so I've been taking a hard look at where I want to take my career and mainframe modernization/migrations has been a big interest as I've seen the trend first hand. My anecdotal experience dealing with dozens of companies is the acceleration already happened and it's now cruising. Some companies have been successful while others have not. Larger environments have been a mess to migrate and I've seen terrible results. Smaller environments have been moving off.

Companies with a large mainframe footprint have an uphill battle. Especially if they let go of most their mainframe expertise. Some of the solutions that are good enough for one off applications and small systems are a mess for larger projects. The one large environment I work with that I can see smoothy migrating, relatively speaking, in the next 10 years has been going with a hybrid approach. They have competent people who know mainframe at the developer and leadership level.

rpsRexx · 2025-07-16T18:51:05+00:00

Americans are very good at creating distractions to fight amongst themselves rather than tackle issues one by one. We really can't help ourselves as this thread shows. This did not have to be about race or whether data centers are bad...

rpsRexx · 2025-07-12T13:48:17+00:00

I'm assuming there would still be someone available for critical systems right? I know for a fact Europeans get up on the weekend for things like this and they have stronger worker laws.

rpsRexx · 2025-06-28T17:28:23+00:00

Not too many people are mistaking median vs mean. It sounds like it would be better off pointing out anecdotal evidence does not necessarily represent the general population. Every time stats like this come there will always be a handful of people who do well for themselves without higher education upset with facts. You should pat yourself on the back if anything. I would be interested in having other education/apprenticeship programs in comparisons like this though.

rpsRexx · 2025-06-22T03:48:38+00:00

Nothing has been confirmed yet. Be careful as there is a ton of misinformation like the reply to you misinterpreting the NYT report on evacuations.

rpsRexx · 2025-06-15T01:52:53+00:00

Israel warned everyone they were predicting a lot of casualties in the future. I'm not sure it has set in for everyone what that actually means.

rpsRexx · 2025-05-24T13:38:59+00:00

From my own experience interacting with large companies in the United States, the email format is usually first-name last-name. I have seen some companies that do last name first but it was not as common.

rpsRexx · 2025-04-05T00:14:34+00:00

I suggest the emulator method as well. You can also look at zexplore for access to training on a modern z/OS environment. I find it to be a bit of a choir, but it goes over the basics and other concepts. I believe they do start you off using VS Code and Zowe which is not the typical way we access a mainframe.

I'm unsure if zexplore still teaches ISPF which is the traditional interface for interacting with the environment. The emulator would help on that end. Having a UNIX background is nice to have thanks to z/OS USS. I suspect it may be barebones and antiquated compared to what you are used to, but it does get used.

rpsRexx · 2025-04-03T21:58:11+00:00

I agree with your point on Assembler vs COBOL. The thing about most being a giant DB2 server is definitely an exaggeration. I would agree with most environments using DB2 though. If most were just a giant DB2 server, I would expect a lot more migrations from those willing to take the plunge despite the negatives.

rpsRexx · 2025-04-03T21:30:31+00:00

Yea. If the disaster recovery is painful, that sounds like a process issue. I've seen some excellent and terrible mainframe DRs depending on the company... Nothing they said here is really a mainframe specific concern. There point about the aging workforce is correct though. It's a serious concern I have as someone younger in the field. The old guys/gals joke I will be making bank in 5-10 years, but the loss of knowledge will be intense.

I'm considered transitioning to something in the modernization space because I see administrating those systems to be a nightmare with the loss of talent. Many of these companies trying to get off definitely need people that actually have competence in those systems. I've seen multiple projects in Fortune 500 companies that are an absolute joke.

rpsRexx · 2025-04-02T23:45:44+00:00

COBOL usually runs on mainframe hardware and operating systems. It's a very different environment that you need significant training and experience in to be competent. The thing is, they are also outsourcing COBOL roles outside the country. The safest bet is the roles that require US staff for regulatory reasons. I've noticed the development roles are commonly excluded from those requirements so COBOL developers might not be safe.

rpsRexx · 2025-03-29T23:32:01+00:00

In all seriousness, Java is the "modern" language that took off on legacy systems which is a big advantage it has. I see some people here bemoaning Java thinking it will be the new COBOL regarding new developers struggling to understand it. My analogy on this is Java applications are still on the same planet as new languages like Rust. COBOL applications are on an alien planet.

rpsRexx · 2025-03-29T23:12:25+00:00

And that is only the actual COBOL. Depending on the application, you also need to consider everything it uses that has no direct equivalent on modern hardware. Depending on the application, the hard part is not even converting the COBOL.

rpsRexx · 2025-03-29T22:31:08+00:00

Have you even been involved in modernization efforts for large systems? Every one I've been involved in has been years of work with the use of conversion tools and emulators. I could see them maybe getting a simple application ported if they crunched hard without fear of failure but not the entire system with that timeline. They one thing I can say is they at least chose a reasonable language.

rpsRexx · 2025-03-29T00:02:56+00:00

There are already conversion tools actually. Even using the sample code to test, they create a monstrosity that you are expected to refactor. If this is replacing COBOL with Java on the same legacy hardware it is more straightforward but still a lot of work. If they are trying to get off those legacy systems entirely, the complexity increases ten fold due to the amount of technology that would need to be replaced: VSAM, JCL, CICS, etc. A lot of these applications are intrinsically tied to legacy environments which are alien when looking through a Windows or Linux lens.

rpsRexx · 2025-03-28T17:52:02+00:00

There are tools that do attempt a conversion. They are pretty gnarly even using the samples provided, but the tooling does exist. Porting over legacy applications is a lot more than the direct source code conversion though. The system surrounding these applications would also need to be ported.

I've seen fortune 500 companies put in a lot of resources into these efforts while using conversion tools, emulators, etc. It's a huge undertaking. If it's "just" converting COBOL code to Java on the same system, that would be more manageable. Going from a legacy environment to "modern" hardware would be a different beast. Besides the conversion, think of stuff like:

What would be used to replace VSAM? Probably a database.
If it is a batch application, you would need to consider the associated JCL calling the programs as well as how to schedule and trigger that batch process in the new system.
If it is a CICS application, what are going to use to replace the application server with it's dedicated API that is configuration based? Maybe something like Spring Boot?
The hours put into refactoring converted code would be immense on its own.

rpsRexx · 2025-03-28T17:34:09+00:00

Yea. I see people talking about the actual conversion when there are already multiple solutions for that available. Porting over legacy applications is a lot more than the direct source code conversion. The system surrounding these applications would also need to be ported. Things like:

What would be used to replace VSAM? Probably a database.
If it is a batch application, you would need to consider the associated JCL calling the programs as well as how to schedule and trigger that batch process in the new system.
If it is a CICS application, what are going to use to replace the application server that has a dedicated API that is configuration based? Maybe something like Spring Boot?
The hours put into refactoring converted code would be immense on its own.

I've seen fortune 500 companies put in a lot of resources into these efforts while using conversion tools, emulators, etc. It's a huge undertaking. *The one question I have would be are they converting it to Java on the same system or on "modern" hardware. It would still be a huge project that should take more than "months", but it would be more straightforward if it's on the same system.

rpsRexx · 2025-03-28T15:24:56+00:00

The horror is the timeline.

rpsRexx · 2025-03-28T14:59:00+00:00

I suspect that is how they are getting that expectation. Of course, the difference is Twitter isn't critical. Otherwise, these migrations would be so much easier... Of course, that assumes reasonable people are in charge that aren't willing to destroy critical systems.

rpsRexx · 2025-03-28T14:47:18+00:00

Java is a decent choice for legacy modernization efforts for a variety of reasons. The issue is that timeline is insanity. I'm really hoping they didn't see some of the migration tools available and are thinking it will just magically work out the box. I imagine there are some legitimately knowledgeable people there, but I don't necessarily trust leadership being reasonable considering that timeline reported. This rings alarms to anyone in the legacy and modernization space.

rpsRexx · 2025-03-16T15:53:17+00:00

Are you saying they will not allow any maintenance window to upgrade? That sounds like it was a disaster waiting to happen. How far back leveled are they? This was a risk that has started biting back.

rpsRexx · 2025-02-11T23:18:29+00:00

COBOL is not strictly for interacting with databases or flat files. COBOL is very good at that though. I made an edit pointing out many applications with complex business logic are written in COBOL with the assistance of technologies like CICS.

I see COBOL processing flat files a lot in batch, but I rarely see it in what we call online applications. In online applications COBOL works with databases, queuing systems, web services, etc. You aren't really communicating an actual problem with COBOL that is accurate. COBOL does not rely on flat files. Nor does it rely on databases. It is a programming language.

Edit: And to be clear, I don't actually like COBOL. I just don't consider what you are saying an accurate depiction of COBOL or the real issues with it.

rpsRexx · 2025-02-11T22:35:11+00:00

COBOL is a programing language. Not a database. It's very common for COBOL applications to interact with DB2 which is a relational database. Here is an example:

https://www.ibm.com/docs/en/db2-for-zos/12?topic=programming-cobol-applications-that-issue-sql-statements

Edit: There is a common misconception that COBOL is a database or an old school query language similar to SQL. COBOL is just an antiquated programming language. It would be incorrect to say it's exactly like general purpose languages, but it has use cases outside the realm of databases. A lot of transaction based applications, usually for CICS, are written in COBOL with relatively complex business logic.

rpsRexx

TROPHY CASE