Download - Migrate from Terma Software Jaws to CA Workload Automation iDash for Enhanced Workload Analytics

1 © 2015 CA. ALL RIGHTS RESERVED.@CAWORLD #CAWORLD

Migrate from Terma Software Jaws to CA Workload Automation iDash for Enhanced Workload Analytics

Jack McCarrick

DevOps: Continuous Delivery

eCLARO, Inc

Senior IT Consultant

DO4X178S


© 2015 CA. All rights reserved. All trademarks referenced herein belong to their respective companies.

The content provided in this CA World 2015 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

Do you have the right tools to predict when SLAs might

be at risk? Join us and hear first-hand about how a

major technology company converted from JAWS to CA

Workload Automation iDash (CA iDash) to adopt a

powerful, real-time workload analytics and reporting

solution.

Jack McCarrick

Senior IT ConsultanteClaro, Inc.


Agenda

MY BACKGROUND & OUR “WORKLOAD AUTOMATION” ENVIRONMENT

WHAT IS OUR “JAWS” ENVIRONMENT?

SUMMARY AND QUESTIONS

WHY DID WE CHOOSE IDASH?

MOVING FROM JAWS TO IDASH

IDASH ADVANTAGES: SOME NICE FEATURES

1

2

3

4

5

6


My Background&

our “Workload Automation”Environment


My Background….

eClaro, Inc.– ECLARO is a Business and Technology Consulting firm headquartered in

New York City with 14 offices across the United States, Canada and the Philippines.

Working through ECLARO since 1998 at a large technology company (headquartered in Long Island, NY)

I came out of the IBM Mainframe era! Started in 1974 with OS/360 and progressed onwards! (Lots of Dinosaurs!)


My Background….

IDMS Database– DBA 1998 (1982) thru 2014 on the Mainframe

– System support (same period)

”CA Workload Automation AE (CA AutoSys®)” Admin– Since 2004

– Release 3.4 to Release 4.5 conversion

– Release 4.5 to Release 11.0 conversion

– Undergoing upgrade from R 11.0 to R 11.3.6

JAWS Admin and (now) CA iDash Admin


Our CA AutoSys (“Workload Automation”) Environment

Running Release 11.0 and Release 11.3.6, concurrently

Workload Control Center (CA-WCC): running with all CA AutoSys instances– WCC Release 11.0 – we use ‘hard coded’ EEM Policies

– WCC Release 11.3.6 – we employ ‘behind the scenes’ EEM Policy code

– (this has impact on use of EEM with CA iDash – topic for another day!)


Our CA AutoSys Instances:

“ACE” Name

CA AutoSys Environment

# Jobs # Runs/Day

“SVU” 11.0 TRN 27,600

“SVT” 11.0 DEV 36,200

“SVQ” 11.0 QA 28,400

“SVP” 11.0 PROD 26,000 500,000

“DV1” 11.3.6 Dev 8,600

“QA1” 11.3.6 QA 8,700

“PD1” 11.3.6 Prod 8,700 25,000


”What is ourJAWS

Environment?”


Our JAWS Environment

JAWS “Prod” and “Test” Instances– Both 64 bit

– Prod is Release 3.5.6; Test is 4.3.4 (fairly ‘old’ releases)

PROD JAWS: all production Job Streams– Approximately 130 job streams

– 70 job streams are monitored by Users (we have had a ‘hard sell’)

TEST JAWS: used for Admin ‘testing’– Applying patches, upgrading the release, etc


Focusing on our “Prod” JAWS Environment

About 50 User tailored Reports

Mainly used to issue SNMP output to generate emails– “Job Stream Late” Alerts are 99% of those received

“Real Time” monitoring not particularly used

History: used, when needed, to ‘look back’ and investigate job runs, etc


”Why did we chooseCA iDash ?”


What made us choose CA iDash to replace JAWS?

IT Management decided:– To switch to a product that was more integrated with existing licensed

CA Software

– IT Management wants to maintain relationship with CA (stay in “CA Family”)

– CA Tech Support was a major factor (same company)

Cost was comparable: CA iDash was about 15% more to license– But……….

“LICENSING”:– This was a factor in our decision (see next slide)

Cost & Licensing


LICENSING: CA iDash vs JAWS

