Migration Requirements

Remodeling:
In the remodeling of a house, the first step is generally to take a step back to determine if the basic structure suits the needs of the owner. In the case of software, similar questions must be asked about the application: Is the basic application sound, or do significant defects exist in the current application? What features must be added? Is there a mandate to add new technology in the application (XML, Java, .NET, etc)? Are the dictionaries clean and appropriately named? The first step is to determine the strengths and weaknesses of the existing application and to build a roadmap to remodel or rennovate.

Application type:
There are many styles of application development. The ease or difficulty of migration to Nucleus depends on how an application was developed. If your application was developed using tables that define screen positioning, field names and width, input and output conversions, search criteria, etc., conversion routines can be built to translate a great portion of your existing application definition to the Nucleus environment, greatly reducing the work involved.

If your applications are coded, with business rules embedded within the display logic, the business rules must be separated or abstracted from the display. The abstractions will then be incorporated into either subroutines that can be called from specific event programs attached to individual Nucleus screens, embedded as expandable functions or as INCLUDES

Where to begin?

The applications:
Individual applications or utilities can be targeted for deployment according to your schedule. There are no hard rules that require every application to be "wrapped" in Nucleus. File maintenance screens and utilities can be quickly built, easily deployed and a good place to begin developing your Nucleus skills.

Report conversion:
Existing reports that take their run-time parameters from either a data file or PROC, can be easily "front-ended" with a Nucleus screen, rapidly adding features like pop-up selection of customer or part description (try and do that in a PROC).

Existing BASIC programs can be executed from within a Nucleus screen or from a Nucleus menu. A basic rule should be followed to not allow a CRT or INPUT within a subroutine called from a Nucleus screen as it would be a conflict in the Graphic User Interface. CHAIN or CLEAR statements should never be used.

Subroutines:
All subroutines with PRINT, CRT or INPUT must be identified, and revised so that the Nucleus engine is used to provide all display and data input using screens developed in Nucleus. This may require that separate Nucleus screens be created, or merely that the logic structures be integrated within a Nucleus subroutine attached to the main-line screen. All subroutines that do Writes must be identified and evaluated to determine if the write should be part of a pre-write event / commit procedure. Equates found in subroutines enhanced for Nucleus, that conflict with Nucleus common block equates must be removed.

Security:
Nucleus security follows a scheme similar to Unix, where GROUP associations and individual user permissions can allow or disallow access. Under Nucleus security, every verb, command, menu, printer, or file can be regulated according to either the workgroup association of the user, or by specific security permissions enabled or disabled for an individual user.

Security can be controlled all the way down to the field level, and can be set according to work-group or specifically for any individual user. Individual users must be defined for each Nucleus user.

For detailed security information, please review the Nucleus Security Overview PDF document, as well as the hyper-linked security documentation at NuWiki.com.

Menus:
Existing menus should be converted to Nucleus menus, as they support both character- based display and GUI. Security is inherent in the Nucleus menu structure. Programmer friendly features enable the programmer to directly jump from a menu option and review the associated program, screen or report called from the Nucleus menu. Conversion from menu structures contained within tables is generally straightforward and can usually be accomplished in a day or less by a skilled programmer. Conversion from legacy style menus embedded within PROC's or BASIC programs usually involve a bit of detective work, as the COMMAND and DISPLAY elements must be abstracted and put in a Nucleus menu structure.

Other menu options include Help, Pause after display, forced display co-ordinates, graphic element (picture), and menu style (Bar, List, Tree). A menu manager assists in menu setup and definition.

Nucleus menus can be global (across all accounts), or specific within an individual account. Different menus can be made available for individual work-group associations (security based) or specific to individual users. If a user is specifically denied access to a program or Nucleus screen (from within Nucleus security assignments), that option would not appear on the user's menu as a choice.

For additional details and information regarding Nucleus menus, please review the detailed hyper-linked menu information at http://www.NuWiki.com.

To see what Nucleus menus look like, view the PowerPoint presentation

Technical Points-general:

