rev scheduler (iseries) 10.1 rev sch 000 datasheet-iseries.pdfrev scheduler (iseries) environments...

1 of 22Data Sheet - iSeries - ENT 10.1 www.revsoft.com

REV SCHEDULER (iSeries)Powerful Scheduling made easyRun scheduled jobs in an unattended environment throughout yourEnterprise to increase:• Throughput, • Accuracy, • Efficiency.

Base Model is native on all platformsRun REV SCHEDULER natively on: • AIX, • AS/400 • HP-UX, • LINUX, • SOLARIS, • WINDOWS.

The REV SCHEDULER Base Model is native on all platforms and doesNOT 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 platformsThe Windows interfaces allowyou to View, Control and Managethe Job Events for any serversthat are running REVSCHEDULER.

Drag and Drop:• Job Events, • Components,• Date Parameters,• Environments, • Conditions,• Calendars etc.,across machines and platforms.

See the status of Jobs as they are runningThe Windows interfaces allow to immediately see (colors) and hear(sounds) the status of Job Events on any servers that are runningREV SCHEDULER.

Utilizing push technology theinformation is pushed from thehost(s) directly (andimmediately) from the serversdirectly to the Windowsapplication.

Sounds can be configured tonotify you of the completionstatus of Job Events on anysystem 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 PlatformDependencies,• Date Parameters,• Forecasting,• Export,• Screen Capture &Run,• Screen Run History,• Job Components,• Audit,• Undo Changes,• Undelete,• High Availability,• HA Integrity Checker,• Components.

http://www.revsoft.com/


REV SCHEDULER (iSeries)Job Event NamingEach Job Event name can be up to 20 characters in length, and you can also define the BatchJob Name for the submitted Job Event, so that you can use meaningful names such asEND_OF_DAY_TAMPA for Job Events.

Run BasisThe Run Basis defines how the Job Event will be processed, by the Scheduler engine, andchecked availability to be submitted for execution. Thiscan be:

• *TIME - This Job Event will be processed bytime.

• *TRIGGER - This Job Event will beprocessed by being triggered based on theJob Dependencies roster completion status.

Run Basis - *TIME - Time to runIf 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 theDependency Roster will be checked and theJob Event will either Pass or Fail: • For a Pass the Job Event will be submitted forexecution . • For a Fail the Job Event will not be submitted and theCompletion Code will be

DE - Dependency Error.

Run Basis - *TRIGGERA 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:00A *TRIGGER Job Event with a Time to Run of 24:00will be submitted for execution EVERY time theDependency Roster is Passed.



REV SCHEDULER (iSeries)Run Basis - *TIME - Time to run & Latest timeIf there is a value in the Latest time, and the Job Event contains Dependencies, when theTime to run is reached the Job Event’s Dependency Roster will be checked and the JobEvent 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 andthe 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 theDependency Roster for the Job Event is Passed ofFailed • The latest time is reached and the dependent jobs have still not all completed a Fail will beregistered for the Job Event that will not be submitted and the Completion Code will be DE -Dependency Error.

Run Basis - *TRIGGER - Latest TimeA *TRIGGER Job Event with a Time to Run and a Latest Time will be submitted forexecution EVERY time the Dependency Roster is Passed.

Any Job Event in the Dependency Roster can only update the Completion Status betweenthe 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 registeragainst the Job Event Dependency Roster.

In this example the Job Event BETWEEN_10_AND_11can only have Dependency records registeredbetween: • 10:00, • 11:00.

This time range is also the only time the Job Event willbe available to be executed (by Trigger).



REV SCHEDULER (iSeries)Run MethodThe Run Method controls when a Job Event will beavailable for execution.

There are Multiple ways a Job Event can be run tocontrol the days or dates: • *CAL - Calendar. • *DATE - Date. • *DOM - Day of Month. • *DOW - Day of Week. • *LIST - Advanced list.

Run Method - *CAL - CalendarA Calendar contains Calendar Day Codes and the JobEvent 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. • 01 - 31 First to Thirty First Day.

