Sidebar

The Benefits and Dangers of Adopted Authority

IBM i (OS/400, i5/OS)
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

One of the problems AS/400 administrators face is that of giving users different levels of authority for an object under different circumstances. Consider the following security problems:

o Sue needs to run an inquiry program to retrieve an employee's name and mailing address from the employee master file, but you don't want her to use Query against the file because she might see salary information. You don't want to restrict Sue from running Query, though, because she needs to use Query for other files. How can you let her read the employee master file through the inquiry program without letting her read it through Query? The answer is adopted authority.

o Joe needs to use a file maintenance program to change records in the vendor master file, but you don't want him to use a utility program (such as DFU) to change vendor records. How do you give him *CHANGE authority while he's running the maintenance program, yet give him *USE authority at other times? Again, the answer is adopted authority.

o How can you let help desk personnel change the password of a user who's forgotten his password without giving them access to the Change User Profile (CHGUSRPRF) command? Big surprise-adopted authority is the answer.

o How can you allow system operators to save and restore data to which they are not authorized? Adopted authority to the rescue again.

All of these problems occur because OS/400 will not permit a user to have different levels of authority to an object under different circumstances. A good way to get around this restriction is to let a user temporarily adopt the authority of a program's owner while the program is executing.

Actually, giving a program adopted authority is simple. When you create a program, you specify whether the system should consider only the authority granted to the user who runs the program or the authority of the program's owner as well. You specify this with the User Profile (USRPRF) parameter of the Create xxx Program (CRTxxxPGM) command. USRPRF(*USER), the default, tells the system to check the user's authority only. If you specify USRPRF(*OWNER), the system considers the authority of both the user who is running the program and the owner of the program. When an object uses the owner's authority, it is known as adopted authority.

When a program adopts authority, it inherits the owner's object authorities and special authorities. In general, the user running the program has the owner's authorities as long as the program remains in the invocation stack. (This creates a serious security exposure, which I'll discuss in more detail later.) The exceptions that suspend adopted authority occur when you use the System Request or Attn key, when you execute a group job request, during the execution of a break-message handling program, and during debug operations.

If you recompile a program and specify REPLACE(*YES), the USRPRF and Authority (AUT) parameters will be ignored. The new copy of the program will have the same USRPRF, Use Adopted Authority (USEADPAUT), and AUT values as the replaced program. To allow an existing program to adopt authority, you must either use the Change Program (CHGPGM) command or delete the program object before recompiling.

Let's take a look at how adopted authority can resolve the security problems I presented at the beginning of this article.

In Sue's situation (retrieving an employee's name and address), you tell the system that Sue is not to use the employee master file at all; grant her *EXCLUDE access. Change the inquiry program to adopt the authority of its owner, who should have *USE authority (or greater) to the employee master file. Sue can see the employee's name and address through the inquiry program she uses, but she can't read the file from Query, SQL, or other query tools.

As regards the problem of the vendor master file, you want Joe to be able to read the file and change vendor information only if he does it through the file maintenance program. By giving him *USE authority to the vendor master file, you allow him to read it but not make changes to it. Joe can run programs that read the vendor master, and he can use query packages to retrieve information from the vendor master.

You must also grant him *USE authority to the file maintenance program so he can run it. You give ownership of the file maintenance program to another user who has *CHANGE authority (or higher) to the vendor master file. Change the maintenance program to adopt the owner's authority. Joe runs the program and, since the owner can change the file, Joe gets to change the file. When Joe cranks up DFU to change a vendor's record, however, he is met with a surprise. The system will not let him change the file.

The last two security problems I mentioned earlier are basically solved by creating a program to run the commands the user needs to run and having that program adopt the authority of its owner.

For all its benefits, adopting authority poses some security risks. To take advantage of adopted authority, you must understand and protect against such risks. For example, it is critical that programs that adopt authority do not give users access to a command line.

If you allow a program to adopt authority, you may unintentionally permit a user to do things he shouldn't do. All the user needs is a command line or an appropriate utility to take advantage of the adopted authority. The potential risks multiply if the program adopts the authority of a user who has *JOBCTL or *ALLOBJ authority. Given *JOBCTL authority and a command line, a user can modify any job on the system. A user who inherits *ALLOBJ authority can potentially access any object on the system.

