Calendar Example 3 – Compile a Single Calendar 21 Calendar Example 4 – Compile All Calendars 22 Calendar Example 5 – Create a List Calendar 22 Calendar Example 6 – Create a Group Calendar 23 Calendar Example 7 – Create a Daily Calendar with Details and a Condition 24 Calendar Example 8 – Delete a Detail in a Calendar 24. Autocalasc –E autosys.STANDARDCAL –s ALL. NOTE: Only standard calendar conversion is supported by the Control-M Conversion Tool. Cyclic and extended calendars require manual definition in the Control-M environment. For more information, see the Control-M User Guide. WCC 11.4 & 11.4 SP1 Release Scope New flows in Monitoring, QuickView, and Forecast Better user experience Improved performance New active users widget and machines widget Support for AE v11.3.6 SP1 and SP2 features Initial status for a job Calendar description field Extended length of calendar name New alarm types Attach View to Alert Policy. I need to create extended calendar which will run on 1st business day of 3rd week of every month. Mon to Fri are considered as working day and no holiday calendar included. Sample dates for year 2018: 16th Jan, 13th Feb, 13th Mar, 17th Apr, 15th May, 12th Jun, 17th Jul, 14th Aug, 11th Sep, 16th Oct, 13th Nov, 11th Dec.
- Autosys Extended Calendar Printable
- Autosys Calendar Commands
- Autosys Update Calendar
- Exclude Calendar In Autosys
This guide will be helpfull in giving basic idea about what autosys is, defining jobs to AutoSys, monitoring and managing jobs.
Introduction to Autosys:AutoSys is an automated job control system for scheduling, monitoring, and reporting. These jobs can reside on any AutoSys-configured machine that is attached to a network.
An AutoSys job is any single command, executable, script, or Windows batch file. Each AutoSys job definition contains a variety of qualifying attributes, including the conditions specifying when and where a job should be run.
Defining Jobs :
There are the two methods you can use to create job definitions:
■ Using the AutoSys Graphical User Interface (GUI).
■ Using the AutoSys Job Information Language (JIL) through a command-line interface.
Autosys Jobs:
- Job Types and Structure :
There are three types of jobs: command, file watcher, and box.
As their names imply, command jobs execute commands, box jobs are containers that hold other jobs (including other boxes), and file watcher jobs watch for the arrival of a specified file.
In the AutoSys environment, the box job (or box) is a container of other jobs. A box job can be used to organize and control process flow. The box itself performs no actions, although it can trigger other jobs to run. An important feature of this type of job is that boxes can be put inside of other boxes.
Default Box Job Behavior:
Some important rules to remember about boxes are
- Jobs run only once per box execution.
- Jobs in a box will start only if the box itself is running.
- As long as any job in a box is running, the box remains in RUNNING state; the box cannot complete until all jobs have run.
- By default, a box will return a status of SUCCESS only when all the jobs in the box have run and the status of all the jobs is 'success.
- By default, a box will return a status of FAILURE only when all jobs in the box have run and the status of one or more of the jobs is 'failure.'
- Unless otherwise specified, a box will run indefinitely until it reaches a status of SUCCESS or FAILURE.
- Changing the state of a box to INACTIVE (via the sendevent command) changes the state of all the jobs in the box to INACTIVE.
- Job States and Status :
AutoSys keeps track of the current state, or status, of every job. The value of a job’s status is used to determine when to start other jobs that are dependent on the job. The job status is displayed in the job report generated by the autorep command, and in the job report you can view in the Job Activity Console
Following are the status of Autosys jobs:
- INACTIVE : The job has not yet been processed. Either the job has never been run, or its status was intentionally altered to “turn off” its previous completion status
- ACTIVATED :The top-level box that this job is in is now in the RUNNING state, but the job itself has not started yet.
- STARTING : The event processor has initiated the start job procedure with the Remote Agent.
- RUNNING : The job is running. If the job is a box job, this value simply means that the jobs within the box may be started (other conditions permitting). If it is a command or file watcher job, the value means that the process is actually running on the remote machine.
- SUCCESS : The job exited with an exit code equal to or less than the “maximum exit code for success.” By default, only the exit code “0” is interpreted as “success.” If the job is a box job, this value means that all the jobs within the box have finished with the status SUCCESS (the default), or the “Exit Condition for Box Success” evaluated to true
- FAILURE : The job exited with an exit code greater than the “maximum exit code for success.” By default, any number greater than zero is interpreted as “failure.” AutoSys issues an alarm if a job fails
- TERMINATED : The job terminated while in the RUNNING state. A job can be terminated if a user sends a KILLJOB event or if it was defined to terminate if the box it is in failed. If the job itself fails, it has a FAILURE status, not a TERMINATED status. A job may also be terminated if it has exceeded the maximum run time (term_run_time attribute, if one was specified for the job), or if it was killed from the command line through a UNIX kill command. AutoSys issues an alarm if a job is terminated.
- RESTART : The job was unable to start due to hardware or application problems, and has been scheduled to restart.
- QUE_WAIT : The job can logically run (that is, all the starting conditions have been met), but there are not enough machine resources available.
- ON_HOLD : This job is on hold and will not be run until it receives the JOB_OFF_HOLD event.
- ON_ICE : This job is removed from all conditions and logic, but is still defined to AutoSys. Operationally, this condition is like deactivating the job. It will remain on ice until it receives the JOB_OFF_ICE event.
The difference between 'on hold' and 'on ice' is that when an 'on hold' job is taken off hold, if its starting conditions are already satisfied, it will be scheduled to run, and it will run. On the other hand, if an 'on ice' job is taken 'off ice,' it will not start, even if its starting conditions are already satisfied. This job will not run until its starting conditions reoccur.
The other major distinction is that jobs downstream from the job that is 'on ice' will run as though the job succeeded. Whereas, all dependent jobs do not run when a job is on 'on hold'—nothing downstream from this job will run.
- Starting Parameters :
AutoSys determines whether to start or not to start a job based on the evaluation of the starting conditions (or starting parameters) defined for the job. These conditions can be one or more of the following:
■ Date and time scheduling parameters are met (it is or has passed the specified date and time).
■ Starting Conditions specified in the job definition evaluate to true.
■ For jobs in a box, the box must be in the RUNNING state.
■ The current status of the job is not ON_HOLD or ON_ICE.
Every time an event changes any of the above conditions, AutoSys finds all the jobs that may be affected by this change, and determines whether or not to start them.
sample jil code / Writing jil code:
jil = Job information language
When using JIL to create a job definition, you enter the jil command to display the JIL prompt.
Runs the Job Information Language (JIL) processor to add, update, and delete AutoSys jobs, machines, monitors, and reports. Also used to insert one-time job override definitions.
-------------------------------------------------------------------------------------------------
/* ----------------- SAP_UAT_MU03_C ----------------- */
insert_job: SAP_UAT_MU03_C job_type: c
command: /local/SAP/processCheckUAT.sh
machine: MU03-UAT
owner: admin@MU03-UAT
permission: gx,wx,mx,me
days_of_week: all
start_times: '15:00, 14:00'
description: 'Job used for Run testing of process'
Autosys Extended Calendar Printable
alarm_if_fail: 1
max_exit_success: 1
-------------------------------------------------------------------------------------------------
The above example is a simple jil code of autosys which we have to write if we want any particular job to be thru autosys.
To Insert a new JIL code :
issue command 'jil'
bash-3.00$ jiljil>>1>
'The following prompt will appear' copy paste the jil code u have made example of jil code below...........
At the end the 'C' or 'B' determines if the job is box job or child job.
if the jil is inserted properly successfull message will come if any errors are there the jil code contains some errors..
if successfull exit;
2. Other way is to create a temp file named temp.jil which contains jil code on autosys server: give command.
bash-3.00$ jil<>
Functional Listing of AutoSys Commands :
This section lists which AutoSys commands to use for specific tasks. All commands are for both Windows and UNIX, unless otherwise specified.
- Accessing Sybase : xql
- Checking System Status : autoflags
autoping
autosyslog
chase chk_auto_up - Converting cron to JIL (UNIX Only) : cron2jil
- Defining AutoSys Jobs or Machines : jil
- Defining Calendars : autocal, autocal_asc
- Reporting Job Status : autorep
autostatus - Starting AutoSys (UNIX Only) : eventor
- Stopping AutoSys : sendevent
Using Autorep command:
Function
Reports information about a job, jobs within boxes, machines, and machine status. Also reports information about job overrides and global variables.
Syntax
autorep {-J job_name -M machine_name -G global_name} [-s -d -q -o over_num] [-r run_num]
autorep -J (job name here)
This will display a list of jobs with complete details with box/jobname, last/latest run date & time, status, exit code, etc.
Viewing JIL code for any Autosys job
autorep -J (job name here)
To obtain the underlying JIL (Job Interaction Language) source code for any Autosys job, run command:
To obtain the information of previous runs
autorep -J (job name here)
would generate a report for the job run one runs back
-------------------------------------------------------------------------------------------------
Status Abbreviations
The following table lists the abbreviations used in the ST (status) column of the autorep report, and gives the status for each abbreviation.
AC - ACTIVATED
FA - FAILURE
IN - INACTIVE
OH - ON_HOLD
OI - ON_ICE
QU - QUE_WAIT
RE - RESTART
RU - RUNNING
ST - STARTING
SU - SUCCESS
TE - TERMINATED
-------------------------------------------------------------------------------------------------
sendevent:
sendevents to AutoSys for a variety of purposes, including starting or stopping AutoSys jobs, stopping the Event processor, and putting a job on hold. This command is also used to set AutoSys global variables or cancel a scheduled event.
sendevent is normally used with '-E' & -J option
-J job_name : Specifies the name of the job to which the specified event should be sent. This option is required for all events except STOP_DEMON, COMMENT, ALARM, or SET_GLOBAL
-E event :Specifies the event to be sent. This option is required. Any one of the following events may be specified:
- STARTJOB
- KILLJOB
- DELETEJOB
- FORCE_STARTJOB
- JOB_ON_ICE
- JOB_OFF_ICE
- JOB_ON_HOLD
- JOB_OFF_HOLD
- CHANGE_STATUS
- STOP_DEMON
- CHANGE_PRIORITY
- COMMENT
- ALARM
- SET_GLOBAL
- SEND_SIGNAL
Following are the example of sendevent command frequently used.
____________________________________________________________________
To start or force start a job manually using sendevent :
sendevent –E FORCE_STARTJOB -J 'Job Name Here'
sendevent -E STARTJOB -J 'Job Name Here'
To put jobs on OFF ICE or ON ICE :
sendevent -E OFF_ICE -J 'Job Name Here'
sendevent -E ON_ICE -J 'Job Name Here'
______________________________________________________________
autostatus: Reports the current status of a specific job, or the value of an AutoSys global variable. Ex: autostatus -J job_name, -S instance
You can first get the list of all your calenders as shown in the example below.
$ autocal_asc
CA WAAE Calendar Utility
Please select from the following options:
[1] Administer Standard Calendar.
[2] Administer Extended Calendar.
[3] Administer Cycle.
[4] List all Calendars.
[5] List all Cycles.
[0] Exit CA WAAE Calendar Utility.
> 4
Existing Calendars:
--------------------------------
Monthy Standard Calendar
monthly_ext Extended Calendar
We can use the command line utility to export the calenders as shown below
autocal_asc -E ca1.txt -s Monthy
autocal_asc -E ca2.txt -e monthly_ext
-rw-rw-r--. 1 autosys autosys 34 Dec 31 01:31 ca1.txt
-rw-rw-r--. 1 autosys autosys 127 Dec 31 01:36 ca2.txt
Copy the exported files to another autosys Manager
scp [email protected]:/home/autosys/*.txt .
ca1.txt 100% 34 0.0KB/s 00:00
ca2.txt 100% 127 0.1KB/s 00:00
Confirming that Initially there is no calenders in the second Autosys Manager
Autosys Calendar Commands
autocal_asc
CA WAAE Calendar Utility
Please select from the following options:
[1] Administer Standard Calendar.
[2] Administer Extended Calendar.
[3] Administer Cycle.
[4] List all Calendars.
[5] List all Cycles.
[0] Exit CA WAAE Calendar Utility.
> 4
Importing the Calender using the command line as shown below
autocal_asc -I ca2.txt
CAUAJM_I_50423 Insert Successful for Extended Calendar: monthly_ext
Confirming the imported calender
Autosys Update Calendar
$ autocal_asc
CA WAAE Calendar Utility
Please select from the following options:
[1] Administer Standard Calendar.
[2] Administer Extended Calendar.
[3] Administer Cycle.
Exclude Calendar In Autosys
[4] List all Calendars.
[5] List all Cycles.
[0] Exit CA WAAE Calendar Utility.
> 4
Existing Calendars:
--------------------------------
monthly_ext Extended Calendar