SB+ to OSMOSiS Conversion

How Does it Work?

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.

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



type Z


Field Definition



Screen Definition



Form Definition



Report Definition



File Update Definition

The following files are converted and stored as:

SB+ File





SB+ Menus Definitions



SB+ Generated numbers

The SB+ File xxDEFN is translated as follows:

Record Type



type CT


Translation Tables

type D


SB+ Dialogs

type J


SB+ Jobs

type K


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. 


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 and Windows mode and away you go., there is no need to convert the screens

After the 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 running the same character screens in 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. 

<< Back

Copyright 2012 SC Systems Ltd.  SC Systems is a member of the Mpower1 Group of Companies.
Privacy and Cookie Policy