2. Who we are
Lands’ End – retailer with sailing roots –
1.4BFY15
• 4 UAC environments TEC, TDQ, PRD, CC
• Production Environment
– 24 agents, windows, unix, z/OS
– >600 workflows, 16,350 tasks
– Over 600,000 task runs each month
3. How we became UAC customers
• The mainframe is going away!
The mainframe is going away!
• We used CA’s ESP for more than 20 years
– Mainframe engine – IPLs affected all workload
• Among the first to move off mainframe
• LE Core Team: Ann as PM, Brian, Mary
Jo, Lisa
4. The Odyssey
Getting to our final go-live with Opswise was a
multi-year effort 2013-2015
• Demos and Request for Proposal (5
vendors/products)
• POC process
– Recreate existing test ESP schedules as
Opswise workflows
• Lost funding
• Regained funding
• Lost time; deadline looms
5. Conversion
• Initial conversion team arrival January 2014
• Decisions galore throughout the conversion
process
• OOPS. Due to internal lack of communication:
Re-converted a sub-set of workload
• It takes a Stonebranch village
– Thanks to Tech Support (Laurie!), Bob ***,
Jackie ***, Tracy ***, Colin ***, and especially
Denis ***
6. Activity During Conversion
• Training for developers
• 9 weeks (2x week) training delivery for
System Operators, also recorded & on
Sharepoint
8. Verification of Conversion
Sub-set of converted code verified line-by-
line
• Core team: 10% of converted workload
• Developers: at their discretion
• Reinforced training in tool
• Raised confidence
9. Cut-Over
• Two cut-overs
– First was small-subset of simple and mostly
independent workflows, Sept 2014
• Interface between scheduler environments
– Second & final cutover Feb 2015
• Around the clock onsite support for a week
• Started Feb 3; contractually required to shut down
old tool Feb 14
10. Lessons about a conversion:
• Involve some developers in your POC – no matter how
busy they are
• Missed accounting for “NOINHERIT” & “NODE” in ESP
• Find a way to keep tabs on changes in old system during
conversion
• (Opinion) Put jobdoc info in a central repository outside
of UAC
11. Life after conversion
• Keep development/QA workload completely
separate from production workload development
• Don’t create anything new* directly in the
production system
• Follow references when promoting
• Don’t allow predecessors to task monitors or
(time-of-day) timer tasks
12. (Some of) What we did right:
Standard Dashboard Series of training sessions
Resource for each agent Recorded training sessions
Resources for online systems Concatenated JCL libraries
Standards for workflows
• Names end in LDATE ${TRDATE}
• ACTION email using variables for
certain status
Standard naming conventions
• Task monitors end in TM
• Resources end in abbrv of type
• Resources representing an agent
named for agent
• File monitors end in FM
• Triggers end in TR
Project manager arranged for food 24x7 during go-live week (big hit!)
13. The BIG Wins
• First night’s processing only 0.03% failures
attributed to Opswise
• Very few problems in converted code since
• Reduced CPU usage on z/OS by ~ 19hrs of
CPU time/month
• Of course $$ savings
14. Some Additional Advantages
Template courtesy of:
www.presentationmagazine.com
Can change commands or parameters in
task instance waiting to run
When z/OS LPAR is IPL-ed, distributed
workload keeps running
Fail-over to passive controller within
minutes
Automatic restarts are easier to code and
easier to identify
More flexibility in how permissions are
defined for users
Not dependent on messages to z/OS
master console
Easier to see # of task monitors running
(rough estimate of remaining workload)
Due to custom dashboard the following is easy:
• Identify Tasks stuck in submitted state
• Notice Late starts / Late ends very visible
• Identify Tasks waiting for resources
• See what is using a resource and what is defined to use it
• See what is currently processing
