Home » Products » OSMOSiS 4GL Builder » OSMOSiS SB Conversion

Key features | About the Conversion Process | Screen shots

Using OSMOSiS SB Converter we have a migration path from other 4GL products. Existing applications, created with proprietary 4GL systems such as System Builder, SB+ or Magician, can be imported and converted into OSMOSiS formats and conventions, in a simple process, with minimal post-conversion work.

OSMOSiS-SB Converter is a full and comprehensive conversion suite taking ALL of the original 4GL parameters and creating both character and Windows-based OSMOSiS applications.

	Key Features
	Convert System Builder (SB) Convert System Builder+ (SB+) Converts Screens, Forms, Reports & Menus Converts ALL Processes & Paragraphs Converts Correlatives, Defaults & Validations	Converts Basic Program Code Converts Toolbars Converts Custom Components Extensive aftercare Beneficial features in OSMOSiS

About the conversion process

SB+ 4GL files and parameters are converted into OSMOSiS formats to ensure that the application can be maintained and developed further after the conversion process is complete. 

All of the original application elements are capable of being developed, as they were before, albeit using different tools, screens and functions.

The functionality of the resulting character application is slightly different to the original SB+ application but is sufficiently similar that the user will observe a familiar look and feel to it.

The graphically represented application becomes a Windows’ suite in look, feel and functionality – not a ‘screen-$scrape’ of a character-based system. There are ‘infinitely’ more facilities and power in the Windows’ GUI mode and there are more being developed regularly.

Once converted into OSMOSiS the application can be run as a Character-based system, a full Client/Server Windows system or a mixture of both.

There is also the flexibility to decide that any routine, better suited to character operations, can be called as character based routine from a Windows based menu option. 

All development can be performed in the Windows OSMOSiS Developer part of OSMOSiS, including generating, maintaining and supporting character-based screens. There are 4GL tools in both OSMOSiS modes, although the OSMOSiS Developer GUI tools must be used to develop GUI screens. 

There are system tools to manage the entire application and development environments of jBASE and OSMOSiS. 

