Standard Life - App Recovery Overview

7/27/2019 Standard Life - App Recovery Overview

http://slidepdf.com/reader/full/standard-life-app-recovery-overview 1/23

1Internal Use only TATA CONSULTANCY SERVICES



Table of contents

About Standard Life

Organization structure

Application Recovery Overview

Systems and conventions

Incident Process overview

Introduction to USD

Introduction to OPC/A

Filtering Incidents

Introduction to Legacy

Introduction to Endevor

Introduction to Tools

Probrec process overview

Change order creation




About Standard Life Group:

Standard Life is a major asset managing group headquartered in Edinburghand operating across the globe. Established in 1825, Standard Life provides

pensions, investment management, banking and healthcare insurance

products to over 7 million customers worldwide.

Standard Life has over 10,000 employees across the UK, Canada, Ireland,

Germany, Austria, USA and Hong Kong. Standard Life's joint ventures haveoffices in India and mainland China

TCS-SL Relationship Overview:

TCS-SL Relationship has started in the late 90’s with migration projects for

Standard Life Healthcare, Papilon, Life & Pensions where in code wasmigrated from Delta, Assembler, Cobol (16 bit) to Cobol (24 bit). The

Application Recovery project has started in November, 2004.




Organization Structure – TCS/SLEL:

TCS Offshore

Arun Kumar Ayyavoo

(GL)

Anil Kumar (PM)

Prakash / Kumar(PL)

Team Members

ISAR Onsite SLESL

Ralph Fairweather

Alan Wright

John Mike

Strachan Driscoll

(Technical managers)

TCS Onsite

(Prasath Saravanan)

Irfan Mohamed(BRM)




Michael Driscoll

John Strachan

Kenny Mair

Andrew Stewart

Kerr Duncan

+ TCS

Application Recovery

Application Recovery Overview:




Application Recovery Overview:

The objective of the project is to provide application recovery support for

SL mainframe applications belonging to the ISAR queue in USD(Unicenter Service Desk). SL has Critical, Customer High, High, Medium

and Low priority incidents. TCS would be working only Customer High,

High, Medium and Low priority Incidents. As part of the recovery

process TCS will not be making any code changes.

Scope of Support:

Working on USD incidents queue is primary priority. However when

USD incidents queue is quiet, the following are taken up

1. Problem Records assigned by SL

2. Data Collection (metrics)

3. Knowledge Sharing Sessions within the team

Since TCS would be working on the problem records only when there

are no Incidents, there will be no agreed end date for implementing the

problem records. TCS has been providing extended support cover since

Oct 2007.




Onsite scope of work:

• Client Coordination, to help the offshore team solve the daily queries by

interacting with client.

• Interact with the client and get the offshore issues resolved on time.

• To work on new application areas that are not part of offshore and give

knowledge transition to offshore.

• Onsite would cover the support on the major TCS holidays when there is

no support from Offshore.




SLA of incidents:

Customer high priority – 2 hoursHigh priority – 4 hours

Medium priority – 8 hours

Low priority – 16 hours

Normal order for processing incident is

1. Customer High

2. High

3. Medium

4. Low

Incidents with mainframe job failures, transaction failure (not starting with

BQ and GW), workstation XCOM job failures will be considered for taking

up.




System / Subsystem Classification:

IMS Subsystems:

IMSA - 90% of the jobs run in this region

IMSB - Obsolete

IMSC – Production region (Minimal no. of jobs run on this, jobs using SAS

etc…)

IMSDEV - Development region

DB2 Subsystems:

DSA - Production region – 90% of the jobs run on this region

DSH – 10% of the jobs run on this region

DSN – Development region






Commonly used datasets:

All the information about the job is available in following libraries

OJ.MASTER.DOCOPER

OJ.UPDATE.DOCOPER (About to move into production)

Description of the applications is available in following libraries

OJ.MASTER.DOCAPPL

OJ.UPDATE.DOCAPPL (About to move into production)

Production JCL’s reside in

OJ.MASTER.JOB

A1.MASTER.JOB (About to move into production)

Production PROC’s reside in

OJ.MASTER.PROCLIB

A1.MASTER.PROCLIB (About to move into production)




Cobol programs in production exist in

NAE.PROD.SOURCE

Copy books in production exist in

NAE.PROD.COPYBOOK

Program list of production programs exist in

NAE.PROD.**LIST where ** is the system name that can be found from

Endeavor

Internal Use only TATA CONSULTANCY SERVICES 12



Usage of Group ops ID:

Group ops id is used to

