omitting start_times in WAAE

[jhill5.5]

If I omit the start_times field but set a calendar and set the date_conditions flag to true, will WAAE treat the job as having a start_times of 00:00?  We're seeing some unexpected behavior when the job has dependencies but no start_times, but we before we exhaustively run this down I wanted to be sure what the expected behavior was.

 

Thanks.

 

11.3 SP1, if that's relevant.

[Mark_Hanson]

Hi -

 

If a time is not specified in the calendar definition or the job definition then the default start time is 00:00.

 

For example,

 

If you set a run_calendar for a job and set date_conditions to true then the job should be scheduled based on the dates/times in the calendar.

 

Consider the following calendar dates/times:

calendar: test-cal

08/24/2014 16:00

08/25/2014 16:00

 

Job:

 

insert_job: test-cal-job

command: sleep 1

machine: localhost

run_calendar: test-cal

date_conditions: 1

 

Job test-cal-job will be scheduled for 08/24/2014 at 16:00, then once that job runs to completion, the next startjob event will be set to 08/25/2014 at 16:00.

 

If I omit the times from the calendar definition:

calendar: test-cal

08/24/2014

08/25/2014

 

Job test-cal-job will be scheduled for 08/24/2014 at 00:00, then once that job runs to completion, the next startjob event will be set to 08/25/2014 at 00:00.

 

If I modify the job definition as follows:

 

update_job: test-cal-job

start_times: "13:00"

 

Job test-cal-job will be scheduled for 08/24/2014 at 13:00, then once that job runs to completion, the next startjob event will be set to 08/25/2014 at 13:00.

[jhill5.5]

But if the job also has a condition, I'm finding that it doesn't run at all unless the condition is already met as of midnight.

 

Example 1:

JobA has condition s(JobB)

Whenever JobB completes successfully, JobA runs, whether that's once a day or 15x a day.

 

Example 2:

JobC has start_times 00:00 and condition s(JobD)

If JobD is already in a Success state, jobC runs at 00:00.

If JobD is not in a Success state at 00:00, but completes successfully at 00:30, JobC runs at 00:30.

If JobD then completes successfully six more times on the same day, JobC does nothing further until the following midnight.

 

Example 3:

JobE has no start_times but does have a calendar.  It has condition s(JobF).

If JobF is already in a Success state, JobE runs at midnight.

If JobF is not in a Success state at midnight but succeeds at 00:30, JobE doesn't run until the following midnight.

If JobF then completes successfully six more times on the same day, JobE still does nothing further until the following midnight.

 

It's as though the scheduler is evaluating JobC's status only at midnight, but it's evaluating JobA's status every time any of its parent jobs completes.  This is not intuitive to me but we've run half a dozen tests now and keep getting the same results.

 

When my user set up her JIL for the child job with a calendar, a condition and no start_time, she thought the behavior would be similar to JobA's except firing only on the days specified by the calendar.  She wanted her job to fire whenever the parent job completed successfully on business days, potentially multiple times per day.  I thought I might be able to do the same thing with a run_window from midnight to 23:59, but without a start_time the child job only runs once a day.  I suppose I could have the job run every fifteen minutes with a s(JobA,0) condition, but that seems way more involved than it should be.

[Mark_Hanson]

jhill5.5 wrote:

 

But if the job also has a condition, I'm finding that it doesn't run at all unless the condition is already met as of midnight.

 

[Mark Hanson] Keep in mind: A job cannot run until all specified dependencies evaluate to true.

 

Example 1:

JobA has condition s(JobB)

Whenever JobB completes successfully, JobA runs, whether that's once a day or 15x a day.

 

[Mark Hanson] As observed, JobA will run every time JobA's specified dependency ( s(JobB) ) evaluates to true.

 

Note, per the User Guide:

Starting conditions that are based on job status use the current (or most recent) completion status of the job. The current completion status is defined by the job run, regardless of when that run occurred.

 

[Mark Hanson] Here in Example 2, we have added another dependency: start_times.

 

Example 2:

JobC has start_times 00:00 and condition s(JobD)

If JobD is already in a Success state, jobC runs at 00:00. [Mark Hanson] When JobD ran to SU it satisfied the conditional dependency so all that remains is the start_times dependency which is met at 00:00, hence the STARTJOB event.

If JobD is not in a Success state at 00:00, but completes successfully at 00:30, JobC runs at 00:30. [Mark Hanson] In this case, the start_times dependency was satisfied at 00:00, but it wasn't until 00:30 that the s(jobD) dependency was satisfied so the job is cleared to run. This resets the start_times dependency so...

