Hi

We're considering porting the server component of an application to
OpenVMS in order to attact some potential new business. It currently
runs on Windows, Unix and Linux.

Essentially I'm looking for some advice (or pointers to advice) about
the following:

1) We currently compile with gcc and use the GNU C and C++ libraries.
Are their binaries around for OpenVMS versions of GCC?
2) Threading: My initial research suggests this shouldn't be a problem
as we use POSIX threads and mutexes. Unless someone knows otherwise?
3) With regards to C++, is support for standard library streams
straightforward enough in the OPenVMS file system.
4) Libraries - Am I correct in thinking we should be able to compile
anything we compile into an SO / DLL into a sharable image?

Finally, does it make sense to be looking at the Porting Library?

Thanks in anticipation of any advice

David Topham

David Topham wrote:
> Hi
> 
> We're considering porting the server component of an application to
> OpenVMS in order to attact some potential new business. It currently
> runs on Windows, Unix and Linux.

Welcome,

Here is a URL to start out with: www.hp.com/dspp . It is for the HP's 
developer & solution partner program.  Membership is free and discounts 
are available for hardware and software.

> Essentially I'm looking for some advice (or pointers to advice) about
> the following:
> 
> 1) We currently compile with gcc and use the GNU C and C++ libraries.
> Are their binaries around for OpenVMS versions of GCC?

There are some binaries available for for VAX and Alpha.  As far as I 
know they are very out of date.

With the avialability of HP C and HP C++ for OpenVMS free under the 
OpenVMS Hobbiest program, the amount of people motivated to maintain a 
port of GCC for either platform has shrunk.  I have not seen a posting 
by anyone claiming to maintain a current public port of GCC in years.

I would recommend using HP C instead of GCC, it will probably give you 
better code generation.

> 2) Threading: My initial research suggests this shouldn't be a problem
> as we use POSIX threads and mutexes. Unless someone knows otherwise?

I know that OpenVMS supports POSIX threads, I have not worked much with 
that API though.

If you go to http://www.hp.com/go/openvms/ and click on the documenation 
link, the documentation for the POSIX threads is there with the 
Operating System Documentation.

> 3) With regards to C++, is support for standard library streams
> straightforward enough in the OPenVMS file system.

I have not worked with C++ either, so it would be a matter of checking 
the C++ documentation.

> 4) Libraries - Am I correct in thinking we should be able to compile
> anything we compile into an SO / DLL into a sharable image?

Yes.  Shared Images are a little different on OpenVMS than they are on 
UNIX/Microsoft Windows.  All global symbols must be resolved at link time.

See the shareable image cookbook:
http://h71000.www7.hp.com/wizard/swdev/ovms-shexe-cook.html

If you want to supply your product as a shared image that will be called 
by others then there are VMS specific things that need to be done.

If you just need your image known so that when multiple processes run it 
they all run the same in memory copy of the executable section, then you 
do not have to create a shared image.  Unless you tell them otherwise, 
the compilers and the linker know to do the right thing.

> Finally, does it make sense to be looking at the Porting Library?

That depends on a your application.  The Porting library provides some 
routines that are missing from the C RTL, and it also provides a one-way 
name mangling to convert UNIX/Microsoft Windows style names to the ODS-2 
format names.  This name mangling works for some client applications, 
but does not work so well for some server applications, as there is no 
way to come up with the original filename from scanning the directory.

OpenVMS has two file systems in use.  An older traditional one that is 
limited to 39.39 character filenames with a single dot, and a restricted 
case insensitive set of characters, and a newer one that allows 
filenames up to 255 characters long with even unicode support, and 
optional case sensitivity.

-John
malmberg@dskwld.zko.dec.compaq.hp
Personal Opinion Only

I have passed this to John E. who will follow up directly.

