REV SCHEDULER (iseries)

Transcription

1 Powerful Scheduling made easy Run scheduled jobs in an unattended environment throughout your Enterprise to increase: Throughput, Accuracy, Efficiency. Base Model is native on all platforms Run REV SCHEDULER natively on: AIX, AS/400 HP-UX, LINUX, SOLARIS, WINDOWS. The REV SCHEDULER Base Model is native on all platforms and does NOT rely on a central database. All Base Models operate independently but can have cross machine/ platform dependencies as well as multiple Focal Points. View, Control & Manage all Servers & other platforms The Windows interfaces allow you to View, Control and Manage the Job Events for any servers that are running REV SCHEDULER. Drag and Drop: Job Events, Components, Date Parameters, Environments, Conditions, Calendars etc., across machines and platforms. See the status of Jobs as they are running The Windows interfaces allow to immediately see (colors) and hear (sounds) the status of Job Events on any servers that are running REV SCHEDULER. Utilizing push technology the information is pushed from the host(s) directly (and immediately) from the servers directly to the Windows application. Sounds can be configured to notify you of the completion status of Job Events on any system in your Enterprise. Major Features Run Basis, *TIME or *TRIGGER, Latest Time, Run Method, Multiple Run Job, Environments, Job Day Codes, Inherit Components, Security/LDAP, Security Violations, Hyperlinks, Group Jobs, X Platfrom Groups, Operations Panels, Networking, Push Technology, Multiple Focal Points, Configurable Sounds, Dependencies, X Platform Dependencies, Date Parameters, Forecasting, Export, Screen Capture & Run, Screen Run History, Job Components, Audit, Undo Changes, Undelete, High Availability, HA Integrity Checker, Components. 1 of 22

2 Job Event Naming Each Job Event name can be up to 20 characters in length, and you can also define the Batch Job Name for the submitted Job Event, so that you can use meaningful names such as END_OF_DAY_TAMPA for Job Events. Run Basis The Run Basis defines how the Job Event will be processed, by the Scheduler engine, and checked availability to be submitted for execution. This can be: *TIME - This Job Event will be processed by time. *TRIGGER - This Job Event will be processed by being triggered based on the Job Dependencies roster completion status. Run Basis - *TIME - Time to run If there is no value in the Latest time, and the Job Event contains no Dependencies, when the Time to run is reached the Job Event will be submitted for execution. If the Job Event contains Dependencies the Dependency Roster will be checked and the Job Event will either Pass or Fail: For a Pass the Job Event will be submitted for execution. For a Fail the Job Event will not be submitted and the Completion Code will be DE - Dependency Error. Run Basis - *TRIGGER A Job Event that has a Run Basis of *TRIGGER will to be submitted based on the: The Pass of the Dependency Roster. The values contained in: Time to Run, Latest time. Run basis - Trigger - 24:00 A *TRIGGER Job Event with a Time to Run of 24:00 will be submitted for execution EVERY time the Dependency Roster is Passed. 2 of 22

3 Run Basis - *TIME - Time to run & Latest time If there is a value in the Latest time, and the Job Event contains Dependencies, when the Time to run is reached the Job Event s Dependency Roster will be checked and the Job Event will either Pass, Fail or be in a Dependency Wait state: For a Pass the Job Event will be submitted for execution, For a Fail the Job Event will not be submitted and the Completion Code will be DE - Dependency Error. A Dependency Wait If state is reached when - Not all the dependent jobs have not completed, and The Latest time to run has not been reached. The Dependency Wait state will remain until: All the Dependent jobs complete and the Dependency Roster for the Job Event is Passed of Failed The latest time is reached and the dependent jobs have still not all completed a Fail will be registered for the Job Event that will not be submitted and the Completion Code will be DE - Dependency Error. Run Basis - *TRIGGER - Latest Time A *TRIGGER Job Event with a Time to Run and a Latest Time will be submitted for execution EVERY time the Dependency Roster is Passed. Any Job Event in the Dependency Roster can only update the Completion Status between the times of the Time to Run and the Latest Time. If the dependent jobs complete outside of this time range their completion status will not register against the Job Event Dependency Roster. In this example the Job Event BETWEEN_10_AND_11 can only have Dependency records registered between: 10:00, 11:00. This time range is also the only time the Job Event will be available to be executed (by Trigger). 3 of 22

