Use Case: Migrating from Terma Jaws to CA Workload Automation iDash

World®
’16
Use Case: Migrating from Terma Jaws
to CA Workload Automation iDash
Antony Askew - Practice Manager - Extra Technology
MFX134S
MAINFRAME AND WORKLOAD AUTOMATION

2 © 2016 CA. ALL RIGHTS RESERVED.@CAWORLD #CAWORLD
© 2016 CA. All rights reserved. All trademarks referenced herein belong to their respective companies.
The content provided in this CA World 2016 presentation is intended for informational purposes only and does not form any type
of warranty. The information provided by a CA partner and/or CA customer has not been reviewed for accuracy by CA.
For Informational Purposes Only
Terms of this Presentation

Abstract
Many CA Workload Automation AE (AutoSys®) customers are looking to migrate from Terma
JAWS to CA Workload Automation iDash (CA WLA iDash).
Extra Technology is one of CA Technologies’ Preferred Partners for Workload Automation
Predictive Analytics, and has defined and created a methodology and toolset for migrating
customers from JAWS to CA WLA iDash.
The first of these was a major financial institution, who was migrated quickly and painlessly from
JAWS to CA WLA iDash. In this session, we and the customer will discuss the challenges that
were met, and the methods and tools used to automate the migration process.
Antony
Askew
Extra Technology
CA Practice Manager

Agenda
INTRODUCTION AND BACKGROUND
WHY MIGRATE? MIGRATION OVERVIEW
LESSONS LEARNED
THE EASY(ISH) BITS: FILTERS, USERS
THE CHALLENGES: SLAS, REPORTS
THE RESULTS
1
2
3
4
5
6

Introduction and Background
§ About Extra Technology:
– Founded in 2007 by ex-Platinum Technology staff
– All CA Workload Automation SMEs, with experience of Financial
Services, Retail, Manufacturing, Public Services, Government
– US, UK, Europe, Middle East and Beyond (Infinity Pending)
– CA WA iDash experience from long before CA Acquisition
– CA’s Worldwide CA WA iDash Education Partner
Who?

Introduction and Background
§ About State Street and CA WA AutoSys:
– Long-established CA WA AutoSys Shop; deep product expertise
– XX CA WA AutoSys instances (version: YY)
– Approximately NNNN job executions per day, across a large estate
– Approximately PPPP Service Users
Who?

Why Migrate? Migration Overview
§ New Environment:
– Upgrades to CA WA AutoSys versions
– Desire to remain within CA Software
– Switch from JAWS to CA WA iDash
– Deploy CA EEM (post CA WA iDash Migration)

Why Migrate? Migration Overview
§ New CA WA iDash Environment Requirements:
– Based on CA WA iDash R12
– Active Directory for Identification
– CA WA iDash Security for Authorisation (Groups and Filters)
– High Availability a must-have
§ Maintain as many JAWS configuration items as possible
– Users/Authorisation
– SLAs
– Reports

The Easy(ish) Bits
§ Filters:
– Based on CA WA AutoSys - Strong naming convention –
“Application Codes”
– Application code is part of CA WA AutoSys Job Name
– Data extract from State Street with App Codes - ~850 App codes
§ Conversion Tool:
– Read Data Extract
– Generate CA WA iDash Filter Definitions to CA WA iDash format files
– Upload in to CA WA iDash - 'idupdate' commands

The Easy(ish) Bits
§ Users:
– JAWS Extract (XML)
– 750 Users defined
§ Conversion Tool:
– Programmatically generate CA WA iDash User definitions, mapping
users to Filters
– Generate CA WA iDash User Definitions to CA WA iDash format files

JAWS
§ System-calculated (automatic - default)
§ Duration (start time + user defined value)
§ Fixed deadline (user defined)
§ Can auto-discover Job Streams (SLAs)
§ (Default) forecasts future Job Streams over
nn hours
The Challenges – SLAs
A Quick Comparison
CA WA iDash
§ Does not auto-discover
§ Requires SLA time parameter per job run
§ Start Time Deadline (user defined)
§ End Time Deadline (user defined)
§ At Risk (user defined)
§ Run Validity (user defined)

§ Define Converted CA WA iDash SLAs as follows:
– All are End Deadline
– All are Disabled
– Where no user-defined deadline time exists, use a dummy value (e.g.
“23:23”)
– No At Risk values
– All Run Validity values to 60
– All ALARMS Enabled
– Define for All Week Days
Make Some Assumptions

§ Conversion Tool:
– Read JAWS XML Data, extract SLA definitions
– System Calculated / Duration: Assumption
– End Deadline: Convert
– Use CA WA AutoSys Job Name as CA WA iDash SLA Name
– Generate CA WA iDash SLA Definitions to CA WA iDash format files

JAWS
§ JobRunHistory 426
§ TargetJobSummary 17
§ ProcessingLoad 16
§ TerminationStatus 4
§ TargetJobDetail 10
§ CriticalPathHistory 2
The Challenges – Reports
A Quick Comparison
CA WA iDash
§ Job Run
§ Job Status
§ Autotrack
§ SLA
§ Latency
§ ALARM
§ CA WA iDash Audit Activity

The Challenges – Reports
§ Conversion Tool:
– Read JAWS XML Data, extract report definitions
– Map Report types where possible:
§ JobRunhistory > Job Runs
§ TargetJobSummary / TargetJobDetail > Job Runs / Job Status
§ ProcessingLoad > Latency
§ TerminationStatus > Job Status / ALARM
§ CriticalPathHistory > SLA
– Generate CA WA iDash Report Definitions to CA WA iDash format files

The Challenges – Post Conversion
§ Subsequent SLA Manual Activities:
– Add/amend deadlines
– Review Days/Calendars
– Add At Risk if required
– Amend Run Validity
– Enable SLAs (carefully!)

The Challenges – Post Conversion
§ Subsequent Report Manual Activities:
– Report Definition / Content Review
– Amend / Delete

The Results
§ Conversion Phase:
– ‘Batch Load/Update’ of configuration items, using CA WA iDash
CLI Tools:
§ Filters: 850
§ Users: 750
§ SLAs: 490
§ Reports: 450
– Each Load/Update took 60-90 minutes

Lessons Learned - 1
§ You must understand that the two products are not the same.
Training is crucial, before you start
§ You must make assumptions when converting configurations
across products
§ Garbage In, Garbage Out. Clean up first

Lessons Learned - 2
§ The CA WA iDash CLI requires close attention
– Example: when using idupdate to create an SLA, there are a couple of
'instance' parameters in the file that must match the instance in the '-i'
parameter
§ Beware report definitions specifying huge job lists, or user
definitions specifying hundreds of filters.
– Configuration data is stored in CA WA iDash within a column of
restricted length
– Wild cards are good, CA EEM is better....sometimes

Questions?

Thank you.
Stay connected at communities.ca.com

Mainframe and Workload Automation
For more information on Mainframe and Workload Automation,
please visit: http://cainc.to/9GQ2JI

Use Case: Migrating from Terma Jaws to CA Workload Automation iDash

Recommended

More Related Content

What's hot (20)

Viewers also liked (17)

Similar to Use Case: Migrating from Terma Jaws to CA Workload Automation iDash (20)

More from CA Technologies (20)

Recently uploaded (20)

Use Case: Migrating from Terma Jaws to CA Workload Automation iDash