[Info-vax] What would you miss if DECnet got the chop? Was: "bad select 38" (OpenSSL on VMS)

[Chris]

On 09/20/16 17:17, Stephen Hoffman wrote:

>
> fork() is not available on OpenVMS, and has little direct relationship
> to the socket API. Code that uses fork() can range from fairly easy to
> port, to basically impossible. The stuff that's easy to port doesn't
> really use fork(), so it can be replaced with some combination of the
> vfork() and exec() calls.
>

Of course, i'm years out of date, but doesn't VMS have a spawn system
call to set of a new new process ? I guess the question being if
a spawned process inherits the parent environment or not.


>
> I'd tend to expect that approach would add as many complications as
> it'll remove. While there are gcc ports around, gcc is gcc and
> self-contained not really tied into any of the underlying interfaces and
> tools on the target platform, and OpenVMS is rather more different from
> most GNU/Linux boxes. Off-hand, I don't know if gcc is tied into the
> OpenVMS debugger, into the threading libraries, or other pieces of the
> environment, for instance.

I only ask that question because much (most?) open source
software assumes a gcc environment, gnu make and all the
other gnu utilities already installed, of which there are
many. Gcc has it's own specific command line arguments,
extensions etc, which are unlikely to be compatible with
other compilers and you really want avoid delving into the
Makefiles if you can avoid it. Having built gcc and other
utils from time to time, I can tell you that you would not
want to go near some of the Makefiles, which can induce
brain damage on sight :-), but that would be needed if
gcc etc is not in place.

Overall, not an easy task I guess. Fwics, gcc for VMS was
dropped years ago, not a good omen. Don't know if it
could be used to bootstrap later versions. I guess you
could cross compile from a Linux or similar os to Itanium,
which works very well on some architectures used here.

In fact, a cross compile environment might be the best way
to go, hosted on Linux, FreeBSD, etc on X86, cross
compiled to an Itanium target. Same for binutils and make.
Doesn't solve the problem of run time interface to VMS,
but it would be a start just to be able to generate Itanium
binaries using a gcc compiler tool chain.

Related HP-UX link here which may be of interest:

http://hpux.connect.org.uk/hppd/answers/4-5.html

and here:

https://gcc.gnu.org/install/specific.html#ia64-x-linux

Looks like Itanium is still supported, so should be
expected to work in a cross compile environment.


>
> There are monthly discussions that John has been a frequent if not
> regular participant, and those discussions have included folks from HPE
> in past years, and have picked up some folks from VSI.
>
.
>
> If you're interested, probably start by getting Python and other tools
> going, as well as getting GNV installed somewhere on an OpenVMS server
> you're using. Or use the GNV environment on decuserve, and develop
> there. Why Python? Python is the path into the common DVCS packages on
> OpenVMS.
>
>

Haven't used VMS since 1995ish, but still take an interest, such was the 
magic of the old DEC :-)...

Regards,

Chris