Another risk is that a program that is not meant to adopt authority-that is, it was compiled with USRPRF(*USER)- might use the authority of another program. By default, a program can use the authorities of programs higher in the invocation stack. 1 contains data from an invocation stack. PGMA calls PGMB. It would appear that a user of PGMB has no access to objects to which he is not authorized. Since PGMB inherits the adopted authority from programs higher in the invocation stack, PGMB can run under the authorities of PGMA. PGMB runs under QSECOFR's authority, and Joe has authority to all objects on the system. Again, if PGMB includes a command line or is a utility program, the danger is that Joe has access to do nearly anything.

Another risk is that a program that is not meant to adopt authority-that is, it was compiled with USRPRF(*USER)- might use the authority of another program. By default, a program can use the authorities of programs higher in the invocation stack. Figure 1 contains data from an invocation stack. PGMA calls PGMB. It would appear that a user of PGMB has no access to objects to which he is not authorized. Since PGMB inherits the adopted authority from programs higher in the invocation stack, PGMB can run under the authorities of PGMA. PGMB runs under QSECOFR's authority, and Joe has authority to all objects on the system. Again, if PGMB includes a command line or is a utility program, the danger is that Joe has access to do nearly anything.

One common cause of this type of security breach is the use of CL programs to provide menus. If a CL menu program adopts its owner's authority, everything the user does while that menu is in the stack is a potential security problem. Menu options may include commands that supply a command line, such as Work with Spooled Files (WRKSPLF), Work with Output Queues (WRKOUTQ), and Work with Submitted Jobs (WRKSBMJOB). It is good to prevent the programs called by the CL menu program from using the authority of the CL menu program.

To prevent a program from using the authority of a program higher in the invocation stack, use the CHGPGM command, specifying USEADPAUT(*NO). When you create a program, the default value for the USEADPAUT parameter is *YES. Unfortunately, the USEADPAUT parameter is not available with the CRTxxxPGM commands.

So there are really two ways a program can adopt authority. Compiling the program with the option USRPRF(*OWNER) lets that program adopt authority from the program's owner. A program can also adopt authority from previous programs in the call stack that have adopted authority, unless you change the program with the CHGPGM command, specifying USEADPAUT(*NO).

You can implement security on the AS/400 in different ways. The following recommendations are not the only ways-or necessarily the best ways-to secure your data. They are recommendations for using adopted authority. You won't be able to use all these; pick the ones that apply to your situation.

1. Separate objects into those that don't store data-such as programs, display files, and printer files-and those that do-such as database files and data areas.

Generally, the data objects should specify that *PUBLIC has *EXCLUDE authority to keep unauthorized users out of the files.

The nondata objects should specify that *PUBLIC has *USE authority so users can run these programs. (For more sensitive applications, such as payroll, you might prefer to give *EXCLUDE authority to *PUBLIC.)

By restricting *PUBLIC authority to objects, you set up a default that reduces the possibility that users will have more access to objects than you intend them to. You can give more authority to the users who need it by granting authority to their individual or group profiles.

An excellent way to separate different types of objects is to put them into separate libraries. When you create a library for data objects, specify CRTAUT(*EXCLUDE). When you create a library to hold nondata objects, specify CRTAUT(*USE). These will set the defaults for new objects created in the libraries.

Double-check the objects in your existing libraries. If you did not specify the authority granted to *PUBLIC when you created those objects, they probably have *CHANGE authority, which indirectly comes from the QCRTAUT system value.

2. Keep users menu-bound as much as possible.

If possible, give the users just the options they need. There are commercial programs that build menus dynamically from options stored in a file. You can also create your own or you can use the program described in "Creating OS/400-Style Rolling Menus" (MC, May 1990). This is not a necessity, of course, but in an environment in which programs typically adopt authority, restricting the menu options to just those a user needs is a good idea.

If your dynamic menu program uses a database file to determine what options a user can perform, be sure no one can change the library list, or someone might insert a library with his own database file ahead of yours. The best way to keep someone from changing the library list is to prevent him from using a command line.

3. Specify LMTCPB(*YES) for most user profiles.