4 Run Method The Run Method controls when a Job Event will be available for execution. There are Multiple ways a Job Event can be run to control the days or dates: *CAL - Calendar. *DATE - Date. *DOM - Day of Month. *DOW - Day of Week. *LIST - Advanced list. Run Method - *CAL - Calendar A Calendar contains Calendar Day Codes and the Job Event can be defined to run by the: Frequency of the, Day Code within the data defined for the, Calendar Identifier. The Frequencies can be: EV Every Day. LS Last Day. L2 - L9 Second Last to Ninth Last Day First to Thirty First Day. e.g. Frequency EV Day Code *WORK Calendar EXAMPLE This represents EVERY occurrence of the Calendar Day code *WORK in the Calendar Data for Calendar Identifier EXAMPLE. Run Method- *DATE - Date A Date will only make the Job Event available for execution on the defined date. 4 of 22

5 Run Method - *DOM - Day of Month Day of Month will only make the Job Event available for execution on the defined day of each month. e.g. 15 will available to execute on - 15th January, 15th February, 15th March, etc., Run Method - *DOW - Day of Week The day of the week option relates to the day names of the week to make the Job Event available for execution. The user enters a Y or N beneath the appropriate day name as a Y or N must be entered. Y signifies yes to execute the Job Event on this day and N signifies no do not execute the Job Event on this day. The day names appear as follows - Sun Mon Tue Wed Thu Fri Sat with these abbreviations representing - Sunday Monday Tuesday Wednesday Thursday Friday Saturday e.g. Sun Mon Tue Wed Thu Fri Sat N Y Y Y N N N This Job Event will execute on every Monday, Tuesday and Wednesday, Sun Mon Tue Wed Thu Fri Sat Y N N N N N N This Job Event will execute on every Sunday, Sun Mon Tue Wed Thu Fri Sat N N N N N Y N This Job Event will execute every Friday. 5 of 22

6 Run Method - *LIST - Advanced List An Advanced List allows you to combine any or all of the: *CAL - Calendar. *DATE - Date. *DOM - Day of Month. *DOM - Day of Week. as well as: *DAY - Day. *MONTH - Month. Each element in the list is also joined by standard boolean IF/AND/OR conditions. This definition contains the List of: 10 IF EQ *DAY EQ 01 MONDAY 20 OR EQ *DAY EQ 03 MONDAY This list will allow the Job Event to be available to run on the 1st or 3rd Monday of each month. This definition contains the List of: 10 IF EQ *MONTH EQ OCTOBER 20 AND EQ *CAL EQ 01 *WORK EXAMPLE This list will allow the Job Event to be available to run, in the month of October only, on the 1st occurrence of the Day code *WORK in the EXAMPLE calendar. This definition contains the List of: 10 IF EQ *DOW EQ NYYYYYN 20 AND NE *CAL EQ EV HOLDY HOLIDAYS This list will allow the Job Event to be available to run every weekday (Monday through Friday) but not on any (EV) occurrence of the Day code HOLDY in the HOLIDAYS calendar. 6 of 22

7 Multiple Run Job Event REV SCHEDULER (iseries) Multiple times allow you to define the execution of a Multiple Run Job Event that will execute at regular time intervals. A Multiple Run Job Event executes the first time at the Time to run and is then defined to run additional times at defined intervals. A Job Event can be registered to: End executing at a time, or Execute a number of times. A Multiple Run Job Event can also: Stay Active and execute within the single Job Event. or Submit a new Job Event at each Multiple Run execution sequence. In this example this Job Event will start at 16:00 and execute every 5 minutes with the last execution being at 17:00. e.g. 16:00, 16:05, 16:10, 16:15, 16:20, 16:25, 16:30, 16:35, 16:40, 16:45, 16:50, 16:55, 17:00. In this example this Job Event will start at 13:00 and execute every 60 minutes with the last execution being at 3:00. This will execute over midnight. e.g. 13:00, 14:00, 15:00, 16:00, 17:00, 18:00, 19:00, 20:00, 21:00, 22:00, 23:00, 00:00, 1:00, 2:00, 3:00. In this example this Job Event will start at 12:50 and execute the pre defined times. The pre defined times are: 12:50, 12:55, 13:02, 13:10. 7 of 22

