Vogel Consulting LLC

“I Have Not Learned the New Debugging Tool”

“What do you mean you have not learned the new debugging tool?”

If you have been coding since the dinosaurs roamed the earth… well, yes—some of us have. And technically, birds are modern-day dinosaurs. With a last name like Vogel (which literally means “bird” in German), I have made more than a few jokes about that over the years.

But here is the reality: if you have been coding for a long time, you have probably seen tools come and go—and sometimes come back again in a different form.

Back When Tools Were Not So Friendly

Early in my career, I worked with CoOperative Development Environment/400—better known as CODE/400—on the IBM AS/400. That was my first real experience with a structured development environment beyond the green screen.

I even dug up an old 1996 reference to “CODE/400 for OS/2.” That alone tells you something: these “new” tools are not always as new as we think.

And yet, despite having access to tools like that, many of us stayed right where we were most comfortable—on the green screen.

Why?

Because it worked.

“Back When?” Tools Were Not So Friendly… Are They Now?

Fast forward 30 years.

It is now 2026. We have incredible tools. Modern IDEs with beautiful interfaces, color coding, structured layouts, extensions—everything looks polished and powerful.

And I will admit it: they look great.

Seriously, the visual experience alone is impressive.

But here is the question…

Are they actually more friendly?

If you read my last post, you know I dropped the IDE like a hot potato when it came to debugging. Same old pattern—go back to what is reliable, what is familiar.

But today was supposed to be different.

“This Time Will Be Different”

I set up the new IDE.

No issues.

Plug in the host. Enter the user profile and password. I am in.

Well… almost.

There was one small issue—I had to use a specific port for the system I was connecting to. But there was a documented solution, so no big deal. Maybe a five-minute delay.

After that?

Connected. From work. From home.

No excuses now.

Time to use the new debugging tool.

And Then Reality Hits

Wait… there is no manual?

How am I supposed to fill in this JSON?

What do you mean “debug owner profile”? Is that me?

Let me just try something…

Fail.

EQAVS1007E {system_host} on port 8005 could not be connected.

What does EQAVS1007E even mean?

Where do I look that up?

Is this coming from the IDE? From the system? From somewhere else entirely?

Then I see it:

“Debug Server Offline”

Ah—missed a step. Easy fix, right?

Let me start that.

And then…

Failed to start debug server:
CPC1221: Job 380864/PVOGEL/QB5ROUTER submitted to job queue QUSRNOMAX in library QSYS.
CPF9802: Not authorized to object QB5ROUTER in QGPL.
CEE9901: Application error. CPF9802 unmonitored by Q5BSTSVR at statement 0000000066, instruction X'0000'.

Are you kidding me?

The Saturday Morning Reality

At this point, I have spent most of my Saturday morning trying to get this working—hoping I could be ready for Monday.

Nope.

This “old dinosaur” programmer is going back to green screen on Monday.

Because it works.

Because it is reliable.

Because I know it.

And right now?

I do not have time to fight tooling.

Where Is the Safety Net?

Back in the day, I had a security officer I could go to—someone who owned access, permissions, and could help resolve issues like this quickly.

Now?

This is an IBM i in the cloud.

Where is that person?

Where is that support?

Because clearly, this is not just a “click a button and go” situation.

So Where Do We Go From Here?

That is the real question.

Monday is coming.

Clients expect results.

I also need to refresh myself on a product I last had in-person training on in 2018 and have not used since 2022. I am confident I will get back up to speed on that quickly.

But this new debugging tool?

It is going on the back burner.

Not because I do not want to learn it.

Not because I cannot learn it.

But because right now—it is not the thing that delivers value.

Final Thought

We like to think tools have gotten easier.

In some ways, they have.

They look better. They promise more. They integrate more.

But when something breaks?

You are still staring at cryptic errors, chasing permissions, and trying to figure out where the problem actually lives.

Some things have not changed in 30 years.

And maybe that is the real lesson:

It is not about whether you can learn the new tool.

It is about whether the tool is ready for you to rely on it when it matters.

View All

Vogel Consulting LLC