|
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 |
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 |
|
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.
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 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 |
