Midrange Programmer

Last year I passed our help desk area on the way back from a meeting and heard two coworkers talking about a problem they were working on. Apparently, users were getting stuck in an application and the help desk was getting flooded with calls to reset terminals. Seeing the obvious frustration and wanting to help, I asked for a little history on the problem. Apparently, the "hung" terminal problem was something that happened frequently. So I decided to research this problem further.

Sometimes the problem was that users had opened multiple rumba sessions because they had forgotten about the original session. They would then see a screen indicating that an original session ended in error and that a subsequent sign-on request was attempted. In any event, the result was that the help desk was always called. In fact, when I asked the help desk manager about the frequency, I was shocked to learn that terminal resets represented 15 percent of all help desk calls!

However, after talking with the support folks who did months of research, I learned there were many things that caused the stuck terminals, such as user error, communication drops, or--dare we say it--application problems. Wall Data was called. IBM was called. Traces were done. And no one could figure out a solution. In the end, my company just learned to live with the problem.

The story could end here. After all, my support guys wrote a slick CL that enabled the help desk folks to easily reset the terminals. I walked back to my desk and started to think outside the box. I hate that term. But seriously, I did try to look at the problem a little differently. Since the vendors couldn't fix the problem and the help desk was getting frustrated with calls, I came up with an idea that was kind of out there: Why not let the users reset their own terminals?

My own support guys fell out of their chairs. "You can't do that," they said. "You can't give the field that kind of authority. How would they know when they had a stuck session? Better yet, if they had a stuck session, how could they fix it?"

All great questions. My support guys were absolutely right. You can't give the field God-like authority. Betty in Denver is not going to have the expertise to fix the problem. So we are back to square one, right? Wrong! The solution is simple. This time, it's in the box (sorry).

I told you it was out there, but believe it or not, the process works like a charm. The process is called Active Session Notification.

The assumption in our environment is that we don't allow users to sign on to multiple sessions. That is, we limit device sessions via the QLMTDEVSSN system value.

We still want to limit the number of active sessions for many of our users, but we decided to relieve the AS/400 of its duty to spit out the CPF1220 message whenever a user was attempting, accidentally or not, to start a second session. Our new Active Session Notification does this.

When the AS/400 is managing the number of sessions via the QLMTDEVSSN system value, users will always get the CPF1220 error message when their original interactive job is still active on the system and they try to start another session. So the first step is to change this system value to '0' – Do Not Limit. This will allow an individual user to have multiple sessions active at once. Only then will we be able to start our new interactive session interrogation process.

It's important to note that our active session notification solution still allows for multiple interactive sessions. So our new process will work at shops that allow users to have numerous interactive sessions. For example, my company has an environment where certain customers are only allowed to have one active session. But certain users, such as systems support personnel, are allowed to have multiple active sessions. This new process will handle both scenarios.

I didn't want to reinvent the wheel, and I was hoping that IBM had already seen this dilemma. I was thrilled to learn that IBM indeed had a generic program that keeps track of active sessions. The purpose of the program was to see if users were trying to access more sessions than they were entitled to. IBM uses the generic program to sign people off when they already have a previous active session. Since our plan is to merely examine the current environment and act on it, we will use the portion of the program that counts the sessions. Keep in mind that IBM won't guarantee the code, but it seems to work fine in our environment. Still you must test, test, test before you implement in production. Now let's look at some code.

The new process is started using the CL program CHKUSRJOBS. It is called via an initial start up program that is defined in a user's profile. Each user who signs on will need to execute this program during the sign-on process. The program call is one line of code placed at the beginning of your company's initial start up program. The new program is called with a parameter, which dictates how many sessions are allowed. In our environment, we will pass a variable of 1, since we are allowing only one active session. Here's an example of the program call:

Notice that the parameter being passed is a hexadecimal representation of the number of sessions allowed. In this case, we are allowing one session.

IBM provided the original CL program, called Q$$CHKSES. As I said before, the purpose of this code is to check the number of interactive sessions for a specified user. If the user has more sessions active than the value specified in his start up program, he was sent a break message notifying him that he needed to sign off. This logic doesn't help us, as we want to continue processing. We are going to simply extract the necessary code needed to count the number of interactive sessions. Here is the first section of IBM code that is necessary to count the active sessions.

First, a user space is created, via the QUSCRTUS API. Next, the current job name is retrieved. Finally, an IBM list job API is called. It's important to note that being proficient in APIs is not a requirement for this program to work. For those new to APIs, just understand that this process is returning the needed information that will allow you to interrogate the session. There is another IBM API that will retrieve the pertinent session data.

In the first section, you will see that a second API (retrieve user space) is called. This is the key one, because it retrieves the number of interactive sessions in the &COUNT variable. The next section shows the code that we have modified. Instead of signing the user off at this point, we will go to the CHECKNUM label. The following section is where we compare the number of active sessions that the API retrieved (&NUMENT) with the &MAX variable (the number of active sessions allowed). The next section shows the two possibilities.

If the user is signing on for the first time, &NUMENT will always equal the number of sessions allowed (1). At this point, we know we don't have our multiple active session problem. So we will simply exit the Active Session Notification program and continue the initial program start up.

The other scenario is when the user is indeed signing on a second time. If the user has two sessions active (an original session and a subsequent sign-on attempt), &NUMENT will never be less than or equal to the number of sessions that are allowed (2 Active > 1 allowed). As a result, we know we have a multiple active session.

When we first started, we learned that the help desk handles many calls where a terminal reset is necessary. My guess is that your environment has the same issue. Thanks to some creativity, we can now change the start up process to interrogate the system and let us know when our users have a potential "hung" interactive sessions on the system. In my next article, I will demonstrate how users can systematically fix the problem themselves, so your help desk will be able to concentrate on more pressing issues that deserve immediate attention. And Betty in Denver will feel like a genius.

Doug Mewmaw is an 18 year "jack of all trades" IT veteran. He works at Boise Office Solutions, a business-to-business catalog order company dealing in office products, located in Itasca, Illinois. Doug has been in IT since 1983 and lives in Illinois with his beautiful wife and five children. While his kids think he's obsessed with golf, Doug contends that he is merely a passionate golfer. He can be reached by e-mail at golferdad75@aol.com.