SYSchange Compliancy and Deployment

Presentation on theme: "SYSchange Compliancy and Deployment"— Presentation transcript:

SYSchange Compliancy and Deployment By Pristine Software

International Software Company (June 2016)

Agenda

What is SYSchange?Fundamental Capabilities of SYSchangeSYSchange Started Task (STC)SYSchange TokenizationSYSchange Promotion Package and DeploymentAdvanced Deployment Discussion Why SYSchange for z/OSApplication by Current CustomersTop 10 Uses of SYSchange

2

What is SYSchange ?

SYSchange is a comprehensive software configuration management (SCM) tool for tracking, controlling, and managing changes in software. It is an advanced software deployment tool designed to synchronize software in z/OS environments. SYSchange capabilities achieve a more resilient IT system. Used by medium and large data centers with multiple LPARs and SYSPLEXes to control and manage system-wide changes and to synchronize their environments

3

SYSchange Integrated Components

Compliancy ManagementEnables data centers to achieve a compliant mainframe environment; Ability to capture systems software changes in real time. This includes the OS, all IBM subsystems (IMS, DB2, CICS,…), all ISV products, production libraries – Anything that runs the System.Deployment ManagementAbility to identify software changes automatically, and to package and deploy the changes across multiple systems, LPARs and SYSPLEXes.Developers Workspace Enables application developers to compile and generate code in a secured environment and move the code via packaging and promotion. A low cost alternative to Application Change Management solutions.

4

Fundamental Capabilities (1 of 4):The SYSchange Started Task (STC)

STC

SYSA

STC

SYSB

STC

SYSC

Control /Data

Files

Audit REPORT

SYSPLEX

VIEW, COMPARE or RECOVER Versions

5

Email

Fundamental Capabilities (2 of 4):The SYSchange Tokenization Engine

The

powerful SYSchange tokenization technology establishes “content” reference tokens for a fileA token represents the content of a file: PS or DA files, members of a PDS or PDS/E, files in HFS, USS, or z/FS pathsTokens are stored in the SYSchange Control File, or optionally to an external file

Fundamental Capabilities (3 of 4):The SYSchange Packaging

From

a pre-tokenized software environment, changed components are

identified

and

packaged

automatically

mitigating risk of losing a change

Custom packaging allows users to

selectively

package

their developed components from multiple

libraries

Custom packaging does NOT require environments to be

pre-tokenized. Systems administrators

select the components to be packaged together in a

“Promotion Package”

and made ready for

promotion

A group of data sets may be placed in a “Promotion Package” for an “initial” install

Member DELETE and data set SCRATCH entities may also be packaged

An ISPF interface facilitates building of “Promotion Packages”

Fundamental Capabilities (4 of 4):The SYSchange Promotion Packages

A “Promotion Package” is a single file containing a variety of file types and structures: Source, Load, Panels, Messages, Skeletons, JCL, USS files, PS and DA files

Promotion packages are well documented - the embedded documentation establishes communication among the people involved in the deployment process and is used for future reference. They

provide

accountability for systems administrators and systems managers.

A

“Promotion Package” contains data, user documentation, and the

intelligence

for

automation (e.g. for data sets to be allocated as NEW, DSCB information is stored in the package itself.)

Promotion packages are transferred to other LPARs or SYSPLEXes using NDM, FTP, or any other

tool.

Once transferred, they can be promoted to update the target

systems

When a package is successfully promoted on an LPAR , the package is “registered” in the Control File of the target

LPAR. The

SHOW=PACKAGES

command reports all successfully promoted packages on an LPAR; providing for full accountability and control

Advanced Deployment Discussion

SYSchange enables data centers to create a “Centralized Point of Control” for deploying all software changes to keep environments current and up-to-date

SOURCE

Deployment Process

Promote

Promotion Package

SOURCE

LOAD

JCL

Promotion Package

LOAD

JCL

Promote

LPAR 1

LPAR2,..LPARn

10

Promoting a Package to Update Target Systems

A “Promotion Package” may be reviewed for member-level details of the content.

Promotion packages are well documented. The embedded documentation establishes communication amongst people involved in the deployment process and is used for future references.

“Promotion Packages” are kept for future references. It provides accountability for systems administrators and systems managers.

When a package is successfully promoted on an LPAR , the package is “registered” in the Control File of the target

LPAR

The SHOW=PACKAGES command reports all successfully promoted packages on an LPAR; providing for full accountability and

control

Promoting a Package (Rollback Option)

When a package is promoted, a rollback package is created first. Then, the target environment is updated

Verify Success of Deployment

Verify success of the deployed

packages by tokenizing and then comparing the token files

Achieve

large scale software integrity verifications by comparing environments of any configuration and size (z/OS

files and USS paths)

Comparing

two data sets, two groups of data sets, two entire DASD volumes, or two groups of DASD

volumes either

directly

, when they are available on the same CPU, or

indirectly

, using their token representations when they reside on multiple LPARs or SYSPLEXes

Identify and report missing data sets between the two groups.

Identify and report missing members in pairs of matched data set names.

Identify and report members having different contents.

SYSchange High-level Compare (local/remote)

High-level compare of two libraries, two groups of libraries, two DASD volumes, or two groups of DASD volumes (local or remote

)Missing data setsMember-level report: SAME, DIFF, MATCH, MISMATCH and MODS

PDS1

“High-level Compare”

PDS2

DIFF

A

DIFF

B

How SYSchange Prevents Regression

