Multiple Job Scheduling Environments.

Traditional Scheduling applications are based upon a single operational Environment for all scheduled jobs - basically a single level Scheduler. Most companies have separate Environments for their ERP s such as : Development, Testing, Quality and Assurance (Q&A), Production, etc., The ERP may also be processing for multiple: Companies, Divisions, Cost Centers, Applications, Countries, Regions, etc., REV SCHEDULER comes shipped with multiple Environments so even at initial installation you have a multiple Environment Scheduler in place. Environments are implemented in the Base Model of REV SCHEDULER and runs natively on: iseries, LINUX, UNIX, WINDOWS. Creating Environments is the same as creating partitions in REV SCHEDULER. Implementing multiple Environments allow you to : Have partitions or multiple Job Schedules, Control who can View and perform actions on Job Schedules, Start or Stop partitions as required, Control your High Availability. Page 2 of 8

Each Environment defined within REV SCHEDULER can be seen as a partition of the Scheduler. When REV SCHEDULER is first loaded the Environments shipped are: *BASE - Production Environment, *DEVELOP - Development Environment, *OPSTEST - Operations Test Environment, *PGMRTEST - Programmers Test Environment, *Q&A - Quality and Assurance Environment. In the shipped version of REV SCHEDULER you can: Create, Test, Promote to production, Job Events through the Environments just as you do with your ERP applications. Page 3 of 8

The Environment is selected and registered with the Job Event during the definition process. The same Job Event name can exist in all the different Environments if you are: Promoting the Job Event through the testing cycle to production, Running different Environments for different Companies etc., Page 4 of 8

Some customers create Environments for separate Companies or Divisions that are all on the same corporate machine or LPAR. In this example we have 4 companies and by creating the 4 Environments we now have 4 separate Job Schedules. Multiple Environments can be active concurrently. Only Environments that are started can have Job Events available for execution. If we wanted to only run Jobs for COMPANY1 and COMPANY2: Environments *COMPANY1 and *COMPANY2 would be Started, Environments *COMPANY3 and *COMPANY4 would be Ended. Environments can be Started and Stopped at any time by: Forms or Panels, Command or Command Line. Page 5 of 8

Each Environment can also have Security defined to control : Users, or Authorization Groups, who can : View, Add, Update, Delete, Execute, Job Events, which belong to that Environment. In our example with 4 companies we can define Environment Security to allow : Only Users from each of the Companies to view their own Job Events, Corporate Users to be able to view manage and control ALL Job Events for all Environments. Environment Security can be defined: Locally on the systems, or LDAP (Lightweight Directory Access Protocol) server and applied to servers in your network. Page 6 of 8

Not all Job Events should be replicated in a High Availability installation as some Job Events will be machine specific (Backups, Shutdowns, Startups, etc.,). By having the Environments defined as : *BASE Machine specific Job Events do not replicate, *HA Job Events to be replicated. By selecting the *HA Environment for High Availability : All Job Events that are registered for that Environment, and All future Job Events for that Environment will be automatically replicated when any component of the Job Event is updated. Page 7 of 8

Learn more about using Environments in REV SCHEDULER by: Watching the Flash presentations at /videos.php?selected=sch#revsch View the Publications at /publications.php Book a Web-Ex with a RevSoft technician at /webex.php Read about REVSCHEDULER at /products.php?product=revsch Page 8 of 8