8 Environments Every Job Event defined to REV SCHEDULER must be registered or belong to an Environment. By using the shipped Environments you can immediately have: *BASE, *DEVELOP, *OPSTEST, *PGMRTEST, *Q&A, and you can promote your Job Events just as you do with your ERP (Enterprise Resource Planning) programs through a Change Management Environment. Only Environments that are started can execute the available Job Events. If a Job Event belongs to an Environment that is not started the Job Events, for that Environment, will not appear in the: Local Operations Panels, Network Operations Panels. Environments can be used for a number of tasks such as: Companies, Divisions or Departments can be defined as Environments. To stop or start all Jobs executing for a region or zone it is as simple as starting or stopping the Environment - This gives you control over Job Events that will execute for Companies, Divisions or any other sub set within your Corporation. Develop, Q & A and Production staging and promotion of Job Events just as you do with application or ERP programs that go through a Change Management Environment - This gives you quality control. Using Environment security you can regulate who can View, Define, Manage and Force Run Job Events. Using Environment security the users for a department only see the Job Events for their Environment and are only authorized to Force Run Job Events they can view - This allows for selection and execution of some Job Events to be controlled by the User departments who are responsible for them. High Availability can be selected by Environment - which will shadow all the Job Events for the selected Environments. Any new Job Events, that are defined to a HA Environment, will automatically be shadowed to the HA systems(s). 8 of 22

9 Job Day Codes Each Job Event, in REV SCHEDULER, can be defined to have different Job Day Codes (JDC) or flavors of the same Job Event. Each JDC can be seen as a different flavor of the same Job Event e.g. Chocolate, Strawberry etc., and can be up to 10 characters in length such as DAILY, WEEKLY, MONTHLY etc., A simple example is as follows: Job Day Code *BASE runs on Monday through Thursday by Time at 16:45 with no dependencies and Job Scripts defined, Job Day Code WEEKLY runs on Friday by Trigger when a Dependency Roster is satisfied and use the Job Scripts defined for the default Job Day Code (*BASE). This is all still only 1 Job Event with the same Job Name, Environment etc., but has varying Job Day Codes or flavors. In other Scheduling software you would need to define 3 separate Job Events all with different names. Dependency Rosters can also use the JDC as the dependency sequence can be dependent upon: Completion status of a designated JDC of the Job Event - by referencing the specific Job Day Code, Completion status of any JDC s of the Job Event - by referencing Job Day Code of *ANY. Inheriting default JDC components Any additional JDC can inherit any of the components from the default JDC. In this example we have defined the Dependencies but will inherit the Job Scripts, from the default Job Day Code (*BASE). By inheriting JDC components you do not have to define the components in the additional JDC definition and you can use the default JDC component definition at execution time. The components that can be inherited are: Job Documentation, Job Recovery Text, Scripts, Post Job Scripts. 9 of 22

10 Security The security function in REV SCHEDULER can be implemented in up to 2 levels: Module level. Environment level. Module Level Using Module Security you can define Users who are authorized to: Command or Menu option, Selection options from panels. All security is defined by: User Profile, *PUBLIC, User defined Authorization groups.. Environment Level By setting the security at Environment level any: Existing Job Events, New Job Events, for the Environment are automatically secured. Setting the security at Environment level allows for the security to be: Controlled, Managed, in one central location. LDAP Interface Security REV SCHEDULER now has full support for LDAP (Lightweight Directory Access Protocol) which is an Open Systems protocol to allow programs to look up information from a server. In this way LDAP can be a central security repository that will contain the security definitions for some of all of the servers where REV SCHEDULER is operational. The LDAP Interface can support security checking for both of the: 5250 Interface or terminal sessions, Windows Interface. The LDAP security also supports keyword values for: *PUBLIC_SYSTEMS - these are Systems other than the Systems specifically defined, *PUBLIC_USERS - these are Users other than the Users specifically defined. 10 of 22