Tokenize a software environment

after a sync point, and

store the tokens into an external token file (OLD token file

)

Re-tokenize the same software environment

just prior to updating the environment

(i.e. promoting a package)

and store the tokens into a second token file (NEW token file

).

Now compare the two external token files (NEW vs. OLD) to discover undesired or unplanned

changes; under normal conditions we expect no changes to appear in the report (RC=0). Otherwise, there is a risk of regression and the promote operation must be handled with care, excluding the reported changed components from the promotion process.

Implementation

SYSchange can be implemented by simply performing two

tasks in order

to start using the software from day 1:

Protect

your critical system

libraries

PARMLIB, PROCLIB, etc.

Some customers have protected more than 300 systems and vendors

libraries

Tokenize

your software

environments

Any desired data set patterns such as: DEV.ZSECURE.*

Any size software environment such as the entire production libraries; some customers have tokenized over 5000 production libraries for their weekly “change control” meetings.

An entire DASD volume such as a SYSRES

Protect Critical System Libraries

PROTECT your critical system libraries to achieve auditability, version control and exclusive component ownership. LOCK=YES or NO INITIAL=YES or NO//JOB1 PROTECT=(DSN=SYS1.PARMLIB, LOCK=YES, INITIAL=Y, COPIES=30)//*

PROTECT

SYSchange STC

Source

Load,

JCL

Change History

Tokenize your software environment

Prior to change, TOKENIZE your software environments of any size and configuration to establish the reference tokens.At a later time, use the SYSchange MODS identification function to automatically identify, report, and package the changed components.Then, use the SYSchange Promotion Packages to synchronize your software on a local or remote LPAR(s). //JOB PATTERN=DEV.ZSECURE.* . . . SHOW=LIST TOKEN=(LIST)//*

SYSchange

TOKENIZE

Source

LOADJCL

Tokens

Library Management Functions (Create a CR)

Assign administrators to a library at PROTECT //JOB PROTECT=(DSN=APPL01.SRC, INITIAL=YES,COPIES=30, LOCK=YES, ADMINS=(IBMUSR1,IBMUSR2)) //*Any one of the Library ADMINS may creates a CR and assign the CR Approver(s)The CR Approvers, in turn, approves the CR making the components in the CR to be solely available to their owners i.e. “Checkers”The CR Approvers, in turn, approves the CR making the components in the CR to be solely available to their owners i.e. “Checkers”Development of the CR begins while the assigned users have exclusive ownership over membersAt the end, one of the Admins “Checks in” the developed components; the “Promotion Package” is created automatically

Locked Source

Why SYSchange for z/OS?

To create a more resilient IT Environment

To create environments with Segregation of Duties (SOD); allowing a

RACF

group of users to

Create Packages

and a separate RACF group to

Promote the Packages

.

To bring an automated process and transparency to System Software Change Control and Management (z/OS, IMS, DB2, CICS and vendors software) in SYSPLEX environments

To reduce the costs and complexities of meeting Auditing and Compliancy Requirements by providing a process and a control structure

To improve quality and reliability by quickly ascertaining what has changed in a very large software environment and to reduce outages

To create an environment that promotes software integrity, added security, and reliability

How SYSchange is used? (1 of 2)

To achieve

compliancy

requirements (e.g. Sarbanes-Oxley), and to provide full reporting capabilities for z/OS and USS software changes

To establish a

uniform process

to deploy software across environments

To

recover

from undesired changes to systems; reducing system outages and to resolve performance issues

To

allow

or

enforce

documentation

of member-level changes as the change is introduced to improve systems administration

Ensures integrity of software in multiple local and remote

LPARs and SYSPLEXes

How SYSchange is used? (2 of 2)

To improve

reliability

,

to eradicate

uncertainties, and

to reduce time

and resources to deploy

changes

To gain

exclusive ownership

over groups of library members to individual users, or to RACF groups; sharing of a library amongst multiple groups (MVS, CICS, IMS, DB2, …) without

intruding on each other’s responsibilities

To discover

system-wide changes

for change control review team

To compare

any size

software environments on local or remote LPARs and SYSPLEXes

To regularly

synchronize

software in multiple SYSPLEX environments (e.g. a hot DR site with the production site)

To

reduce operational risk and cost of software maintenance

Top 10 Uses of SYSchange (Summary)

Change Tracking and Control for Systems Libraries and Issuing Emails for changes

Software Deployment and Release Management

Member-level Recovery of Real-time Changes

On-line Documentation of Changed Members at the Time of Edit/Save

Exclusive Member-level Ownership, and Source Library Management

Detect System-wide Changes for z/OS and USS Environments

Local or Remote Compare of Software Environments for z/OS and USS

Regularly Synchronize DR Software with the Production Software

Regression Control and Prevention to complement all ALM Software

Immediate Rollback Capabilities to UNDO the Effect of Unplanned/Undesired Promotions

SYSchange Installation (version 4.2)

Upload only one XMIT PDS and RECEIVE it

Installed with SMP/E or IEBCOPY

Plan for an APF Authorized Library

Plan for an MLPA for the Intercepts

Customization of

a PARM

member

SYSchange VSAM Files Initialization on Shared DASD

SYSchange ISPF CLIST and CSAVE CLIST

Invoke the Software (No IPL required)

No complex new RACF rules and no staging libraries

SYSPLEX support (Sharing VSAM Files)

SYSchange for z/OS by Pristine Software

Email

for support:

support@pristineUSA.com