On Tue, Jun 24, 2025 at 2:04 PM Justin Taylor <jtaylor.0ab@xxxxxxxxx> wrote:
This came up because I was working with a call stack and job log that
references line numbers. In VS Code, those weren't even executable lines.
The preferred option is of course to renumber and recompile any
program that doesn't have "clean" sequence numbers.
If that's off the table for some reason, maybe you can set the logging
level so that you can see the CL code in the log. (Though frankly, if
the CL commands are not already logged, I'd think recompiling the CLP
is less onerous than changing the logging level.)
I guess I'll submit a bug report.
Where? The only place that even sort of makes sense is the IT
department which is allowing SRCSEQ to not automatically be renumbered
upon save. The "bug" is that they're not renumbering.
IBM isn't going to change the behavior on the i (even though I think
that is where it *should* be fixed). There's probably a snowball's
chance in hell that Liam and company would put that much work into the
VS Code extension for a nonbenefit. I'd be genuinely scared if Liam
entertained the possibility for more than half a second.
I'm in complete agreement that everyone should always renumber, but there's
a long way between "should always" and "always."
I don't think it's as long as the way between "Code for IBM i as it
stands now" and "Code for IBM i with SRCSEQ support". I think it would
literally be less effort to just renumber, even if that includes
taking the time to convince the powers that be that renumbering is the
only sensible course of action, and even if it includes writing up a
shop standards document that spells out mandatory renumbering.
John Y.
midrange.com
