Many IBM i installations use the NetServer facility of the operating system to present directories in their system’s IFS as standard SMB file shares on their network, shares that can be accessed by Windows client PCs and any other SMB clients that may need to access IFS directories. It is very common in many shops for customers to have a share directly on the /QDLS folder, but what many don’t know is that directly accessing files in /QDLS via a standard NetServer file share can be problematic.
Why is it not a good idea to share /QDLS as a NetServer file share?
It is because of multithreading. NetServer by default is shipped as a multithreaded facility for optimal performance, and because /QDLS is a very old directory technology that cannot support multithreading, any file share connections to /QDLS must be single-threaded. If an SMB client (e.g. a Windows PC) makes its initial SMB connection to the system via a share on /QDLS then the NetServer server-side connection will be a single-threaded job, and any additional accesses to other IFS directories (e.g. outside of /QDLS) will also be funneled through that single-threaded connection. If an SMB client makes its initial SMB connection to the system via a share on a normal IFS share (“normal” = a share on a directory outside of /QDLS) then the NetServer server-side connection will be a multithreaded job and any requests to access /QDLS after that initial connection will fail, and therein lies the fundamental problem with /QDLS NetServer shares.
So, how do you avoid encountering these connectivity issues with shares on /QDLS?
The best practice approach is to not have a share on /QDLS in the first place. If you have code running on your system now that requires the use of the /QDLS folder (e.g. you may have a population of old applications that execute CPYTOPCD commands to create ASCII files of database files in /QDLS), then a good workaround is to still use the /QDLS folder but then after you place files in that folder then have your application take the additional step of moving those files from /QDLS to a normal IFS directory (outside of /QDLS) that can then be accessed via its own SMB share that will be serviced by a multithreaded connection on the server-side.
If you must continue to use a share on /QDLS for whatever technical/application reasons and you are experiencing the /QDLS connectivity issue that I described above, another approach to take (albeit not recommended for performance degradation reasons) is to simply configure your system to only use single-threaded server-side SMB connections with NetServer.
This approach will ensure that client-side connections to a /QDLS share will always work because the connection attempts by the client will always be serviced by a single-threaded job on the system, but it will impact the overall performance of IFS file shares on your system.
There are two different prestart jobs in subsystem QSERVER that service NetServer file shares to SMB clients. Single-threaded sessions that support file systems like /QDLS that are not thread-safe are handled by prestart job QZLSFILE, and multi-threaded sessions that support files systems except /QDLS are handled by prestart job QZLSFILET.
To force all SMB client connections to be single-threaded then you simply need to remove the QZLSFILET prestart job entry from subsystem QSERVER using these steps:
- End NetServer: ENDTCPSVR SERVER(*NETSVR)
- End the QZLSFILET prestart job: ENDPJ SBS(QSERVER) PGM(QZLSFILET) OPTION(*IMMED)
- Remove the QZLSFILET prestart job entry: RMVPJE SBSD(QSERVER) PGM(QZLSFILET)
- Re-start NetServer: STRTCPSVR SERVER(*NETSVR)
NetServer will now use only the QZLSFILE prestart jobs (single-threaded) for all SMB client connections. Because the multi-threaded prestart job QZLSFILET entry was removed from the QSERVER subsystem, the QZLSFILET job cannot start when NetServer is restarted thus all SMB connections will be forced into single-threaded connections and /QDLS connection failures should no longer occur.
If you need to re-enable multithreading for NetServer SMB connections then execute these steps:
- Add the QZLSFILET prestart job entry back to subsystem QSERVER: ADDPJE SBSD(QSYS/QSERVER) PGM(QSYS/QZLSFILET) STRJOBS(*NO) INLJOBS(1) THRESHOLD(1) ADLJOBS(0) MAXJOBS(*NOMAX) JOBD(QSYS/QZLSPJ) MAXUSE(1) CLS(QSYS/QPWFSERVER)
- Start the QZLSFILET prestart job: STRPJ SBS(QSERVER) PGM(QZLSFILET)
Many shops still use the /QDLS directory in their application/processing environments, however, sharing the /QDLS directory using NetServer has some caveats and hopefully, this article has given you some good insight as to what those caveats may be.
More from this month:
- OpenJDK Disables Legacy TLS Versions
- What Do I Need To Do Full System FlashCopy Backups?
- 4 Disaster Recovery Services That Can Improve your IBM i Recoverability
- iPOWER Hour Episode 29: What’s Going On With All The Ransomware Attacks?
- IBM i Security Resource Page
- iTech iTip Videos
- Sips & Tricks: Coffee with iTech
- iBasics: IBM i Education for the Beginner System Administrator
- Upcoming Events
- IBM i, FSP, and HMC release levels and PTFs (May 2021)