The previous post covered IBM i system operations with CL — subsystem management, job control, data queues, and scheduling. This post goes deeper into the Integrated File System: journalling stream files, sharing IFS directories over the network with NetServer, backing up IFS data, handling large files, and the encoding challenges that trip up teams working with modern text formats in the IFS.
Post 24 covered the IFS foundations — stream files, directory structure, Git, and basic RPG/CL integration. This post covers the operational and advanced aspects that matter once the IFS is in active use across a development team or production application stack.
IFS journalling for stream files
The IBM i library system has had journalling for decades — every change to a database file can be captured in a journal receiver for recovery and replication. Stream files in the IFS support journalling too, but it works differently and is less commonly enabled.
Why journal IFS stream files:
- Point-in-time recovery for application configuration files and data files stored in the IFS
- Replication of IFS content to a standby system using IBM i native replication or third-party tools
- Audit trail for changes to sensitive IFS files (scripts, configuration, keys)
Enabling journalling on an IFS directory:
/* Create a journal receiver in the library system */
CRTJRNRCV JRNRCV(ORDLIB/IFSRCV0001) THRESHOLD(50000) TEXT('IFS journal receiver')
/* Create a journal */
CRTJRN JRN(ORDLIB/IFSJRN) JRNRCV(ORDLIB/IFSRCV0001) +
MNGRCV(*SYSTEM) DLTRCV(*YES) TEXT('IFS stream file journal')
/* Start journalling on an IFS directory (covers all files in the directory) */
STRJRNLK OBJ('/home/app/data') JRN(ORDLIB/IFSJRN) +
SUBTREE(*ALL) OBJTYPE(*STMF) IMAGES(*BOTH)SUBTREE(*ALL) includes all files in subdirectories. IMAGES(*BOTH) captures before and after images — required for both recovery and replication.
Checking which IFS objects are journalled:
SELECT PATH_NAME, JOURNAL_NAME, JOURNAL_LIBRARY, JOURNAL_IMAGES FROM QSYS2.IFS_JOURNAL_INFO WHERE PATH_NAME LIKE '/home/app/%' ORDER BY PATH_NAME;
NetServer: sharing the IFS as a Windows network drive
IBM i NetServer implements the SMB (Server Message Block) protocol — the same protocol Windows uses for network file sharing. Any Windows, macOS, or Linux workstation on the same network can mount an IFS directory as a network drive through NetServer, without installing any IBM i client software.
Starting NetServer:
STRTCPSVR SERVER(*NETSVR) /* Start NetServer */ ENDTCPSVR SERVER(*NETSVR) /* Stop NetServer */
Configuring NetServer shares:
/* Create a share for the application IFS directory */
ADDNWSSTG TYPE(*SHARE) STGSIZE(0) ONLINE(*YES) DIRNAME('/home/app') +
ONLINE(*YES) TEXT('Application files')
/* Or use the CFGTCPSVR command for the full NetServer configuration */
CFGTCPSVR SVRSPCVAL(*NETSVR)NetServer shares are configured through IBM Navigator for i (the browser-based management interface): Network → Servers → TCP/IP → NetServer → File Shares. This is more practical than CL for initial setup.
Connecting from Windows:
\MYSYSTEMSHARENAME
Type this in Windows Explorer’s address bar, authenticate with an IBM i user profile and password, and the IFS directory appears as a network folder. Developers can edit files directly, drag and drop, and copy without using ACS or FTP.
Permissions on NetServer shares: NetServer respects both the IFS POSIX permission bits and IBM i object authority. A file that a Windows user cannot read through NetServer is also inaccessible through RPG or PASE — it is the same object with the same authority model.
NFS exports
IBM i also supports NFS (Network File System) for UNIX/Linux client mounting. Where NetServer serves Windows clients, NFS serves Linux and macOS clients.
/* Start NFS server */ STRTCPSVR SERVER(*NFS) /* Export an IFS directory via NFS */ /* Configuration is done through /QOpenSys/etc/exports file */
# /QOpenSys/etc/exports /home/build/shared *(rw,sync,no_subtree_check)
/* Apply exports without restarting NFS */
QSH CMD('exportfs -ra')Mounting on a Linux client:
mount -t nfs mysystem:/home/build/shared /mnt/ibmi-build
NFS is less common than NetServer for IBM i shops but is useful when Linux build servers need to access IBM i source files directly as part of a CI/CD pipeline.
IFS backup and restore
The library system has SAVLIB/RSTLIB for libraries. The IFS has SAV/RST (Save/Restore) for directories and stream files.
Saving an IFS directory:
/* Save to a save file */
SAV DEV('/QSYS.LIB/ORDLIB.LIB/APPSAV.FILE') +
OBJ(('/home/app')) +
SUBTREE(*ALL) +
UPDHST(*YES)
/* Save to tape */
SAV DEV('/QSYS.LIB/TAP01.DEVD') +
OBJ(('/home/build') ('/home/app')) +
SUBTREE(*ALL)Restoring an IFS directory:
RST DEV('/QSYS.LIB/ORDLIB.LIB/APPSAV.FILE') +
OBJ(('/home/app')) +
SUBTREE(*ALL)Saving only changed objects (incremental backup):
SAV DEV('/QSYS.LIB/ORDLIB.LIB/INCRSAV.FILE') +
OBJ(('/home/app')) +
SUBTREE(*ALL) +
CHGPERIOD(*LASTSAVE) /* Save only objects changed since last save */Saving from PASE with tar (for Git-managed source):
For source code managed under Git in the IFS, the most reliable backup is simply pushing to a remote Git repository. The Git history is the backup. For additional safety, archive with tar:
QSH CMD('cd /home/build && tar -czf /home/backup/source-$(date +%Y%m%d).tar.gz project-repo')Large file support
By default, IBM i stream files support sizes up to 1 GB in the IFS (limited by a 32-bit offset). For files larger than 1 GB, large file support must be enabled at the directory or file level.
Creating a directory with large file support enabled:
CRTDIR DIR('/home/data/largefiles') DTAAUT(*RWX) OBJAUT(*ALL)
/* Enable large file support for new files in this directory */
CHGATR OBJ('/home/data/largefiles') ATR(*ALWSAV) VALUE(*YES)
CHGATR OBJ('/home/data/largefiles') ATR(*CCSID) VALUE(1208)Practically, large file support is relevant for:
- Save files written to the IFS (SAV to STMF)
- Log files that accumulate over long periods without rotation
- Data extract files for analytics pipelines
- Binary data files (images, documents stored in the IFS)
CCSID and encoding in the IFS
This is the most frequent source of IFS-related problems for developers from non-IBM backgrounds. IBM i uses EBCDIC for library system objects (source members, database files). The IFS supports multiple encodings through CCSID (Coded Character Set Identifier) attributes.
Common CCSID values:
37— EBCDIC US English (the default for library system objects on US IBM i)1208— UTF-8 (the correct encoding for source files, configuration files, and any text that modern tools will read)819— ISO 8859-1 (Latin-1)65535— “no conversion” / binary — use for binary files and files with pre-determined encoding
Checking the CCSID of an IFS file:
SELECT PATH_NAME, CCSID, OBJECT_TYPE
FROM TABLE(QSYS2.IFS_OBJECT_STATISTICS(
START_PATH_NAME => '/home/build/project-repo/src',
SUBTREE_DIRECTORIES => 'YES'))
WHERE OBJECT_TYPE = 'STMF'
ORDER BY PATH_NAME;Setting CCSID on a file:
/* Set a stream file to UTF-8 */
CHGATR OBJ('/home/build/project-repo/src/rpgle/CRTORD.rpgle') +
ATR(*CCSID) VALUE(1208)Setting default CCSID for new files created in a directory:
/* All new files in this directory will default to UTF-8 */
CHGATR OBJ('/home/build/project-repo') ATR(*CCSID) VALUE(1208)CCSID conversion during CPYTOSTMF:
When copying a source member (EBCDIC) to an IFS stream file, CPYTOSTMF converts the encoding if you specify STMFCCSID(1208). Always specify this when the destination file will be read by modern tools:
CPYTOSTMF FROMMBR('/QSYS.LIB/ORDLIB.LIB/QRPGLESRC.FILE/CRTORD.MBR') +
TOSTMF('/home/build/project-repo/src/rpgle/CRTORD.rpgle') +
STMFOPT(*REPLACE) +
STMFCCSID(1208) /* Convert EBCDIC to UTF-8 */The CCSID 65535 trap: Files created by some PASE tools default to CCSID 65535 (no conversion). These files appear correct when viewed in the tool that created them but display as garbage in tools that expect UTF-8 or EBCDIC. When a Git clone produces files with CCSID 65535, set the directory default to 1208 and re-clone.
IFS performance considerations
File system cache: IBM i caches IFS stream file data in main storage. The effective performance of IFS reads depends on how much of the working set fits in the cache. For applications that repeatedly read the same configuration or reference files, the IFS cache means the second and subsequent reads are from memory, not disk.
Directory depth: Very deep directory trees (20+ levels) can slow path resolution. Keep IFS directory structures reasonable — four to six levels for source repositories is practical.
Many small files: Applications that create thousands of small temporary files in the IFS (log entries, individual record files) can cause directory scan performance problems. Use DB2 for i tables for structured data, not individual IFS files per record.
IFS objects and system backup: SAV/RST for IFS objects is slower than SAVLIB/RSTLIB for the same data volume because stream file objects require per-object processing rather than the optimised library save path. If IFS backup time is a concern, use a dedicated backup server that mounts the IFS via NFS or NetServer and runs file-level backup software.
The IFS is not a separate concern from IBM i operations — it is the storage layer for everything modern on the platform. Journals, NetServer shares, CCSID management, and proper backup coverage of IFS directories are operational requirements for any IBM i shop running Git, open-source tools, or Node.js/Python applications on the system.
Next post: Advanced ILE RPG — system pointers, IBM i OS APIs, dynamic program calls, user spaces, and the patterns that allow RPG programs to interrogate and control the IBM i system from within application code.