Data Center Management Systems
Change Control System - Technical Overview
Complying with Sarbanes-Oxley
is of critical importance to IT. IT must demonstrate that they have implemented
the needed internal controls dictated by the Sarbanes-Oxley regulations
compliance act. CCS provides the needed automation, security, controls and
audits to insure compliance for the for the Application Development Lifecycle.
Today's software application environment is becoming increasingly
complex. Application software managers are required to understand and
manage very complex relationships that exist among all components of an
application. Additionally, as the software development process continues
to become more sophisticated the desirability and increased use of shareable
and reusable modules will increase this complexity ten fold.
Information Technology management is also faced with the responsibility for
insuring the continued integrity of the corporations software application assets
in this complex and changing environment. The days are long gone
when you can legally or financially afford to rely only on trusted
employee's memories and questionable manual documentation to insure that all of
your corporations source code, copy books, reusable modules, documentation,
JCL, module relationship documentation, module recreation processes,
etc., are properly accounted for and documented. Increasing enforcement
and adding additional manual procedures only slows the development process
and manually maintained documents are seldom useful, current, available
To properly secure and effectively manage today's software environment
requires that the software change process be automated as much as possible.
There are many, many issues surrounding software development, documentation,
availability, implementation, reliability, serviceability, protection
that need to be resolved. If your company is experiencing one or more
of these issues, it may be time to consider an alternative to your current
production implementation system:
- You are concerned that not all of your production program load modules match
the corresponding program source. In some cases you may be missing
the program source entirely. These conditions make program
maintenance difficult and can produce unpredictable results.
- Due to the lack of an adequate audit trail of production changes, you are
unable to determine who has made changes, as well as when and why the changes
were made. Without this information it can be very difficult to
accurately identify why production failures are really occurring. Accurate
information and measurement is critical to improving production application system
- Your current procedures can be circumvented by those with sufficient
authority. This opens the possibility of accidental damage or intentional sabotage
or embezzlement by a disgruntled employee.
- The requirements of your Internal Auditing department are not being met. You are unable
to accurately restore previous versions of programs for audit purposes and are uncertain of who changed what and when.
- Your current manual (or semiautomatic) turnover procedures are prone to errors or
omissions. Reruns have occurred due to changes which were missed or implemented at
the wrong time.
- Your existing change control group is doing a good job, but the staff is growing and
frequently they become an implementation bottleneck when two or more systems must be implemented in the same time frame. If asked, they admit
that occasionally they feel the need to compromise quality to meet implementation
schedules. You could hire additional people, but that would be expensive and they would only really be needed during peak times.
- Your current procedures do not provide an automated way to restore a previous
production version. When an abend occurs, you are faced with a choice of
spending hours to attempt to accurately recreate the previous environment or
spending minutes or hours waiting for an applications programmer to correct his
- Your programmers understand that there is often a direct correlation between a problem
they have been asked to fix and a change that was just implemented.
But, what changed? Your paper change request forms are difficult to
search and not available to everyone. Finding a history of changes to a
particular module is laborious and time consuming. Solving a
problem from home is often impossible without access to change history.
- An approval process using paper forms is slow and can be lost. Changes can be
delayed because a request form is misplaced. If more than one signature
is required, the movement of the request form can take days.
- Impact analysis of future changes is time-consuming and error prone.
When trying to determine the impact of changing a file layout, you must run
time consuming library scans, often yielding incomplete results.
Your staff often discover something was missed when production systems
- Production compile listings are unavailable for problem solving while using a
remote terminal. Each programming group is responsible for keeping the
current listing in a filing cabinet. Even when the listing is needed
during the day, it may be misplaced or out of date. Many people feel
they need to recompile a program before they look at a problem just so they
can be sure they have a current listing.
- Uncontrolled concurrent development is causing loss of changes. On several
occasions, many hours of programming have been lost when a programmers changes
were accidentally overlaid by someone else changing the same program or
making an emergency fix.
- Several change methods are being used with varying degrees of success.
Everybody has put their own creative spin on the change process. Most
appear to work ok, but most have not been put through all of the tests.
Like what happens if you have a disaster or lose a disk drive.
- As new divisions were acquired, their existing change procedures were adopted
'temporarily' until the merger was completed. You had intended to
consolidate their change process into your system when there was time,
but could never get around to it.
- Naming standards have been adopted but are difficult to enforce. This
non standardization of names causes confusion over ownership.
- Production JCL can contain many errors, including syntax errors, missing programs
and PDS members, undefined GDG bases, invalid job and output classes,
invalid dataset names and logic errors. For each new application system
to be implemented, many hours are required to fix and rerun JCL until all
the errors can be found.
- Application software is sometimes impacted by system software changes.
Occasionally Technical Services will implement a new release of COBOL or other
changes to the infrastructure which will cause an application to fail.
Without knowing that a system change occurred it may take an application
programmer hours to determine the cause of the problem.
To address these issues you must be willing to commit to a comprehensive
software implementation process, which could best be addressed by an automated
software solution. There are two basic approaches to solving production
turnover problems: The first is to develop a software solution
in-house. The second is to purchase a vendor supplied software solution.
The in-house approach will cost the salary of a experienced
Programmer/Analyst devoted to this project for perhaps one man-year (or
more!). Your problems (and the costs associated with them) will not be
addressed until the project is completed. The developer, assuming continues
to be employed by your company, would also be required to provide
ongoing support and enhancements for the in-house system for an indefinite
period of time.
The second alternate is to purchase existing software. Since there
are several such products on the market, your personnel would be required
to evaluate and select the one which most meets your needs. The
purchase of the software could cost between $10,000 and $250,000. Most
software vendors also require a yearly maintenance charge of between 12 and 22
percent of the cost of the product. With either approach, your personnel
would need to be trained on how to use the system. One or two
days of training is usually sufficient.
The developer of an in-house system would require strong technical
programming skills and an in-depth knowledge of your current procedures and their
limitations. Experience in working with automated turnover systems is highly
desirable. In purchasing a software package, you will need someone on your staff
to act as administrator. This person will be responsible for product
installation/implementation, user training and ongoing support.
This person should have a working knowledge of JCL and utilities, and a
thorough understanding of your current procedures. The remainder of the
staff who are involved in production turnover will be trained as needed.
It is important to realize that the acquisition of any change management
software package will require some changes to your established procedures.
Assuming the package can support your existing library configuration
and can duplicate your implementation processes, it is unlikely that its
use could be transparent to your development staff. It is more likely
that you would want to take this opportunity to streamline and
standardize your implementation process. This will require that a percentage of
your development staff will be impacted by the new process, and because some
people are resistant to change, you can expect some amount of
resentment should you proceed without regard to their concerns. The early
involvement in the implementation project of a few veteran programmers and the
clear communication of your intentions and benefit to them can prove useful
in heading off a rejection of your efforts. It is our experience
that even those developers that are most resistant to change totally embrace
the new change control system within the first 30 days and if asked
would never go back to the old system.
The in-house development of a software change management system will most
likely prove to be too time-consuming and expensive to be a practical
solution. In addition, it causes you to rely too heavily on the developer for
ongoing support. Unless this person can be dedicated indefinitely to the
system, it is unlikely to be enhanced as your requirements
evolve. Should the developer leave the company, you are faced with the
temporary loss of support while a replacement is hired and trained. The
better solution is to acquire an existing software package which can meet your
change management needs. The package can be installed immediately
and can be ready to use in 1 to 3 months, depending on your specific
requirements and implementation schedule. The software vendor is then
responsible for maintenance, support and enhancements. You should find a
package which is versatile enough to handle your complex current environment
and which can provide solutions to tomorrow's problems and needs. You
should seek out a vendor with a proven track record of providing
quality, innovative software and responsive support services. It is
crucial that the vendor is dedicated to ongoing enhancements to the product, so
that it will continue serve your needs in the future as the Information
Technology world changes.
was designed and developed by the DCMS development staff with the help
of several corporations interested in addressing their real software
management problems. Since its inception in 1983, CCS has been continually
enhanced to support an ever expanding variety of environments and user
requirements. The focus in recent years has been to increase its easy-of-use to both
the typical user and the CCS Administrator.
CCS is a TSO/ISPF based system designed to manage any number of application
software libraries of medium large scale Data Processing
installations. The CCS programs are written in COBOL and Assembler and use a VSAM data
base. All phases of the development process, from module checkout
through production implementation, can be managed by CCS. Modules
are typically grouped and controlled by project. During
implementation detected processing errors (such as a compilation failure) is
communicated to the project leader. Normally, the entire project must be error
free before any part of it can be implemented into production.
This may be overridden with special authorization.
CCS provides a very comprehensive solution to change management. Even
though CCS's price tag is a fraction of our competitors, its design
enables you to easily manage your entire MVS production environment. It
can even be used to manage your applications running on other platforms,
such as VSE and Client Server environments. CCS is not labor intensive
to manage. Once CCS has been configured to your environment, only
changes to your requirements would re-envolve the system administrator.
CCS's flexible design permits you to manage any entity in your production
environment. CCS is much easier to setup and use than our competitors'
products. CCS provides benefits and features not available in competitors
products. CCS also costs significantly less than comparable products.
When DCMS Problem Management and Reporting System (PM/RS) is also installed,
batch and on-line problems display information obtained real time from
CCS. For the affected problem job and/or program, PM/RS shows the
person who made the last change, the change's date, time and the change
request identifier. With the use of a single PF key, the
referenced CCS request can be displayed in its entirety. The CCS PM/RS
combination also provides a management report which displays the success rates of
those making production changes.
- CCS insures
source and load programs match by managing the final compile into the
production environment. By using our 'where used' data base during a delete
request, the source and load libraries are protected against the
accidental loss of needed modules.
- CCS provides a complete audit trail of all production changes, including information
on who, when and why. The on-line CCS Historical Review permits
any CCS user to access this information in a variety of ways, including a search using specified selection criteria.
- CCS is normally configured in such a way that production libraries cannot be
updated without using CCS. While no system can insure that authorized
program modifications will not cause data corruption, CCS will tell you who
made the changes and exactly when they were implemented.
- CCS maintains a history of all prior versions of each production module. Using
the on-line History Restore facility, any prior version of any
production module can be quickly and easily restored to a user specified test
- CCS manages the entire process of implementing changes to the production
libraries. Multiple related changes can be entered as a single request "package"
to be implemented at the same time.
- A change request can be coded with a desired date/time to prevent its premature
implementation. This facility is often managed by the Production
Scheduling group to insure that changes to production modules do not
conflict with the production workload.
- The recommended CCS configuration includes the use of 'Minus' or 'Backout' libraries
residing on disk. These libraries contain the most previous version of
each production module and are used during CCS's automated 'Backout'
procedure to quickly reverse an erroneous or untimely change.
- CCS's on-line Request Review facility permits requests to be authorized and
released for implementation interactively. Up to 5 levels of authorization
are available to provide a completely paper less change process.
- CCS includes a Cross Reference facility (XREF) which provides up-to-the-minute
'where used' information on programs, datasets, procedures, copybooks,
etc. During the change implementation process, CCS analyzes JCL and program
source code to maintain its XREF data base. Using an on-line
inquiry, for example, you can determine such things as which jobs execute a
particular program, or which programs access a particular dataset, or which
programs use a particular copybook or ++Include module, or which jobs, procs and
programs will be impacted if you change a particular dataset. The
list of relationships maintained by XREF is long and is continuously
growing. XREF allows analysts to perform error free change impact analysis in
seconds rather than hours or days.
- During the CCS managed production compile, the compiler and linkage editor
listings are captured and stored in a highly compressed format on disk.
The current compile listing for each production program is available for
on-line viewing or printing through a CCS on-line facility. To conserve
disk space, CCS can migrate old listings to tape and automatically recall
them when access is attempted.
- CCS's Check-out facility, which is used to obtain a test copy of a production
module, prevents two people from unknowingly working on the same module
at the same time. CCS can support concurrent development on a
single test library or on multiple test libraries.
- CCS is a the total solution. The flexibility of CCS's design permits you
to manage a wide variety of production entity types. While CCS is
MVS based, it can be used to manage the software changes on other platforms
such as VSE, AS/400 and PC's.
- CCS can permit you to enforce your naming standards. Each production
entity type (programs, jobs, etc.) can be defined with a unique naming
standard and rules on when enforcement is required.
- The CCS package includes DCMS/JED, which can be used by CCS to validate and
reformat MVS JCL during testing and implementation. DCMS/JED provides a
multitude of functions including:
- Syntax checks to insure proper coding
- Reformats JCL to your standards for positioning and alignment
- Verifies the existence of executed programs
- Verifies the existence of executed procedures
- Verifies the existence of referenced PDS members
- Verifies referenced GDG bases are defined
- Validates JOB, MSGCLASS and SYSOUT classes
- Validates SYSOUT forms and FCB's
- Validates UNIT names
- Validates conformity to dataset naming standards
- Detects logic errors
- 100's of other functions
- Exits are available for special custom requirements
- CCS's System Software Change facility permits your Technical Support staff to
document their changes to system software on the CCS historical database.
This enables you to see application and system changes in the same historical
- CCS's security system allows you to control user access to any CCS function,
based on entity type, name, application or change action.
DCMS provides a 60-day free trial, so you are able to easily see how CCS can
perform and meet your needs. A sample data base is included on the
distribution tape. Immediately after installing the demo/trial
system, you can use the on-line functions of CCS to see sample historical data,
pending requests, etc. Our customization manual will step you through
the procedures required to define an 'entity type' to CCS. You will
learn first-hand how easy it is to setup CCS.
After loading the CCS software and demo/trial data base from the
DCMS web site download, you are guided through an on-line system generation dialog.
The entire process can be accomplished in one hour, after which you
are ready to begin your evaluation.
The product installation and system generation requires someone with some
technical skills. Typically this activity is performed by a Systems
Programmer or an Operations Analyst. The evaluator should have an
understanding of the change management issues and requirements.
CCS is distributed with the capability of managing a four tier library
configuration (test, staging, production and minus 1) supporting most of the commonly
used production entity types. If your site's requirements are
typical, implementation can be simply a matter of updating a few tables and
turning the system on. If your site requirements call for variations in
our recommended configuration or support of unique entity types or unusual
processing, you can easily make modifications to the supplied model JCL.
The length of time required to implement CCS can vary greatly, depending on
your site's unique processing and configuration requirements, the
relative skills of those working on the project and the amount of time they can
dedicate to the effort. CCS has been fully implemented in as
little as two weeks.
DCMS recommends that at least two individuals from your company be trained
as CCS Administrators. This provides adequate coverage during sick
days and vacations and can lessen the impact when a trained Administrator leaves
the company. The Administrator candidates must possess a knowledge
of MVS JCL and your current turnover procedures and processes. An
understanding of OS Utilities, TSO/ISPF, library utilities (Panvalet/Librarian,
etc.) and VSAM is highly recommended. DCMS is now offering onsite
turnkey implementation services. CCS typically takes us two weeks
to implement. Implementation includes planning, installation, customization
CCS includes the following manuals.
DCMS CCS Administrator Guide
DCMS CCS Technical Overview
DCMS CCS User Guide
DCMS CCS Utilities Guide
following training classes are available:
User Training - A 4 hour class in which the CCS features, operating environment
and on-line functions are explained.
CCS Administrator Training - 16 to 20 hours of instruction covering CCS internals,
tables, security and utilities.
The DCMS support line is available 7 days/week, 24 hours/day.
DASD for software libraries: 80 cylinders. DASD for system VSAM files
Products are licensed (Perpetual and Renewable) on a per processor basis.
Multiple processor and DCMS product discounts are available.
Pricing is tiered based on Processor Software Group. Annual maintenance
for perpetual licenses (after the first year) is calculated at a rate of
15% of the current license fee.
Q: Does CCS support the use of PANVALET or LIBRARIAN?
A: Yes, CCS can manage an environment using up to 39,000 PANVALET
(Computer Associates) libraries, 39,000 LIBRARIAN (Computer Associates) masters
and/or 39,000 Partitioned Datasets.
How many entity types can be defined to CCS?
A: There is no upper limit.
Q: Can we setup CCS so that it does not perform the final production compile?
A: Yes. CCS implements changes by submitting installation tailored model JCL, so any manner of batch processing can be performed. However
if CCS does not manage the production compile, either during staging or implementation, it cannot insure that the source matches the executable
and that the proper compilation options were used.
Q: How can CCS help us manage vendor supplied application packages?
A: It is common for vendors to supply only a portion of the package's
source code, so compiling these programs into production would not be
possible. For this type of situation, CCS can be setup to migrate only the
executable load modules, JCL and parameters. Some CCS sites have defined an
entity type in which actions ADD, DELETE and REPLACE manipulate a single
load module in the package and an action of RESET implements an entire
new release library.
Q: Is CCS capable of printing a formatted document, describing a change
request which is ready to be implemented, so that we can route a request form
to users and managers for their approvals?
A: Yes, CCS does provide this capability. But do you really need a
piece of paper to prove a request carries the proper authorizations?
CCS's on-line approval process prevents users with insufficient authority
from approving or releasing changes. If each TSO user has a unique
LOGON identifier and keeps their password secret, forged approvals are more
difficult through CCS than with paper and ink.
Q: Does CCS support DB2?
A: Yes. During the implementation of a DB2 program into production
CCS prompts for the DB2 Bind options and then executes the DB2 Bind process. CCS
fully supports the use of DB2 packages and plans.
Q: Which 4GL languages/products does CCS support?
A: Gener/OL (Computer Associates), BMS-GT (GT Software), Progeni, and APS
are among the many products supported by CCS at our customer sites.
The design of CCS provides the flexibility to support any entity type in
which migration can occur in a batch mode.
Q: Does CCS 'footprint' the production load modules to insure the source
A: CCS can modify the IDRDATA, placing the change request identifier in
the load module. Although, we recommend that you insure production
module integrity by update-protecting all of your production libraries.