The API Corner: Automating Recovery, Part III

  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

Detect errors when using the API system.


In last month's column, "Automating Recovery, Part II," we looked at the Process Commands (QCAPCMD) API and the flexibility the API provides for determining just what went wrong when attempting to run a CL command and the command fails for one reason or another. In this article, we will look at what's available with the API system when it comes to determining what went wrong when a CL command fails in the middle of our RPG application and attempting to recover from the error situation.

But First…

Before we do that, though, I would like to briefly return to the QCAPCMD API. In response to last month's article, Loek M. sent me a note regarding the QCAPCMD API and a problem that was encountered during application development—namely, that the QCAPCMD API is provided with a public authority of *EXCLUDE. This surprised me as a quick check on several systems showed the public authority as *USE (and I never change the public authority of IBM commands or APIs on my systems), but a check of the IBM Information Center did indicate that the API is provided with a public authority of *EXCLUDE. Clearly, some investigation was warranted as I use the API extensively in my applications and no one had ever reported an authority problem to me.


With the assistance of Guy Vig with IBM, also known as Mr. CL, we discovered what was going on. When the QCAPCMD API initially became available in V2R3, it was mistakenly defined with a public authority of *EXCLUDE. This error was later reported and, since V4R1, the API has been shipped by IBM with a public authority of *USE. This change in public authority may not, however, be reflected on all systems.


Any system that has been installed (from IBM media) starting with V4R1 will have the public authority to QCAPCMD set as *USE. This will be the case for any newly installed system or any pre-existing system that has been scratch installed (from IBM media) since V4R1 became available.  Systems that may have the public authority to QCAPCMD still as *EXCLUDE will be those that predate V4R1 and meet one or more of the following conditions:


  • Have done release upgrades through all the years—in this case, the release upgrade will have retained the previous release public authority setting of the API (propagating the incorrect setting)
  • Predate V4R1 and have done scratch reloads using previous saved media (where the saved media retained the incorrect *EXCLUDE setting of the API)
  • Have explicitly set *EXCLUDE using various security-related commands (in which case I hope they realize that the APIs QCMDEXC and system have always been provided with a public authority of *USE)


