IBM i Global

Rather strange questions... sources should be just like any other object on your IBM i (ie. programs, database, configuration, ...) part of your backup strategy (meaning that you backup them daily and keep a week/month/year history with intervals that suite your needs).  Objects stored on IBM i don't get corrupted but remain intact as long as your system is running fine (meaning proper hardware maintenance like replacing defect disks - which is no issue as one normally runs a form of RAID protection).

Git is another method and goes further than just saving sources as it will register every commit you do (while a normal backup only runs once a day) and is indeed used in the context of version control (but there are tools - which you can even easily write yourself - do so on IBM i as well keeping your sources just in the standard source physical files).  As far as Git is concerned, it is a stream based tool so it doesn't work well with source physical files (but again tools exist for that) but is normally used with IFS files (which requires some conversion from your end).

Still amazed by your statement "if AS400 fails"... the box is running your business I suppose so there's is more to worry that loosing your sources !

Hi,

source code is like every other data - you should back it up regularly. You have to do the same on every PC or Linux system, otherwise you will lose it in case of a system failure.

A good strategy is to do daily backups of ALL libraries and objects that change daily. If you are doing daily changes on source code, you should do daily backups of the source code. Whether you use version control or not.

We are going a step further and have ALL source code files under journals and do replication to another machine - the same way we do that with our databases. But even that is no replacement for a backup.

For using GiT with IBM i source files, there are solutions. Of course you can "manually" export your sources into an IFS directory and have GiT there - or you can use a commercial solution like iForGit (by Richard Schoen) which makes this a lot easier and might be a better fit for your workflow.

The last solution would be, to move your sources into the IFS permanently. Most compilers on IBM i can compile directly from IFS. You can create you own structure and add all that to GiT. You will lose the typical "member comments" as those aren't available in IFS. But you might be in a better position with IBM Project BOB. But you still have to do backups regularly - GiT is not a backup - it's version control.

So - there is no silver bullet, and also no best practice. You should evaluate all solutions a choose the one, that fits you and your development team most. iForGit can be a good solution to evaluate everything.

HTH

Daniel

Hello,

you may have a look here: https://community.ibm.com/community/user/blogs/nirmal-khatri/2025/09/10/unlocking-modern-development-on-ibm-i-with-github

Thank you,

Nikos

Hi,

As a side note about IFS source files & Git:

• Liam published a tool to migrate source files to IFS, quite old but may still work: https://github.com/worksofliam/migrate
• If you want to keep your Git repositories local to ease backups and use Windows, you may find this of interest: https://bonobogitserver.com/
• You may find some quick-start hints in this free course: https://www.ibm.com/training/course/getting-started-with-ibm-i-development-DL06005G (Unit 3)

If you create in VS Code a filter on libraries (not source pf's) you can right click on it and select "Migrate Source"  (believe you need the Source Orbit extension for this to be installed).

This will migrate your SRC-PF based sources to the IFS and do some extra stuff (like fixing your includes).

Just a caution on running git server itself as a store for the source itself on the IBM i on large code bases, due to the nature of how it writes and stores data and the movements of it on the IFS, there could be a large performance knock using it that way with many source changes and uploads with lots of developers, best to use it "outside" the ibm i on more supported platforms that can handle that. 

(lots ot people want to keep the source securely on their IBM i development box and which they should , just know that this "new world" expand that perception to use and cater for security in other manners if you are going to roll your own source pipeline for the IBM i). -> if your enterprise audits require that no developer has their hands in the  mechanisms of what is rolled by their own, then its best to use the Rocket / ARCAD solutions of the world to save you that headache. 

lastly, also forget about the notion for date stamping on source changed lines once you are in the new GIT world , there you have much more freedom to express the intention of what has changed (lots of people do struggle with that concept of "changed source lines by filtering and comparing on the date"

Hi all,