[Info-vax] Help wanted : Porting code from Linux to VMS

[Stephen Hoffman]

On 2019-01-22 20:44:15 +0000, Marc Van Dyck said:

> My job today is mainly system administration. But I have done software 
> development in the past, and still enjoy doing some programming when 
> the opportunity arises. What I have been asked to do today is however a 
> bit more challenging for me than usual.
> 
> It'll basically consist of porting C code written for a linux platform 
> to OpenVMS. And it won't be the trivial 'copy the code and recompile' 
> job :

That's a wholesale rewrite, not a port.

I'd tend to port the C code, as that's almost always a smaller project 
than a wholesale rewrite.

Porting the C code also means I have less effort re-porting changes in 
the existing app from Linux, and less effort porting OpenVMS changes 
back to Linux.  This if the C code is being maintained and updated for 
Linux.

> 1) it contains several system calls which I'll need to find an adequate 
> equivalent for. I think I can manage that one, even if I know nothing 
> about Linux.

The OpenVMS CRTL implements most Linux system calls; those in ANSI/ISO 
C, and the older/subset IEEE POSIX calls, and the pthreads C threading 
calls.

There's open source from BSD and other projects for various of the 
remaining calls.

Which specific C system calls?

If the particular C code involved is open source, what is the package?

> 2) I will port the code from C to Pascal, which is the only language I 
> feel comfortable with. Not afraid by that one, have done it several 
> times already.

You are rewriting the code.  Not porting it.   Pragmatically, you're 
probably better wholly reimplementing the environment.  There's little 
reason to even start with the existing C code if you choose this path, 
save maybe as one very general reference for what's involved in your 
rewrite.  And I'd start with a new design here, specific to your 
requirements.  If you're going all-in on OpenVMS, that variously also 
means ASTs or KP threads and $qio calls.

> 3) The code contains a good dose of TCP/IP programming. And there I'm 
> somewhat lost, because I never touched that in the past. So I'd 
> appreciate a bit of help to get me started...

Time to learn C and sockets and TLS, then.   There are far more career 
opportunities here than there will be with Pascal and $qio calls.  Get 
out of your comfort zone.

> Hence the following questions :
> 
> 1) Is there any documentation about that ? How to write, on OpenVMS, 
> code to establish a TCP/IP communication with another host ? Like what 
> you would do with DECnet non transparent task to task communication ?

The code involved is the Unix code.  I'd avoid the examples included 
with the OpenVMS documentation (TCPIP$EXAMPLES), as those tend to be 
outdated and the error handling can be problematic, and security is 
utterly lacking.

And I'd look to enable IPv6, and to use TLS and/or DTLS here.  You're 
writing new code.  Best to write this new code securely, and the 
rewritten code should use modern IP networking.

> 2) Any coding examples availabe somewhere, or that someone would agree 
> to share ?

DDG and Google will find various source code examples.  Many examples 
of C socket code exists around the 'net.  And the C socket code is very 
commonly directly portable to OpenVMS.

Beej's site is a pretty good read, for old-style C and IP socket code.  
https://beej.us/guide/bgnet/html/single/bgnet.html

There are also C and IP socket books available from various sources.

If the code is not particularly performance-sensitive, then Python or 
another similar approach may well be a good approach, and Python has 
far better networking support than does OpenVMS Pascal.

DEC/Compaq/HP/HPE had some old $qio example code from circa 1999 that 
they've seemingly been passing around to customers for a while now, but 
that $qio code can be somewhat lacking in features and capabilities and 
compatibility, and there's no way to retrofit updates as that code has 
gotten embedded in various apps.  This having bumped into it at various 
sites.

> Preferably in Pascal, but I'll understand if only C is available...

I can send along some open-source C socket and TLS code that's callable 
from descriptor-based languages on OpenVMS.  Not sure if it'll fit in 
your mailbox, though.  And it's definitely not the way I'd go, here.  I 
would not look to rewrite the existing code into Pascal.

> 3) Are the TCP/IP calls definitions that I'll need to use available in 
> pascal environment files somewhere ? Or SDL definitions that I could 
> translate and compile ?

The $qio definitions are in the libraries, if you want to rewrite all 
of this code using the $qio[w] interface.  And there's no TLS interface 
for $qio on OpenVMS.

Otherwise, you're wrapping and using the C socket code, if you need 
Pascal.   Convincing Pascal to use the C sockets API or the TLS API 
directly will be an exercise in frustration.

The Process IP stack has compatible C socket and $qio support, though 
the command interface does differ.  This as VSI is replacing the TCP/IP 
Services stack with a fork of the Process IP stack.  C code should not 
see differences here, and I'd doubt that the $qio code will 
substantially differ.  The Process stack had better IPv6 support when 
last I checked, too.

> If you want to send me something, the address is marc dot gr dot 
> vandyck at skynet dot be.

Caveat: TCP is a *stream* protocol, and not a datagram-oriented or 
message-oriented protocol.  That is, you can write one big I/O, and the 
receiver can get then receive the data as one big read, or a loop and a 
blizzard of one-byte read requests until all the data arrives.  Or you 
can write a hundred one-byte requests out, and the receiver might get 
one or two hunks totalling a hundred bytes.  Don't assume that reads 
and writes match.  At all.  TCP sockets do not work at all like OpenVMS 
mailboxes or RMS records.

 Yes, I've been grumbling about the lack of secure networking 
frameworks on OpenVMS for a while, too.

In any case, you'll inevitably end up learning a whole lot about C 
here.  Might as well learn C.



-- 
Pure Personal Opinion | HoffmanLabs LLC