The ‘old’ SB+ account becomes more powerful, more flexible and more future-proof after the move to OSMOSiS.

	System  Builder to OSMOSiS Conversion The system converts the Dictionary and/or Data of every file in the SB source account and creates the equivalent files in the ‘new’ OSMOSiS account. The SB Dictionary holds all SB field definitions, OE fields, screens and prints, which are copied to OSMOSiS files. The resulting converted files are split so that the file’s dictionary contains the OE definitions, the _DICTS,filename contains the OSMOSiS definitions (converted from SB), the _DISPLAYS,filename contains the screen definitions and the _PRINTS,filename contains the print forms and/or reports. The 4GL conversion procedures are:   SB/SB+ Files OSMOSiS Files xxBATCH _BATCH xxREPORTDEFN _ACCESS,filename xxUPDATEDEFN _UPDATES,filename xxTRANDEFN _TRANS xxCONTROL records are converted to various files: Menus are converted to _MENUS. Generated numbers are converted to _GENNO. xPASSWORD is converted to _PASSWORD. During the conversion process, any SB defaults, validations, correlatives and conversions are recorded in BOTH SB and OSMOSiS formats. This enables developers to continue with their familiar formats and the items are converted at the time of entry into OSMOSiS formats for run-time execution. Finally, any file named xxUFO or xxPROGS, where xx is the SB system id., will be treated as a program file together with any that the operator specifies separately. Each program’s code convert to use the OSMOSiS COMMON area and the OSMOSiSsubroutines that correspond to COMMON variables and routines in SB. These files will be compiled and catalogued ready for use in running the application.

	The SB+ Conversion Process OSMOSiS SB Converter converts the Dictionary and/or Data Files of every file in the SB+ source account and creates the equivalent files in the ‘new’ OSMOSiS account. The SB+ Dictionaries, holding all SB+ field definitions, OE fields, screens and prints are converted into OSMOSiS. The OSMOSiS files are split so that the file’s dictionary only contains the OE definitions.  SB+ record types stored in the file dictionaries are converted and stored as:   SB+ Record OSMOSiS File Description type Z _DICTS,filename Field Definition SCREEN _DISPLAYS,filename Screen Definition PRINT _PRINTS,filename Form Definition REPORT _ACCESS,filename Report Definition UPDATE _UPDATES,filename File Update Definition The following files are converted and stored as: SB+ File OSMOSiS File Description xxBATCH _BATCH  SB+ Transaction Batch File xxTRANDEFN _TRANS SB+ Transaction Definitions xxMENUS _MENUS SB+ Menus Definitions xxCONTROL _GENNO SB+ Generated numbers The SB+ File xxDEFN is translated as follows: Record Type OSMOSiS File Description type CT _TABLES Translation Tables type D _DIALOGS SB+ Dialogs type J _AUTO SB+ Jobs type K _FKEYS SB+ Function Keys The SB+ File xxPROCESS is translated as follows: All records are stored in the OSMOSiS file _PROCS and consist of the original code.  SB+ paragraphs/P-processes convert to Basic code and are stored in _PROCS,filename Those routines not associated with any file go to _PROCS,COMMON SB+ selections/S-processes convert to _SEARCH,filename During the conversion process, all SB+ defaults, validations, correlatives and conversions are recorded in BOTH their original construct and converted to the OSMOSiS format. Finally, any file that is named xxUFO or xxPROGS, where xx is the SB+ system id, is treated as a program file together with any specified separately by the operator at the beginning of the conversion routine. Each program’s source code is converted to use the OSMOSiS COMMON area, variable names and subroutines that correspond to SB+ COMMON variables and routines. These files will be compiled and catalogued ready for use in the application.

	After the SB/SB+ Conversion Once the conversion process is complete, the OSMOSiS account’s logon is attempted and the Password and User Id are requested. Upon a successful logon, the “MAINMENU” is displayed, which is a list of original SB+ ‘systems’.  OSMOSiS does NOT work with ‘systems’ and therefore during the conversion menu names are created which are prefixed with the SB+ system parameter, e.g. SALESMENU in a SB+ system id of AC will become ACSALESMENU in OSMOSiS. Similarly, transactions and processes will be prefixed with the SB+ system id for the file that the transaction was converted from. OSMOSiS does NOT allow field names that contain full stop, comma, plus, star, slash, minus or equals. Underscore is the most commonly used delimiter that is permitted in OSMOSiS. During the conversion process it was recognised that many SB+ applications use any (and most) delimiters in field names.  OSMOSiS allows the continued use of these fields, as is, BUT new fields cannot be defined with the restricted delimiters within their id. The resulting application will have the same files, fields, screens, prints, reports, menus, updates, processes, passwords and generated numbers as the original. The contents of each database element will be the same but will be formatted differently and will reside in OSMOSiS files. Some names will have changed. The data file’s dictionary will only contain the OE definitions for the file. Defaults, Validations, Correlatives and Conversions will be visually identical to those in the original application. Developers can continue to use these same formats that are so familiar to them and OSMOSiS will take care of making it a OSMOSiS formatted statement, invisible to the developer. Processes will be visually identical to those in the original application but will be referenced as OSMOSiS processes. Developers can continue to use these same formats that are so familiar to them and OSMOSiS will take care of making it a OSMOSiS formatted subroutine, invisible to the developer. Now the application can move forward into the Client/Server Windows environment by applying the converted character screens into the OSMOSiS Windows system. The final application can be operated in Character and Windows modes and if required a combination of both, even on the same screen.

	Conclusion The final result is designed to ensure that the developer has the minimal post-conversion tasks to perform and that the continued development of their application in OSMOSiS requires no retraining in the substantive areas of their existing systems – defaults, validations, correlatives, conversions and processes.  The application is now ready to run in character mode. To run the application in Windows mode you just need to convert the screens and away you go.

Screen Shots

		Main Conversion Screen
		The screen shot illustrates an SB+ account being setup to be converted over to OSMOSiS. Notice the program file list needed to be entered to complete the job correctly.