If you encounter a system with the public authority of QCAPCMD set to *EXCLUDE, and the user did not explicitly set this authority value (which they generally wouldn't as it's really the authority to the command to run that's important, and the authority to the command is checked by the API), then you should change the public authority to *USE. This change would be consistent with IBM's current public authority for the API. Unfortunately, and further complicating things, the developer responsible for this authority change back in V4R1 did not realize that the Information Center documents the public authority for system APIs, so this change has not been reflected in the online API documentation. This will be corrected over time as the various release levels of the Information Center are updated.

We'll Now Return to Our Regularly Scheduled Program

With that out of the way, let's now turn to the API system and the ability to determine what went wrong when attempting to run a CL command using the API. Below is an enhanced version of the sample program originally published in the article "Running CL Commands from RPG" that utilizes the API system.


h dftactgrp(*no) bnddir('QC2LE')                                 


dRunCmd           pr            10i 0 extproc('system')          

d Cmd                             *   value options(*string)     


dSndMsg           pr                  extpgm('QSYS/QMHSNDPM')    

d MsgID                          7    const                      

d QualMsgF                      20    const                      

d MsgDta                     65535    const options(*varsize)    

d LenMsgDta                     10i 0 const                      

d MsgType                       10    const                       

d CSE                        65535    const options(*varsize)    

d CSECtr                        10i 0 const                      

d MsgKey                         4                               

d QUSEC                               likeds(QUSEC)              

d LenCSE                        10i 0 const options(*nopass)     

d CSEQual                       20    const options(*nopass)   

d DSPWaitTime                   10i 0 const options(*nopass)   

d CSEType                       10    const options(*nopass)   

d CCSID                         10i 0 const options(*nopass)   


/copy qsysinc/qrpglesrc,qusec                                  


dPSDS            sds           429    qualified                 

d JobUsr                254    263                              


dCmd              s            512                              

dMsgID            s              7    import('_EXCP_MSGID')     

dMsgKey           s              4                              




  QUSBPRV = 0;                                                  


  Cmd = 'CLRPFM FILE(SOMEFILE) MBR(' + PSDS.JobUsr + ')';       

  if RunCmd(Cmd) = 1;                                           


        when MsgID = 'CPF3141';                                 

             Cmd = 'ADDPFM FILE(SOMEFILE) MBR(' + PSDS.JobUsr + ')'; 

             if RunCmd(Cmd) = 1;                                     

                SndMsg('ESC0002' :'OURMSGS   *LIBL'                  

                       :MsgID :%size(MsgID)                           

                       :'*ESCAPE' :'*PGMBDY' :1 :MsgKey :QUSEC);     



        when MsgID = 'CPF3142';                                      

             Cmd = 'CRTPF FILE(SOMEFILE) MBR(' + PSDS.JobUsr +       

                   ') MAXMBRS(*NOMAX) OPTION(*NOSRC *NOLIST)';       

             if RunCmd(Cmd) = 1;                                      

                SndMsg('ESC0002' :'OURMSGS   *LIBL'                  

                       :MsgID :%size(MsgID)                          

                       :'*ESCAPE' :'*PGMBDY' :1 :MsgKey :QUSEC);     




             SndMsg('ESC0002' :'OURMSGS   *LIBL'                  

                    :MsgID :%size(MsgID)                          

                    :'*ESCAPE' :'*PGMBDY' :1 :MsgKey :QUSEC);     




  // Do further processing                                        


  *inlr = *on;                                                     





The message description ESC0002 was previously created with this command:



   MSG('Unexpected error &1 encountered .') FMT((*CHAR 7))


At first glance, use of the API system appears to provide the same level of function as our previous examples using the APIs QCMDEXC and QCAPCMD—and with less coding on your part. There are fewer parameters to pass to the API system, there is no need to calculate the length of the command string to run because the options(*string) specification for the system prototype enables the API to determine the length based on the presence of a null byte, there is no need to establish a monitor group as with QCMDEXC or a non-zero Bytes provided error code structure as with QCAPCMD, and so on (though I will return to this point later in this article). And for simple errors in the running of the command, where you only need access to the CPF error message ID, recovery can be automated in a manner very similar to what is used with the QCMDEXC and QCAPCMD APIs.


However, more complex error recovery when using the API system can be like trying to pull firmly attached teeth; it can be a very painful and lengthy process. When developing an application, I tend to be a pessimistic optimist. I anticipate that anything that can go wrong will (eventually and typically at the absolute worst time) and that I can successfully automate recovery from any application error if I choose to (with some recovery procedures just not being worth the effort, unless of course the user feels otherwise). In order to effectively recover from errors, I prefer to utilize system interfaces that will tell me everything possible about an error situation. And it is in this "everything possible" desire of mine that I find the API system to be lacking.


As we saw last month when running the CLRPFM command, we are using a library qualifier of *LIBL to identify the file containing the member to be cleared. If, after a failure is encountered clearing the member, we wanted (or needed) to determine the name of the library associated with SOMEFILE, the QCAPCMD API provides this information very easily. The name of the library is readily available as variable CPF3141.Library, which is mapped over the message replacement subfield of the QCAPCMD error code data structure. With the QCMDEXC, the library name is also available (though you do need to call another API in order to receive the escape message CPF3141 from your program message queue). With the API system, you will however find that determining the name of the library can be a non-trivial task.


All three APIs will, if the file SOMEFILE is found and the specified member does not exist, be sent CPF3141 from the CL command CLRPFM. When this CPF3141 message is received by the API, these things happen:


  • QCMDEXC will resend the escape message to your program, allowing you to detect the error (a monitor group, a PSSR, etc. if provided).
  • QCAPCMD will, if the error code Bytes provided field is zero, resend the escape message to your program, allowing you to detect the error (a monitor group, a PSSR, etc. if provided).
  • QCAPCMD will, if the error code Bytes provided field is non-zero, provide the escape message information (message ID and message replacement data) in the error code data structure, allowing you to detect the error.
  • system will return a return value of 1 allowing you to detect the error, store the message ID in exported variable _EXCP_MSGID, and remove the escape message from the job log.


Note that the API system removes the message, so it's not just difficult to access the additional information provided by the CPF3141 escape message replacement data (the library name in our example); the message is simply not there anymore.


The API system has additional error-related characteristics that I find troubling. Some CL commands, in addition to sending escape messages, will also send diagnostic messages in response to a failure when attempting to run a command. Let's say for instance that in response to the CPF3141 error, our program attempts (as the example does) to add the member to the file using the ADDPFM command (not caring at this point about the name of the library containing the file). If the file member count is currently at its maximum, the ADDPFM command will send the diagnostic message CPF3213 (Members for file SOMEFILE more than maximum allowed) followed by the escape message CPF7306 (Member xxxxxx not added to file SOMEFILE in yyyyyy). In the same manner as the three APIs handled the escape CPF3141, so will they handle the CPF7306. CPF7306, however, does not tell us why the member was not added—just that the ADDPFM command failed. If the program wants/needs to automate recovery when the maximum member count has been reached (for instance, change the MAXMBR value of SOMEFILE), the program requires access to the associated diagnostic message to determine the underlying reason for the failure. That is, there is no reason to change MAXMBR if the diagnostic is not CPF3213. For diagnostic messages such as CPF3213, the behavior of the API used is this:


  • QCMDEXC will move the diagnostic message(s) to the caller of QCMDEXC.
  • QCAPCMD will move the diagnostic message(s) to the caller of QCAPCMD.
  • system will leave the diagnostic message(s) as is.


QCMDEXC and QCAPCMD, by moving the diagnostic message(s) to the caller of the API, enables the application program to easily receive the message using message-handling APIs, determine the message ID, access the message replacement data (if needed), and determine the appropriate recovery process (for instance, run the CHGPF CL command if CPF3213 is found as the underlying reason for the failure). The API system, by not moving the message, makes access to the message (while not impossible as in the case of removing the underlying escape message) much less direct.


The location of the diagnostic message(s) is important due to the message-handling functions of the i operating system being call stack–oriented. When using an API to receive a program message, you can use the special value '*' to specify the current call stack entry (you) and 0 as a counter relative to the call stack entry where the message to receive can be found (that is, your program again). In the case of QCMDEXC and QCAPCMD, these two API parameter values correctly, and easily, identify where to find the diagnostic messages: your program message queue. The API system, however, did not move the messages to "you"; rather, they're still back where the CL command initially sent them. The message-handler APIs can access messages associated with another call stack entry, but the call stack entry must exist (or, if it doesn't exist, you must have a message key to specify the message, which the API does not provide to us, or you must derive the message key similar to what is shown in the Information Center here). In the case of the API system, the diagnostic message(s) were associated with the API call stack entry and the API is no longer on the call stack as it has returned to our application program. To access the message(s) when using the API system, the application program needs to process the job log and, while there are also message-handling APIs enabling access to the job log, this access is nowhere near as direct as when using QCMDEXC or QCAPCMD. Trying to, within a program, find the CPF3213 message when using the API system will be a true learning experience....


