Multiple Interactive Subsystems

IT Infrastructure - Other
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

Brief: AS/400 system management requires knowledge, skill and infinite patience. Change one parameter, and performance for hundreds of jobs can be affected-some positively and some negatively. In this article, we'll examine the pros and cons of assigning multiple subsystems for interactive jobs. If you decide to try this technique on your AS/400, you'll get all the details you need to make it a success.

It's a common misconception that all interactive jobs must run in the QINTER subsystem. In fact, you can create, run and maintain multiple interactive subsystems for different groups of workstations on the AS/400. At first glance you may ask, "what do multiple interactive subsystems give my organization?" By partitioning workstations into separate subsystems, you can obtain better control over how your users access AS/400 resources such as storage pools and activity levels. This technique allows you to performance-tune your system by workstation groups, which gives you more freedom and flexibility to run your AS/400 the way you know it should be run.

Some of the specific benefits that are possible once you've implemented multiple interactive subsystems include:

o The MIS department can upgrade software without worrying about users updating files.

o Batch processing can be scheduled so only those users whose applications are directly affected are restricted from the system. OfficeVision applications, programming and users in other departments are free to use their workstations.

o MIS can control run priorities for specific workstations. For example, during the Christmas season you might want to increase priorities for the order department.

o Groups of workstations can be assigned to specific storage pools and activity levels.

Setting the Scene

To understand the benefits of using multiple interactive subsystems, let's look at an example. Each evening at 7:00 p.m., your AS/400 begins the nightly batch run. The only authorized users during batch processing are members of the MIS department; all other users must stay off the AS/400 until 6:00 a.m.

To accomplish this, we create a second interactive subsystem that only MIS workstations can access. At 7:00 p.m., QINTER is ended, which ends all interactive jobs. MIS users can continue working in a second interactive subsystem-MISINTER. We'll take advantage of the similarities between QINTER and our new subsystem to minimize the effort required to set up MISINTER. (For this example, we're assuming that the QINTER subsystem has basic default values-if you have modified QINTER substantially you may need to create the new subsystem from scratch.)


We create MISINTER by making a copy of QINTER using the Create Duplicate Object (CRTDUPOBJ) command:


The CRTDUPOBJ command creates MISINTER, complete with default storage pool allocations, routing entries, job queue entries and workstation entries.

The next step is to create a job queue to service our new subsystem. Again, we take our cue from the QINTER subsystem and make a copy of its job queue:


Now that we have a new subsystem and a job queue to service it, we have to modify the subsystem description so it can be used as intended. To assign MISJQ to MISINTER, run the Add Job Queue Entry (ADDJOBQE) command:


This assigns the MISJQ to the new subsystem. Any jobs submitted to it will run in MISINTER. It also specifies that there is no limit on the number of jobs submitted from this job queue that can run in MISINTER at one time.

We have all the objects we need for the new subsystem but it still contains one element that is particular to QINTER. Since the QINTER job queue is serviced solely by QINTER and we want to give QINTER total control over it, we'll remove the job queue from the MISINTER description:


Limiting Access to the New Subsystem

Now our new subsystem is ready to be used. But first, we need to limit access to MISINTER. The problem is that every interactive user still has access to MISINTER through the workstation-type entries it inherited from QINTER. We need to specify which workstations can run in MISINTER, and exclude all others. Unfortunately, we can't limit access by group profile. However, in our subsystem description, we can designate valid jobs to be run in MISINTER by their workstation type (e.g., *ASCII, 3179 terminals, 5251 terminals) or by workstation names. We do this by modifying the workstation-type entries in subsystem MISINTER. Here's how we do it.

o Run the Display Subsystem Description (DSPSBSD) command for MISINTER (see 1).

o Run the Display Subsystem Description (DSPSBSD) command for MISINTER (see Figure 1).

o Select option 5 to view the workstation type entries (2). This display shows you the types of workstations that are eligible to use the subsystem. Since we copied the MISINTER object from QINTER *ALL workstation types are eligible.

o Select option 5 to view the workstation type entries (Figure 2). This display shows you the types of workstations that are eligible to use the subsystem. Since we copied the MISINTER object from QINTER *ALL workstation types are eligible.

o Use the Remove Workstation Entry (RMVWSE) command to remove the universal workstation access that MISINTER inherited from QINTER:


o Use the RMVWSE command to remove any other workstation type entries from the new subsystem. For example, you may find an entry for type *CONS (console).

Next, we need to specify that the MIS department can run jobs in the new subsystem. We'll take advantage of our workstation naming convention to accomplish this goal; all MIS workstation devices are defined as MISxx where xx is a two-digit number. Currently, there are 10 MIS workstations: MIS01-MIS10. We'll use the Add Workstation Entry (ADDWSE) command to add a generic entry to make these workstations eligible to run jobs in MISINTER:


