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 encom