Licensed by “Number of CA AutoSys Jobs” Right now, our license is for 100,000 jobs JAWS Prod is set up for 60,000 JAWS Test is set up for 40,000 One JAWS instance can ‘see’ mutiple CA AutoSys instances

(depending upon the license for that particular JAWS)

‘JAWS’

License NOT limited by “Number of CA AutoSys Jobs” No limit to number of CA iDash instances

Currently, two (2): CA iDash ‘test’ and ‘prod’ Will create a ‘sandbox’ CA iDash R12 Instance

One CA iDash instance can ‘see’ mutiple CA AutoSys instances (no limit with regard to number of jobs)

‘CA iDash’

“No Limit to CA iDash Instances gives GREAT VALUE to its cost, even if it is slightly more than JAWS”


What made us choose CA iDash to replace JAWS?

Ease of Installation & Use

Configuration for use is simple

User Interface very friendly

Reporting features

Other factors…..


CA iDash at my current Client:

Currently, TWO CA iDash instances– “Prod”: sees CA AutoSys SVP & PD1 (Prod Release 1.0 & 11.3.6)

– “Test”: sees CA AutoSys SVP, SVQ, QA1

– We could ‘mix and match’, pretty much at will

– We could easily install another CA iDash instance (no license limits)

– Installations are 64 bit

We shall install CA iDash Release 12 to explore (as of 9/25/2015)


Converting JAWS Job Streams to CA iDash “SLAs”

“Aim for the Target (job)”– Find name of TARGET JOB (eg: C_ZZBJ0140010)

Supply the JOB NAME– Use the “SLA Helper” ( a Wizard); follow screens

– CA iDash reads job information; takes just moments

– Give the new SLA a name (if you wish it to be different from Job name)

You are Off and Running (“in a (i) Dash”) !

“I created 40 SLAs (former Job Streams) in about two (2) hours”…Jack


Converting JAWS Job Streams to CA iDash “SLAs”

“We have COMPLEX Job Streams”– In JAWS, the LEARNING CURVE was ‘lengthy’

– All our night batch streams required heavy TRIMMING, just to make the flow view ‘humanly understandable’

– Trimming took many hours, resulted in a “Critical Path” view

CA iDash “SLA” generation:– The WIZARD is a great “plus”

– Generation of SLA job flows takes moments (for complex flows)

– You get the Critical Path (“trimmed”) view AUTOMATICALLY!

– Thus, NO learning curve (or, not as much) !


SLA Created !

CA iDash Created this

SLA Definition in

about 3 seconds

“SLA creation seems

markedly faster than Job Stream generation”


Converse: SLA Deletion? – “Admin performance”

“Saves time for the CA iDash Admin”“SLA DELETION is quick! Even if the

full SLA structure is complex”


You can get Run History right away !


“CA iDash Advantages”


CA iDash “SLAs” vs JAWS “Job Stream”

The SLA is already TRIMMED! (default)– JAWS job streams, especially if ‘complex’, require effort (man hours) to

edit down to a recognizable view

– CA iDash does this automatically

– Saves time in SLA preparation (“it can save hours of work”)

– Less of a ‘learning curve’ for the CA iDash Admin

Now, CA iDash does maintain the complexity internally…..


CA iDash “SLA” - automatically TRIMMED:

The “trimmed” SLA is called

the CRITICAL

PATH

This is about one-third of the graphical view of

the Critical Path

(done for presentation purposes)


..same CA iDash “SLA” - the full monty !....

This is about 1/10 of the full graphical view !!


We also like this….

SEPARATION of Job Flow and GANTT displays

JAWS:– Combined into ONE display

CA iDash:– Job Flow display

– GANTT display


JAWS

This GANTT display also indicates a ‘semblance’ of the actual Job Flow


CA iDash:

This Job Flow display shows the static dependencies


CA iDash:

”GANTT” display of same Job Flow


CA iDash “Real Time” Monitoring

Similar to

JAWS


Btw…here is that same flow, FULL display

“Critical Path Distilled”


CA iDash “Reporting”

Similar to JAWS, CA iDash has ‘shells’ of report types:– Job Status Reports - CA AutoSys Event Reports

– Job Run Reports - SLA Trend Reports

– All are TAILORABLE for your needs

Have you ever had users ask for CA AutoSys information?– “I find myself using CA iDash more than I did JAWS to satisfy requests”

