[Info-vax] [From VSI website] VSI Announces a Strategic Partnership with Sector 7

[Arne Vajhøj]

On 1/30/2021 6:36 PM, Bill Gunshannon wrote:
> On 1/28/21 11:00 AM, Arne Vajhøj wrote:
>> On 1/28/2021 10:44 AM, Richard Murphy wrote:
>>>> I know that, but the text said:
>>>>
>>>> "Postgres or Oracle databases hosted on VMS or Linux servers"
>>>
>>> ^ That's badly worded!  The option for Postgres is only for Linux.
>>>
>>> i.e. The options are:
>>> - Rdb, migrate database to Postgres on Linux
>>>     - Application can stay on VMS using the VSI Postgres Client 
>>> (fastest solution)
>>>     - or Application can migrate to Linux (obviously takes longer).
> 
> That depends on the language the application was written in.
> 
>>> - Rdb, migrate database to Oracle Classic hosted on Linux or VMS
>>>     - but Oracle Classic for VMS is going away, no one would do this now
>>>
>>> - Oracle Classic, migrate database to Postgres on Linux
>>>     - Application can stay on VMS using the VSI Postgres Client 
>>> (fastest solution)
>>>     - or Application can migrate to Linux (obviously takes longer).
> 
> See comment above.  :-)

Some depend on the language itself. VMS Cobol -> GNU Cobol,
VMS Fortran -> gfortran and VMS C -> GCC is probably not bad.
VMS Pascal -> FPC could be bad. And VMS Basic -> ??
would be very bad.

But more will depend on what the code actually does.

ISO/ANSI SQL is easy - database specific SQL means
problems.

Database access technology matters. Rdb module would
be a problem. Embedded SQL would be a problem for
some languages but fine for other languages (Cobol and C).
OCI would be fine.

Code full of LIB$ and SYS$ calls would be a problem.
Code using ISO/ANSI defined RTL functions would be
fine.

Newer stuff would be much better off. JVM languages
usinG JDBC or JPA would most likely not even need to
recompile. Python using DB API 2.0 would just need to
change the open statement. PHP would be be fine
if using PDO, but have problems with a database
specific API.

Arne