e.g. Frequency EVDay Code *WORKCalendar EXAMPLE

This represents EVERY occurrence of the Calendar Day code‘*WORK’ in the Calendar Data for Calendar Identifier EXAMPLE.

Run Method- *DATE - DateA Date will only make the Job Event available forexecution on the defined date.



REV SCHEDULER (iSeries)Run Method - *DOM - Day of MonthDay of Month will only make the Job Event available forexecution on the defined day ofeach month.e.g. 15 will available to execute on -15th January,15th February,15th March, etc.,

Run Method - *DOW - Day of WeekThe day of the week option relates to the day names of the week to make the Job Eventavailable for execution.

The user enters a ‘Y’ or ‘N’ beneath the appropriateday name as a ‘Y’ or ‘N’ must beentered.

‘Y’ signifies yes to execute the Job Event on this dayand ‘N’ signifies no do notexecute 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.



REV SCHEDULER (iSeries)Run Method - *LIST - Advanced List

An Advanced List allows you to combine any or all ofthe: • *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 standardboolean IF/AND/OR conditions.

This definition contains the List of:10 IF EQ *DAY EQ 01 MONDAY20 OR EQ *DAY EQ 03 MONDAY

This list will allow the Job Event to be available to run on the 1st or3rd Monday of each month.

This definition contains the List of:10 IF EQ *MONTH EQ OCTOBER20 AND EQ *CAL EQ 01 *WORK EXAMPLE

This list will allow the Job Event to be available to run, in the monthof October only, on the 1st occurrence of the Day code *WORK inthe EXAMPLE calendar.

This definition contains the List of:10 IF EQ *DOW EQ NYYYYYN20 AND NE *CAL EQ EV HOLDY HOLIDAYS

This list will allow the Job Event to be available to run everyweekday (Monday through Friday) but not on any (EV) occurrenceof the Day code HOLDY in the HOLIDAYS calendar.



REV SCHEDULER (iSeries)Multiple Run Job Event

Multiple times allow you to define the execution of a Multiple Run Job Event that willexecute at regular time intervals.

A Multiple Run Job Event executes the first time at the ‘Time to run’ and is then defined torun 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 5minutes 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 every60 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 thepre defined times.

The pre defined times are:12:50, 12:55, 13:02, 13:10.



REV SCHEDULER (iSeries)EnvironmentsEvery Job Event defined to REV SCHEDULER must be registered or belong to anEnvironment.

By using the shipped Environments you canimmediately have: • *BASE, • *DEVELOP, •*OPSTEST, • *PGMRTEST, • *Q&A,and you can promote your Job Events just as you dowith your ERP (Enterprise Resource Planning)programs through a Change ManagementEnvironment.

Only Environments that are started can execute theavailable Job Events.

If a Job Event belongs to an Environment that is not started the JobEvents, 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 asEnvironments. To stop or start all Jobs executing for a region orzone it is as simple as starting or stopping the Environment - Thisgives 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 JobEvents just as you do with application or ERP programs that gothrough a Change Management Environment - This gives you quality control.

• Using Environment security you can regulate who can View, Define, Manage and Force RunJob Events. Using Environment security the users for a department only see the Job Events fortheir Environment and are only authorized to Force Run Job Events they can view - This allowsfor selection and execution of some Job Events to be controlled by the User departments whoare 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).



REV SCHEDULER (iSeries)Job Day CodesEach 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, Strawberryetc., 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 throughThursday by Time at 16:45 with no dependencies andJob Scripts defined, • Job Day Code WEEKLY runs on Friday by Triggerwhen a Dependency Roster is satisfied and use the JobScripts defined for the default Job Day Code (*BASE).

This is all still only 1 Job Event with the same JobName, Environment etc., but has varying Job DayCodes or flavors.

In other Scheduling software you would need to define 3separate Job Events all with different names.

Dependency Rosters can also use the JDC as the dependencysequence can be dependent upon: • Completion status of a designated JDC of the Job Event - byreferencing the specific Job Day Code, • Completion status of any JDC’s of the Job Event - by referencingJob Day Code of *ANY.

