Re: [IBMiOSS] code4i and CL line numbers

On Tue, Jun 24, 2025 at 8:48 PM Buck Calabro <kc2hiz@xxxxxxxxx> wrote:

RDi shows me the source statement described by the line number in the
call stack / error message. I'm there in an instant.
Code/400 - same.
SEU - same.
DSPPFM, CPYF, CPYSRCF - same.

Then you use one of those in that situation.

And then, once the fire is put out, you renumber the offending source
and recompile.

Code for i makes me guess which line is the one referenced in the
message, the call stack, the job log, the cross reference tool - Code
for i is the odd duck here. In my opinion, that's not correct
behaviour.

Code for IBM i isn't "making" you do anything.

The issue isn't about editing/recompiling; the issue is about
researching and debugging.

But it *is* about editing/recompiling, because if everyone allowed
SRCSEQ to be automatically renumbered, for every source member, on
every save, then the other stuff is a nonissue.

Think about what SRCSEQ is *for*. The ONLY reason ANYONE doesn't
renumber automatically is because it wasn't turned on for them when
they first started using SEU, and they never bothered to change it.
Most likely they didn't even know they *could* change it.

This is basically the very same reason so many IBM i systems in the
real world have QCCSID set to 65535 (i.e. not set to anything). And
the ramifications for recompiling a CLP are so much less scary than
for changing a fundamental system value.

The only reason I can think of for having even the slightest
resistance to renumbering and recompiling (and enforcing automatic
renumbering as a shop standard going forward) is that a "working"
piece of CL code would have a misleadingly recent last-changed date.
To which I say: if it matters that much, add an explanatory comment at
the top of the source.

John Y.