• Edit a dataset

• Rename or back up a dataset

Categorization based on type of fix:

The problems that are encountered in application recovery may

require

• Data fix

• Code fix




Points to consider in resolving incidents

• When ever an incident is accepted, keyword ‘TCS’ needs to bespecified at the end of summary description.

• If a Job under an application fails then all the failures related to thatapplication should be accepted by the person who has accepted theoriginal incident.

• To work on an incident in the queue, first we should accept theincident.

• When we pass incident to CSSI or other teams for investigation on aparticular policy, that policy number should be mentioned in the latest

update.

• Whenever an incident is accepted, first update should be kept ASAP.




How to USE USD (Unicenter Service Desk)

USD is a tool useful to create, update comments, update status of the

following. USD is also useful to transfer the incidents from one group to

other group.

i.Incidents

ii.Problem records

iii.change records.

USD is replaced with old application called SOLVE. USD training manual

can be referred for more details.




OPCA (OPERATION PLANNING CTRL & AUDIT)

• OPCA is a tool used to check the status of the Job/Application,

or to rerun the Job etc. in mainframe

• Applications run on OPC/A are accessible from TSOB. Applicationsrun on OPC/K are accessible from TSOK.

• OPCA is used to modify the current plan of the Applications

or to edit JCL of the Job. Even a new job or application can beadded to run at required time

• Used to check the Special Resources and Dependencies

of the Jobs.

• Used to check workstation job logs.

To access OPCA, logon to TSOB and enter 9.o at ISPF Primary Menu.

OPC-A scheduler document in attachment can be referred for moredetails




FILTERING Incidents creation

Filtering is a way of reducing unnecessary incidents beingcreated. Sometimes, in addition to main incident, duplicate

incident will also be created. The duplicate incident appears like

‘Error in program xxxxxxxx’. The duplicate incident will

sometimes be useful for knowing error message, some times the

duplicate incident will not be useful. In case the duplicateincident is not required, Filtering can be applied to avoid

duplicate incidents.

Filtering document in attachments can be referred for more

details




INTRODUCTION TO LEGACY

• Legacy contains all the information about Jobs, Programs, Datasets, etc..For example, to know the jobs that use a particular dataset, Legacy can be

referred

• Legacy is active in TSOB.

• To invoke Legacy, enter TSO Legacy at ISPF Primary Option Menu.

Legacy document in attachments can be referred for more details




INTRODUCTION TO ENDEVOR

Endeavor is useful for promoting components into production.

• Various environments in Endevor are:

Production

Acceptance

System Testing .• Each program is considered as an element in Endevor.

• Endevor is accessible from TSOD.

• From TSOD ISPF Primary Option Menu, hit 9.ndv to go to Endevor.

•Endeavor process document in attachments can be referred for more

details




INTRODUCTION TO TOOLS

There are Various tools that are used for Application Recovery.

1. Abend-aid

2. Platinum

3. File-aid

4. PAS

5. x-peditor • Abend-aid is a tool used to view the data from dump in a formatted way. It

shows the previous and current record of files of a failed job.

• Platinum is used to browse/view the DB2 tables.

• File-aid is used to view the files in a formatted mode.

• PAS is used to find the past job details information.

Introduction to Tools document in attachments can be referred for more details




Problem Records

If a Job is failing often we give permanent fix or solution to the Job

by creating a problem record.

Notes:

a. If problem has been caused by a recent software change, go back to

developer to arrange a fix – only cut a problem record if this is not an

option.

a. No problem record should be created for OPCA changes. They should

be passed to the Schedulers q (SC OPSUPP).

c. USD incidents should not be passed to developers to deal with .

These should be retained by ISAM. If the recovery action is complete, but there

are still actions outstanding, then a P/R should be created by mentioning the incident

into it.

d. A P/R should still be created where it is for a KNOWN PROBLEM, but it is not

deemed worthwhile to progress a fix. These should not be closed unless a fix has

been applied.




Change orders

If an incident recovery needs a component (e.g. Program) change, then

a change record will be created to implement the program change

into production. Following is the process.

a. Make changes to the component and keep in local dataset

b. Create a change order request and get a change number

c. Create endevor package for the component change

d. Request Alen Wright to submit the change

e. Request change request group to implement the changef. Request operation group to implement the package into production

g. Once the change is successful, close the change order request




APPENDIX A

Abbreviation – Description:

TCS – Tata Consultancy Services

SL – Standard Life

SLA – Service Level Agreement


Documents

Standard Life - App Recovery Overview