Prevent Access to System Request Menu

by Shannon O'Donnell

The code for this article is available for download.

I was looking over the back issues of Four Hundred Guru recently and came across a tip by Ted Holt on preventing access to the System Request Menu. In that tip, a reader asked how to prevent his users from gaining access to the System Request Menu and inadvertently logging off the system before his cleanup code executed. Ted's response was to monitor for the system message ID CPF1907, which is fired when the user attempts to bring up the System Request Menu. I have another solution that might appeal to you instead.

A Bulletproof Solution

I use the System Exit Point QIBM_QWT_SYSREQPGMS, which is the Presystem Request Program exit point. When you attach a program to this exit point, it will be called every time the user attempts to access the System Request menu, which makes it a fairly bulletproof way to ensure that you trap all access to the System Request menu without having to rely on application programs. Although the application program solution advocated by Ted is fine, when you fall back on programming to control system-type functions the potential for problems is always there. For example, you may have a program that needs to block access to the System Request menu but you may have forgotten to add that program to the user's job, or perhaps you forgot to add the correct library to the library list so when the user attempts to call that program, they get errors. I like to use exit points whenever possible to control things like this because then OS/400 is responsible for ensuring that my user written program is called.

The RPG IV program we will add to this exit point will automatically disallow access to the System Request menu for whatever users you specify. It does this by setting an input/output parameter to zero.

Here's all the code you will need for you user written exit program:

 D SysReqDsp         S                       10i 0                         
 D SysUsrDta          S                     128a                           
                                                               
  *============================================================
 C     *Entry        Plist                                     
 C                       Parm                    SysReqDsp         
 C                       Parm                    SysUsrDta         
  *                                                            
 C                       Eval         SysReqDsp = 0                   
  *                                                            
 C                       Eval        *Inlr = *On                     

That's it. There is nothing more you need to do once you have this all set up, which is saying quite a bit considering that most exit point programs have terribly complex parameter and data structures that are hard to decipher and use.

In the above code, the only variable you have to worry about is the SysReqDsp parameter which, as previously mentioned, be set to zero.

Using the Exit Point Program

To use this exit program, you will need to do two things. First, compile the above code to whatever program name you like and then attach it to the QIBM_QWT_SYSREQPGMS Exit Point using the Work With Registration Information (WRKREGINF) command.

The second thing you'll need to do is to call another API, QWTSETPX (Set Profile Exit Programs), which will change the user profile(s) to call your new exit program.

You will need to explicitly set each user profile to use the new exit program because if you don't, the user profile will not look for that exit program. Don't ask me why this works this way. I didn't create the exit points, I just use them.

Killing Two Birds

The nice thing about using the combination of the QIBM_QWT_SYSREQPGMS and the QWTSETPX API is that you can kill two birds with one stone. In this case, you can control access to not only the System Request menu but all to the users ability to call the Attention Key menu, even when it's a user-defined custom program. This adds another layer of security to prevent your users from doing something you do not want them to do.

To use the QWTSETPX API, you will pass to it the following data:

Number of Entries: This is the number of Exit Program Flags (see next) you will pass for program in question.

Exit Program Flags: This parameter controls whether or not the exit program identified in the next parameter will be called or not. The valid values are:

• 0 -- No, do not call this exit program
• 1 -- Yes, call this exit program
• -1 -- Do not change the value

Format: This is the exit program you want the user profile to know about in the previous parameter. The valid values are:

• ATTN0100 -- This controls the Attention Program
• SREQ0100 -- This control the System Request Menu

User ID: This is the user profile you wish to set the exit program for.

Error Code: This is the standard API Error Data Structure.

Once again, the RPG IV code you need to use this API is surprisingly simple. The relevant portion of that code is shown here:

c                   callp     SetProfExt(1:1:'SREQ0100':ToUser:ErrDS) 
c                   callp     SetProfExt(1:1:'ATTN0100':ToUser:ErrDS)

Granular Control Over User Profiles

Call this program for every user profile on you system that you do not want to allow access to the System Request Menu and/or the Attention Key menu. You could even set up a procedure whereby you call this program any time you set up or change a user profile on your system. In fact, a great way to ensure that you call this program every time is to add an exit program to the Change User Profile and Create User Profile (QIBM_QSY_CHG_PROFILE and QIBM_QSY_CRT_PROFILE) Exit Points. We will explore how to use those APIs in a future issue of Four Hundred Guru.

RELATED ARTICLE

Monitoring for System Request Menu Option 2