If JobD then completes successfully six more times on the same day, JobC does nothing further until the following midnight. [Mark Hanson] JobC cannot run every time JobD runs to SU because start_times dependency is not met.

 

Example 3:

JobE has no start_times but does have a calendar.  It has condition s(JobF).

If JobF is already in a Success state, JobE runs at midnight. [Mark Hanson] Similar to Example 2 scenario...

If JobF is not in a Success state at midnight but succeeds at 00:30, JobE doesn't run until the following midnight. [Mark Hanson] This should behave similar to Example 2 scenario. start_times and run_calendar are equivalent. I ran some tests that behaved the same using start_times or run_calendar. I suspect a timing issue with the STARTJOB event. There is a STARTJOB event associated with the start_time or run_calendar. In both cases the STARTJOB event must be processed in order for JobC/JobE to run when JobD/JobF runs to SU. The STARTJOB event being processed satisfies the start_times/run_calendar dependency.

If JobF then completes successfully six more times on the same day, JobE still does nothing further until the following midnight. [Mark Hanson] Similar to Example 2 scenario...

 

It's as though the scheduler is evaluating JobC's status only at midnight, but it's evaluating JobA's status every time any of its parent jobs completes.  This is not intuitive to me but we've run half a dozen tests now and keep getting the same results.

 

When my user set up her JIL for the child job with a calendar, a condition and no start_time, she thought the behavior would be similar to JobA's except firing only on the days specified by the calendar.  She wanted her job to fire whenever the parent job completed successfully on business days, potentially multiple times per day.  I thought I might be able to do the same thing with a run_window from midnight to 23:59, but without a start_time the child job only runs once a day.  I suppose I could have the job run every fifteen minutes with a s(JobA,0) condition, but that seems way more involved than it should be.

[Mark Hanson] You can set the child job up to run with start_times slightly behind JobA with optionally the lookback, and only on WORKDAYS.

 

Hi - I have replied in-line above in bold.

[jhill5.5]

Thanks for the considered response.  I'm surprised to hear that you can get example 3 to behave the same way as example 2.  I cannot.  Dunno if it matters but we're on 11.3 SP1.

 

Here's an example.  The parent job completed at 14:37 but we had to force_start the child. 

 

 

/* ----------------- jenn_egl_roll_bus_date_job ----------------- */

 

insert_job: jenn_egl_roll_bus_date_job   job_type: CMD

command: D\:\PROGRA~1\Jennison\ETLTaskJobs\Eagle\bin\ExecuteETLTaskEagle.bat EGL_ROLL_BUS_DATE_JOB

machine: job2

owner: autosysR11dev@JACC

permission: gx,ge,wx,we,mx,me

date_conditions: 1

run_calendar: biz

condition: s(jenn_etl_etltask_calendar_synch_dly_eglt,06.00)

description: "Sends request to EAGLE to roll Over the business date"

term_run_time: 1440

std_out_file: $${AUTO_LOGDIR_WIN}\%AUTO_JOB_NAME%.%AUTORUN%.out

std_err_file: $${AUTO_LOGDIR_WIN}\%AUTO_JOB_NAME%.%AUTORUN%.err

alarm_if_fail: 1

autosys@pacsinf1:/opt/CA/WorkloadAutomationAE/autouser.DEV/out

 

 

 

 

[08/21/2014 00:00:17]      CAUAJM_I_40245 EVENT: STARTJOB         JOB: jenn_egl_roll_bus_date_job

[08/21/2014 00:00:17]      <Event was scheduled based on job definition.>

[08/21/2014 00:00:18]      CAUAJM_I_40162 This job's starting conditions have not been met - cannot be started.

…

[08/21/2014 14:41:44]      CAUAJM_I_40245 EVENT: FORCE_STARTJOB   JOB: jenn_egl_roll_bus_date_job

[08/21/2014 14:41:44]      CAUAJM_I_40245 EVENT: CHANGE_STATUS    STATUS: STARTING        JOB: jenn_egl_roll_bus_date_job MACHINE: nydwinjob2

[08/21/2014 14:41:44]      CAUAJM_I_10082 [nydwinjob2 connected for jenn_egl_roll_bus_date_job 588.160393.1]

[08/21/2014 14:41:45]      CAUAJM_I_40245 EVENT: CHANGE_STATUS    STATUS: RUNNING         JOB: jenn_egl_roll_bus_date_job MACHINE: nydwinjob2

[08/21/2014 14:45:42]      CAUAJM_I_40245 EVENT: CHANGE_STATUS    STATUS: SUCCESS         JOB: jenn_egl_roll_bus_date_job MACHINE: nydwinjob2      EXITCODE:  0

 

 