11 Security Policies There are two security policies available : *SYSTEM, * LDAP. There is also a Tailoring Option that can allow the System policy to override the LDAP policy, and this can be set on a system by system basis. Security Violations All Security violations are logged and can be displayed by date or date range. The security violation logs: Domain, System, User - if from the Window application, Function that was attempted to be accessed, Operation that was attempted, Date and Time of violation, Policy type - if this value is *LDAP the LDAP server name will also be displayed. In this example the user (QSYSOPR) attempted to use the Force Run option (7) from the Local Operations Panel (RJOPRJOB) on a 5250 session. Even though this was from a 5250 session the *LDAP security definition on Windows Server (AMERICAS) restricted the access. Hyperlinks When defining the: Documentation, Recovery Text, of a Job Event you can enter a URL anywhere in the text. Using a URL will allow you to enter text or a URL that will allow you to enable Recovery instructions to be actioned in a short period of time and this will decrease times for problem resolution. The decreasing of problem resolution time will give greater throughput and accuracy. By having your: Operational Procedures, Soft copy manuals, on the Intranet or a departmental server will allow them to be accessed via the URL. 11 of 22

12 Group Jobs In a lot of circumstances computer tasks are run as streams where a group of jobs are executed in a sequence or are grouped to run together. This is referred to as a Group Job where the initial or controlling Job Event is referred to as the Parent Job and all the subsequent stream jobs are referred to as the Child or Children Jobs. Child or Children Job Events are controlled by a Parent Job. Each Child Job can also be defined to: Monitor for messages, Submit and continue or wait until the completion of the Child Job, Be able to Branch to another Group sequence based on the completion status of the Child Job. Group Job terminology The terminology for Group Jobs are as follows: Parent Job - This is the Group Control job or the main Job Event that executes all the chained Job Events. Child Jobs - These are the Group Member jobs or the Child Job Events that are being controlled by the Parent Job. Intra Dependency - This is a dependency of a Child Job on one or more other Children Jobs within the same Group. Group Job - Concurrent A Concurrent Group Job is a group execution where all the Child jobs will be submitted at the same time. In this example the Parent Job PARENT_CONCURRENT will start and it will submit the Child Jobs: GROUP_CHILD_01, GROUP_CHILD_02, GROUP_CHILD_03, GROUP_CHILD_04, at the same time. Group Job - Sequential A Sequential Group Job is a group execution where all the Child Jobs wait until the successful completion of the prior Child Job. In this example the Parent Job PARENT_SEQUENTIAL will start and it will submit the first Child Job GROUP_CHILD_01, If GROUP_CHILD_01 completes normally then Child Job GROUP_CHILD_02 will be submitted, If GROUP_CHILD_02 completes normally then Child Job GROUP_CHILD_03 will be submitted, If GROUP_CHILD_03 completes normally then Child Job GROUP_CHILD_04 will be submitted, 12 of 22

13 Group Job - Mixed A Mixed Group Job is a group execution with Concurrent and Sequential processing. In this example the Parent Job PARENT_MIXED will start and it will submit the Child Jobs: GROUP_CHILD_01 is submitted, If GROUP_CHILD_01 completes normally then Child Job GROUP_CHILD_02 will be submitted, GROUP_CHILD_03 will be submitted, GROUPCHILD_04 will wait for the normal completion of GROUP_CHILD_02 and GROUP_CHILD_03. Cross Platform (X Platform) Child Jobs Child Jobs can now be executed locally (*LOCAL) or on any other networked machines that are running REV VIEW and REV SCHEDULER. In this example the Parent Job is on AS/400 and executes: Child Job Locally on AS/400 (HYPERION), Child Job on LINUX (GALATEA), Child Job on AIX (PORTIA), Child Job on WINDOWS (OCEANIA), Child Job on AS/400 (HYPERION). All of thses Child Job are alos dependent upon the normal completion of the prior Child Job. Groups within Groups As Group Jobs basically are a representation of Job Streams within a business work flow we may encounter Job Streams within Job Streams and within REV SCHEDULER the concept of Group Jobs within Group Jobs is supported and can be simply implemented. Group Explosion on the Operations Panels Parent Jobs can be easily identified on the Operations Panels by the image displayed. Double clicking on the Parent Job image will launch a Group Explosion view - which is a subset of the Operations Panel for that Group Job only. In this example we have two Group Explosion panels as we are executing a Group within a Group. The Group Explosion panel uses exactly the same push technology as the Operations Panels and they are immediately updated when actions occur on the Host. 13 of 22

