(Note: This is dated, historical information from a previous version of N2O. However, most of the information is still relevant.)
A recent N2O prospect began to evaluate change management solutions for their organization. They prepared a list of requirements for the change management software to meet, and asked TSI to explain how N2O would meet those requirements. The following text reproduces their requirements and our response to them.
Note: This particular prospect was evaluating N2O against ChangeMan and PAC.
Checkout of a program from Production is allowed only when the program has completed the life cycle (that is, checked back in to Production) before another programmer can checkout the same program.
N2O provides a Checkout/Checkin level on the Install Parms screen in the Environment Subsystem, which allows a site to define how many concurrent checkouts are permitted at the site. If the Checkout/Checkin level is defined as "1", only one checkout will be permitted for the program, and the program must be checked back into Production (the BASE Environment) before another programmer can checkout the same program. (For more information regarding Checkout/Checkin, refer to page 50 of the N2O Version 3.3.0 Administrator Manual and pages 26-27 of the N2O User Manual.)
Allows only one person to checkout the program at any one time and only the same person can checkin the program he/she checks out.
If the Checkout/Checkin level on the Install Parms screen in the Environment Subsystem is defined as "1", only one person can checkout a program at any one time and only that person can migrate the program throughout the life cycle. (For more information regarding Checkout/Checkin, refer to page 50 of the N2O Version 3.3.0 Administrator Manual and pages 26-27 of the N2O User Manual.)
Able to regress the program from User Acceptance Testing to Development by the programmer who checked it out to make further improvements.
N2O provides a Reject Utility, which allows users to reject an object back to the environment from which it last migrated. This utility only updates the Checkout/Checkin status and does not perform a migration. (For more information regarding the Reject Utility refer to pages 153-154 of the N2O Version 3.3.0 User Manual.)
An object may also be rejected back to the environment from which it last migrated by creating an Event to migrate the object back to the previous environment.
Include a compare step for comparing the source program against the existing version during migration authorization by the System Manager. This can be done on-line as well as batch.
N2O does not currently provide a compare step during event authorization. However, the on-line authorization process does provide a view function, which allows the authorizer to view the NATURAL source code before authorizing the Event.
N2O provides a Source Compare Utility for NATURAL programs, but this utility cannot currently be invoked during the authorization process. The site must perform the source compare before authorizing the Event.
One event for both NATURAL and PREDICT object migrations instead of two separate events.
N2O allows users to migrate NATURAL programs, SYSERR messages, PREDICT objects, and 3GL/Other members in a single Event.
In case of an emergency fix, a program that requires changes has already been checked out. The System Manager must be able to cancel the program's "checked out" status, so that this program can be checked out by another programmer into a different library (so that it does not overwrite the previous programmer's modifications).
N2O provides several Checkout/Checkin utilities, which allow users to update the checkout status for an object and perform these types of actions. The following Checkout/Checkin utilities are offered: Cancel Utility, Transfer Utility, Checkout Utility, and Reject Utility. (For more information regarding the Checkout/Checkin utilities, refer to pages 134-155 of the N2O Version 3.3.0 User Manual.)
Access restriction on some of the functions: The System Manager and Data Center Manager are not allowed to create Events. The System Manager can cancel the checkout status of an Event.
With N2O, sites create Function Profiles, which define the N2O functions and sub-functions a user can access. Function Profiles are typically defined for a group of users who may access the same functions. If a function or sub-function is not defined in a user's Function Profile, the function will not be displayed on the menu, and the user will not have access to it. Using this group concept, the site can, in this example, restrict the use of certain functions to only the System Manager and/or Data Center Manager, prohibiting others from using those functions. The site can also limit the System Manager and/or Data Center Manager from accessing functions they do not require. (For more information regarding Function Profiles, refer to pages 153-164 of the N2O Version 3.3.0 Administrator manual.)
Require four levels of authorization in a specific order for migration to Production. For Emergency fixes, there will be only two levels - the programmer and the shift supervisor, but the next day there will be a post authorization by the System Manager and Data Center Manager.
N2O provides up to ten levels of authorization for a given path (Migration Profile), and the order for authorizing may be specified. N2O does not currently provide post authorizations. All authorizations must be provided before the migration can take place. However, if the managers wanted to reject a migration after it took place, it would be a simple matter to reject the checkin to Production and recover the previous version of the Production environment from the archive.
Emergency Migration Profiles may be defined for special users. This Migration Profile could only require two levels of authorization. The Reporting Subsystem could be used the following day to identify any emergency migrations.
Able to support multiple environments for Development/UAT and create a mirror of Production environment for the programmers.
There is no limit to the number of environments that can be defined to N2O. Multiple BASE and non-BASE environments can be defined to N2O.
Multiple Target Events can be used to easily maintain mirror images of an environment by automatically migrating the same objects to different environments.
Audit trail for all migrations, detailing the user, objects, time stamps, and the authorizer.
N2O maintains an audit trail for all migration activity, including the user who created the Event, the objects requested, and the date/time stamp of the authorizer. The Reporting Subsystem may be used to display the information maintained in the audit trail. (For more information regarding the Reporting Subsystem, refer to pages 247-365 of the N2O Version 3.3.0 User Manual.)
Audit trail for all functions done by the administrator.
N2O maintains an audit trail for migrations and the Checkout/Checkin utilities. None of the other functions currently update the audit trail. However, N2O does maintain a "last updated" date, time, and User-ID for entities defined in the Environment Subsystem (such as Function Profiles and Migration Profiles) to monitor who last changed the entity and when.
Can run without ADABAS.
N2O cannot run without ADABAS. N2O requires two ADABAS files in order to execute, the N2O Administration file and the N2O Migration file. An additional ADABAS file is also required for each N2O Archive file used at the site.
Track the change cycle by a specific identifier for the Project or SMR.
N2O provides a Project Tracking Subsystem, which allows sites to track a change throughout the life cycle. (For more information regarding the Project Tracking Subsystem, refer to pages 177-246 of the N2O Version 3.3.0 User Manual.)
A change may also be tracked throughout the life cycle by specifying the related Change Control number when creating the Event. The Reporting Subsystem provides reports based on the Change Control number value. This report displays all Events processed to complete a particular change.
Support for DB2 - DBRM.
After a migration has completed, N2O can submit JCL to generate the DBRM and to bind the DBRMs and/or packages into a DB2 Application Plan. (For more information, refer to pages 219-221 and 266-278 of the N2O Version 3.3.0 Administrator Manual.)
The backout process should be able to backout a particular program from the Event, not just the entire Event.
Recovery from Archive allows a user to select any of the objects archived by an Event for recovery. (For more information regarding Recovery from Archive, refer to pages 52-57 of the N2O Version 3.3.0 User Manual.)
Can schedule a migration Event ahead of time.
Batch Events may be scheduled ahead of time (i.e., post-dated) by identifying the Process Date and Process Time when creating the Events. (For more information regarding post-dating, refer to page 33 of the N2O Version 3.3.0 User Manual.)
For migration to UAT and Production only the object code is to be migrated, not the source.
N2O allows users to migrate NATURAL source, object, or both to any environment. The type of code to migrate to a particular environment is defined on the Migration Profile. (For more information regarding Migration Profiles, refer to pages 88-101 of the N2O Version 3.3.0 Administrator Manual.)
A history of all versions of the programs with the list of changes made, by programmer, for each migration Event.
N2O maintains all versions of the objects by storing them in the N2O Archive file. The N2O Archive file may be purged of undesired versions using the N2O Purge Archive utility. This utility purges objects from the archive file to a work file. Another utility, Recover from an Archive Backup, allows sites to recover purged objects from the work file.
N2O does not currently maintain a list of the program changes by programmer. Doing so could dramatically increase the storage requirements associated with the N2O audit trail. However, facilities are in place within N2O for a site to prepare such a report if needed. By using the N2O reports which identify who checked an object into Production, the site can identify who is responsible for the changes to a particular object. By performing a Program Compare of that version of the object(s) with the archived version(s), the site can identify which changes were made by that person.
