Is there a way to prevent re-sequencing line numbers?

[GeorgeAtArborSolutions]

It seems like the line numbers are being re-sequenced when saving back to the source member. Is there a way to prevent this? I couldn't find a setting related to line numbering or re-sequencing. The combination of source member line number sequences and dates assists with identifying a prior change made by someone in the event that there are issues with how it was done. In addition, if an error pops up the line number in the log points to the line at which the error occurred. That information is lost if the line numbers get re-sequenced for some reason.

Have found that this happens during compiles but I don't see an option set on the command that would cause this. When compiling from the green screen source sequence numbers are preserved but when compiling using the actions from VS code they are re-sequenced.

[Max-crosskey]

Does this only happen when you compile the program? For me it seems to resequence whenever I open a source just to browse it as well. Need to open the source in the RDI to find the corresponding LOC that's causing the issue when fixing bugs.

[chrjorgensen]

IMHO You cannot trust the source member after compile - you can only trust the program object and the source, that you're storing in the program object by having DBGVIEW(*LIST) - or even better DBGVIEW(*ALL) - on your compile command.

If you do not store the source in the program object and anyone changes the source member after compilation, you will have no way of knowing what the source looked like when the program was compiled. This is true for all source types, whether it's a member or a streamfile.

Please stop using the source line numbers and dates for change history - they are obsolete and can be manipulated behind the scenes. Move to streamfiles in IFS and use git for SCM. If you really insists on keeping your source as source members (for whatever reason), use a tool to store your source members in git - an example could be i for git (note, I have no experience with that tool).

Whatever you do, stop trusting source members!

[GeorgeAtArborSolutions]

I think you misunderstand. The line numbers ARE relevant. When *SRCSTMT option is used at compile time, the line numbers from the source are available and used when an error occurs. It's then possible to access the source and identify the line at which the error occurred. Additionally, it is valuable to me when dealing with code someone else modified to know where line numbers have been added and the sequence number assists with this since normally line numbers end in "00" unless someone has added code in between. Losing that hampers my ability to identify issues. I've stopped using code for i at this point primarily for two reasons. 1. Resequencing of line numbers and 2. no ability to show block nesting which makes it very difficult to determine the conditions present when a given line of code is executed.

[worksofliam]

Sequence numbers are changed when the file is saved. There are no plans to retain sequence dates. We already retain source dates and that will likely be the extent to it.

Also, by block nesting, VS Code by default does show blocks and the ability to expand+collapse them.

You can take it one step further with an extension like Blockman: https://marketplace.visualstudio.com/items?itemName=leodevbro.blockman

[GeorgeAtArborSolutions]

The blocks shown in VS code are all messed up when there is embedded SQL code. They are not usable since they don't show actual block nesting but instead show indention based on syntax rules.

[chrjorgensen]

@GeorgeAtArborSolutions No, I did not misunderstand - my point was that the source member and line numbers are completely irrelevant if you store the source code in the program object. Then you have the source available if any errors occur, and you can see the source (including any copy members) AND the line if you start debug against the failing job. The debugger will show you exactly what line the program is failing in and you can view the source code. This way your program object and source code are linked and cannot be separated.

If you don't do this, then you risk someone (accidentally) changes the source code after compilation - or remove the source member altogether. Your program and source are only soft-linked, and the link can easily be broken or invalidated.

You seem to want the line numbers and source members for debugging - the above way is the best and most secure way to do this. Once you include the source and compile listing in the program object, you can let go of the source members and move the source to streamfiles in the IFS (or elsewhere) and use git for version control of the source. Using git gives you the ability to see deleted lines in the source - something you can never do with source members! Let go of the old way of using source with line number and line dates - git gives you so much more! I've been there years ago, and I admin it was hard in the beginning - but after a short while I didn't miss the dates anymore and have never regretted the switch to streamfiles and git.

[GeorgeAtArborSolutions]

That only helps when debugging. It does nothing to assist me in with getting into the mind of the developer that was adding code to a program and that code is not working correctly. In that case added lines with gaps in the sequence can tell me things. Or lines that were inserted (don't end in "00") but did not include any kind of modification tag. Or lines inserted (don't end in 00) with a different date than the inserted lines around them. Those all tell me things the developer was doing that are completely lost when the numbers get resequenced. George L. Slater IS Consultant Arbor Solutions, Inc. (616) 451-2500 (269) 509-2008 (cell) (616) 451-2571 (fax) ***@***.******@***.***> www.arbsol.com<http://www.arbsol.com>

