CA Tuesdays Tip By Stacey Ruggier Sr Support Engineer
The following CA Workload Automation PTFs were published on 30-Jul-2014
CA Workload Automation AE r11.3SP1:
Published PTF # | TestFix/PIB | Problem Number | Hyper | Prereq / Coreq | Platform | Problem Description |
RO71970 | T43B538 | 4202 | YES | Prereq: RO68486 | Linux | LNX-FIXES POST 11.3 SP1 INCR3 |
RO71972 | T43B540 | 4202 | YES | Prereq: RO68504 | Solaris-Sparc | SUN-FIXES POST 11.3 SP1 INCR3 |
RO71971 | T42B272 | 4202 | YES | Prereq: RO68505 | Windows | WIN-FIXES POST 11.3 SP1 INCR3 |
RO71973 | T43B542 | 4202 | YES | Prereq: RO68506 | HPUX | HP -FIXES POST 11.3 SP1 INCR3 |
RO71969 | T43B541 | 4202 | YES | Prereq: RO68507 | AIX | AIX-FIXES POST 11.3 SP1 INCR3 |
The above PTFs are available for download from “Download Center“ page on CA Support Online.
For more information on your CA Workload Automation product please visit the products home page on support.ca.com
https://support.ca.com/irj/portal/anonymous/prddtlshome?productID=8104
FIXES POST 11.3 SP1 INCR3
----------------------------------------------------
Since the release of WAAE 11.3 SP1 INCR3, CA has
become aware of what seem to be isolated
incidents reported by several customers who have
implemented 11.3 SP1 INCR3.
Following are issues addressed in this fix:
01. BOX RUNS BUT ITS DECENDENTS DO NOT RUN
When restarting a new run of a box after
completing a previous run, the scheduler may not
reset all the jobs in the box to ACTIVATED. The
jobs in the box that are not reset do not execute
at their scheduled start time and the top level
box remains in the RUNNING state indefinitely.
This issue is observed when users take manual
JOB_ON_HOLD actions on children while boxes are
running.
User kills or sends INACTIVE event to the
high-level box and force starts, it causes the
jobs to run fine.
Detailed autorep reports will show jobs in boxes
having the previous run number while the top
level box has a new assigned run number. The top
level box remains in the RUNNING state
indefinitely and manual intervention is required
to complete the box run. One visible indication
in the scheduler log may be the appearance of the
following catalog messages:
CAUAJM_I_40245 EVENT: STARTJOB
CAUAJM_I_40154 Already scheduled job Cannot start
job.
This issue affects multi-level box jobs (boxes
within boxes).
PROB#: 4184
02. JAVA SDK DUP WHERE CLAUSE
Duplicate, superfluous WHERE clauses can be
generated when using the Java SDK and making
calls to GetAlarmsWithFilterReq (or any of the
GetXXXWithFilterReq APIs) when the Filter has
either an AND or OR filter inside another AND or
OR filter. The lower filter has its AND/OR clause
duplicated in the resultant WHERE clause on the
Application Server.
This can also be manifest by WCC monitoring views
that have complex filters applied to them.
Example:
From within WCC creates a JSC View with an Alarm
filter that queries for 10 specific types of
Autosys Alarms. Save the view and refresh it, the
query sent to the Application Server will be
unnecessarily long/complex.
These superfluous WHERE clauses can cause the SQL
to execute much more slowly than it should,
perhaps causing timeouts or an unresponsive
Application Server. The long WHERE clauses will
show up in the Application Server log file when
there is a trace level of LIGHT.
The Java code may experience timeouts, the WCC
views many not refresh, and the Application
Server may appear to be hung and require a
restart.
PROB#: 4191
03. MULTIPLE FORCESTARTS CAUSES SCHED TO CORE
When multiple FORCE_STARTJOB events for the same
job are processed by the scheduler, a timing
issue causes the scheduler to access invalid
memory and abort ungracefully.
The scheduler aborts shortly while processing a
FORCE_STARTJOB event. The scheduler log should
show that it is processing multiple
FORCE_STARTJOB events.
The job flow is halted when the scheduler cores.
PROB#: 4202
04. ON_HOLD CREATES BAD BOX RUN
Jobs in a box do not execute with the proper run
number when they are taken OFF_HOLD.
When a box job has auto_hold attribute set, jobs
inside the box will not start even when the box
job goes into RUNNING state and JOB_OFF_HOLD is
issued.
Detailed reports shows that a job ran under the
previous run number with an incremented ntry
value.
Historical job reports may show as jobs as
missing from a box run.
PROB#: 4196
Below issue was a known issue prior to 11.3 SP1
INCR3. During rigorous testing of this fix, it
was found to be fixed partially in 11.3 SP1 INCR3.
So the partial solution has been removed and the
complete solution is being targeted for the next
published maintenance of 11.3.
JOB STATUS OUT OF SEQUENCE
When CA WAAE is running in Dual-Server mode,
scheduler copies the missing events from one
database to other database. If a RUNNING event is
copied from Secondary database to Primary
database, then scheduler may process the RUNNING
event after SUCCESS event due to wrong event
number, it will lead to job stay in RUNNING
status forever. It is intermittent issue.
PROB# 3866
Notes:
- This fix is generated off the r11.3 SP1 INCR3
code base. Applying this fix may potentially
regress any testfixes you have received and
applied above r11.3 SP1 INCR3. Please contact
CA technical support should you have any
questions or concerns in this area.
- This fix must be applied on machines having
Scheduler, Application Server or SDK(WCC).
It is not applicable to other installs.