Did Your User Leave an Open Job Unattended AGAIN? PDF Print E-mail
Security - IBM i (OS/400, i5/OS)
Written by Steve Pitcher   
Wednesday, 01 September 2010 00:00

Support MC Press - Visit Our Sponsors

Forums Sponsor

POPULAR FORUMS

Forums

Search Sponsor

Search

With QINACTITV and QINACTMSG, you can manage interactive jobs when your users are out to lunch…literally.

 

In my shop, we have some users who key data all day long and others who enter data once every hour or maybe even longer. The amount of time you allow an inactive job to run is not an industry standard; what you choose must fit your business.

 

Inactive interactive jobs can mean trouble. For security purposes, an interactive job left unattended allows shady employees in your organization (yes, you may have one or more) or even the delivery guy making his rounds to take control of a session in the physical absence of the rightfully signed-on user.

 

Depending on your environment and the security policy you've defined—because, of course, we all have a policy, right?—your company may not care too much about 5250 screens left open for anybody to hijack as they pass by. Plus, you may have other means of locking down user interfaces (i.e., Windows may lock the computer after a time limit but the Client Access session is still ready for user input). If so, locking down interactive jobs may seem like overkill.

 

A more practical and likely problem may involve a user updating a record in a widely used application and then going for a coffee or lunch break right in the middle of it, all the while inhibiting other users from updating that record.

 

There are a number system values that can help you with controlling interactive jobs once they've been abandoned.

 

The QINACTITV system value specifies how many minutes a job is allowed to remain inactive, while the QINACTMSGQ system value controls what action to take once the QINACTIV threshold has been reached.

 

The shipped value of QINACTITV is *NONE, which means that interactive jobs may remain idle until they are ended. You can set the value to anywhere between 5 and 300 minutes.

 

QINACTMSGQ is a little bit of a misnomer. It specifies the actions taken by the system, and only one of these actions involves writing a message to a message queue, so let's cover that first. You specify the message queue/library, and if the QINACTITV limit is reached, then a message with ID CPI1126 is sent to that queue. From there, you can monitor for that message and take whatever customized action you wish.

 

Your other options are *ENDJOB, which ends the job, or *DSCJOB, which disconnects the job. If you disconnect the job, the job remains in a disconnected state, but the abandoned 5250 session displays a sign-on screen and allows a user to log back on and resume the job. Beware: any disconnected jobs will retain record or file locks that it had before it was disconnected.

 

Also, you should take a look at the system value QDSCJOBITV, which sets the time limit on how long a disconnected job will remain in that state until it is ended. Ideally, you should set a value for this (between 5 and 1440 minutes). The default is 240 minutes, but you should customize it to what your environment requires. You can actually set a value for *NONE, which will keep disconnected jobs on the system until the subsystem ends or the next IPL.

 

Disconnecting jobs that are inactive without ending them automatically means that they will stay alive on the system until they are ended manually. In order to manually end these jobs, you'll have to check your active jobs list (i.e., WRKACTJOB, another misnomer), including jobs in a disconnected (DSC) state, and then end them. Here's a fun fact: having a disconnected job in the controlling subsystem will actually prevent you from putting the system in a restricted state with your active job! This is an extreme example of the pain a disconnected job can cause, but in my opinion, if you don't need disconnected jobs, then don't use them, or at least put a limit on them.

 


Steve Pitcher
About the Author:

Steve Pitcher is the Enterprise Systems Manager for Scotsburn Dairy Group in Nova Scotia, Canada, and is a specialist in IBM i and IBM Lotus Domino solutions since 2001. Visit Steve's Website, follow his Twitter account, or contact him directly at stevepitcher@scotsburn.com.

Read More >>
Last Updated on Wednesday, 01 September 2010 00:00
 
User Rating: / 2
PoorBest 
   MC-STORE.COM