…

------ Original Message ------ From "Christian Jorgensen" ***@***.******@***.***>> To "codefori/vscode-ibmi" ***@***.******@***.***>> Cc "George Slater" ***@***.******@***.***>>; "Mention" ***@***.******@***.***>> Date 12/8/2023 11:20:23 AM Subject Re: [codefori/vscode-ibmi] Is there a way to prevent re-sequencing line numbers? (Discussion #1367) @GeorgeAtArborSolutions<https://github.com/GeorgeAtArborSolutions> No, I did not misunderstand - my point was that the source member and line numbers are completely irrelevant if you store the source code in the program object. Then you have the source available if any errors occur, and you can see the source (including any copy members) AND the line if you start debug against the failing job. The debugger will show you exactly what line the program is failing in and you can view the source code. This way your program object and source code are linked and cannot be separated. If you don't do this, then you risk someone (accidentally) changes the source code after compilation - or remove the source member altogether. Your program and source are only soft-linked, and the link can easily be broken or invalidated. You seem to want the line numbers and source members for debugging - the above way is the best and most secure way to do this. Once you include the source and compile listing in the program object, you can let go of the source members and move the source to streamfiles in the IFS (or elsewhere) and use git for version control of the source. Using git gives you the ability to see deleted lines in the source - something you can never do with source members! Let go of the old way of using source with line number and line dates - git gives you so much more! I've been there years ago, and I admin it was hard in the beginning - but after a short while I didn't miss the dates anymore and have never regretted the switch to streamfiles and git. — Reply to this email directly, view it on GitHub<#1367 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BALQTGKHJNSSWQ4GKE3XC53YIM44PAVCNFSM6AAAAAAZDURM7CVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TQMBRGQ3TS>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[sebjulliand]

I guess this was exactly @chrjorgensen 's point: use an actual SCM to manage your source code. That's the kind of tool that gets you into the mind of the developer. Even better: you don't have to guess what happened, it tells you explicitly!
Git does that, it's free, it runs on IBM i (yum install git) and the compile commands supports IFS files. You should step up and give it a try, this could save you a lot of headaches. You'd be amazed 😁 And since you already use Code for IBM i, you're no stranger to modern tools, so why not give it a try?

[GeorgeAtArborSolutions]

I'm restricted as a consultant to use what my clients use. They do have source control systems in place but they are not GIT based and don't track code outside of what the developer puts in as comments. George L. Slater IS Consultant Arbor Solutions, Inc. (616) 451-2500 (269) 509-2008 (cell) (616) 451-2571 (fax) ***@***.******@***.***> www.arbsol.com<http://www.arbsol.com>

…

------ Original Message ------ From "Sébastien Julliand" ***@***.******@***.***>> To "codefori/vscode-ibmi" ***@***.******@***.***>> Cc "George Slater" ***@***.******@***.***>>; "Mention" ***@***.******@***.***>> Date 12/8/2023 2:40:36 PM Subject Re: [codefori/vscode-ibmi] Is there a way to prevent re-sequencing line numbers? (Discussion #1367) I guess this was exactly @chrjorgensen<https://github.com/chrjorgensen> 's point: use an actual SCM to manage your source code. That's the kind of tool that gets you into the mind of the developer. Even better: you don't have to guess what happened, it tells you explicitly! Git does that, it's free, it runs on IBM i (yum install git) and the compile commands supports IFS files. You should step up and give it a try, this could save you a lot of headaches. You'd be amazed 😁 And since you already use Code for IBM i, you're no stranger to modern tools, so why not give it a try? — Reply to this email directly, view it on GitHub<#1367 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BALQTGO6A243X76LDQNXUGDYINULJAVCNFSM6AAAAAAZDURM7CVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TQMBTGAZDE>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[Wright4i]

George,

I'm a consultant as well and I get the struggle of working within the bounds set by each client. Sometimes there isn't a perfect answer.

The first approach for me would be to talk with your client about the merits of modernizing their source control management. You might be surprised at their answer if it comes from their hired subject matter expert.

Second, I've found a lot of success in keeping code changes compact and functional. Make well-documented procedures for your changes and minimize impact to preexisting code if you aren't refactoring an entire program. While, yes, the sequence lines would be renumbered your code changes are clear to any developer who comes after you and it's hard to argue with that.

I do highly encourage the above, but there's always the option of submitting a solution as a pull request to this project. Typescript is a fun language and that is the beauty of open source that vscode offers above the paid alternatives.

Happy Holidays!

[GeorgeAtArborSolutions]

The one thing you neglect to mention here is that I have to deal with fixing things that aren't working correctly and may not have been for years without anyone noticing. Those are things other developers changed without any kind of documentation and often in the quickest (and therefore not the optimal) way. I've run into code that was supposed to omit a couple of conditions and it was written as "if not condition 1 or not condition 2"; completely inaccurate logic for the task so instead of omitting two conditions it includes all conditions. There are many times I run into things like this and in order to correct it, I have to identify what the intent of the developer was. Knowing what they inserted and when they did it, helps me to identify the condition they were trying to address. I won't argue my point any further. There is a reason that the re sequence option when saving in SEU is always set to "N" everywhere I've ever worked. Losing that is something that prevents me from adopting Code as my editor of choice. George L. Slater IS Consultant Arbor Solutions, Inc. (616) 451-2500 (269) 509-2008 (cell) (616) 451-2571 (fax) ***@***.******@***.***> www.arbsol.com<http://www.arbsol.com>

…

------ Original Message ------ From "Joseph Wright" ***@***.******@***.***>> To "codefori/vscode-ibmi" ***@***.******@***.***>> Cc "George Slater" ***@***.******@***.***>>; "Mention" ***@***.******@***.***>> Date 12/9/2023 12:55:23 AM Subject Re: [codefori/vscode-ibmi] Is there a way to prevent re-sequencing line numbers? (Discussion #1367) George, I'm a consultant as well and I get the struggle of working within the bounds set by each client. Sometimes there isn't a perfect answer. The first approach for me would be to talk with your client about the merits of modernizing their source control management. You might be surprised at their answer if it comes from their hired subject matter expert. Second, I've found a lot of success in keeping code changes compact and functional. Make well-documented procedures for your changes and minimize impact to preexisting code if you aren't refactoring an entire program. While, yes, the sequence lines would be renumbered your code changes are clear to any developer who comes after you and it's hard to argue with that. I do highly encourage the above, but there's always the option of submitting a solution as a pull request to this project. Typescript is a fun language and that is the beauty of open source that vscode offers above the paid alternatives. Happy Holidays! I'm restricted as a consultant to use what my clients use. They do have source control systems in place but they are not GIT based and don't track code outside of what the developer puts in as comments. George L. Slater IS Consultant Arbor Solutions, Inc. (616) 451-2500 (269) 509-2008 (cell) (616) 451-2571 (fax) @.@.> www.arbsol.com<http://www.arbsol.com>http://www.arbsol.com

------ Original Message ------ From "Sébastien Julliand" @.@.>> To "codefori/vscode-ibmi" @.@.>> Cc "George Slater" @.@.>>; "Mention" @.@.>> Date 12/8/2023 2:40:36 PM Subject Re: [codefori/vscode-ibmi] Is there a way to prevent re-sequencing line numbers? (Discussion #1367<#1367>) I guess this was exactly @chrjorgensen<https://github.com/chrjorgensen>https://github.com/chrjorgensen 's point: use an actual SCM to manage your source code. That's the kind of tool that gets you into the mind of the developer. Even better: you don't have to guess what happened, it tells you explicitly! Git does that, it's free, it runs on IBM i (yum install git) and the compile commands supports IFS files. You should step up and give it a try, this could save you a lot of headaches. You'd be amazed 😁 And since you already use Code for IBM i, you're no stranger to modern tools, so why not give it a try? — Reply to this email directly, view it on GitHubhttps://github.com/orgs/codefori/discussions/1367#discussioncomment-7803022, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BALQTGO6A243X76LDQNXUGDYINULJAVCNFSM6AAAAAAZDURM7CVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TQMBTGAZDE. You are receiving this because you were mentioned.Message ID: @.***> — Reply to this email directly, view it on GitHub<#1367 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BALQTGNKVNOHBJVUNFMPF3LYIP4MXAVCNFSM6AAAAAAZDURM7CVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TQMBVGQ3DC>. You are receiving this because you were mentioned.Message ID: ***@***.***>