"John E. Malmberg" <Malmberg@dskwld.zko.dec.compaq.hp> wrote in message
news:EnVKc.6094$kz.534@news.cpqcorp.net...
> David Topham wrote:
> > Hi
> >
> > We're considering porting the server component of an application to
> > OpenVMS in order to attact some potential new business. It currently
> > runs on Windows, Unix and Linux.
>
> Welcome,
>
> Here is a URL to start out with: www.hp.com/dspp . It is for the HP's
> developer & solution partner program.  Membership is free and discounts
> are available for hardware and software.
>
> > Essentially I'm looking for some advice (or pointers to advice) about
> > the following:
> >
> > 1) We currently compile with gcc and use the GNU C and C++ libraries.
> > Are their binaries around for OpenVMS versions of GCC?
>
> There are some binaries available for for VAX and Alpha.  As far as I
> know they are very out of date.
>
> With the avialability of HP C and HP C++ for OpenVMS free under the
> OpenVMS Hobbiest program, the amount of people motivated to maintain a
> port of GCC for either platform has shrunk.  I have not seen a posting
> by anyone claiming to maintain a current public port of GCC in years.
>
> I would recommend using HP C instead of GCC, it will probably give you
> better code generation.
>
> > 2) Threading: My initial research suggests this shouldn't be a problem
> > as we use POSIX threads and mutexes. Unless someone knows otherwise?
>
> I know that OpenVMS supports POSIX threads, I have not worked much with
> that API though.
>
> If you go to http://www.hp.com/go/openvms/ and click on the documenation
> link, the documentation for the POSIX threads is there with the
> Operating System Documentation.
>
> > 3) With regards to C++, is support for standard library streams
> > straightforward enough in the OPenVMS file system.
>
> I have not worked with C++ either, so it would be a matter of checking
> the C++ documentation.
>
> > 4) Libraries - Am I correct in thinking we should be able to compile
> > anything we compile into an SO / DLL into a sharable image?
>
> Yes.  Shared Images are a little different on OpenVMS than they are on
> UNIX/Microsoft Windows.  All global symbols must be resolved at link time.
>
> See the shareable image cookbook:
> http://h71000.www7.hp.com/wizard/swdev/ovms-shexe-cook.html
>
> If you want to supply your product as a shared image that will be called
> by others then there are VMS specific things that need to be done.
>
> If you just need your image known so that when multiple processes run it
> they all run the same in memory copy of the executable section, then you
> do not have to create a shared image.  Unless you tell them otherwise,
> the compilers and the linker know to do the right thing.
>
> > Finally, does it make sense to be looking at the Porting Library?
>
> That depends on a your application.  The Porting library provides some
> routines that are missing from the C RTL, and it also provides a one-way
> name mangling to convert UNIX/Microsoft Windows style names to the ODS-2
> format names.  This name mangling works for some client applications,
> but does not work so well for some server applications, as there is no
> way to come up with the original filename from scanning the directory.
>
> OpenVMS has two file systems in use.  An older traditional one that is
> limited to 39.39 character filenames with a single dot, and a restricted
> case insensitive set of characters, and a newer one that allows
> filenames up to 255 characters long with even unicode support, and
> optional case sensitivity.
>
> -John
> malmberg@dskwld.zko.dec.compaq.hp
> Personal Opinion Only

In article <77fa68a3.0407190915.18466fd4@posting.google.com>,
 david.topham99999@tiscali.co.uk (David Topham) wrote:

> 1) We currently compile with gcc and use the GNU C and C++ libraries.
> Are their binaries around for OpenVMS versions of GCC?

You might check with AdaCore Technologies (http://www.adacore.com/), 
who I believe maintain a port of gcc in support of their Ada product.  
Whether you can get gcc separately or whether it has a code generator 
anywhere near the quality of the well-regarded hp compilers I don't know.

If you are accustomed to recent versions of gcc and don't get a lot of 
spewage when you enable all warnings, the hp C compiler will cause you 
very little trouble from a language perspective.  The C library will be 
missing a few things that are in libc, but it's hard to predict without 
doing an analysis whether this will be an issue. 


 The CRTL manual is located off of 

http://www.hp.com/go/openvms/doc


> Finally, does it make sense to be looking at the Porting Library?

By all means look, but don't assume you need what's there unless you 
are solving the exact same problem the writer of the wrapper function 
there was solving.  

A few places you'll want to look as you build your toolbox:

http://h71000.www7.hp.com/opensource/opensource.html

http://h71000.www7.hp.com/portability/index.html

http://h71000.www7.hp.com/ebusiness/technology.html

David Topham wrote:

>Finally, does it make sense to be looking at the Porting Library?
>
Many of the problems which were addressed by the Porting Library have 
been fixed in more recent versions of the CRTL. To be honest the Porting 
Library is getting less and less useful. Having that said though, I 
think its still worth looking at the routines and seeing what they do. 
At least then if you do run into a problem which is addressed by the 
Porting Library you'll have an immediate solution.

John E. Malmberg wrote:
> David Topham wrote:
>> 2) Threading: My initial research suggests this shouldn't be a problem
>> as we use POSIX threads and mutexes. Unless someone knows otherwise?
> 
> 
> I know that OpenVMS supports POSIX threads, I have not worked much with 
> that API though.
> 
> If you go to http://www.hp.com/go/openvms/ and click on the documenation 
> link, the documentation for the POSIX threads is there with the 
> Operating System Documentation.
> 
I use them sometimes, but note that the set is not complete (especially 
the part where signalling/interupts are used) Every thing is well 
documented in one of the manuals : Guide to the POSIX threads library.

              Jouk