1. Slide 1 of 10 Job Event Basics A Job Event is the name for the collection of components that comprise a scheduled job. On the iSeries a the available Job Event components 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, 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, 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 tailoring and distribution of the 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.

2. Slide 2 of 10 Job Event - Execution The Job Event execution component defines : The Job Event name, Batch Job Name, Run Basis, Environment, When to Run, Multiple Run, Submission, Details that will be used to submit the Job Event for execution. All of these details are logged within the Audit facility and can be Undone or Undeleted. Security will also allow users to Add Job Events and also only to permitted Environments. If a Job Event is maintained for an Environment that is registered for High Availability (H.A.) then all the appropriate data will be automatically sent and applied to the registered H.A. servers.

3. Slide 3 of 10 Job Event – Execution The Job Event name can be up to 20 characters in length as this allows you to have meaningful Job Event names and not have to abbreviate names. The Job Event name cannot contain embedded blanks but characters such as _ and. are permitted. The Job Event name is the name that is used on all the User Interfaces and Commands (command lines) is you Hold, Force, Release etc., a Job Event. All processing by the ‘engines’ is by the Internal ID so changing a Job Event name will not affect Dependencies, Group Jobs etc., either Locally or Networked.

4. Slide 4 of 10 Job Event – Execution The Run Basis determines the way in which a Job Event can be controlled for availability for There are 3 possible Run Basis values: *GROUP – the Job Event can only be executed as part of a Group Job, *TIME – the Job Event is controlled by time, *TRIGGER – the Job Event is Controlled by a Dependency Roster and time values. Both *TIME and *TRIGGER Run Basis Job Events can be further Controlled by the use of Time to Run and Latest Time.

5. Slide 5 of 10 Job Event – Execution - *TIME Job Events can run by simple time (with no Latest time) and the submission will be Passed or Failed at the Time to Run. Job Events can be controlled by Time to Run and Latest time to give a time range ‘window’ that a Job Event can be submitted in if the Dependency Roster is not completed at the Time to Run. This will result in a Dependency Wait (DW) state until : The Dependency Roster is completed, or The Latest time is reached, and the submission will be Passed or Failed.

6. Slide 6 of 10 Job Event – Execution - *TRIGGER Job Events can run by simple trigger (24:00) and the Job Event will be submitted every time the Dependency Roster is completed. Job Events can be controlled by Time to Run and Latest time to give a time range ‘window’ that the Dependency Roster can accept Dependency records. This will result in the Job Event only being executed between the valid time range that the Dependency Roster can accept records. This function does operate across the midnight boundary.

7. Slide 7 of 10 Job Event – Execution – Run Method The Run Method controls the days a Job Event will be available for submission. There are multiple ways to control the days or dates a Job Event can be run can tested for validation for execution: *CAL – this is based on the frequency of a Day Code appearing in a Calendar, *DATE – this is based on a specific date, *DOM – this will be executed on the same date each month, *DOW – this will be executed on the selected days of the week, *LIST – this is an advanced list comprising multiple Run Methods linked by Boolean Operands and simple tests. In this example the Job Event will be Available for submission on the 1 st and 3 rd Monday of each month.

8. Slide 8 of 10 Job Event – Execution – Multiple Run Job Events can be executed multiple times at : Regular time intervals,or Pre defined times (irregular 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. Job Events can also be executed across the midnight time boundary A Multiple Run Job Event can also: Stay Active and execute within the single Job Event using a delay between executions, or Submit a new Job Event at each Multiple Run execution sequence.

9. Slide 9 of 10 Job Event – Execution - 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 programs through a Change Management Environment. Only Environments that are started can execute the available Job Events. Multiple Environments can be active concurrently. Security can also be implemented by Environment and users can only see the Job Events for the Environments they are allowed (by security) to see. High Availability can also be implemented, within REV SCHEDULER, by Environment.

10. Slide 10 of 10 Job Event – Execution – Job Day Codes Each Job Event 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., The default JDC is *BASE and any additional JDC’s are user defined (e.g. 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 Scripts defined for the default Job Day Code (*BASE). Any additional JDC can inherit any or all of the components from the default JDC (*BASE).