1. The cleanup of Data Dictionaries is an essential step in the transition to Nucleus. Dictionary names should be meaningful. Labels should be provided for each dictionary element. Dictionary names using numbers as main definitions should be avoided. No reserved characters may be used in the dictionary names. A utility to convert reserved characters found within dictionary names to periods, is called FIX.DICTS and can be used in any account shared with Nucleus. Reserved characters include ~!@#%:^&*()-=+[]{}<>, The Nucleus FILEMAINT utility will simplify dictionary maintenance. See the document NucleusTechRef for information on FILEMAINT.
2. It is recommended that file-names be self-documenting. Two letter file names should be avoided, as we often see conflicts with filenames as VM, CM. Create all new files with FILEMAINT. This will make it easier for new staff programmers to support your applications.
3. All subroutines with PRINT or INPUT must be identified, and revised so that the Nucleus engine is used to provide all display and data input using screens developed in Nucleus. This may require that separate Nucleus screens be created, or merely that the logic structures be integrated within a Nucleus subroutine attached to the main-line screen.
4. All subroutines that perform WRITE's must be identified and evaluated to determine if the write should be part of a pre-write event / commit procedure.
5. Equates found in subroutines that are enhanced for Nucleus, that conflict with Nucleus standard equates must be revised to eliminate conflicts. Review within IBP,INCLUDES the EQUCOMMONS, GLOBALCOMMON, INITIALZE and the SBP,INCLUDES PORTINFO files for listing of reserved Nucleus equates.
6. All subroutines that will be called from within a Nucleus screen must be reviewed to ensure compliance with standard Nucleus INCLUDES and data passing requirements.
7. It is recommended that current INCLUDES used in your application set should be moved to a common area such as VARNAME.BP,INCLUDES to simplify future maintainability and support
8. Source Code control. Existing programs should be placed under Nucleus source code control to simplify support and deployment issues during the transition. Programs should be placed in a data area under a main program file as VarName.BP,S where the source is found in the "S" data area. See Nucleus SourceCodeControl document for additional information. Source code control is covered in depth in the intermediate Nucleus course.
9. Development "Projects" should be setup under Nucleus source code control. Project management allows sections of applications to be delivered as a sub-set of the entire application, and also tells Nucleus which files will be managed under NuControl.
10. If any necessary programs that will be part of your application set do not have source code, the functionality must be reverse-engineered or a de-compiler procured to re-build the source.
11. PROC-driven menus should be replaced with Nucleus menus providing both character and GUI support as well as enhancing security.
12. All programs that write-out PROC's must be revised/re-written to avoid PROCs. for additional information. It is suggested to use Nucleus PARAGRAPHS in either Batch or Procedure mode.
13. Any programs that use CLEAR or CHAIN should be modified, removing these commands.
14. Logic should be extracted from legacy code and reconstructed as either subroutines, or expandable functions so that compatibility between legacy and Nucleus applications can be preserved using the same rules and logic in both application sets during the transition from legacy to Nucleus. (Reviewed in depth in the advanced Nucleus class)

Note to System Builder users:
Existing applications written in System Builder or other development environments can be transformed and empowered for the future with Nucleus, capitalizing on your existing application investment. We can convert 95% - 99% of a System Builder or SB+ application directly to Nucleus, preserving the look and the feel of your applications, while reducing support requirements and increasing future functionality.
Download PowerPoint: System Builder to Nucleus Conversion
Download PowerPoint: Reasons to convert from System Builder to Nucleus

Training and Support:
Binary Star can provide a full range of training and instruction at your location, at your convenience, or at our training site in Cincinnati Ohio. Support programs can be tailored to suit your specific needs whether they are standard 9-5 Monday-Friday or 7 x 24 including holidays.

Migration Assistance:
Binary Star offers a full range of professional services including application design, development, prototyping and proof-of-concept engineering services to ensure a rapid and successful migration of your applications to Nucleus. We would be happy to provide you with a quotation for short-term or long-term programming and engineering assistance.