Inheriting default JDC componentsAny additional JDC can inherit any of the components from the default JDC.

In this example we have defined the Dependencies but willinherit the Job Scripts, from the default Job Day Code (*BASE).

By inheriting JDC components you do not have to define thecomponents in the additional JDC definition and you can usethe default JDC component definition at execution time.

The components that can be inherited are: • Job Documentation, • Job Recovery Text, • Scripts, • Post Job Scripts.



REV SCHEDULER (iSeries)SecurityThe security function in REV SCHEDULER can be implemented in up to 2 levels: • Module level. • Environment level.

Module LevelUsing Module Security you can define Users who areauthorized to: • Command or Menu option, • Selection options from panels.All security is defined by: • User Profile, • *PUBLIC, • User defined Authorization groups..

Environment LevelBy 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 SecurityREV SCHEDULER now has full support for LDAP (LightweightDirectory Access Protocol) which is an Open Systems protocol toallow programs to look up information from a server.

In this way LDAP can be a central security repository that willcontain the security definitions for some of all of the servers whereREV 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 thanthe Systems specifically defined, • *PUBLIC_USERS - these are Users other than theUsers specifically defined.



REV SCHEDULER (iSeries)Security PoliciesThere are two security policies available : • *SYSTEM, • * LDAP.

There is also a Tailoring Option that can allow the System policy to override the LDAP policy, andthis can be set on a system by system basis.

Security ViolationsAll 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 ForceRun option (7) from the Local Operations Panel (RJOPRJOB) on a5250 session.

Even though this was from a 5250 session the *LDAP securitydefinition on Windows Server (AMERICAS) restricted the access.

HyperlinksWhen 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 youto enable Recovery instructions to be actioned in a short period oftime and this will decrease times for problem resolution.

The decreasing of problem resolution time will give greaterthroughput 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.



REV SCHEDULER (iSeries)Group JobsIn a lot of circumstances computer tasks are run as ‘streams’ where a group of jobs areexecuted 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 theParent 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 theChild Job, • Be able to Branch to another Group sequence based on thecompletion status of the Child Job.

Group Job terminologyThe terminology for Group Jobs are as follows: • Parent Job - This is the Group Control job or the main Job Event that executes all the chainedJob Events. • Child Jobs - These are the Group Member jobs or the Child Job Events that are beingcontrolled by the Parent Job. • Intra Dependency - This is a dependency of a Child Job on one or more other Children Jobswithin the same Group.

Group Job - ConcurrentA Concurrent Group Job is a group execution where all theChild jobs will be submitted at the same time.

In this example the Parent Job PARENT_CONCURRENT willstart 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 - SequentialA Sequential Group Job is a group execution where all theChild Jobs wait until the successful completion of the priorChild Job.

In this example the Parent Job PARENT_SEQUENTIAL willstart and it will submit the first Child Job GROUP_CHILD_01, • If GROUP_CHILD_01 completes normally then Child JobGROUP_CHILD_02 will be submitted, • If GROUP_CHILD_02 completes normally then Child JobGROUP_CHILD_03 will be submitted, • If GROUP_CHILD_03 completes normally then Child Job GROUP_CHILD_04 will be submitted,



REV SCHEDULER (iSeries)Group Job - MixedA Mixed Group Job is a group execution with Concurrent andSequential processing.

In this example the Parent Job PARENT_MIXED will start andit will submit the Child Jobs: • GROUP_CHILD_01 is submitted, • If GROUP_CHILD_01 completes normally then Child JobGROUP_CHILD_02 will be submitted, • GROUP_CHILD_03 will be submitted, • GROUPCHILD_04 will wait for the normal completion ofGROUP_CHILD_02 and GROUP_CHILD_03.

Cross Platform (X Platform) Child JobsChild Jobs can now be executed locally (*LOCAL) or on any other networked machines that arerunning 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 normalcompletion of the prior Child Job.