14 Operations Panels When Job Events are defined and executing you need to have a mechanism to control and manage the entire Schedule of Job Events and this is performed by the Operations Panels. There is also a Network Operations Panel to allow you to control and manage Job Events on networked machines. The Operations Panel will be the panel most used by the operations personnel within your corporation to control the Job Events under the control of REV SCHEDULER. There are various Operations Panels to provide varied views and functionality for the Local and Network schedule of Job Events. To make the Operations panel more informative the Job Events status is displayed in color. Types of Operations Panels The Operations panels are available for: All Job Events to be executed on the directly connected Servers - this is the Local Operations panel. All Job Events to be executed on any networked machines (regardless) of Operating system that are running REV SCHEDULER and this system is a Focal Point - this is the Network Operations panel. Environments started The Operations panels display Job Events that are available to be executed on the date for: Environments that are currently started. Environments that you are authorized to see. If you are logged on as a Master User you will be able to see all Job Events for the Environments regardless of the Environment security. Authorization for options The security for options can also restrict what options the user(s) can execute on the Operations panels. If you are logged on as a Master User you will be able to se all Environments regardless of the Environment security. 14 of 22

15 Fully Networked Solution REV SCHEDULER is a fully networked solutions not only to: Local Servers, Remote Servers, but also to other platforms. REV SCHEDULER currently has native scheduling software that runs on: AIX, AS/400, HP-UX. LINUX, SOLARIS, WINDOWS. Push Technology The Local and Network Operations panels use Push Technology - where the information is pushed from the Host(s) directly to the Windows application software. Using Push technology : Eliminates unnecessary polling of machines, Reduces network traffic, Display the status immediately the host detects it, Eliminates manual intervention to detect the status of a Job Event. Multiple Focal Points All RevSoft products have been designed and constructed to have: Multiple Focal Points, Multiple Focal Points on multiple platforms. Using this technology you can have - Multiple major Focal Points on AS/400 for all AS/400, WINDOWS, LINUX and AIX machines, Single or Multiple WINDOWS Focal Point only for the WINDOWS machines, Single or Multiple LINUX Focal Point only for the LINUX machines, Single or Multiple AIX Focal Point only for the AIX machines. Configurable Sounds The Local and Network Operations panels can be configured for sounds to be played based on the completion status of Job Events. The Operations panels can be configured so they: Automatically update, Play sounds, Change colors, whenever the status of a Job Event changes in your network. 15 of 22

16 Dependencies Not all Job Events to be executed by the REV SCHEDULER run strictly by time and a Dependency Roster can: Pass a Job for execution, Trigger a Job to be executed immediately. Only accept Dependency Roster records between time ranges. What is a Dependency Roster? A Dependency Roster is a defined list of dependency criteria which can contain: Job Events - These are scheduled Jobs executed in REV SCHEDULER on any platform, Conditions - These are conditions set in REV SCHEDULER on any platform, User Jobs- These are non scheduled batch jobs executed on AS/400 platforms only. Dependency Expiry Each Dependency Roster element can have a use by date for the dependency record which can be: *NEVER - This value will never expire and any date dependency record can be used. *TODAY - Only dependencies created on the same date can be used. *YESTERDAY - Only dependencies created on the same date or the day before can be used. Platforms for Job Events Dependencies can be executed within REV SCHEDULER on any available platforms. e.g. On AS/400 use REV SCHEDULER for AS/400, On AIX use REV SCHEDULER for AIX, On HP-UX use REV SCHEDULER for HP-UX, On LINUX use REV SCHEDULER for LINUX, On SOLARIS use REV SCHEDULER for SOLARIS, On WINDOWS use REV SCHEDULER for WINDOWS. Cross Platform (X Platform) dependencies Dependencies can be on the: Local Servers, Networked Servers. Any machines running REV SCHEDULER (and REV VIEW) on other platforms such as AIX, LINUX, WIDNOWS etc.,. All Network and Cross Platform dependencies can be simply: Defined, Monitored, Managed, from the REV SCHEDULER WINDOWS application. Dependency History On the Operations Panels you can view the Dependency: Roster status - This displays the current status of all the elements in the Dependency Roster, History - This displays status of all the elements of the Dependency Roster when the Job Event started or failed the dependency check. 16 of 22