For jobs that have a start_times defined, the event log looks similar (shortly after start_times has passed we see the note that the job's starting conditions have not been met), but when the conditions are satisfied we go right into an EVENT: CHANGE_STATUS   STATUS:  STARTING.

[Mark_Hanson]

I see you have a STARTJOB event at 00:00:17 for jenn_egl_roll_bus_date_job. This is likely based on the run_calendar: biz. That's starting condition 1. There is also a SUCCESS condition set on jenn_etl_etltask_calendar_synch_dly_eglt with a lookback of 6 hours. That's starting condition 2.

 

From the scheduler log excerpt we can see that at [08/21/2014 00:00:17], the 1st condition was met. According to the scheduler condition 2 was not met. If jenn_etl_etltask_calendar_synch_dly_eglt ran to SU within the 6 hour lookback window (you mention 14:37, so that could qualify) then condition 2 should have been satisfied.

 

If conditions continue to not be met as expected it may be best at this point to open a case so we can pursue it further. When opening a case please have the scheduler log, job definitions for all affected jobs and if possible autorep -d reports.

 

Thanks,

Mark Hanson

CA Support

[Legacy User]

What is WAAE?

 

Janet Russell

Sr. Production Control Analyst / IT Operations Department / 814.870.2944 / Cell: 814.323.7301

Work hours: 8-4:30 Monday - Friday

[jhill5.5]

I think it means Workload Automation Advanced Edition.  It's CA's new(ish) name for Autosys.

[Legacy User]

Thank you, I thought that was it but wasn’t sure.

 

Janet Russell

Sr. Production Control Analyst / IT Operations Department / 814.870.2944 / Cell: 814.323.7301

Work hours: 8-4:30 Monday - Friday

[Mark_Hanson]

Actually it is Workload Automation AutoSys Edition

 

The name was changed with the 11.3 release, but AutoSys was (thankfully) kept in the name.

[Anon Anon]

Hi Mark,

 

Example:

BAP-C-CPSRPNA01002TRN1 job having run_calendar:2nd-Fri-445 and Condition:s(BAP-C-CPSRPNA02001PSP5)  without start_times

/* ----------------- BAP-C-CPSRPNA01002TRN1 ----------------- */

insert_job: BAP-C-CPSRPNA01002TRN1   job_type: SAP

machine: BAP_SAP

owner: zautsys@BAP_SAP

permission: me, gx, mx

date_conditions: 1

run_calendar: 2nd-Fri-445

condition: s(BAP-C-CPSRPNA02001PSP5)

description: "Copy Total Forecast to LTP Plan | 03/11/16 185607 | Pramod Patil"

alarm_if_fail: 0

timezone: US/Arizona

sap_job_name: BAP-C-CPSRPNA01002TRN1

sap_client: 940

sap_rfc_dest: BAP

sap_mon_child: N

sap_office: N

sap_release_option: A

sap_step_parms: variant="RP_ZAMMACLTP1",abap_name="/SAPAPO/TS_BATCH_RUN",banner_page=N,release=N,print_imm=N,new_spool=Y,footer=N

2nd-Fri-445

11/06/2015 00:00

12/04/2015 00:00

01/15/2016 00:00

02/12/2016 00:00

03/11/2016 00:00

04/15/2016 00:00

 

Parent job BAP-C-CPSRPNA02001PSP5  completed successfully at 03/11/2016 20:46:09 but BAP-C-CPSRPNA01002TRN1 job not triggered from autosys

after the completion of the parent job BAP-C-CPSRPNA02001PSP5 and we manually force started the child job BAP-C-CPSRPNA01002TRN1

Please let us know why the child job not kicked off from autosys eventhough its parent job completed successfully...

 

Parent job:

 

az18u8886:jr BAP-C-CPSRPNA02001PSP5 -d

Status/[Event]  Time                 Ntry ES  ProcessTime           Machine

  --------------  --------------------- --  --  --------------------- ----------------------------------------

  STARTING        03/11/2016 20:45:29    1  PD  03/11/2016 20:45:29   BAP_SAP

  RUNNING         03/11/2016 20:45:29    1  PD  03/11/2016 20:45:30   BAP_SAP

    <Job Open: Defined and Released>

  [STATE_CHANGE]  03/11/2016 20:45:39    1  PD  03/11/2016 20:45:39   BAP_SAP

    <Active>

  SUCCESS         03/11/2016 20:46:09    1  PD  03/11/2016 20:46:09   BAP_SAP

 

 

Child job:

 

[03/11/2016 21:26:13]      CAUAJM_I_40245 EVENT: FORCE_STARTJOB   JOB: BAP-C-CPSRPNA01002TRN1

[03/11/2016 21:26:13]      CAUAJM_I_40245 EVENT: CHANGE_STATUS    STATUS: STARTING        JOB: BAP-C-CPSRPNA01002TRN1 MACHINE: BAP_SAP

[03/11/2016 21:26:13]      CAUAJM_I_10082 [BAP_SAP connected for BAP-C-CPSRPNA01002TRN1 48860.65829884.1]

 

Is there any autosys configuration requires to automatic run of child job defined with run_calendar,condition without start times

[Anon Anon]

Hi Mark,

 

Example:

BAP-C-CPSRPNA01002TRN1 job having run_calendar:2nd-Fri-445 and Condition:s(BAP-C-CPSRPNA02001PSP5)  without start_times

/* ----------------- BAP-C-CPSRPNA01002TRN1 ----------------- */

insert_job: BAP-C-CPSRPNA01002TRN1   job_type: SAP

machine: BAP_SAP

owner: zautsys@BAP_SAP

permission: me, gx, mx

date_conditions: 1

run_calendar: 2nd-Fri-445

condition: s(BAP-C-CPSRPNA02001PSP5)

description: "Copy Total Forecast to LTP Plan | 03/11/16 185607 | Pramod Patil"

alarm_if_fail: 0

timezone: US/Arizona

sap_job_name: BAP-C-CPSRPNA01002TRN1

sap_client: 940

sap_rfc_dest: BAP

sap_mon_child: N

sap_office: N

sap_release_option: A

sap_step_parms: variant="RP_ZAMMACLTP1",abap_name="/SAPAPO/TS_BATCH_RUN",banner_page=N,release=N,print_imm=N,new_spool=Y,footer=N

2nd-Fri-445

11/06/2015 00:00

12/04/2015 00:00

01/15/2016 00:00

02/12/2016 00:00

03/11/2016 00:00

04/15/2016 00:00

 

Parent job BAP-C-CPSRPNA02001PSP5  completed successfully at 03/11/2016 20:46:09 but BAP-C-CPSRPNA01002TRN1 job not triggered from autosys

after the completion of the parent job BAP-C-CPSRPNA02001PSP5 and we manually force started the child job BAP-C-CPSRPNA01002TRN1

Please let us know why the child job not kicked off from autosys eventhough its parent job completed successfully...

 

Parent job:

 

az18u8886:jr BAP-C-CPSRPNA02001PSP5 -d

Status/[Event]  Time                 Ntry ES  ProcessTime           Machine

  --------------  --------------------- --  --  --------------------- ----------------------------------------

  STARTING        03/11/2016 20:45:29    1  PD  03/11/2016 20:45:29   BAP_SAP

  RUNNING         03/11/2016 20:45:29    1  PD  03/11/2016 20:45:30   BAP_SAP

    <Job Open: Defined and Released>

  [STATE_CHANGE]  03/11/2016 20:45:39    1  PD  03/11/2016 20:45:39   BAP_SAP

    <Active>

  SUCCESS         03/11/2016 20:46:09    1  PD  03/11/2016 20:46:09   BAP_SAP

 

 

Child job:

 

[03/11/2016 21:26:13]      CAUAJM_I_40245 EVENT: FORCE_STARTJOB   JOB: BAP-C-CPSRPNA01002TRN1

[03/11/2016 21:26:13]      CAUAJM_I_40245 EVENT: CHANGE_STATUS    STATUS: STARTING        JOB: BAP-C-CPSRPNA01002TRN1 MACHINE: BAP_SAP

[03/11/2016 21:26:13]      CAUAJM_I_10082 [BAP_SAP connected for BAP-C-CPSRPNA01002TRN1 48860.65829884.1]

 

Is there any autosys configuration requires to automatic run of child job defined with run_calendar,condition without start times

[Mark_Hanson]

Hi  Sandipkumarmahakud,

 

At a glance nothing is jumping out at me to explain why the dependent job didn't run. If you haven't yet, please open a case with support so this can be investigated further. Please attached the event_demon log for March 11 to the new case.

 

Thanks,

Mark

[Anon Anon]

Thanks Mark for your support

 

Jobs are running fine now

 

Mark@

 

I am able to retrieve all last  7 days jobs running in autosys through wcc reports.

 

Is there any autosys command that display the list of autosys jobs that ran last 7 days ?

 

I tried with job_depends –c –j ALL –F  “ 03/14/2016 00:00 “ –T “ 03/19/2016 23:59 “ but not getting clear result

 

 

 

Thanks & Regards,