Midrange Programmer

In my last article, I shared with you my concern about help-desk associates spending too much time resetting terminal sessions on the AS/400 and, subsequently, not enough time working on more important issues. I then showed you a solution that I created, called active session notification, which enables me to keep track of the number of active sessions per user. This is the first step toward not only aiding the help-desk associates but also empowering users. In this article, I will demonstrate my method that allows users to systematically reset their own sessions.

There are many reasons why help-desk associates spent so much time resetting interactive sessions. Things like communication drops, user errors, and applications malfunctions all contributed to the help desk crew spending less time on critical issues. This had to stop.

In the old environment, users were using Wall Data's Rumba product to access the AS/400. The "hung" terminal problem was something that happened quite frequently. The help desk was always called to reset the old, inactive session so that the user could sign on again. I wanted to remove this responsibility from the help desk associate and place it back on the user. To accomplish this, I borrowed some code that IBM developed, and, with a little creativity, I made my own active session notification program. In my first article, I explained the portion of the code that collected the pertinent information and kept track of the number of active sessions per user. In this article, I'll give you the rest of the solution. However, before I show you the rest of the code, let's take a look at the new process, specifically at how the user will be able to control his own destiny, so to speak.

For the sake of this discussion, assume that a user has a forgotten session, or job, on the AS/400; possibly another Rumba session is open. Use the WRKUSRJOB command to display the Work with User Jobs screen.

Now that I know there are multiple sessions active, I need to act on them. I need to inform the user that a problem exists; that is, I want to give him a warning screen indicating that the system recognizes he has interactive jobs active on the system.

Upon seeing the Confirm Active Session screen, the user will be able to do either of the following:

Next, we will look at the CL and RPG code that allows users to fix their multiple-session problem.

The CL program, CHKUSRJOBS, determines whether a user who is signing on to the system already has an active interactive job. To allow the user to fix a multiple-session problem, I needed the fully qualified job information for all active jobs. Once I have that information, I can give the user a systematic way to end the desired session. A call to the RPG program gets me the information I need.

Keep in mind that I'm not an RPG programmer. I can spell it, and that's about it. Seriously, with the help of some my RPG IT peers, I was able generate some simple code to retrieve the fully qualified job names for all active jobs.

The RPG code processes through in USRJOBS input file and builds the parameters that will be passed back to the CL program. Notice that only job 1's parms were built in our example. It's important to note that three jobs can actually exist. That's because of the way group jobs are listed on the system; that is, group jobs are listed under one job name but are indeed two separate interactive sessions. See Figure 1 and note the unique job numbers.

In Figure 1, notice that L024DOUG has three unique jobs on the system. In my example, I allow group jobs to be present in my environment. As a result, I can have a total of three jobs on the system, which is why the CL CHKUSRJOBS has three sets of qualified job parameters.

I now have all the data I need to end the user's obsolete jobs. Now it's time to send the warning screen to the user, so he can decide which session to end.

In Figure 3, the current job (second sign-on attempt) is compared with the first parameter returned. If they are equal, it means the session I am trying to end is either job 2 or job 3 in the input file. The monitor message command is to see if the job is still active on the system at the time I am trying to end it. Notice that I am ending the job with an *IMMEDIATE option.

Sometimes I have a system user or a certain type of customer that is allowed to have multiple interactive sessions. As a result, I can add code to bypass the end-job process. To do that, I simply enter the CL code in Figure 4 before the section of code that does the end job function. The code can be positioned just after the RPG call that collects all the qualified job data.

In my first article, I presented an idea that I deemed as kind of "out there." Suggesting that my users reset their own stuck AS/400 sessions seemed like I was asking the help-desk associates not to do their jobs anymore. Well, in a way, that's exactly what I wanted. No, I am not trying to eliminate help-desk personnel, but by implementing my active session notification environment, I enable the help-desk associates to be more productive. By putting the onus on the users to reset their own terminals, I help to create an environment that allows our help desk to work on issues that are more critical to the health of the systems. While I was not giving official dollar savings at my company, I was told that the annual savings was in the neighborhood of $60,000 a year. At a time when companies are under constant scrutiny to cut and control costs, successfully implementing this environment will not only make your help-desk folks happy, but the CFO will call you a hero.

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.