IBM i source code line change dates set to zeros

[StephenMWest]

When editing source code on an IBM i, upon saving the code the change date on every line of code changes to zeros. This renders the editor un-useable out-of-the-box.

Even if there is a configuration option to change date behavior to match previous IBM i editors, the default behavior of setting all dates to zeros will impede the acceptance of VS Code for IBM i.

I changed a couple of lines in a source member that is 30,731 lines. Upon saving the member, the change date of every line was changed to all zeros. I did not notice it until promoting the changed version up to our QUA environment. This was repeated for two other source members before it was noticed. It is very important to our source code management efforts to have the correct dates on the source code. This is the default behavior in IBM's SEU and RDi editors. It took a days worth of effort to recover the three sources.

I have since found the documentation for turning on the use of source code dates in the VS Code for IBM i. It looks like a decision was made for VS Code for IBM i to have the default behavior of not using the metadata elements of source line date and sequence. The documentation characterizes using the additional metadata element of 'date' as dumb. I disagree with that assessment. There are some advantages for using open source utilities for source code management that are common on other systems. None of those tools will make use of the source code metadata that are ubiquitous to the use of IBM i source code files. That does not suit our needs. Changing the QCCSID system value should not be a prerequisite for using the source line change date; it is not required for other IBM i source code editors that do use the date.

All of this leads me to believe you will not be making a change to have source line date support as the default behavior.
 
I applaud the fine work that you and others have made to bring a new source code editing tool to the IBM i landscape. There will certainly be those who are ready to abandon source line date and sequence number. They will gladly make use of this extension to VS Code. Keep up the good work.

Bye.

Stephen West
Stillwater Insurance Group

---

Context	Version
Code for IBM i version	2.6.1
Visual Studio Code version	1.83.1
Operating System	win32_x64

Active extensions

Code for IBM i Walkthroughs (vscode-ibmi-walkthroughs): 0.4.0 Db2 for IBM i (vscode-db2i): 0.6.0 Emmet (emmet): 1.0.0 Error Lens (errorlens): 3.15.0 Git (git): 1.0.0 Git Base (git-base): 1.0.0 GitHub (github): 0.0.1 IBM i Notebooks (vscode-ibmi-notebooks): 0.0.6 JSON Language Features (json-language-features): 1.0.0 Merge Conflict (merge-conflict): 1.0.0 Node Debug Auto-attach (debug-auto-launch): 1.0.0 TODO Highlight (vscode-todo-highlight): 1.0.5 TypeScript and JavaScript Language Features (typescript-language-features): 1.0.0 WSL: Recommender (remote-wsl-recommender): 0.0.19 ```

Remote system

Setting	Value
IBM i OS	V7R3M0
Tech Refresh	13
CCSID	65535
SQL	Disabled
Source dates	Disabled

[AG1965]

I agree with you that source change dates are important as long as you have your sources in source physical files.
More than once i pressed F5 to reset a line that i accidentally touched, loosing my edit. And more than once i pressed F3 without saving to leave a statement with their original date.

But the times are changing, the better is the enemy of the (not even so) good.

If you switch to free or even **free, you surely want to indent lines, and sometimes i move a whole block further to the right, or when i decide it has to go in it's own procedure, to the left, without actually changing anything. SEU would mark all these as changed, and pretty much any PC-editor which copies the whole file would have to do extra work in comparing the member in it's previous state to the state now to be saved. So much work for so little insight gained.

If you have your sources in a git repository, git has the history of all changes and a lot of tools for git can display the changes made in a more or less pleasing way.
With VS Code and the gitlens extension, you can see the last commit message and the date of the last edit in the editor.

When i name my branch like the JIRA ticket id, or mention the ticket id in the commit message or a tag, a link to our gitlab server hosting our repository appears and one can see exactly what has been done for this change.

So it's more than understandable that most of the folks want not only to use a decent editor but also want to enjoy the safety and comfort of git.
That's why it's dangerous to ride a really good bicycle - you won't really enjoy the old one as much as before.

So being able to edit source physical files, too, gives you the benefit of a modern editor now and helps keeping people satisfied while you are working out how to move your sources into a git repository and build your objects from it which isn't necessarily a simple task.

[StephenMWest]

We already use free-format RPG and fully-free **FREE. IBM's RDi tool works for both and maintains the line change date. I agree that the change date being changed for spacing changes is frustrating. I am hoping that at some point in the future, AI can be added to determine when the line change date s.b. changed based on the statements functionality. With that added intelligence, "eval psrefn = alprvr" can become "psrefn = alprvr;" without changing the date. Till then, we will have to settle for paying for RDi to get functionality we need over using the no cost VS Code for IBM i and losing out on the line change dates. One option would be for someone to create an RPGLE editor plug-on for VS for Code that supports the meta-data elements present in an IBM i source file.