The API system is provided with the i operating system as part of C runtime support and is very good at its primary function: running CL commands with an API interface and providing implementation that is consistent with what's found with other operating systems. The API has, in addition, been extended with _EXCP_MSGID support to allow a basic level of error recovery.


When developing an application, I prefer to use one consistent interface for a given purpose (such as running a CL command) and to use an interface that is as flexible as possible. For the following reasons, I use the QCAPCMD API for the running of CL commands (from within a non-CL based application program):


  • QCAPCMD gives me access to the basic function: running a CL command.
  • QCAPCMD provides me with flexibility in terms of receiving monitorable escape messages or error information in the form of variables within the error code parameter for first-line error recovery.
  • QCAPCMD enables easy access to much more extensive error-related information when I need it (which admittedly is not often, but I like knowing it's there).


Due to these reasons, I recommend the use of QCAPCMD, though in your environment, you may have good reasons for selecting one of the other APIs (such as consistency with C implementations in other areas of your company).


Earlier in this article, I mentioned that one perceived drawback of the QCAPCMD API is the number of parameters required by the API (at least relative to QCMDEXC and system). For my own application development, I have implemented a procedure named RunCmd that accepts two parameters: the CL command to run and an error code parameter. So in my own programs I would code the following…


RunCmd(Cmd :ErrCde);




RunCmd(Cmd :QUSEC);


rather than


RunCmd(Cmd :%len(%trim(Cmd)) :QCAP0100 :%size(QCAP0100)            

         :'CPOP0100' :NotUsedChr :0 :NotUsedInt :ErrCde);            



RunCmd(Cmd :%len(%trim(Cmd)) :QCAP0100 :%size(QCAP0100)            

         :'CPOP0100' :NotUsedChr :0 :NotUsedInt :QUSEC);            


…depending on whether or not I wanted escape messages sent directly to my program. My RunCmd procedure then calculates the length of the Cmd value, initializes the QCAP0100 input parameter (among other parameters to the API), resends and/or moves messages returned by the API, and so on. In this way, I get all of the function and flexibility found with QCAPCMD and avoid cluttering my application program source with unnecessary parameters. A win-win situation for me!


If you have any API questions, send them to me at This email address is being protected from spambots. You need JavaScript enabled to view it.. I'll see what I can do about answering your burning questions in future columns.  

as/400, os/400, iseries, system i, i5/os, ibm i, power systems, 6.1, 7.1, V7,

Bruce Vining

Bruce Vining is president and co-founder of Bruce Vining Services, LLC, a firm providing contract programming and consulting services to the System i community. He began his career in 1979 as an IBM Systems Engineer in St. Louis, Missouri, and then transferred to Rochester, Minnesota, in 1985, where he continues to reside. From 1992 until leaving IBM in 2007, Bruce was a member of the System Design Control Group responsible for OS/400 and i5/OS areas such as System APIs, Globalization, and Software Serviceability. He is also the designer of Control Language for Files (CLF).A frequent speaker and writer, Bruce can be reached at 

MC Press books written by Bruce Vining available now on the MC Press Bookstore.

IBM System i APIs at Work IBM System i APIs at Work
Leverage the power of APIs with this definitive resource.
List Price $89.95

Now On Sale



Support MC Press Online





  • 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 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.