The Four Hundred

One of the best things about the Admin Alert column is that I learn as much from the readers as you, hopefully, learn from me. Several readers have written in recent weeks to add to or correct some of the information I've presented. Here are a few of the more recent gems about inactive jobs and QSTRUP job logs that come straight from my e-mail inbox. My responses follow each e-mail.

After reading "Dealing with Inactive Jobs," I thought it would be a good idea to mention that the TCP Keep Alive parameter (TCPKEEPALV), in the Change TCP/IP Attributes (CHGTCPA) command, could keep interactive jobs from ending if it is set too low. In our shop, the inactivity time-out system value (QINACTITV) was set at 160 minutes, while the TCPKEEPALV parameter was set at 120 minutes. This kept our inactive terminal sessions out there and alive, so that the system never took action on inactive jobs.

It's important to keep in mind that TCPKEEPALV has a different function from QINACTITV. TCPKEEPALV is concerned with checking whether a connection--not necessarily a terminal session--is active, by sending out TCP probes after x number of minutes, in order to keep it alive. QINACTITV is a timer that prompts OS/400 to take action when an interactive job has been sitting idle for too long. These two settings may conflict with each other. For instance, TCPKEEPALV may keep jobs active that you would rather have end or be disconnected from the system, so you should consider the proper values to set each parameter to.

There's another OS/400 setting that you should look into for ensuring that active Telnet sessions are still communicating with their target iSeries or AS/400 server. The Session Keep Alive Timeout (TIMMRKTIMO) parameter can be found inside the Change Telnet Attributes command. (Type CHGTELNA and press F4.) OS/400 uses TIMMRKTIMO to schedule periodic checks for lost Telnet connections and to end the Telnet connection if it doesn't respond to a TCP probe. It's important to note that the TIMMRKTIMO parameter is entered in seconds, instead of minutes, as OS/400 uses in the QINACTITV and TCPKEEPALV settings. So if you wanted to check for dropped Telnet connections every two minutes, you could set TIMMRKTIMO to 120 seconds by using the following CHGTELNA command:

The default value for TIMMRKTIMO is 600 seconds (or 10 minutes). You can also set TIMMRKTIMO to *CALC, which checks Telnet sessions based on a calculated frequency of sampling value. In addition, you can set TIMMRKTIMO to a specific numeric value.

As a follow-up to last week's story, I've reexamined how QINACTITV and the inactivity message queue (QINACTMSGQ) system value work together when used with Telnet sessions. This week I found instances on three different V4R5 AS/400s where QINACTMSGQ was set to disconnect jobs (*DSCJOB) that exceeded the QINACTITV timer value. However, instead of disconnecting the jobs, OS/400 ended the jobs, leaving the following sequence of messages in the ended device's job log.

These two messages indicate that QINACTMSGQ processing may behave differently for Telnet jobs, and you may not be able to specify *DSCJOB if you're trying to manage inactive Telnet jobs (such as those you create in the PC5250 program that comes with Client Access Express for Windows). It looks as if QINACTMSGQ disconnection processing may not work on 5250 sessions that are activated through the OS/400 Telnet server. As a result, the only viable actions you may be able to set QINACTMSGQ to for Telnet sessions would be to end the job (*ENDJOB) or to send a notification message to a specific OS/400 message queue.

I don't have the definitive word on this from IBM, only what I saw and deduced from trouble-shooting these systems. So be careful when you're setting up inactive-job processing for a system where the majority of users sign on through Telnet server client jobs. This restriction may be in force. If any sharp-eyed reader can provide more information on this issue, please feel free to e-mail me at jhertvik@itjungle.com.

Here are two e-mails I received about my suggestion that readers can find their start-up program (QSTRUPJD) job log by using the Work with User Jobs (WRKUSRJOB) command for the QPGMR user profile, as follows:

In the article, I said that, after running this command, you should page through all the QPGMR jobs that WRKJOB provides, looking for the most recent QSTRUPJD job. While that works when QSTRUPJD is run under QPGMR, several readers pointed out the flaws in this technique.

Just a quick thought. The following Work with Job (WRKJOB) command is a better way to find your start-up job's log, especially if you run QSTRUPJD under another user profile (in our case, QPGMR didn't have enough authority to do the things we wanted it to do):

I like searching for jobs by the job name, if known. In this case, I'd use the WRKJOB command, like this:

Using WRKJOB is not only an easier solution, it also takes care of start-up programs that don't run under the QPGMR user profile. I stand corrected, and I even started using WRKJOB to locate other OS/400 jobs I could never find before. So thanks for writing, guys. And keep those e-mails coming.