Around period turnaround variables are not correctly inherited by scheduler (JSCH)

Document ID : KB000092959
Last Modified Date : 08/05/2018
Show Technical Document Details
The issue is described by an example. A scheduler JSCH.VAR contains two tasks. It is the same job, one it is started at 23:58 and one at 23:59:
User-added image
The job JOBS.WIN.VAR contains only a wait for 150 seconds and a print of the value of the variable &TEST#:
User-added image
The script must have set Maximum number of simultaneous executions of this object (short Max parallel) to 1. The variable &TEST# is declared in the Variables tab JOBS.WIN.VAR:
User-added image
The scheduler passes a value of &TEST# in the task properties of both tasks:
User-added image
Both tasks are activated before the period turnaround at 00:00. As they have Max parallel set to 1, the one activated at 23:59 has to wait until after period turnaround to start, as the task activated at 23:58 runs for ca. 150 seconds.
The RunIds and results can be seen here:
User-added image
RunId 1075023 was activated first and started immediately, two minutes before period turnaround at midnight. RunId 1075024 was activated second, one minute before turnaround, and had to wait because of Max parallel. It started at 3 minutes after turnaround. With RunId 1075023 everything is ok. The activation report shows:

2017-11-27 11:58:18 - U00020206 Variable '&TEST#' was stored with value 'Started 23:58'.
2017-11-27 12:00:48 - U00020408 Started 23:58

The first line shows, the value was stored, the second is the :print.

In the report of RunId 1075024, the variable &TEST# was not inherited from the schedule and is empty:

2017-11-27 12:00:50 - U00020206 Variable '&TEST#' was stored with value ''.
2017-11-27 12:03:20 - U00020408

The value is empty and the :print (second line) gives no output.
The root cause is still under investigation by CA development.
The root cause is still under investigation by CA development.