Groups within GroupsAs Group Jobs basically are a representation of Job Streams within a business work flow we mayencounter Job Streams within Job Streams and within REV SCHEDULER the concept of GroupJobs within Group Jobs is supported and can be simply implemented.

Group Explosion on the Operations PanelsParent 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 subsetof the Operations Panel for that Group Job only.

In this example we have two Group Explosion panels as weare executing a Group within a Group.

The Group Explosion panel uses exactly the same pushtechnology as the Operations Panels and they areimmediately updated when actions occur on the Host.



REV SCHEDULER (iSeries)Operations PanelsWhen Job Events are defined and executing you need to have a mechanism to controland manage the entire ‘Schedule’ of Job Events and this is performed by the OperationsPanels.

There is also a Network Operations Panel to allow you tocontrol and manage Job Events on networked machines.

The Operations Panel will be the panel most used by theoperations personnel within your corporation to control theJob Events under the control of REV SCHEDULER.

There are various Operations Panels to provide varied viewsand functionality for the Local and Network schedule of JobEvents.To make the Operations panel more informative the JobEvents status is displayed in color.

Types of Operations PanelsThe Operations panels are available for:• All Job Events to be executed on the directly connected Servers - this is the Local Operationspanel.• All Job Events to be executed on any networked machines (regardless) of Operating systemthat are running REV SCHEDULER and this system is a Focal Point - this is the NetworkOperations panel.

Environments startedThe 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 Environmentsregardless of the Environment security.

Authorization for optionsThe security for options can also restrict what options the user(s) can execute on the Operationspanels.

If you are logged on as a Master User you will be able to se all Environments regardless of theEnvironment security.



REV SCHEDULER (iSeries)Fully Networked SolutionREV SCHEDULER is a fully networked solutions not only to: • Local Servers, • Remote Servers,but also to other platforms.

REV SCHEDULER currently has native scheduling softwarethat runs on: • AIX, • AS/400, • HP-UX. • LINUX, • SOLARIS, • WINDOWS.

Push TechnologyThe Local and Network Operations panels use PushTechnology - 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 PointsAll 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 SoundsThe Local and Network Operations panels can be configured for sounds to be played based onthe 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.



REV SCHEDULER (iSeries)DependenciesNot all Job Events to be executed by the REV SCHEDULER run strictly by time and aDependency 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 ExpiryEach Dependency Roster element can have a ‘use by date’ for the dependency record which canbe: • *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 EventsDependencies can be executed within REV SCHEDULER on anyavailable 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) dependenciesDependencies 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 HistoryOn the Operations Panels you can view the Dependency: • Roster status - This displays the current status of all the elementsin the Dependency Roster, • History - This displays status of all the elements of theDependency Roster when the Job Event started or failed thedependency check.



REV SCHEDULER (iSeries)Date ParametersUsing Date Parameters allow you to define a variable and thedate to be transposed whenever that date variable is locatedin the: • Job Scripts, • Post Job Scripts.

Each Date definition can calculate the required date based oncombination of: • Years, • Months, • Weeks and • Days,and the required Date Format mask can be defined.

Date definitions can be dragged and dropped acrossplatforms.

In this example the Job Event PRINT_ERROR_LOG runs aJob 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 timevalues were:PRTERRLOG PERIOD((*AVAIL 051307) (*AVAIL 051407))

ForecastingAs well as being able to view dates in the future from the Local andNetwork Operations panel to see Job Events that will be available tobe 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 immediatelyvisible.

ExportBoth the Monthly and Yearly forecast panels can be exported for: • Reporting, • Posting on the Intranet, • E-mailed to departmental heads so the Job run rosters arenotified and visible.



REV SCHEDULER (iSeries)Screen Capture and RunREV 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 supportedCustomer sites have been running Screen Capture and Run with: • MAPICS, • Home grown applications, • S36 environmentapplications.

Screen MaskingOnce the Screens have been captured you can mask dates over the existing values that werecaptured on the screens.

If a panel expects a value of 7 days prior to today in format of CCYYMMDD this can be achievedby: • Creating a Date definition for the date value, • Define the start area of the panel (Row and Column) that the Date definition value will bepositioned (masked).

