N2O, the NATURAL Organizer from Treehouse Software, Inc. (TSI), automates and tracks Change Management activity, adapts to a site's environment, and enforces the site's Change Management rules through a feature set that is unmatched by any other Change Management product.
Since its release in 1989, TSI has been asked many questions about the product and its capabilities. Although these questions date back several years and many of the product's features have been enhanced, they may be helpful during your evaluation of N2O. During your evaluation, keep in mind that TSI employs a full-time development staff to ensure that the features of N2O are constantly enhanced to meet the needs of sites everywhere. For information on the latest release of each product, visit our Products and Services page or contact TSI.
Is there an API available where the site can interface N2O to other tools, like problem tracking systems?
Answer:
N2O offers many user-exits that can be used to interface with other tools, such as a problem tracking system. (Note that N2O Version 3.3.0 includes a Project Tracking Subsystem.) Several APIs have been added in versions 4 and 5. These APIs allow access to the checkout utility, copying events, and various other functions.
How long will N2O wait before deleting programs from the archive?
Answer:
Programs remain on the N2O archive until the site wishes to delete them. The N2O Purge Archive Utility allows a site to specify the number of versions of a program to retain, as well as the length of time a version should be retained on the archive. When this utility is executed, it will delete the appropriate programs from the archive.
Question:
Does N2O archive copies of the objects that are superseded by a revision and provide methods for restoring the archived copies that constitute earlier versions of the application?
Answer:
Yes. N2O provides complete archiving and restoration capabilities. Note that archiving is optional, however. You may choose to have some environments (such as Production libraries) for which archiving is performed and others (such as development environments) for which no archiving is done.
Question:
Does N2O allow the site to specify the number of versions of a program that are stored in the archive?
Answer:
Yes. N2O allows the site to store an unlimited number of previous versions of a program in the archive file.
Question:
Does N2O enable the site to unload objects from the archive and place them on tape for possible restoration at some later date?
Answer:
Yes. Refer to the N2O documentation for more information.
At our site, it is necessary to know what migrated, who migrated it, who approved the migration, and who changed the object. Does N2O include an audit trail of all actions and changes made under the control of the system?
Answer:
N2O provides complete logging of all information related to migrations, including archiving and compilation at the target. An extensive selection of reports is provided to assist Auditors, Administrators, Project Leaders, and Programmers.
N2O includes a utility to compare NATURAL source or object programs for differences (lines added, changed, or deleted), which provides options to ignore spacing or comments. This utility may be run in batch or on-line and can be used as part of your site's code review, auditing, or authorization process.
Treehouse Software provides information about the layout and content of its audit trail information. This allows a site with unique reporting requirements to code its own NATURAL programs to report from the N2O audit trail.
Question:
Does N2O keep an audit trail that identifies the person who authorized the transfer, the date of the migration, and the objects migrated for each occurrence of a migration?
Answer:
Yes. This and other information is available on the N2O audit trail through the Reporting Subsystem. Refer to the N2O documentation for more information.
Does N2O require us to use its Autocompile feature? Is the Autocompile feature related only to migrations?
Answer:
Autocompile is an optional feature of N2O. The site determines whether or not N2O will perform automatic compilation. The Autocompile process is only invoked for migrated programs.
Question:
If you use the N2O Autocompile feature, does PREDICT have to exist in the Development, Test, and Production environments at the site?
Answer:
N2O Autocompile requires that files exist in PREDICT, just as CATALL does. If programs are to be cataloged against views of those files, the correct files must be in PREDICT for any environment where Autocompile is to occur.
Question:
Does N2O permit an application to be defined, so that when an object is moved into the application library and should operate on different databases or files, it is automatically changed to point to the new databases or files?
Answer:
Yes. By using the Autocompile feature of N2O, it is possible to ensure that applications are automatically recompiled in the application library. This will ensure that the applications are automatically updated to point to the new databases and files. This is different from other products, which offer "translation tables" that must be continually maintained by the site. Such translation tables have reportedly required constant effort to keep current.
You mentioned that N2O users create all migration requests on-line, even those requests involving batch migrations. If the requests are entered on-line, how are these batch jobs submitted?
Answer:
N2O provides an on-line submission facility for submitting batch jobs. Batch jobs are initiated using the system internal reader. It is also possible to submit these jobs manually or through a batch scheduler.
During on-line migrations, how does N2O handle the NATURAL buffer pool? Will N2O automatically flush the CICS buffer pool?
Answer:
If the N2O Autocompile feature is used, N2O will automatically catalog NATURAL objects in the target environment. This will cause the NATURAL buffer pools in that environment to be flushed. In cases where multiple TP systems are in use, it may be necessary to manually flush buffer pools in the other environments.
Can N2O identify other objects that are, or will be, affected by object changes and generate change impact analyses? Will it simulate the change function prior to activation?
Answer:
N2O utilizes PREDICT cross-reference information to provide program dependency information during a migration. This information identifies whether programs about to be migrated affect other modules or require other modules for a successful recompile. Impacted programs may optionally be added to the migration. N2O includes a cross-reference report to determine the programs affected by, or invoked by, a specified program. This information is available prior to making a migration request.
In addition, N2O scans PREDICT information in the environment that is the target of a migration, and determines if modules already existing in the target environment (which are not part of the migration) should be recompiled to reflect changes in the programs being migrated into the environment.
Does N2O's change request process include tracking through the entire process from input through review, approval, implementation, acceptance, and closure?
Answer:
N2O provides many reports to track change request and migrations. These reports include information for site-specific change control numbers. Thus, it is easy to track all change activity, whether NATURAL, 3GL, PREDICT, or SYSERR related, back to the original request or project for which it was performed.
Does N2O offer an option to prevent more than one person from "checking out" the same module for modification at the same time? Will it automatically notify other users when a component is checked out?
Answer:
Checkout/Checkin is a method of controlling and monitoring changes in the development life cycle for a new program or the maintenance cycle of existing programs. It is designed to protect the integrity of a program throughout the development cycle and to provide an audit trail of the Checkout process.
Once a program is checked out, other users can be prevented from migrating the program. During the migration selection process, appropriate messages notify the user that the selected program is already checked out to another user.
However, in those cases where a site desires concurrent development, or where such development might be necessary in an emergency, N2O offers capabilities to allow multiple users to check out the same program at the same time, but to different environments.
Question:
Can I check out a program on Monday and check the same program out again on Friday without checking it back in?
Answer:
Checkout/Checkin allows 1-15 copies of a program to be checked out concurrently. If the site has directed N2O to limit checkouts to 1 user at a time, then no user could check out the program until it was checked in. If the site sets the checkout level to 2 or more users, then the program could be checked out on Friday, assuming that the checkout limit has not been reached.
Question:
Does N2O Checkout/Checkin support concurrent development?
Answer:
N2O Checkout/Checkin supports up to 15 levels of concurrent development. In concurrent development situations, N2O provides a warning message when the program is selected for migration. Each checkout user is then aware that other users are working with the same program. This enables users to coordinate their changes to ensure the integrity of the production environment.
Question:
Our site has a "Librarian" who performs all of the migrations at our site. If we use N2O Checkout/Checkin, it looks as though the Librarian will have to transfer the checkout of each migrated program to the programmer before the programmer may begin modifying it, and transfer it back before migrating the program to the next environment. Can we configure N2O so that our Librarian is still responsible for all program migrations, but avoid all of these checkout transfers?
Answer:
Yes. There are two ways to accomplish this. One of the simplest is to configure your environment so that all migrations require "authorization". Your Librarian can then be defined as the authorizer. Programmers will still request migrations, but programs will not be migrated until the Librarian authorizes the migration request. The programs will be checked out to the programmers and no transfers of checkout responsibility will be required.
Another way to deal with this situation is to have the programmer perform the initial migration from Production to Development. (N2O Security can be configured so that users can only migrate along this Production-Development migration path.) When development is completed, the Librarian can execute the Transfer by Event Utility to automatically transfer programs from the programmer to the Librarian. The Librarian can then migrate the programs to the next environment in the development cycle.
Question:
Assume that N2O Checkout/Checkin is in effect at a site, and a programmer checks out a certain Production program for enhancement. In the meantime, an emergency occurs in Production, which requires an immediate change to that program. How would the N2O Checkout/Checkin functionality handle this emergency?
Answer:
First, the Checkout/Checkin level must be set to at least 2. A second checkout of the program from Production to a different library is then permitted. The person performing the emergency fix will receive a "WARNING" message on the "checkout" migration, indicating that another programmer is working on the same program. The emergency fix is completed and the program is migrated back to Production. The programmer enhancing the program in the Development library will receive a "WARNING" message when migrating the program from Development to another environment. Ideally, the programmer who made the emergency fix has notified the other programmer of the change and the change has already been incorporated.
Is N2O compatible with our existing security software (RACF)? We need to control access to all files/libraries established as being under control of the system. In addition, we need security to be different in each environment and for each related group of items within the environment (i.e., the approval for each subsystem to move from development to test may belong to different team leaders).
Even though the person performing the migration is authorized to perform the function, we are concerned that the migration could take place without the proper approval. Will N2O allow the authority to approve migration between environments and the authority to perform the migration to be different?
Answer:
N2O provides internal security that can effectively control migration activity. Security for N2O includes "profiles" that control who can access N2O functions, who can migrate between specified environments, and who can approve and service migrations. RACF and/or the NATURAL Security System (NSS) can also be used to control access to N2O.
If your site uses Treehouse Software's SECURITRE product, N2O will allow all of its security information to be stored in RACF, ACF2, or Top Secret and will access this security information via SECURITRE. For more information about the other functions and benefits of SECURITRE, contact Treehouse Software.
N2O allows your site to specify the levels of authorization required for a particular migration path. For example, site policies may dictate that routine migrations between personal or development libraries be set up with no authorization. Certain migrations, such as those targeted for production or system test environments, may require one or more levels of authorization. N2O supports up to 10 levels of authorization prior to allowing a migration to be processed.
Question:
Is N2O compatible with our existing products? Will it impair their functionality? Is it able to functionally coordinate (effect event changes between systems), interact, and interface with Software AG products? Can we operate N2O without additional hardware or software?
Answer:
N2O is installable and executable on any mainframe that supports NATURAL. N2O requires no zaps to any operating system, teleprocessing system, or Software AG product. N2O requires two ADABAS files. N2O offers its own security system, does not require the NATURAL Security System (NSS), and will not impair the functionality of any existing products.
Question:
Will N2O provide interface to our existing problem management software products (SmarTrac and/or HEAT)? Is automatic notification of changes and problem events or problem management event tracking provided within the product?
Answer:
N2O currently provides several optional user-exits that are available as NATURAL subprograms. Refer to the N2O manual for complete descriptions of the user-exits. These user-exits may be used to interface with an external problem management product such as SmarTrac and HEAT to provide automatic notification of changes to an environment.
In addition, N2O allows your site to track changes to any program or environment through its own reporting capabilities. For instance, it is possible to see the entire change history of a program and to compare the source code for the current version to the archived source code for previous versions to see actual program changes. Events created by several users can be related to one another through the use of a site-specific change control number, which can be assigned by each user requesting the migration of code.
Question:
When N2O migrates programs generated using Software AG's NATURAL CONSTRUCT, does N2O actually move the CONSTRUCT-generated programs or does it automatically re-generate CONSTRUCT programs at the target environment?
Answer:
N2O currently migrates CONSTRUCT-generated programs, but it does not automatically regenerate CONSTRUCT programs.
Question:
How current is N2O relative to the new SAG Natural releases? Will we have to install a new version of N2O each time we upgrade NATURAL?
Answer:
In the past, N2O has always worked with each new release of NATURAL. We believe that this will continue to be the case.
Question:
Our site uses Software AG's NET-WORK product. Does this mean that N2O will let us do on-line migrations across networked CPUs and shared systems?
Answer:
Yes. If the databases are networked, on-line migrations can be performed across shared systems. If the databases are not networked, batch migrations must be performed.
Question:
Does N2O support Natural for Windows or NATURAL for OS/2?
Answer:
N2O does not currently support NATURAL for Windows or NATURAL for OS/2.
Question:
What repositories are supported by N2O and N2O/3GL?
Answer:
N2O without N2O/3GL supports NATURAL, PREDICT, and SYSERR migrations. Adding the optional N2O/3GL feature will provide support for Partitioned Data Sets (PDSs), LIBRARIAN Master Files, PANVALET Libraries, and ENDEVOR Stages.
Question:
Does N2O support the site's use of the NATURAL HELP facility?
Answer:
N2O supports the migration of NATURAL Helproutines used in the site's applications.
Question:
Can a site use Software AG's NATURAL Command Processor to give more direct access to N2O?
Answer:
At this time, the N2O Development Team has not performed any testing with the NATURAL Command Processor. However, the N2O team has a number of enhancements currently planned that will make N2O even more accessible from outside the menu system.
Question:
Does N2O function with NATURAL SECURITY from Software AG?
Answer:
N2O provides its own internal security system. N2O may optionally be interfaced with SECURITRE from Treehouse Software. N2O will operate under Software AG's NATURAL SECURITY SYSTEM, but does not require (or interface with) that product.
Question:
What versions of NATURAL does N2O support?
Answer:
N2O operates under NATURAL 3.1.6 and above. N2O migrates NATURAL code written in any version of NATURAL.
Question:
Another vendor's sales representative told us that N2O will not be supporting future versions of NATURAL. Is that true?
Answer:
Definitely not. N2O is a strategic product for Treehouse Software and has been since it was introduced in 1989. As a strategic product, N2O receives constant attention from a staff of full-time developers, support personnel, and documentation specialists. These individuals work hard to ensure that the needs of N2O customers are being met by rapidly implementing the changes and features our customers desire most.
N2O has always kept pace with the evolution of NATURAL and will continue to do so. TSI keeps track of changes to NATURAL structures, examines new and different NATURAL objects, etc. As Software AG improves NATURAL, TSI will ensure that N2O adapts to the changes and makes use of the new facilities whenever it is appropriate to do so.
N2O also keeps pace with PREDICT. TSI evaluates changes to PREDICT and determines how N2O should be modified to support them.
But TSI wants to do more than just keep pace with Software AG products. We also want to see N2O grow and improve. N2O continues to remain a quantum leap ahead of its competitors.
Some vendors are currently taking the approach that ADABAS/NATURAL products should simply be "maintained" and not enhanced. They are taking their development and support resources away from these products. This is not the approach being taken at Treehouse Software. We continue to monitor our customers' and affiliates' requests for enhancements and implement as many of these requests as we can in each new release of our products.
Question:
Is there an interface between N2O and NATURAL Security?
Answer:
N2O is able to secure itself and a site's environment without requiring the site to purchase additional software. Therefore, N2O does not require NATURAL Security to be installed. Many sites have been very pleased by this fact. These sites either did not like NATURAL Security or did not wish to purchase it.
However, N2O is very flexible and can be interfaced with NATURAL Security through the various N2O user-exits. Some N2O sites have coded user-exits that enable them to interface N2O with NATURAL Security to meet their specific security needs.
N2O does include an interface to Treehouse Software's SECURITRE product, which secures ADABAS, NATURAL, and Utilities through a System Security Facility (SSF), such as RACF, ACF2, or Top Secret. The N2O interface helps the site maintain a single security rule base by allowing the site to control NATURAL program migration activity through RACF, ACF2, or Top Secret. Having a single security rule base reduces administration and training costs associated with having multiple security rule bases.
We need to provide reports of all inventoried objects, identified by the environments in which they are located. Can N2O provide a cross-reference list of objects and associated groups? Will the reports depict authority groups and their membership, as well as what migrated, who migrated it, who approved the migration, and who changed the object? Are they available both on-line and hardcopy?
Answer:
The current N2O reports provide all of the indicated capabilities and more. Refer to the N2O Reference Manual for more information.
Question:
How does XREF come into play at selection time?
Answer:
The ability to see related modules to a selected program is defined on a user basis. If a user has XREF available, then related modules will be presented at the end of the selection process on the XREF selection screen. From this screen, the user can add the related modules to the migration list.
How is the FUSER file updated? Are Software AG Utilities used to manipulate the FUSER file? Is there any contractual agreement with Software AG for definition of the FUSER file if Treehouse is updating the FUSER directly?
Answer:
The FUSER file is updated via direct calls to ADABAS. Software AG utilities are not used to manipulate the FUSER file.
TSI currently has no contractual agreement with Software AG for definition of the FUSER file with regard to N2O, but we do have a relationship regarding PROFILER for NATURAL - Treehouse Software's NATURAL Quality Assurance and Testing Tool. Because PROFILER interacts with NATURAL (including the NATURAL FUSER file), Software AG has agreed to keep TSI informed of changes to NATURAL that may affect PROFILER. The N2O developers would learn of these changes immediately and would take steps to adapt N2O to work with the changes.
When a site installs N2O, where do the various components of N2O reside and how much space is required to store these components?
Answer:
N2O is shipped on one tape cartridge or via e-mail. It contains all of the NATURAL modules that comprise N2O. These modules are loaded onto the site's computer system via the NATLOAD utility. There are no assembler modules or other components to install. The exact space requirements for N2O are provided in the N2O Reference Manual.
In addition to the NATLOAD of the NATURAL modules, the site must add two ADABAS files to its system. These files are required by N2O in order for the product to function. A third file (the Archive file), or set of files, may optionally be created to store archived programs, if archiving is desired.
Question:
Does N2O have to be installed in each environment at a site (e.g., TEST, PRODUCTION, DEVELOPMENT, and QA)?
Answer:
If a site has only one CPU, N2O has to be installed in only one environment in order to control all migrations on that CPU. Treehouse Software recommends installing N2O on a development FUSER to which the programmers have access. Installation on the Production FUSER is not recommended because a site's security could prevent programmers from accessing N2O on that FUSER.
Question:
We have more than one CPU. Do we require more than one N2O license, and will N2O have to be installed on all of our CPUs?
Answer:
The answer to this question depends upon your specific situation.
If the site has multiple CPUs, but N2O will be used to perform migrations on only one of those CPUs, then only a single copy of N2O must be purchased or installed.
If the site has multiple CPUs that are networked together (i.e., ADABAS calls can be issued via the network across CPUs), only one copy of N2O is required in order to control migrations on all of the networked CPUs. This central copy of N2O will migrate programs between environments on each CPU, as well as between environments on different CPUs. All migration requests are submitted on the CPU where N2O is installed.
If the site has multiple CPUs that are not networked (i.e., ADABAS calls cannot be issued via the network across CPUs), the site may choose to install N2O on only one CPU. Migrations between environments on that CPU can occur on-line, while migrations involving environments on other CPUs must be performed in batch. In this instance, programs are migrated from one CPU to another via tapes, cartridges, or some other medium. Only one copy of N2O is purchased. A small number of N2O programs are installed on all CPUs where migrations will be performed. These programs will accomplish the actual migration and communicate audit trail information back to the CPU on which N2O is installed (again via tapes, cartridges, etc.). All migration requests must be submitted on the CPU where N2O is installed.
In certain circumstances, the site may wish to manage change separately on each of its multiple CPUs. For example, a state government might have multiple CPUs, each used by a specific department of that state. Migrations would not normally take place between the CPUs. The state might want to manage change independently on each CPU, so that each department's records were maintained separately. In this case, the site might want to install N2O on each of the CPUs. In this instance, each copy of N2O will require separate administration activities, as multiple copies of N2O will not communicate with each other. We strongly urge any site considering this approach to contact us to discuss the alternatives to using multiple copies of N2O.
How complex is N2O to maintain? We are looking for a well-structured flow of software products from purchase to replacement or removal, which is capable of installing the software components and verifying them through the use of a version and release identifier. Does N2O provide upgrades (i.e., apply PTFs, etc.), maintenance enhancements, releases that have been functionally tested and proven to be stable and fully documented prior to its release? Can N2O be installed and maintained by a journey level systems programmer with no more than 15% of a senior level programmer's supervision?
Answer:
N2O can be installed in one hour by a DBA or other individual capable of running NATLOADs and loading ADABAS files. The initial installation requires the execution of the NATLOAD program, the creation of ADABAS files, and the simple modification and assembly of the NATPARM module to be accessed by N2O users. Upgrade or maintenance releases typically require a NATLOAD of the new N2O code and occasionally changes to the ADABAS files to support new features or functions.
Can N2O schedule migrations between environments, so that the migration takes place only on the specified date and time and automatically moves components through different stages or environments of the change process? Can N2O automatically archive prior versions of the changed members?
Answer:
The N2O batch migration process is provided as an alternative to the on-line migration system, as well as a method of migrating programs between nodes that do not have network connections. Event requests are entered through the on-line system, but the actual migration of code occurs when the batch migration JCL is executed.
Postdating of a batch migration can be done to ensure that program migration does not occur until a desired date and time. A postdated migration time is specified at migration request time. The selection program, which is part of the batch process, will not migrate programs in an Event until after the date/time specified. Manual submission, CA-7, or another scheduler can be used to submit N2O batch JCL periodically, looking for any eligible Event.
N2O provides optional archiving when NATURAL program (or SYSERR message or PDS member) migrations replace existing source and/or object. Archived programs may be easily recovered in the event that the new version of a program does not work properly. An Archive Purge facility is provided for removal of obsolete versions of programs.
Question:
When I migrate programs and the N2O program selection screen displays the message "REPLACE" next to a program I am migrating, does this mean that N2O will replace the object code for that program?
Answer:
N2O allows the migration of both source code and object code. If the type of code being migrated (source or object) exists in the target environment, N2O will display the "REPLACE" message to indicate that code will be replaced during the migration. If both source and object code are to be migrated, but only source exists at the target, the message field will show "REPLACE", even though the object code is being added rather than replaced.
Question:
If the person who migrates a program is different from the person who actually edits the migrated code, does ownership have to be transferred within N2O to allow the editing to take place?
Answer:
The person who edits code does not have to be the same person to whom the code is currently checked out, unless the optional N2OEDIT feature is in place.
The N2OEDIT feature can be used to restrict editing of programs to those individuals who checked them out. This feature works by front-ending the NATURAL editor with an N2O module that verifies whether or not the user attempting to edit the code is the person to whom it is currently checked out. If the N2OEDIT feature is installed at the site, ownership would have to be transferred in order for the code to be edited.
Question:
Could I check out some source code to a development environment, migrate only the object code to a test environment, and then later migrate the source code into that test environment
Answer:
Yes. The object code can be "extracted" from the development environment to the test environment using N2O. Because the object code has been "extracted" rather than migrated, N2O considers the code to still be checked out to the development environment. Later, the source can be "migrated" to the test environment. N2O includes a very easy-to-use, on-line utility for performing this transfer.
Question:
If you are migrating LDAs, PDAs, etc. does N2O sort them into the proper STOW order?
Answer:
Yes. N2O Autocompile does sort programs into the proper STOW order before compiling them.
Question:
In what order does N2O migrate PREDICT objects?
Answer:
N2O migrates PREDICT objects in "preferred order" (i.e., KEYWORDS, USERS, DATABASES, FILES/USERVIEWS, VERIFICATION RULES, RELATIONSHIPS, SYSTEMS, PROGRAMS, MODULES, and REPORTS).
Question:
Does N2O allow a single migration profile to perform both on-line and batch migrations between two environments?
Answer:
Yes. The N2O administrator can specify batch, on-line, or both for the migration mode. Specifying both allows users to select between batch and on-line at the time the event is executed.
Question:
If the N2O Migration Profile indicates that XREF information must be migrated with a program, and the site has deactivated the PREDICT XREF function, what will happen?
Answer:
If the Migration Profile indicates that XREF must be migrated with the program and no XREF information exists, the programs will be marked "NO XREF" when selected for migration. If the XREF information exists, the programs will be added to the migration list.
Question:
Does N2O automatically delete object code after migrating it?
Answer:
N2O offers two migration options, MOVE and COPY. When the COPY option is used, N2O will not delete code after a migration has completed. When the MOVE option is specified, N2O will automatically delete source and/or object code from the previous environment. This option allows a site to automatically "clean up" its libraries as part of the migration cycle.
The MOVE option also allows for "Deferred MOVEs." When a Deferred MOVE takes place, N2O will only delete the code from the previous environment after a specified time period has elapsed (e.g., "Move this from test to production and delete it from test after 3 days."). This option gives you the time to be certain that migrated code passes all quality assurance tests before it is deleted from the development area.
Question:
If a user enters incorrect information on a migration request, can this information be corrected later?
Answer:
Any Event that is "open" can be modified to correct errors. In addition, some changes can be made during the Authorization and Servicing steps of the migration process. However, once the migration has completed, the information cannot be modified, as this would compromise the integrity of the audit trail maintained by N2O.
Question:
During an N2O presentation, we learned that N2O allows a person authorizing a migration to view the source code for the migrated programs. Can the authorizer limit the viewing to just the changed statements?
Answer:
The source code viewing function available during the authorization process does not offer the authorizer the option to view only the changed statements. However, the authorizer could access the N2O Program Compare function and view the changes for any desired program.
Question:
Before a migration takes place at our site, we require a number of electronic forms to be completed and stored in a PDS. These forms make it possible for us to track and document a number of things. For example, operators often need to know the restart instructions, how to interpret messages and codes, etc. Can N2O support such an arrangement?
Answer:
As part of the authorization process for migrations, your site may want to add a manual procedure, which requires the authorizer to verify that the correct forms have been properly completed and filed before authorizing the migration.
Question:
What process is used for migrating software between environments? Our organization has two separate environments and uses unload and load JCL to transport the software.
Answer:
N2O issues ADABAS commands to read and write the program source and object code in the NATURAL System Files. This enables N2O to perform both on-line and batch migration of NATURAL programs. For migrations between networked CPUs, N2O can migrate programs on-line if ADABAS calls can be issued from one CPU to the other. For migrations between non-networked CPUs, N2O unloads the programs to a dataset that must be transferred to the remote machine and processed there. Software AG utilities are not used for migration.
Question:
Does N2O make it possible to define the valid migration paths over which objects of an application can be migrated?
Answer:
Yes. By defining a Migration Profile, N2O sites can specify the migration paths that are valid at their site.
Question:
Can N2O perform deferred on-line migrations?
Answer:
Currently, N2O does not allow on-line migrations to be deferred. There are ways to delay the actual migration of programs using authorization and servicing.
Can N2O centrally manage all installed and maintained objects? Can it handle libraries containing code in NATURAL, PREDICT, partitioned datasets (PDSs), sequential datasets, source code (ASM, COBOL, and JCL), load modules (with or without source code), PROCs, SORTLIB controls, GDAs, LDAs, and data libraries and files?
Answer:
N2O will currently migrate NATURAL source and object programs (including maps, data areas, etc.) either on-line or in batch, involve either a copy or move of the NATURAL objects to the target environment, and include source code, object code, or both. SYSERR error messages can also be migrated on-line or batch.
N2O includes batch migration of PREDICT objects. The user specifies the types of PREDICT objects to be migrated through the on-line request system.
N2O provides facilities for migrating 3GL members, including ASM, COBOL, JCL, and PROCs, through the N2O/3GL feature. N2O/3GL migrates 3GL members stored in PANVALET, LIBRARIAN, ENDEVOR, and partitioned datasets (PDSs).
Question:
Is N2O capable of notifying the next approving authority of pending actions and logging comments and questions?
Answer:
Through its reporting mechanism, N2O allows approvers to list the Events awaiting their approval. This list can be displayed on-line or printed for later reference. Each migration request includes comment lines for comments, descriptions, and questions. The comment lines can be modified by the creator of the request and by individuals authorized to process the request.
N2O also provides user-exits throughout the migration process. These exits are implemented as NATURAL subprograms and are invoked via a CALLNAT. Refer to the N2O manual for a complete description of the user-exits available. Through the use of these exits, N2O may be interfaced with an external mail system, such as Connect-EMAIL or any other system as another method to notify approving authorities of pending actions.
Question:
Can N2O group various objects of varying formats together to form a cohesive unit for migration? (For example: Group a COBOL program (source and object), a subroutine that is copycode, an included subroutine, a NATURAL program, maps, JCL, and LDAs together to form one unit that migrates as a whole.)
Answer:
N2O allows a user to migrate NATURAL, PREDICT, SYSERR, and 3GL members with a single Event, as a cohesive whole. Reporting and tracking will encompass all related components of an Event.
Question:
At our site, we store source code in multiple places. Will N2O require us to move all of our source code to one place?
Answer:
N2O does not require a site to move its source code to a special area. N2O migrates source code between the site's current FUSERs. Source code can be kept wherever the site is (e.g., in every environment or only in the production environment).
Question:
Since N2O allows concurrent checkouts of the same program, does it also provide a facility for merging two versions of the same program into one?
Answer:
This feature is currently recorded on the N2O enhancement list and may be incorporated into a future version of N2O. At this time, however, the site must merge these two versions manually. The Source Program Compare report will be very helpful in performing such merges.
Question:
Does N2O require source code to be in Production?
Answer:
N2O adapts to a site's current procedures. Source code and/or object code can be stored wherever a site requires it. These decisions are made by the N2O Administrator when the Environment is configured.
Question:
What is the Treehouse/SAG relationship with regard to N2O? How will this relationship affect N2O development?
Answer:
Customers occasionally ask about our relationship with Software AG. On March 1, 1994, Treehouse Software and Software AG of Darmstadt, Germany, (SAGD) entered into an Interface Partnering Agreement for PROFILER for NATURAL. Because NATURAL and ADABAS are developed in Darmstadt, we felt that a partnership with SAGD was desirable. The partnership has helped us to keep improving PROFILER and keep it operating with new releases of NATURAL. SAGD even presented PROFILER and DynaDoc in a recent issue of the newsletter it mails to sites in Germany, helping our German affiliate to market the products.
A by-product of this partnership was an increased interest by SAGD in all of the Treehouse products, including N2O. TSI and SAGD have helped each other overcome development hurdles. Each company has made changes to its products in order to improve compatibility, and we have shared detailed technical information. For example, SAGD reserved three LFILEs for the exclusive use of N2O. This ensures that N2O will not conflict with SAG products that require LFILEs. Both TSI and SAGD continue to further improve the relationship and the flow of information. We feel that everyone (customers, SAGD, and TSI) benefits from this cooperation. Most importantly, this is not a "paper" relationship created to enhance the marketability of our products. SAGD and TSI actively communicate and assist each other on a frequent basis.
It is also important to note that TSI has been in business for almost 14 years. Through nearly all of that period, we have had little or no formal relationship with SAG. In spite of this, our products have remained compatible with the SAG products. We are typically weeks or months ahead of our competitors (including SAG itself) in releasing versions of our products that are compatible with new SAG releases.
Question:
How does TSI feel that N2O compares to its competitors?
Answer:
N2O was released in 1989 and was the first change management product available for NATURAL, PREDICT, and SYSERR. Since then, no other product has been able to match N2O for functionality, ease of use, reliability, and ease of installation. In 1992, we released the optional N2O/3GL feature, which enables N2O to provide change management for 3GL members stored in MVS Partitioned Data Sets (PDSs), PANVALET Libraries, LIBRARIAN Master Files, and ENDEVOR Stages. We hope to make another quantum leap soon by offering a Project Management feature. As you can see, we are committed to continued improvement of N2O. A staff of dedicated, full-time developers is currently working to provide the features and functions our customers have requested.
One important difference between N2O and its competitors is the N2O customer base. While a competitor may claim a higher number of sales, we remain convinced that more sites actively use N2O in production than any of the other NATURAL change management products. Our customer base includes both large and small shops in a wide variety of industries. Some shops use N2O to migrate thousands of programs at a time. Others have hundreds of programmers using N2O simultaneously. N2O has been a solid performer for all of them.
Question:
A Gartner Group report implied that TSI is moving away from ADABAS/NATURAL products. Is this true?
Answer:
TSI has always been a vendor of products complementary to the SAG product line. All current TSI products rely on the existence of ADABAS and/or NATURAL at the site. TSI has no intention of abandoning ADABAS. At the urging of our customers, however, we are expanding our focus to include more than mainframe ADABAS/NATURAL.
Many customers have expressed an interest in having versions of the TSI ADABAS/NATURAL tools for UNIX, OS/2, and Windows. Some have expressed interest in products for Oracle, Sybase, DB2, and Informix. We are currently investigating these areas and determining whether we should develop such products.
Question:
Does TSI have an on-line program compare and, if so, how does the program compare feature work?
Answer:
N2O does include an on-line NATURAL program compare function. A batch program compare function is also available. See the N2O documentation for more information about this feature.
Question:
How does the software determine a true compilation error versus a "job not completed" error from the Software AG return codes?
Answer:
Because N2O does not use the Software AG utilities for migration, there is no need for the product to determine a compilation error versus a "job not completed" error. N2O Autocompile makes use of the CATALL facility of NATURAL and is able to determine the error codes from the output of the CATALL activity.
Question:
Is there a way within N2O to define a set of people who can check out objects of an application into a development environment, and a different person who can move the objects of the application into Production?
Answer:
Yes. By configuring N2O so that all migrations into Production require the authorization of one or more individuals, you can ensure that no migrations are made into Production unless these individuals have approved them. Programmers can check objects out from Production into Development, modify those objects, and request migration into Production. Until approval is given, the objects are not migrated. Thus, the person providing authorization is effectively the one who is migrating the programs into Production.
If you would prefer to handle it in a different way, N2O can accommodate this also. Authorize only the desired individuals to migrate into Production. Then as programmers are ready to migrate the programs they have checked out into a Production environment, they can "transfer" their checkout of the programs to one of the individuals authorized to migrate the objects into Production.
Question:
Does N2O make it possible to load a revision into a production application, but not use that revision until a later time, when the old version has been backed up and the new version activated?
Answer:
Yes. There are a number of ways you might accomplish this with N2O. One of these ways is the postdated migration. By postdating a migration to occur at a specific time, the site can postpone when the revision will be loaded into the production environment and activated. With archiving enabled for that application library, N2O will automatically backup the old version of the application before moving the revision into the library. The new version can then be automatically compiled and will become the active version. The N2O developers can discuss other alternatives provided by N2O.
Question:
When a new version of an application is in production and is not performing as intended, can N2O back it out of production so that the application returns to the way it was before the revision was applied?
Answer:
Yes. By doing a "restore" from the N2O archive, it will be possible to back out the changes you have made and restore the application to its former status. The revised application will be archived so that it can be placed in a development environment for further development, testing, or debugging.
Question:
With N2O, can all or almost all of the functions be performed on-line, and can long-running functions also be performed in batch?
Answer:
Yes. Almost all N2O functions can be performed on-line. In addition, long-running functions like program comparison, migration of large numbers of programs, or archive purging can also be performed in batch.
Is N2O capable of managing and maintaining multiple environments? Our site requires development, two or more test environments, a Q/A, production, emergency, maintenance, and a historical (archived) environment with the capability to retrieve historic versions and restore them
Answer:
N2O is capable of managing and maintaining as many environments as the Change Management Administrator defines. N2O is designed to allow your site to tailor its own change management process. Your site determines which environments (including archives) it requires, who is authorized to perform migrations to or from those environments, whether migrations should occur on-line or in batch, what happens in emergencies, and whether your site wishes to migrate source, object, or both into a particular environment.
The archive process includes full recovery capability for old versions, ensuring that changes to an environment can be backed out if needed. The archives will contain as many historical versions as desired by your site.
Question:
We currently have multiple production environments. Will N2O support this arrangement?
Answer:
N2O allows a site to define as many production environments as it requires.
You mentioned the optional N2OEDIT feature for restricting "edit" access to programs. Does this mean that N2O has its own editor that replaces the standard NATURAL editor?
Answer:
N2OEDIT is a front-end to the standard NATURAL editors supplied by Software AG. N2O sites continue to use the standard NATURAL editors they have always used, but with the added protection provided by N2O.
Is there a way within N2O to mark NATURAL objects for movement as a group?
Answer:
Yes. By creating an Event, the user specifies that the selected NATURAL objects are to be moved as a group. Using the N2O user-exits, it is possible to further enhance this grouping or "packaging" capability.
Does TSI use the NET-WORK product for data migration?
Answer:
Your question mentions "data migration" rather than program migration. This function is not within the current scope of N2O. With respect to the migration of NATURAL programs, N2O does not make specific use of NET-WORK but will issue ADABAS calls for program migration through NET-WORK if it is available - just as any standard NATURAL application would do.
What is a Node Definition in N2O? Does it have anything to do with VTAM/ADANET network IDs?
Answer:
The Node Definition defines a logical CPU and is primarily used by N2O to indicate if that CPU is local or remote. The Node is not intended to define the VTAM/ADANET network IDs.
We require on-line access through TSO, COM-PLETE, and/or CICS. Can we enter data on-line, establish environments, review objects, and approve objects with N2O? Is the actual migration between environments and the ability to restore historic versions on-line? If not, will we be able to submit a batch run?
Answer:
All N2O functions can be performed on-line. The definition of environments, security, migration requests, the approval process, and reporting are all on-line functions. The actual migration of NATURAL programs and SYSERR messages can occur on-line or in batch, and the migration of PREDICT objects and 3GL members is available in batch. On-line access is available through all known teleprocessing systems.
The N2O batch migration process is provided as an alternative to the on-line migration system. Batch migration requests are entered through the on-line system, but the actual migration of the code occurs when the batch migration JCL is submitted.
We would like the N2O Program Locking feature to be enabled in target databases and certain remote databases. What is involved in doing this?
Answer:
N2OEDIT should be installed in the FNAT for every database that is to have restricted editing enforced by N2O. N2OEDIT can only be used to control databases that are local to the N2O files. Editing on remote databases cannot be restricted by N2OEDIT because there is no way for N2O to communicate "up to the minute" information about program locking to these unconnected databases.
Does TSI have a quality assurance program in place?
Answer:
Treehouse Software has always considered product quality to be an important issue. Every product undergoes testing in-house before being shipped to BETA test sites. Following thorough BETA testing, the product is made available for general release.
More recently, Treehouse Software is improving its Quality Assurance program. Our Quality Assurance staff continuously improves our Standard Quality Procedures to monitor and control the quality of each release. Formal standards and policies are evolving for BETA testing to ensure that each release is properly tested. Our goal in developing these procedures is to prepare the company for the strictest internationally recognized standards, including ISO 9000.
The specifics of how this interface is used are documented in the N2O manuals. The diagram below illustrates the function of the interface itself:
When the user attempts to access N2O (or any function of N2O), N2O calls the security system (RACF, ACF2, or TOP SECRET) through SECURITRE to verify that the user has the appropriate authorization. The security system verifies that the user is authorized and communicates the response back to N2O through SECURITRE. N2O then reacts appropriately, either allowing or denying access.
Does the N2O internal security system enable a site to restrict access to certain functions of N2O to certain users?
Answer:
Yes. N2O provides detailed security profiles, which allow the site to restrict access to N2O itself and to each function within N2O. The security profiles permit the site to develop "groups" that have certain access privileges associated with them, and to assign the privileges of one or more such groups to a user.
If the N2O interface to Treehouse Software's SECURITRE product is activated, N2O will check all security with the site's System Security Facility (i.e., RACF, ACF2, or TOP SECRET).
Question:
Can we guard against one user assuming ownership of another user's program?
Answer:
Yes. Access to the N2O utilities is controlled through the N2O security system. Users who do not have access to this utility cannot transfer their ownership of a program. In addition, the transfer utility, which is used to transfer ownership of a program, calls an N2O user-exit to enforce any site specific rules that further restrict users who can transfer ownership of programs to other users.
How does N2O determine which programs to list on its selection screens? Do all the programs on the selection screen come up because they are related by PREDICT XREF?
Answer:
N2O displays all of the objects in a given environment that are available for migration, even if those objects are not related by XREF. If XREF is being used, any related objects will be displayed on the XREF selection screen.
Question:
When the selection screen indicates that the selection of a given program has "FAILED" due to checkout restrictions, will N2O automatically indicate which user currently has that program checked out?
Answer:
When a program "fails" for Checkout reasons, placing the curser on the failed message and using PF11 will display why the failed message appeared.
Treehouse Software maintains a 24-hour, 7-day support system. Technical personnel are on call around the clock to solve customer problems.
Question:
We are seeking a vendor that is dedicated to support of their product. Does TSI employ full-time developers to maintain and enhance N2O and make it possible for customers to speak directly with product developers to discuss problems and enhancements?
Answer:
Treehouse Software has considered N2O to be an important, strategic product since it was introduced in 1989. Any N2O customer or prospective customer wishing to speak to a developer needs only to call Treehouse Software. Often, the developers speak with current and potential customers to discuss the value and implementation of intended enhancements to evaluate how users would prefer these enhancements to be implemented.
Question:
If necessary, is TSI willing to travel to our site to assist in the installation and setup of the product? Does TSI offer training in the use of the product?
Answer:
Treehouse Software's technical representatives are available to visit customer sites to assist with the installation, training, and setup of N2O if needed. Most sites, however, find that N2O requires little or no formal training, and that the installation can be quickly and easily accomplished using in-house resources.
Does N2O provide on-line tutorial/help functions? Are they menu-driven? Do they provide an "expert" mode? We are looking for user documentation that is clear and precise. Can we fully implement and use N2O without expert (senior programmer level) knowledge or additional training beyond that which is provided at acquisition time?
Answer:
N2O is completely menu driven and provides the ability to traverse the system using direct commands. Scrolling is available for functions that may produce several screens of output. On-line help screens display information about the current function or identify the data entry requirements for a particular field.
We are concerned about disrupting our production facilities during the activation/implementation and deactivation/removal of product upgrades. Will this be a problem with N2O?
Answer:
Conversion from one version of N2O to another generally requires nothing beyond a simple NATLOAD of the new software. Occasionally, an additional field or superdescriptor may have to be added to one of the N2O files to be used by the new enhancements.
The removal of N2O from your system will have no effect on Production, as N2O migrates code between existing FUSER and FDIC files. N2O requires two ADABAS files, which are used for tracking and audit purposes. These files do not contain NATURAL programs or PREDICT objects. This activity, therefore, should not cause any significant disruption to a site's production activities.
We need to ensure compliance with established standards, including JCL and documentation for standardization of Production activities. Is N2O capable of providing verification of compliance?
Answer:
An approver may review source programs in a migration before authorizing or servicing the migration. The approver may examine the NATURAL source code using an editor-like screen, but the approver may not edit the code. The N2O user-exits described earlier allow sites to code an exit to automatically enforce site program standards. Further, the N2O Program Compare utility, discussed earlier, will report all changes made to a NATURAL program. This report simplifies the verification of code changes or site standards.
How does N2O warn authorizers that an Event is awaiting their authorization? Will N2O interface with home-grown or standard EMAIL facilities to provide this type of information?
Answer:
The authorizer may view the "Events Pending Authorization" report to determine that Events are awaiting authorization. If the site has an EMAIL system, the N2O user-exits allow the site to code an interface that will notify the authorizer that an Event is awaiting approval.