Our MISINTER configuration is now complete and we can activate the subsystem by issuing the Start Subsystem (STRSBS) command.

The ABCs of WSE

When we defined workstation entries for MISINTER, we specified that any workstation that begins with MIS* is eligible to start jobs running in MISINTER. This does not necessarily mean that these jobs will automatically be transferred to MISINTER when they are started. It merely means that they are cleared for running in the subsystem. The QINTER subsystem can also allocate the MIS* workstations through its universal workstation access (*ALL). As a result, both QINTER and MISINTER can now allocate our workstations. To use MISINTER effectively, we need to understand the logic that controls what subsystem a workstation will be assigned to. The AS/400 uses these rules to allocate workstations to subsystems.

1. Initial workstation allocation occurs when a subsystem starts. This means a particular workstation is automatically allocated to a starting subsystem in the following situations:

o When a dumb terminal is powered on but not yet assigned to a specific subsystem, a subsystem can allocate that workstation and display the sign-on screen when the subsystem is started. This occurs when the AS/400 is IPLed.

o If any workstation (including a PC Support session) is displaying a sign-on screen, it is eligible to transfer to another subsystem. In our case, if an MIS* workstation has been allocated to QINTER but is still at a sign-on screen, it is reallocated to MISINTER when MISINTER is started.

When a subsystem starts under these circumstances, it will allocate the workstations assigned to it unless a user is signed on. This explains how a workstation can be reallocated to a different subsystem as the subsystems are starting up in sequence (as happens when the AS/400 powers up).

2. If a workstation assigned to more than one active subsystem is varied off, it is impossible to predict which subsystem it will be allocated to when it becomes active. In our example, if workstation MIS01 is not active and it is specified in both QINTER and MISINTER, we cannot determine which subsystem it will be allocated to when it becomes active. However, if MISINTER is active and QINTER is inactive, the workstation will be assigned to MISINTER when it is varied on.

3. If a workstation is already allocated to another subsystem and it is running a job when the new subsystem is started, it will remain in the subsystem in which it is running. The AS/400 will not automatically transfer active jobs between subsystems.

The last two points are key to managing our new MISINTER subsystem. Since the AS/400 is inconsistent in allocating newly varied-on workstations to a specific subsystem, and since it will not transfer active jobs between interactive subsystems, it would seem that we cannot rely on OS/400 to transfer MIS* workstations to MISINTER. However, there is still one more feature that we can take advantage of which allows us to be certain that all MIS workstations will be allocated by the MISINTER subsystem.

Excluding Workstations

There is a technique we can use which allows us to exclude MIS workstations from being allocated by QINTER although they can still run jobs in QINTER. The ADDWSE or Change Work Station Entry (CHGWSE) commands have a parameter called AT which controls whether or not a workstation is allocated by a subsystem. This parameter has two possible values. The default, AT(*SIGNON), specifies that the workstation is allocated by the subsystem. AT(*ENTER) specifies that the workstation is not allocated by the subsystem. To prevent QINTER from allocating any of the MIS workstations, add a workstation entry using the following command :


At this point you may want to refer to 3 to see the current workstation entries for the QINTER and MISINTER subsystems.

At this point you may want to refer to Figure 3 to see the current workstation entries for the QINTER and MISINTER subsystems.

Even though QINTER still contains a workstation entry for *ALL at *SIGNON, the subsystem will not allocate any of the MIS workstations. The reason for this is that workstation entries are processed in a specific order:

1. Specific workstation name.

2. Generic workstation name.

3. Special workstation type (*CONS).

4. Specific workstation type (5250, 3279, ...).

5. Special workstation type (*ASCII and *NONASCII).

6. Special workstation type (*ALL).

The generic workstation entry (2) is processed before the *ALL workstation entry (6). Therefore, when QINTER attempts to allocate an MIS workstation, the first entry it encounters which satisfies the search is the generic workstation entry, which contains MIS* at *ENTER. The *ENTER value specifies that the subsystem should not allocate the workstation. When the subsystem finds an entry which satisfies the search, it stops checking-so for MIS workstations the entry for *ALL at *SIGNON is ignored, and the workstation is not allocated.

The MISINTER subsystem will also attempt to allocate an MIS workstation. The first entry it encounters contains MIS* at *SIGNON. The *SIGNON value specifies that the subsystem should allocate the workstation. So, the MISINTER subsystem allocates the workstation and presents a Sign On screen.

As you can see, this technique assures that all MIS workstations will always be allocated by the MISINTER subsystem. However, if we want an MIS* workstation to run in QINTER, we can still accomplish this. The tool we'll use is the Transfer Job (TFRJOB) command discussed in the next section.

