IBM i NetServer Threaded Request Support

Resolving The Problem

To increase performance, beginning with operating system V5R4, IBM i NetServer supports the use of pools of threads to process client requests.

QZLSFILET is a prestart job (OS V5R4 and above) that handles threaded connection requests. QZLSFILE is a prestart job that handles non-threaded connection requests at all OS levels. The first session that is established from a particular client will determine which of these jobs will process subsequent sessions.

If threaded support is desired, verify that the QZLSFILET job is awaiting client requests for file or print serving (TIMW or TIMA status on the Work with Active Jobs screen for Subsystem QSERVER). If neither the QZLSFILET nor a QZLSFILE prestart job is found, you should use the Start Prestart Jobs (STRPJ) command to start them.

Note: One or more QZLSFILE jobs might be active; however, they will not show by default on the initial WRKACTJOB screen if they are not currently servicing any connections. Press the F14 key (which is Shift + F2) to display prestart jobs that are waiting for connection requests.

The QZLSFILET and QZLSFILE prestart jobs normally run in the QSERVER subsystem; however, they can be customized to start in a different subsystem. The job can be added to the subsystem description by using the Add Prestart Job Entry (ADDPJE) command to add the prestart job entry and to allow them to start automatically with the subsystem.

Note: An upgrade will overwrite changes made to QSYS/QSERVER Subsystem Description. Thus, change will have to be re-implemented after an OS upgrade.

If a subsystem is configured to start the QZLSFILET job, that single QZLSFILET job services multiple clients and their respective threadsafe file shares. There are multiple QZLSFILE jobs in a subsystem, and each one supports one Microsoft Windows client and all of the non-threadsafe file shares that are accessed by that one client when using IBM i NetServer. Linux connections behave differently. If not running threaded (using QZLSFILET), Linux connects to a separate QZLSFILE job for each mount of a NetServer share.

Trying to Access a Non-Threadsafe File System (Such as QDLS) while Running Threaded

A client that is running threaded (has already established the IBM i NetServer connection using QZLSFILET) will receive access denied type messages when trying to access a non-threadsafe file system from that threaded connection. The text of the message might vary. The IBM will send a "no access" type rejection to the client PC and Windows will generate whatever Windows error it interprets that rejection to be. The PC error can also take the form of a repeated prompt for User ID and Password.

The client will receive similar errors when attempting to map a new NetServer drive to a non-threadsafe file system when the client already has an established session that is running threaded. The Root, QOpenSys, User-Defined (UDFS), QNTC, QSYS.LIB, QOPT, and QLANSrv file systems are threadsafe, with some exceptions. See section titled 'Non-Threadsafe exceptions to the rule' at the bottom of this document. The QDLS and QFileSvr.400 file systems are not threadsafe.

If the first session established from a particular client is to a threadsafe file system and QZLSFILET is running, the session will run under that job and subsequent sessions from the same client will also run under the same job. If the subsequent session request is to a file system that is not threadsafe, the connection request will fail with an access denied type message.

If the first session established is to a file system that is not threadsafe, a connection to a QZLSFILE job will be established and subsequent sessions from the same client will also be serviced by QZLSFILE jobs.

Once a threaded connection has been made, when access denied type messages are encountered during an attempt to access a file system that is not threadsafe, all threaded sessions from the client must be ended to allow the new session to start and be serviced by a QZLSFILE job. This can be done on the PC side by using the Windows Disconnect Network Drive option (right-click on My Computer and select the option) or by using the NET USE /DELETE command from a Windows command prompt. From an IBM i5/OS command line, the disconnect can be done by using NETSTAT and selecting Option 3, then searching for the TCP/IP address of the PC and using Option 4 to end each session. After the sessions are ended, ensure the next session request is to the file system that is not threadsafe.

For additional trouble-shooting tips, visit the Troubleshooting file share problems section of the V7R1 IBM Knowledge Center.

Non-Threadsafe Exceptions to the Rule

The individual object type handlers determine whether an operation on a particular object is allowed in a multi-threaded environment, so some non-threadsafe objects can exist in otherwise threadsafe file systems. While not all such objects can be documented in this technote, one particular object does need to be listed here because this has a definite impact on what can and can not be done over a threaded (QZLSFILET) NetServer connection to the QSYS.LIB file system. Save Files, a common object type in QSYS.LIB are not fully threadsafe and access by a threaded QZLSFILET connection is not dependable because stream I/O operations to save file data are not allowed when multiple threads are running in a job. For additional information information see the section on Support for save files in the QSYS.LIB file system in the V7R1 IBM Knowledge Center.