| Oracle applications are generally portable across operating systems
because the applications are written in Oracle's languages, tools, etc.
The same application is also portable to many other environments.
However, there are many limitations - some due to the nature of 4GL's
and some due to Oracle's release cycles.
A simple SQL*FORMS application is portable anywhere. However, not all
applications are that simple. Many times an SQL*FORMS application must
use 'user exits' - calls to 3GL code. If this is done, the application
is no longer portable - unless you consider any 3GL portable. There
are differences in building the application (MMS, MAKE, compiles, links,
loads, etc).
Applications may also require access to operating system features or to
command language processors (DCL, C shell, Borne shell, JCL, etc). In
this case, the application is not portable.
Some applications have a performance requirement that requires the use of
3GL code, non Oracle forms packages, etc. These are not portable.
Because each machine has different performance capabilities due to architecture
or configuration, the performance of the application may vary. As a result,
the application and database may be designed around one set of constraints.
When the application is moved to a new environment, the set of constraints
may change. This non-portability issue probably appears more with the
physical database design but may also impact the logical design and the
application.
So, the simple application is portable. But the simple application is
portable with almost any system. Even, dare I say it, Rdb. Use standard
SQL and C, avoid operating system calls, select a portable forms package, and
you have portability. You can also recommend a variety of portable 4GLs that
run on Rdb and get application portability and a better 4GL in the process.
Everyone has their own list of 4GL's. This weak we are featuring Ingres
tools for Rdb, Powerhouse, {and I forgot the others}. Check Today, Corvision,
Cullinet's stuff, etc.
...............
Talk about long-winded .... :-)
--david
|
|
I have worked on "portable" software systems and applications for
several years with another company. The following is a brief summary of
my past experience.
. Usually, the best we can hope for is source level portability across
machines with different architecture and/or operating systems unless
the systems are made completely compatible.
For simple DBMS applications, it is portable provided that the applications
only contain the DBMS application language sources. Even in this case,
performance may differ from system to system.
. For applications involving 3GL's, the portability cannot be greater than the
languages themselves. However, it is still possible to write conditional
code to maintain source level portability.
With portable source code, it is still necessary to generate the resulting
executable code on the target machine. Even within UNIX System V, the
executable are generally not compatible for different hardware systems.
Sometimes the executable are not even compatible among different models
of a given series by the same manufacturer.
. For applications involving the command language of the host environment,
the languages themselves are usually not portable. For example, DCL and
Ultrix shell are certainly different. Ultrix/BSD 4.2 and UNIX System V
are not completely compatible either. The best I have seen is to write
in a conditional form and invoke some preprocessor to generate the results
for any particular target system.
. Even for applications involving the host environment command languages and
3 GL's, it is indeed possible to use a single system for most of the
development work for the applications. However, it is necessary to have
access to all the targeted systems for the final porting, testing, and
delivery. For example, the porting may involve the generation of the
resulting conditional code and the excutables, the tuning of the system
dependent features, etc.. Depending upon the complexity of the system,
the porting cycle on each target system may take days or months.
In short, although it is not necessary to reinvent the wheel on all the
systems, it is also not likely to deliver the applications to different
systems without having access to the systems. The truth is usually
somewhere in between.
|