The TRFJOB Command

TFRJOB moves an active job to a job queue running in another subsystem. For example, if a job is running on workstation MIS01 in MISINTER and the user wants to transfer to subsystem QINTER, he could type in the following command:


This command will place the calling job on the QINTER job queue. QINTER will then retrieve it off the job queue and continue running it. All job attributes and all of the temporary objects associated with it will remain with the job as it switches job queues. The net effect is that it moves your already existing job from one subsystem to another.

You have to be careful with TFRJOB-it will transfer all your temporary objects to another subsystem, but it will not transfer any objects that were allocated to the job in the old subsystem. This means that any programs you were running, files you had open or other objects that you had allocated will be released when you transfer. It's a strange quirk of OS/400 that it can transfer your library list and QTEMP between subsystems but it will lose any allocated files and programs. In effect, this means TFRJOB should always be run from a command line.

There are two other limitations on the use of TFRJOB: neither group jobs or associated jobs (started from the system request panel) are transferable. Suspended jobs started through Sys Req must be ended before TFRJOB can be run.

Despite these drawbacks, TFRJOB is the only way we can transfer our MIS* workstations into the QINTER subsystem after we have specified *ENTER access for these workstations. It is also useful in transferring workstations between subsystems when they can be allocated by more than one subsystem.

Back to our Example

Now that we have everything defined for MISINTER, we can make it part of the production environment by incorporating it into our regular schedule. This requires several steps:

1. Change the startup program (specified in system value QSTRUPPGM) to start MISINTER when our AS/400 is powered on. This will ensure that our subsystem will always be available. Because we have excluded the MIS* workstations from QINTER, MISINTER must be running or those workstations will not be able to sign on.

2. Schedule the nightly ending of QINTER at 7:00 p.m. by manually doing it through our Systems Operation staff or by automatically doing it through the OS/400 job scheduler. (See "Job Scheduling: Compliments of IBM!", December 1992, MC.)

3. Have our security officer authorize the appropriate MIS users to use the TFRJOB command to enter the QINTER subsystem when the situation warrants it.

4. Schedule the daily startup of QINTER at 6:00 a.m. so that the rest of the workstations can reenter the system for the day's processing.

These four jobs only need to be done once. We also need to instruct the MIS* workstation users how to use the TFRJOB command to transfer between subsystems.

These items complete the configuration described in this article. All nonessential users will be taken off the system at 7:00 p.m. while the MIS staff is free to operate its night shift. At 6:00 a.m., the rest of the staff will be able to reenter the AS/400 for daily work. By using this technique, we have solved our access problems and provided an environment for an uninterrupted nightly batch run.

Another Way

There is another way to assign workstations to subsystems. If all your workstations are named consistently, you can take advantage of those naming conventions to explicitly assign each workstation to a subsystem. For example, MIS* to MISINTER, AR* to QINTER, AP* to QINTER, and so forth. As you can see, if you have inconsistent device names or numerous device groups, this could be a tedious task.

This technique will work very well, but it is much more maintenance-intensive since every single workstation must be accounted for and logged into its proper subsystem. It has been my experience that it is easier to maintain and track the selected workstations that are eligible to use restricted subsystems than it is to try to pigeon-hole each individual workstation to its own subsystem.

The Way to Go

So, there you have it. An easy to implement and maintain technique for allocating specific workstations into separate subsystems. Give it a try. You might find it has some very positive benefits for your company.

Joe Hertvik is a systems administrator at a manufacturing company outside Chicago.

Multiple Interactive Subsystems

Figure 1 Subsystem Description for MISINTER

 Display Subsystem Description System: MC PGMR Subsystem description: MISINTER Library: $SHARIC Status: INACTIVE Select one of the following: 1. Operational attributes 2. Pool definitions 3. Autostart job entries 4. Work station name entries 5. Work station type entries 6. Job queue entries 7. Routing entries 8. Communications entries 9. Remote location name entries 10. Prestart job entries More... Selection or command ===> F3=Exit F4=Prompt F9=Retrieve F12=Cancel 
Multiple Interactive Subsystems

Figure 2 Workstation Type Entries for Subsystem MISINTER

 Display Work Station Type Entries System: MC PGMR Subsystem description: MISINTER Status: ACTIVE Type options, press Enter. 5=Display work station type details Opt Type Opt Type Opt Type Opt Type *CONS *ALL Bottom F3=Exit F9=Display all detailed descriptions F12=Cancel 
Multiple Interactive Subsystems

Figure 3 Subsystem Workstation Entires

 Subsystem QINTER Workstation entries: MIS*...................*ENTER *ALL...................*SIGNON Subsystem MISINTER Workstation entries: MIS*...................*SIGNON 


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.


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