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 to
OSMOSiS Home
|