Users with LMTCPB(*YES) are not able to enter commands from the command line, even under adopted authority. They also won't be able to press the F4 key to get the Major Command Groups menu. You can set a user profile to LMTCPB(*YES) using the Create User Profile (CRTUSRPRF) or CHGUSRPRF command.

For the commands that you want all users to have access to, specify ALWLMTUSR(*YES) on the Create Command (CRTCMD) or Change Command (CHGCMD) command.

4. Beware of initial programs that adopt authority.

If possible, let a user's initial program come to end of job. That is, don't let the initial program remain in the job stack during the interactive session if it's not necessary.

5. Use native menus rather than CL program menus.

If a user runs a command with a command line-such as the Work with Spooled Files (WRKSPLF) command-from a CL program that adopts authority, he could get into places he doesn't need to be.

6. If you use CL program menus, don't allow them to adopt authority.

After compiling the CL program, run the CHGPGM command, specifying USEADPTAUT(*NO). Add a comment to the CL source to remind you or inform someone else to change the program every time it's compiled.

7. Don't put commands that run file utilities-such as Run Query (RUNQRY) and Start DFU (STRDFU)-directly behind menu options.

Menu options that run file utilities should run them indirectly through CL programs.

Don't let these CL programs adopt authority from the owner or from programs higher in the invocation stack. The users still have access to Query or DFU, but they have to run those programs under their own authority.

8. Try to limit the amount of authority adopted.

Instead of giving ownership of your programs to QSECOFR, set up some dummy "super users" to own programs. Give these user profiles access to just the necessary objects and not to special authorities like *JOBCTL, *SPLCTL, or, heaven forbid, *SECADM and *ALLOBJ. Set the passwords for these super users to *NONE, so no one can sign on under these user IDs.

9. Use the Transfer Control (TFRCTL) command rather than CALL.

There will be circumstances in which you cannot follow this rule, but, in general, it provides a higher level of security. CALL leaves the invoking program in the stack, and programs lower in the stack may be able to adopt authority from it. TFRCTL removes the invoking program from the stack, so its authority cannot be passed along.

10. Process in batch rather than interactively.

Not only is batch processing good for performance, but it is also a good security process as batch jobs do not inherit authority from submitting jobs.

11. Run the Display Programs that Adopt (DSPPGMADP) command periodically.

The DSPPGMADP command displays the objects that adopt the authority of a specific user profile. This command provides you with a good way to check for potential security exposures due to program adoption.

12. Don't depend on a user's ignorance of OS/400 to keep him out of information.

I have been surprised on more than one occasion to learn that a user knew more than I had given him credit for. Besides, you never know who has a friend or relative who programs an AS/400. For example, a one-minute lesson from an AS/400-savvy outsider may be all a user needs to learn to run the RUNQRY command over a file from a command line.

13. Protect the library list or qualify object references with a specific library.

If a hacker knows that PGMA adopts the authority of the security officer and then calls PGMB, he can place a program with the name PGMB in the library list before the library that contains the intended PGMB. Since the adopted authority of PGMA is propagated to called programs, the hacker's version of PGMB will inherit the propagated authority. You can limit this exposure in two ways.

o Qualify all references to programs and commands with a specific library.

o Save the library list on entry to the adopting program, and set the library list as expected. On exit, restore the saved library list.

If you don't like to qualify objects, specifying LMTCPB(*YES) on user profiles will protect the library list. Users with limited command line capability cannot execute commands that change the library list.

14. On programs that adopt, specify LOG(*NO) and ALWRTVSRC(*NO).

This prevents a hacker from determining the program logic and possibly compromising the adopted authority.

Sometimes we get so busy fighting fires and whacking away at the backlog that we neglect security. Granting *PUBLIC a minimal amount of authority to objects by default and granting more authority as needed on an individual basis tightens security and reduces the amount of attention you must give to security issues.

Keep in mind that restricting authority is a way of protecting users, not an expression of a lack of trust in them. By restricting authority, you protect a user in several ways. First, if a user has no way to get to sensitive information, he is less likely to be suspected if sensitive information is leaked. Second, you protect his privacy by locking everyone out of sensitive information about him, such as payroll data. Third, you help him do his job by keeping others out of the data he is responsible for maintaining. Fourth, you prevent the user from accidentally deleting objects. If you communicate these ideas to your users, they are less likely to get perturbed when they must come to you for authorization.

