A client application sometimes "freezes" or begins responding very slowly. You may need to look at the IBM i side of the application. But can you can find it? This tip helps you track down the IBM i server job.
For the purposes of this discussion, a client application is a "program" that isn't running on the IBM i host, but is connecting to it using JDBC, or ODBC, or JT/400, or FTP, or TCP/IP, or some other communications technique. A client application might be the Rational Developer for i (RDi) IDE. It might be one of the free SQL clients like SQuirreL or SQL Workbench/J. It might be an FTP client. It might be a .NET application. Or something else entirely.
Server Job Documentation
IBM documents the characteristics of server jobs in the IBM Knowledge Center in a section named "Server table." It includes the job name, the subsystem the job runs in, the job description used, and some other info. I don't claim knowledge of all the server jobs documented here, but the table is fairly useful. Here is a link to the IBM i 7,2 Server table. Hopefully, this link will continue to work, but if not, try a Google search for 'site:ibm.com "server table" "server jobs" -SQL -.PDF'. (Curiously, when I searched with Bing, it found the IBM i 7.1 Server table.)
Server Job Overview
This is a conceptual overview, and there are other technical nuances in the process that I'm not covering here.
A client application connecting to an IBM i is handled by an IBM i "Server Job." Server jobs are started automatically by the OS and have job names that start with Q, e.g., QZDASOINIT.
The jobs run in various subsystems, but many are found in the QUSRWRK subsystem, and that's where most people look, but there may be dozens, or hundreds, of server jobs with the same job name. See Figure 1 below.
Figure 1: Many identically named server jobs run in the QUSRWRK subsystem.
Most of the server jobs you would want to look at are "prestart" jobs, type PJ. These jobs start when the subsystem starts and typically run under the QUSER user profile. Server jobs mostly just "hang around" doing nothing, waiting for the OS to wake them up when a client application needs to connect. Then the OS selects a waiting server job, swaps the user profile of the job to the user profile of the client, and connects the client to the server job. When the connection ends, the user profile is swapped back to QUSER and the server job goes back to "hanging around."
Quickly Find Your Server Job
Client applications need to provide a user profile and a password to make a connection. Generally, that user profile is yours.
You might think that issuing WRKUSRJOB (Work with User Jobs) from a green-screen command line would show your server jobs. It doesn't. It shows only *BATCH and *INTERACT job types.
If you're looking at jobs in the QUSRWRK subsystem, you can do 5=Work with, then do 1. Display job status attributes on each job until you find one where the Current user profile is yours. But this is tedious and can be hit or miss.
However, when your server job is running, it has been swapped from running under an IBM profile to running under your profile, so the server job has a shared read (*SHRRD) lock on your user profile object. There are not many things that have locks on a user profile—I can't remember ever having seen anything other than a job having such a lock—so you can use this to help isolate which of the many service jobs you need to look at.
WRKOBJLCK OBJ(userprofile) OBJTYPE(*USRPRF)
If you're signed on to a single 5250 session and you have no client applications running or batch jobs running, you will probably see that two jobs have locks, as in Figure 2:
Figure 2: Here's an example of User Profile locks with a single 5250 session.
The first job above, LENNONSA1, is the interactive 5250 session. The second, QZSCSRVS, is a server job. In the Server table, its name is Central Server, and I believe this is where licenses are checked. Depending on the 5250 emulator you're using, you may not see this job.
If you start SQL Workbench/J (which uses JDBC) and connect, you will now see a QZDASOINIT job, as in Figure 3:
Figure 3: You can see a QZDASOINIT job from an SQL Client Connection.
You can do 5=Work with job against the QZDASOINIT job, then 1. Display job status attributes to confirm that the Current user profile is yours.
And you have very quickly found the Server job you need to look at!
You can investigate as you see fit with the options available on the 5=Work with job display, or start a service job and run the debugger, or some other suitable technique.
Above, I've given you a simple example with just a single 5250 emulation session and a single connection from a client application. In practice, it may be a little more complex. A client may make multiple connections. SQL Workbench/J, for example, can have multiple windows open, and each one has a separate connection, so you may need to investigate more than one QZDASOINIT job. And in Rational Developer for i, you'll find that the RSE perspective has at least two server jobs, QPWFSERVSO and QZRCSRVS. Other parts of the product, or plugins, may open additional connections. However, using WRKOBJLCK is still easier than looking at all the server jobs that are running.
If a server job is impacting the system and you can't get control from the client end, is it safe to end the server job? If it's a prestart job, (1. Display job status attributes and Type of job is PJ), then it's safe to end it, because 1) it's your job and 2) the OS will take care of starting a new PJ job if needed. If you want to end the server job immediately, and you probably do, remember that 41. End job in Work with Job allows you to specify OPTION(*IMMED). Obviously, killing your server job may do bad things to your client application.
I've assumed the client application is connecting using your user profile. If you're trying to solve a problem for someone else, substitute their user profile.
It can be hard to find the server job for a client application, but using WRKOBJLCK and checking the locks on a user profile can make it much easier.