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

[Stephen Hoffman]

On 2016-09-20 21:06:53 +0000, Chris said:

> 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.

Ponder that folks that do understand both fork() and spawn might have 
thought this through?    You're years out of date on OpenVMS by your 
own comments, and — inferring further from your comments — you're not 
entirely current on how parts of Unix work, particularly around fork(). 
    fork() and spawn are very different.  Sure, the results of both 
tend to be another process, but that's just the high-level overview.   
The details of that do differ.   The fork() call copies I/O channels 
and I/O state, and spawn doesn't.   The spawned process has to open its 
own channels.   The forked process gets the channels handed to it.   
The fork() call copies all of memory and the system implements what's 
known as copy-on-write and spawn doesn't and OpenVMS doesn't have 
copy-on-write in its memory management.   There are other differences.

There was a source code survey from OpenVMS development many years ago, 
and IIRC around 5% of the C code really used the fork() call.   The 
folks that worked on that particular code really understood what fork() 
provided, and used some or all of the features of the call.  The rest 
of the folks calling fork could have used some variation of the 
portable and standard C calls; the vfork() and exec() giblets.

For those that "just" need a spawn operation, vfork() and exec() work, 
and are much more portable.

Altering the code from fork() to something that works on OpenVMS or 
other non-fork() platforms can be somewhere between fussy but fairly 
easy to port and some can approach a rewrite.

>> 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 and LLVM/Clang are common choices on most platforms, and the 
OpenVMS x86-64 port targets support of LLVM and Clang on OpenVMS.

> 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.

It's less about make — GNU make is available on OpenVMS — and more 
about the GNU expectations of autoconf and configure et al.   It's now 
possible to run GNU configure scripts on OpenVMS, but that still 
requires tweaking the scripts, and getting them tailored to work with 
what OpenVMS provides.    The need to tweak these configure scripts 
and/or the source code when porting across disparate Unix systems is 
not particularly unusual, either.

More than a little of this — what allows the configure scripts to run — 
was code that John got working and is maintaining, too.

> 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.

There's code tied pretty tightly to gcc, but I've seen rather less of 
that than of code that's tied to some specific feature of GNU or Linux. 
  This mess really isn't all that different from the days of porting 
between various Unix systems, and it's something

> 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.

Cross-compilation and translation make for less maintainable code.   
I've used it as part of porting OpenVMS itself, and it's problematic — 
and that's when you are maintaining the cross tools and the rest within 
your team — and something that everybody wants to rip out just as soon 
as they can.  Errors can arise in the underlying target system, in the 
translated code and libraries, in the secondary translation for stuff 
that came over from VAX, or in the original source code itself.  Makes 
figuring out failures very interesting.

Tools including bash, binutils and other pieces are already available 
for OpenVMS, too.

Itanium is not the path forward.  There's one more generation of that 
expected; the Kittson processor.

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

Having ported more than a little code around, gcc isn't a central 
factor in any of the code I've hauled around.   Dependencies on c99 or 
(just starting to see these) c11 bits, missing library calls, buggy 
OpenVMS implementations, dependencies on fork(), it runs the gamut.   
But I've encountered little that was tied specifically to gcc.

Ask questions.   Ask for documentation or pointers to tools or 
resources.    Twenty year old assumptions and recollections might still 
work — this is OpenVMS, after all — or they might not.   Get Python and 
GNV and the GNV updates installed.   Go port some code.  Maybe read 
some notes from and listen in on some of the porting calls.  Search 
through postings here in comp.os.vms newsgroup via the Google Groups 
archives.    OpenVMS doesn't have an open source community of any size, 
so it'll be pretty easy to get to know most folks involved, and what's 
going on...




-- 
Pure Personal Opinion | HoffmanLabs LLC