• The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
Menu
  • The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
  • Prevent Access to System Request Menu

    May 18, 2005 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)
    

    Because I want to control access to both the System Request Menu and the Attention Key Menu, I call the QWTSETPX API twice, passing the appropriate Format name each time.

    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

    Share this:

    • Reddit
    • Facebook
    • LinkedIn
    • Twitter
    • Email

    Tags:

    Sponsored by
    WorksRight Software

    Do you need area code information?
    Do you need ZIP Code information?
    Do you need ZIP+4 information?
    Do you need city name information?
    Do you need county information?
    Do you need a nearest dealer locator system?

    We can HELP! We have affordable AS/400 software and data to do all of the above. Whether you need a simple city name retrieval system or a sophisticated CASS postal coding system, we have it for you!

    The ZIP/CITY system is based on 5-digit ZIP Codes. You can retrieve city names, state names, county names, area codes, time zones, latitude, longitude, and more just by knowing the ZIP Code. We supply information on all the latest area code changes. A nearest dealer locator function is also included. ZIP/CITY includes software, data, monthly updates, and unlimited support. The cost is $495 per year.

    PER/ZIP4 is a sophisticated CASS certified postal coding system for assigning ZIP Codes, ZIP+4, carrier route, and delivery point codes. PER/ZIP4 also provides county names and FIPS codes. PER/ZIP4 can be used interactively, in batch, and with callable programs. PER/ZIP4 includes software, data, monthly updates, and unlimited support. The cost is $3,900 for the first year, and $1,950 for renewal.

    Just call us and we’ll arrange for 30 days FREE use of either ZIP/CITY or PER/ZIP4.

    WorksRight Software, Inc.
    Phone: 601-856-8337
    Fax: 601-856-9432
    Email: software@worksright.com
    Website: www.worksright.com

    Share this:

    • Reddit
    • Facebook
    • LinkedIn
    • Twitter
    • Email

    Expand Simplifies Network Device Management AppWorx Brings Job Scheduler to OS/400

    Leave a Reply Cancel reply

Volume 5, Number 20 -- May 18, 2005
THIS ISSUE
SPONSORED BY:

WorksRight Software
Profound Logic Software
Guild Companies

Table of Contents

  • Prevent Access to System Request Menu
  • Use SQL to Send Database Files via FTP
  • Admin Alert: Configuring an i5/OS-based EIM Table for Single Sign-On

Content archive

  • The Four Hundred
  • Four Hundred Stuff
  • Four Hundred Guru

Recent Posts

  • Power Systems Grows Nicely In Q3, Looks To Grow For All 2025, Too
  • Beta Of MCP Server Opens Up IBM i For Agentic AI
  • Sundry IBM i And Power Stack Announcements For Your Consideration
  • Please Take The IBM i Marketplace Survey
  • IBM i PTF Guide, Volume 27, Number 43
  • IBM Pulls The Curtain Back A Smidge On Project Bob
  • IBM Just Killed Merlin. Here’s Why
  • Guru: Playing Sounds From An RPG Program
  • A Bit More Insight Into IBM’s “Spyre” AI Accelerator For Power
  • IBM i PTF Guide, Volume 27, Number 42

Subscribe

To get news from IT Jungle sent to your inbox every week, subscribe to our newsletter.

Pages

  • About Us
  • Contact
  • Contributors
  • Four Hundred Monitor
  • IBM i PTF Guide
  • Media Kit
  • Subscribe

Search

Copyright © 2025 IT Jungle