17 Date Parameters Using Date Parameters allow you to define a variable and the date to be transposed whenever that date variable is located in the: Job Scripts, Post Job Scripts. Each Date definition can calculate the required date based on combination of: Years, Months, Weeks and Days, and the required Date Format mask can be defined. Date definitions can be dragged and dropped across platforms. In this example the Job Event PRINT_ERROR_LOG runs a Job Script executing the OS/400 command PRTERRLOG PERIOD((*AVAIL #DAT-1) (*AVAIL #DAT##)) which uses Date parameters: #DAT-1 - which is today minus 1 day in MMDDYY format, #DAT## - which is today s date in the system date format. When this Job Event was executed on May 14th the Script run time values were: PRTERRLOG PERIOD((*AVAIL ) (*AVAIL )) Forecasting As well as being able to view dates in the future from the Local and Network Operations panel to see Job Events that will be available to be execute din future dates - there is also Forecasting by: Month, Year, in the Windows application and is available in the: Definitions, and Operations Panels, Applications. Any types of Job Holds (Operator or Future Holds) are immediately visible. Export Both the Monthly and Yearly forecast panels can be exported for: Reporting, Posting on the Intranet, ed to departmental heads so the Job run rosters are notified and visible. 17 of 22

18 Screen Capture and Run REV SCHEDULER has functionality that will allow you to: Capture all the Screens and Keystrokes for a session, all the way from Log On through to Log Off. This Screen Capture session can then be executed as a Job Event in Batch. Why is the Log On captured? The Log On information is captured so: The entire session from Log On through to Log Off is executed, The correct authorization is executed during the Screen Run process. Any ERP is supported Customer sites have been running Screen Capture and Run with: MAPICS, Home grown applications, S36 environment applications. Screen Masking Once the Screens have been captured you can mask dates over the existing values that were captured on the screens. If a panel expects a value of 7 days prior to today in format of CCYYMMDD this can be achieved by: Creating a Date definition for the date value, Define the start area of the panel (Row and Column) that the Date definition value will be positioned (masked). Screen Comparison Defining a Screen comparison allows you to check and compare the actual value in a screen location to and expected or required value. All screen comparison are mapped by the starting location defined by the Row and Column. When defining the comparison data you can also define the: Command key or enter key to be actioned. Delay time (MM:SS) between comparisons. Maximum number of comparisons to be executed before failing the comparison. Screen Run history As REV SCHEDULER executes each of the Screen the actual screen is captured and can be reviewed after the executing of the Screen Collection. This allows you to view the actual Screen and the data on the screen as it was executed. 18 of 22

19 Audit The Audit function in REV SCHEDULER logs every change that is made to a Job Event or any of its components. These details are logged in the REV SCHEDULER database and can be reviewed. The details are simple to follow with 6 possible images: Add new, Delete, Update (Before), Undo Update, Update (After) Undo Delete. The audit details will even log the: Domain\System\User if the change is made in the Windows applications, If the change was made by - Keyboard - Manual Entry, REV VIEW - Send from another machine, Drag & Drop - Drag and Drop in the Windows interface. Undo Changes When updates are performed to the Job Event or any of the components the: Before image - Data prior to the change, After image - Data after the change, are captured and this does allow for the component to be rolled back of Undo the change. The Undo action is also registered in exactly the same manner and in that case you can actually Undo the Undo should the need arise. Un Delete Job Events or Components When a Job Event or any of the components are deleted all the details are registered. The Undo functionality allows you to: Un Delete a complete Job Event all its original - Job Day Codes, Components, Un Delete a Job Event component. 19 of 22

20 High Availability Some companies have multiple HA machines as their applications are mission critical to the continuity of their business. The HA function with REV SCHEDULER operates totally independently of the HA solution implemented for the ERP application. Real Life example In a customer site shadowing approximately 1,000 Job Events: The cutover (RJACTHAV) took less than 1 second to be completely operational, The HA Checker proved that the Scheduled Jobs were 100% complete and accurate. Why use REV SCHEDULER HA? Even though the ERP applications and data may be replicated to achieve business continuity it may not be wise to replicate all the Scheduler Job Events as some will be specific to the machine. A simple example of this is the Backups - you would not have them both executing at the same time on both machines as they would then be both unavailable. The Scheduled Job Events can then be broken down into the areas of: Machine specific, HA applicable. Within REV SCHEDULER you can ensure the HA applicable Job Events are shadowed and both Job Schedules are kept in sync. Shadowing Shadowing is the term used for the process synchronize the Job Events between the machines. Selecting for HA Job Events can be selected for HA by: Individual Job Event name, Environment name. Once the Job Events are selected the shadowing process begins immediately and the Job Event is sent to the HA computer(s). Activate for HA There is a REV SCHEDULER command that can be executed as part of the cutover process to: Start defined H.A. Environments, and End NON H.A. defined Environments. De Activate for HA There is a REV SCHEDULER command that can be executed as part of the cut back process to: End defined H.A. Environments, and Start NON H.A. defined Environments. 20 of 22

21 High Availability Integrity Checker The High Availability Integrity Checker was created so that you can check the exact and current status of ALL the shadowed Job Events and all their components. All Job Events that have passed the HA Integrity check will display the and any Job Events that fail the HA Integrity check will display the As part of the HA Integrity Check the OS/400 objects: Job Description, Job Queue, Output Queue, User Profile, are also checked as the Job Event will not execute without these objects. In this example the EXAMPLE Job Event on HYPERION has been defined to use Output Queue IBMGSA in RVLGPL that does not exist on the Fail Over machine (REVUSA). The Job Event EXAMPLE has the the HA Integrity check. as it has failed Double clicking on the EXAMPLE Job Event will drill down to the components for the Job Event and the component that failed the HA Integrity check has a displayed alongside. The component that failed the HA Integrity check was Job Event details. Drilling down on the Job Event details then displays all the registered details and we can see the Output Queue and Output Queue library are the failing details as the Output Queue value is N (i.e. does not exist). This function can also be executed as a Script in REV SCHEDULER for WINDOWS and the images Exported to an Intranet site. 21 of 22

22 Job Event components A Job Event definition can contain some/all of the available components. The defined components can be viewed on the Job Events definition Tree in the Windows application. The Base Model components are available in REV SCHEDULER on all platforms are: Job Execution - This controls when, where and how a Job Event will be executed, Job Scripts - This contains the scripts (Commands or Program calls) that are executed during the processing of the Job Event, Pre Checks - This contains Pre Checks processes that will be executed when the Job Event is available for execution prior to the Scripts being executed, Job Documentation - This contains detailed instructions about the Job Event, Job Recovery Text- This contains detailed recovery instructions about to the Job Event, LDA (Local Data Area) - This contains the contents of the Local Data Area to be used when the Job Event is submitted, Report Distribution - This contains the details for the Reports (Spooled Files) that can be split, bundled and distributed after the Scripts have been executed, Dependencies - This contains a list of prerequisite dependency conditions that must be satisfied to allow the Job Event to be available to run, Messages - This contains the definitions for the tailoring and distribution of the Job Event completion message, Post Job processing - This contains the scripts (Commands or Program calls) that are executed at the completion of the Job Event and can be based on the completion status, Security - This contains details defining User Profiles or Authorization Groups and the functions they are allowed to perform on a Job Event, Monitors - This contains Scripts that can be executed if the Job Event is on Job Queue or Active for defined time periods. All Job Event components can be accessed directly from: Clicking on the component name in the Job Event tree, Clicking on the component image at the top of the Job Event panel, Clicking on the component image in the Job Event definitions grid. 22 of 22