You can secure the data on your system and, at the same time, give users the authority they need-no more, no less-when they need it. Adopting authority is one powerful tool that can help you do that.

Ted Holt is an associate technical editor for Midrange Computing. He can be reached by E-mail at This email address is being protected from spambots. You need JavaScript enabled to view it..

Reference

OS/400 Security?Reference V3R1 (SC41-3302, CD-ROM QBKALC00).


The Benefits and Dangers of Adopted Authority

Figure 1: Partial Invocation Stack in which PGMB Adopts Authority from PGMA

 Program Owner USRPRF USEADPAUT PGMA QSECOFR *OWNER N/A PGMB JOE *USER *YES 
Ted Holt

Ted Holt is IT manager of Manufacturing Systems Development for Day-Brite Capri Omega, a manufacturer of lighting fixtures in Tupelo, Mississippi. He has worked in the information processing industry since 1981 and is the author or co-author of seven books. 


MC Press books written by Ted Holt available now on the MC Press Bookstore.

Complete CL: Fifth Edition Complete CL: Fifth Edition
Become a CL guru and fully leverage the abilities of your system.
List Price $79.95

Now On Sale

Complete CL: Sixth Edition Complete CL: Sixth Edition
Now fully updated! Get the master guide to Control Language programming.
List Price $79.95

Now On Sale

IBM i5/iSeries Primer IBM i5/iSeries Primer
Check out the ultimate resource and “must-have” guide for every professional working with the i5/iSeries.
List Price $99.95

Now On Sale

Qshell for iSeries Qshell for iSeries
Check out this Unix-style shell and utilities command interface for OS/400.
List Price $79.95

Now On Sale

BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

