Not a lot of shops on IBMi have their members on IFS and those who have it is more likely they are not native IBMi languages but JavaScript, Python, and PHP.

The way mid-range systems were designed was a bit different than we see in Linux machines. There was no concept of IFS back then so the way the system was structured was within the operating system there is a master Library QSYS which is the only library that can contain other library objects. Other libraries can have any object except a *LIB object in it.

A special type of object is a source physical file which would be focusing in this article. A physical file is a table in a schema/library that can store data in its fields. Similarly, a source physical file is a table that can store source/code in it. If you look at the way all these objects are structured that seems similar to directory structures we see in Linux machines like QSYS.LIB/SAMPLE.LIB/QRPGLESRC.FILE/SOME.MBR. This path clearly defines where the source some is stored.

Often we hear that everything in IBMi is an object so what should be moved to IFS folders for better development? That is the source member/code which is nothing but a set of data inside an object of type *FILE a.k.a source physical file which is a multi-member file. Move this source data to IFS as a stream file and have only objects in the Libraries.

These systems were so well architectured that they provide an integrated environment within the same operating system where businesses can do all the development, database integration, and production run. This structure of the system in its early days led developers to do development on the business machine inside the source physical file using SEU. This way of development has its advantage, but in today's world, that is not very relevant and limits developers to use only IBM's applications or native applications by a few vendors, which is expensive.

Since SEU has not been receiving any updates for a long it's not wise to use it anymore for any development. Instead, a developer should make use of better available options like using an open-source editor for coding, git for version control, and Jenkins for CI/CD. We must know that IBMi uses EBCDIC encoding in its environment and usually, other systems like Linux, windows, and macOS use ASCII encoding this difference presents a bit of a challenge in accessing IBMi resources from other systems since they should be properly converted before being read by the system. All though there are methods to do this conversion they are not very handy and also add overhead in the process which is not likely.

Creating an object from a stream file is similar to creating objects from source members because all the create command provides a parameter called SRCSTMF where we can specify the relative or absolute path. Using different extensions in VS code we can easily do remote development. Since we will be using stream files it becomes easy to use GIT for version control.

A question can arise about maintaining the source members as stream files, it's not difficult at all, just assume the main directory as your source library which has multiple directories just like source physical files in a library. Each directory will have multiple stream files just as source physical file has multiple members. Have a look at the structures mentioned below.

Library structure ->  /QSYS.LIB/MYLIB.LIB/QRPGLESRC.FILE/PGM1.MBR
IFS structure -> /mylibdir/qrpglesrc/pgm1.rpgle

Additionally, there might be a requirement to keep the source in the native environment so that we can create a sync program that will run as scheduled and update the source in the source physical file from the stream file. As IBMi developers are adopting the latest programming methodologies like extensively using ILE concepts and doing test-driven development. In the long run it would be wise to use stream files instead of source members.

More to come on this in the future with steps to perform a few tasks so that those who are not used to or are scared of a new form of development can get some hands-on.

SUBSCRIBE to the newsletter.