– “When did job XYZ run last week?”

– “I need all job Failures from 6am to 8am last Thursday”


CA iDash “Reporting”…..continued

“Server Statistic Report”– Gives you Graphical and Detail views (not in JAWS)

– Reports upon LATENCY automatically!

In JAWS reports, you must ‘deduce’ latency to some extent

(see examples on next slide)

Reporting features not available in JAWS.


CA iDash “Reporting”…..LATENCY


CA iDash “Reporting”…..EVENT


CA iDash “Reporting”…..Detail (Latency & Events)



“CA AutoSys AUTOTRACK Reports”– (one of my favorites!)

When I am asked ‘who Force Started a job on Nov 1st ?” Go to CA AutoSys LOG, extract (grep) the log records for job and date/time

Verify the event/run (force start)

The LOG does NOT have the User ID who Force Started job

But.. Autotrack does …..so, I run an Autotrack ‘scan’, create a file

File has event (FORCE_START) and some user IDs

I have to ‘match up’ the LOG and Autotrack date/time and ESTIMATE!




“CA AutoSys AUTOTRACK Reports”– (one of my favorites!)

CA iDash does that work automatically– Specify job(s), date range, etc., and…..

– Out comes your report!

– It’s as easy as that – and saves research time!

(As with all reports, output can be HTML, XLS, PDF, CSV)



CA iDash “Reporting”…..my favorite (not in JAWS)


CA iDash - “Building Job History”:

“Here’s another feature we like a lot!”

Both JAWS and CA iDash need CA AutoSys job history to function

CA AutoSys generates Job Run, Event, Audit history (once a day)

Both JAWS and CA iDash read this data (series of files)

For JAWS, these files (“they can be quite large”) are COPIED from the CA AutoSys server to the JAWS server to be read


CA iDash - “Building Job History”: (continued)

For CA iDash, you have an option:– Install an “CA iDash Agent” on your CA AutoSys server

– Then, from your CA AutoSys server, run the IDARCHIVE command

– IDARCHIVE will load the history data from where the files reside!

– You don’t need to COPY the history data

– (SAVES THE COPY EFFORT, AS WELL AS DISK SPACE)

– You can even run the IDARCHIVE command in an CA AutoSys job!

“This is an CA iDash Admin feature we like a lot”


Example: CA iDash could do this, JAWS could not

Request: if the Target Job runs over 60 minutes– In this case, JAWS will **NOT** “TRIM out” the Parent jobs

– Job Stream monitoring MUST start at 12:00am, not 2:45am

– JAWS tends to monitor ‘job flows’


CA iDash: single job SLA was NOT an issue:

“Just select the “SLA” Job and let CA iDash monitor it!”


CA iDash: single job SLA: (part of job flow dependencies)

“The SLA Job (in blue) is tracked.

But, CA iDash still knows about all the previous dependencies in the entire job flow!”

CA iDash can track Job Flows or SINGLE jobs


SUMMARY: (my own interpretation)

Not trying to push CA iDash over JAWS – both are great products!

But, if you are curious, have an interest in CA iDash…. then…– I definitely recommend to have a look at it!

– If you are a JAWS user: install CA iDash and test it out

– CA would gladly do a Proof Of Concept install for you

– You will definitely find things you like!

– Even if JAWS and CA iDash ‘come out even’, perhaps LICENSING could be a deciding factor

– If you run CA AutoSys (WA) or CA 7®, CA iDash will complement them!


What would I like to see in CA iDash! (current: R 11.4)

REPORTING: select criteria are Jobs, Machines, Statuses, etc,..and DAYS! (eg: Nov 16th to Nov 20th)– it would be nice if we could restrict to specific hours or ‘windows’ of

time in a day

– For example: “All Mornings last week”

SNMP: include additional SLA fields that can be trapped by network monitors such as NNMi and Open View (“give email recipients additional info about their SLA”)

Thank You


Follow Conversations At…

CA Workload Automation

Mainframe Theatre

CA Workload Automation iDash

DevOps Continuous Delivery Theatre

Thursday 1:00PM


For More Information

To learn more, please visit:

http://cainc.to/Nv2VOe

CA World ’15

http://cainc.to/Nv2VOe

http://bit.ly/1wbjjqX