RESOURCE CENTER

  • WHITE PAPERS

  • WEBCAST

  • TRIAL SOFTWARE

  • White Paper: Node.js for Enterprise IBM i Modernization

    SB Profound WP 5539

    If your business is thinking about modernizing your legacy IBM i (also known as AS/400 or iSeries) applications, you will want to read this white paper first!

    Download this paper and learn how Node.js can ensure that you:
    - Modernize on-time and budget - no more lengthy, costly, disruptive app rewrites!
    - Retain your IBM i systems of record
    - Find and hire new development talent
    - Integrate new Node.js applications with your existing RPG, Java, .Net, and PHP apps
    - Extend your IBM i capabilties to include Watson API, Cloud, and Internet of Things


    Read Node.js for Enterprise IBM i Modernization Now!

     

  • Profound Logic Solution Guide

    SB Profound WP 5539More than ever, there is a demand for IT to deliver innovation.
    Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects.
    The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the companyare not aligned with the current IT environment.

    Get your copy of this important guide today!

     

  • 2022 IBM i Marketplace Survey Results

    Fortra2022 marks the eighth edition of the IBM i Marketplace Survey Results. Each year, Fortra captures data on how businesses use the IBM i platform and the IT and cybersecurity initiatives it supports.

    Over the years, this survey has become a true industry benchmark, revealing to readers the trends that are shaping and driving the market and providing insight into what the future may bring for this technology.

  • Brunswick bowls a perfect 300 with LANSA!

    FortraBrunswick is the leader in bowling products, services, and industry expertise for the development and renovation of new and existing bowling centers and mixed-use recreation facilities across the entertainment industry. However, the lifeblood of Brunswick’s capital equipment business was running on a 15-year-old software application written in Visual Basic 6 (VB6) with a SQL Server back-end. The application was at the end of its life and needed to be replaced.
    With the help of Visual LANSA, they found an easy-to-use, long-term platform that enabled their team to collaborate, innovate, and integrate with existing systems and databases within a single platform.
    Read the case study to learn how they achieved success and increased the speed of development by 30% with Visual LANSA.

     

  • Progressive Web Apps: Create a Universal Experience Across All Devices

    LANSAProgressive Web Apps allow you to reach anyone, anywhere, and on any device with a single unified codebase. This means that your applications—regardless of browser, device, or platform—instantly become more reliable and consistent. They are the present and future of application development, and more and more businesses are catching on.
    Download this whitepaper and learn:

    • How PWAs support fast application development and streamline DevOps
    • How to give your business a competitive edge using PWAs
    • What makes progressive web apps so versatile, both online and offline

     

     

  • The Power of Coding in a Low-Code Solution

    LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed.
    Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

    • Discover the benefits of Low-code's quick application creation
    • Understand the differences in model-based and language-based Low-Code platforms
    • Explore the strengths of LANSA's Low-Code Solution to Low-Code’s biggest drawbacks

     

     

  • Why Migrate When You Can Modernize?

    LANSABusiness users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
    In this white paper, you’ll learn how to think of these issues as opportunities rather than problems. We’ll explore motivations to migrate or modernize, their risks and considerations you should be aware of before embarking on a (migration or modernization) project.
    Lastly, we’ll discuss how modernizing IBM i applications with optimized business workflows, integration with other technologies and new mobile and web user interfaces will enable IT – and the business – to experience time-added value and much more.

     

  • UPDATED: Developer Kit: Making a Business Case for Modernization and Beyond

    Profound Logic Software, Inc.Having trouble getting management approval for modernization projects? The problem may be you're not speaking enough "business" to them.

    This Developer Kit provides you study-backed data and a ready-to-use business case template to help get your very next development project approved!

  • What to Do When Your AS/400 Talent Retires

    FortraIT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators is small.

    This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:

    • Why IBM i skills depletion is a top concern
    • How leading organizations are coping
    • Where automation will make the biggest impact

     

  • Node.js on IBM i Webinar Series Pt. 2: Setting Up Your Development Tools

    Profound Logic Software, Inc.Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. In Part 2, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Attend this webinar to learn:

    • Different tools to develop Node.js applications on IBM i
    • Debugging Node.js
    • The basics of Git and tools to help those new to it
    • Using NodeRun.com as a pre-built development environment

     

     

  • Expert Tips for IBM i Security: Beyond the Basics

    SB PowerTech WC GenericIn this session, IBM i security expert Robin Tatam provides a quick recap of IBM i security basics and guides you through some advanced cybersecurity techniques that can help you take data protection to the next level. Robin will cover:

    • Reducing the risk posed by special authorities
    • Establishing object-level security
    • Overseeing user actions and data access

    Don't miss this chance to take your knowledge of IBM i security beyond the basics.

     

     

  • 5 IBM i Security Quick Wins

    SB PowerTech WC GenericIn today’s threat landscape, upper management is laser-focused on cybersecurity. You need to make progress in securing your systems—and make it fast.
    There’s no shortage of actions you could take, but what tactics will actually deliver the results you need? And how can you find a security strategy that fits your budget and time constraints?
    Join top IBM i security expert Robin Tatam as he outlines the five fastest and most impactful changes you can make to strengthen IBM i security this year.
    Your system didn’t become unsecure overnight and you won’t be able to turn it around overnight either. But quick wins are possible with IBM i security, and Robin Tatam will show you how to achieve them.

  • Security Bulletin: Malware Infection Discovered on IBM i Server!

    SB PowerTech WC GenericMalicious programs can bring entire businesses to their knees—and IBM i shops are not immune. It’s critical to grasp the true impact malware can have on IBM i and the network that connects to it. Attend this webinar to gain a thorough understanding of the relationships between:

    • Viruses, native objects, and the integrated file system (IFS)
    • Power Systems and Windows-based viruses and malware
    • PC-based anti-virus scanning versus native IBM i scanning

    There are a number of ways you can minimize your exposure to viruses. IBM i security expert Sandi Moore explains the facts, including how to ensure you're fully protected and compliant with regulations such as PCI.

     

     

  • Encryption on IBM i Simplified

    SB PowerTech WC GenericDB2 Field Procedures (FieldProcs) were introduced in IBM i 7.1 and have greatly simplified encryption, often without requiring any application changes. Now you can quickly encrypt sensitive data on the IBM i including PII, PCI, PHI data in your physical files and tables.
    Watch this webinar to learn how you can quickly implement encryption on the IBM i. During the webinar, security expert Robin Tatam will show you how to:

    • Use Field Procedures to automate encryption and decryption
    • Restrict and mask field level access by user or group
    • Meet compliance requirements with effective key management and audit trails

     

  • Lessons Learned from IBM i Cyber Attacks

    SB PowerTech WC GenericDespite the many options IBM has provided to protect your systems and data, many organizations still struggle to apply appropriate security controls.
    In this webinar, you'll get insight into how the criminals accessed these systems, the fallout from these attacks, and how the incidents could have been avoided by following security best practices.

    • Learn which security gaps cyber criminals love most
    • Find out how other IBM i organizations have fallen victim
    • Get the details on policies and processes you can implement to protect your organization, even when staff works from home

    You will learn the steps you can take to avoid the mistakes made in these examples, as well as other inadequate and misconfigured settings that put businesses at risk.

     

     

  • The Power of Coding in a Low-Code Solution

    SB PowerTech WC GenericWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed.
    Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

    • Discover the benefits of Low-code's quick application creation
    • Understand the differences in model-based and language-based Low-Code platforms
    • Explore the strengths of LANSA's Low-Code Solution to Low-Code’s biggest drawbacks

     

     

  • Node Webinar Series Pt. 1: The World of Node.js on IBM i

    SB Profound WC GenericHave you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.
    Part 1 will teach you what Node.js is, why it's a great option for IBM i shops, and how to take advantage of the ecosystem surrounding Node.
    In addition to background information, our Director of Product Development Scott Klement will demonstrate applications that take advantage of the Node Package Manager (npm).
    Watch Now.

  • The Biggest Mistakes in IBM i Security

    SB Profound WC Generic The Biggest Mistakes in IBM i Security
    Here’s the harsh reality: cybersecurity pros have to get their jobs right every single day, while an attacker only has to succeed once to do incredible damage.
    Whether that’s thousands of exposed records, millions of dollars in fines and legal fees, or diminished share value, it’s easy to judge organizations that fall victim. IBM i enjoys an enviable reputation for security, but no system is impervious to mistakes.
    Join this webinar to learn about the biggest errors made when securing a Power Systems server.
    This knowledge is critical for ensuring integrity of your application data and preventing you from becoming the next Equifax. It’s also essential for complying with all formal regulations, including SOX, PCI, GDPR, and HIPAA
    Watch Now.

  • Comply in 5! Well, actually UNDER 5 minutes!!

    SB CYBRA PPL 5382

    TRY the one package that solves all your document design and printing challenges on all your platforms.

    Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product.

    Request your trial now!

  • Backup and Recovery on IBM i: Your Strategy for the Unexpected

    FortraRobot automates the routine tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
    - Simplified backup procedures
    - Easy data encryption
    - Save media management
    - Guided restoration
    - Seamless product integration
    Make sure your data survives when catastrophe hits. Try the Robot Backup and Recovery Solution FREE for 30 days.

  • Manage IBM i Messages by Exception with Robot

    SB HelpSystems SC 5413Managing messages on your IBM i can be more than a full-time job if you have to do it manually. How can you be sure you won’t miss important system events?
    Automate your message center with the Robot Message Management Solution. Key features include:
    - Automated message management
    - Tailored notifications and automatic escalation
    - System-wide control of your IBM i partitions
    - Two-way system notifications from your mobile device
    - Seamless product integration
    Try the Robot Message Management Solution FREE for 30 days.

  • Easiest Way to Save Money? Stop Printing IBM i Reports

    FortraRobot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing.
    Manage your reports with the Robot Report Management Solution. Key features include:

    - Automated report distribution
    - View online without delay
    - Browser interface to make notes
    - Custom retention capabilities
    - Seamless product integration
    Rerun another report? Never again. Try the Robot Report Management Solution FREE for 30 days.

  • Hassle-Free IBM i Operations around the Clock

    SB HelpSystems SC 5413For over 30 years, Robot has been a leader in systems management for IBM i.
    Manage your job schedule with the Robot Job Scheduling Solution. Key features include:
    - Automated batch, interactive, and cross-platform scheduling
    - Event-driven dependency processing
    - Centralized monitoring and reporting
    - Audit log and ready-to-use reports
    - Seamless product integration
    Scale your software, not your staff. Try the Robot Job Scheduling Solution FREE for 30 days.