Data Center Management Systems

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 or used.

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 reliability.
  
  
• 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 enhancements.
  
  
• 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 fail.
  
  
• 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.

• 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 library.
  
  
• 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 inquiries.
  
  
• CCS's security system allows you to control user access to any CCS function, based on entity type, name, application or change action.

CCS 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.