Screen ComparisonDefining a Screen comparison allows you to check and compare the actual value in a screenlocation 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 executedbefore failing the comparison.

Screen Run historyAs REV SCHEDULER executes each of the Screen theactual screen is captured and can be reviewed after theexecuting of the Screen Collection.

This allows you to view the actual Screen and the dataon the screen as it was executed.



REV SCHEDULER (iSeries)AuditThe Audit function in REV SCHEDULER logs every change that is made to a Job Eventor any of its components.

These details are logged in the REV SCHEDULER databaseand 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 ChangesWhen updates are performed to the Job Event or any of thecomponents 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 ‘rolledback’ of ‘Undo’ the change.

The Undo action is also registered in exactly the same manner andin that case you can actually ‘Undo the Undo’ should the need arise.

Un Delete Job Events or ComponentsWhen a Job Event or any of the components are deleted all thedetails 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.



REV SCHEDULER (iSeries)High AvailabilitySome companies have multiple HA machines as their applications are mission critical tothe continuity of their business.

The HA function with REV SCHEDULER operates totally independently of the HA solutionimplemented for the ERP application.

Real Life exampleIn 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 itmay not be wise to replicate all the Scheduler Job Events as some will be specific to themachine.

A simple example of this is the Backups - you would not have them both executing at the sametime 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 bothJob Schedules are kept in sync.

ShadowingShadowing is the term used for the process synchronize theJob Events between the machines.

Selecting for HAJob Events can be selected for HA by: • Individual Job Event name, • Environment name.

Once the Job Events are selected the shadowing processbegins immediately and the Job Event is sent to the HA computer(s).

Activate for HAThere 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 HAThere 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.



REV SCHEDULER (iSeries)High Availability Integrity CheckerThe High Availability Integrity Checker was created so thatyou can check the exact and current status of ALL theshadowed Job Events and all their components.

All Job Events that have passed the HA Integrity check willdisplay 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 HYPERIONhas been defined to use Output Queue IBMGSA inRVLGPL that does not exist on the Fail Over machine(REVUSA).

The Job Event EXAMPLE has the as it has failedthe HA Integrity check.

Double clicking on the EXAMPLE Job Event will drilldown to the components for the Job Event and thecomponent that failed the HA Integrity check has a displayed alongside.

The component that failed the HA Integrity check wasJob Event details.

Drilling down on the Job Event details then displays allthe registered details and we can see the OutputQueue and Output Queue library are the failing detailsas the Output Queue value is N (i.e. does not exist).

This function can also be executed as a Script in REVSCHEDULER for WINDOWS and the images Exportedto an Intranet site.



REV SCHEDULER (iSeries)Job Event componentsA Job Event definition can contain some/all of the available components.

The defined components can be viewed on the Job Events definition Tree in theWindows application.

The Base Model components are available in REV SCHEDULER on all platformsare: • Job Execution - This controls when, where and how a Job Event will beexecuted,• Job Scripts - This contains the scripts (Commands or Program calls) thatare executed during the processing of the Job Event,• Pre Checks - This contains Pre Checks processes that will be executed when the Job Eventis 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 whenthe Job Event is submitted, • Report Distribution - This contains the details for the Reports (Spooled Files) that can besplit, bundled and distributed after the Scripts have been executed, • Dependencies - This contains a list of prerequisite dependency conditions that must besatisfied to allow the Job Event to be available to run, • Messages - This contains the definitions for the tailoring and distribution of the Job Eventcompletion message, • Post Job processing - This contains the scripts (Commands or Program calls) that areexecuted 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 thefunctions 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 orActive for defined time periods.

All Job Event components can be accessed directlyfrom: • Clicking on the component name in the Job Eventtree, • Clicking on the component image at the top of theJob Event panel, • Clicking on the component image in the Job Eventdefinitions grid.


rev scheduler (iseries) 10.1 rev sch 000 datasheet-iseries.pdfrev scheduler (iseries) environments...

Documents