Help wanted : Porting code from Linux to VMS

[Marc Van Dyck]

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 :

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.

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.

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

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 ?

2) Any coding examples availabe somewhere, or that someone would agree
to share ? Preferably in Pascal, but I'll understand if only C is
available...

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 ?

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

Many thanks in advance for all your hints !


--
Marc Van Dyck

[Steven Schweda]

> 1) it contains several system calls which I'll need to find

> an adequate equivalent for. [...]

Such as?

> 2) I will port the code from C to Pascal, [...]

That sounds to me like a serious mistake.

> 3) The code contains a good dose of TCP/IP programming.

> [...]

The C/TCPIP RTL on VMS can do most things of that sort.

> 1) Is there any documentation about that ? How to write, on
> OpenVMS, code to establish a TCP/IP communication with

> another host ? [...]

Why not use the existing C code?


> 2) Any coding examples availabe somewhere, [...]

SYS$COMMON:[SYSHLP.EXAMPLES.TCPIP]

I wouldn't put forward as a model any of the stuff which
I've done, but there must be a boatload of freeware out there
which does IP stuff on VMS.

> 3) Are the TCP/IP calls definitions that I'll need to use

> available in pascal environment files somewhere ? [...]

There's a QIO interface for this stuff, so you could, in
principle, do it from any language, but why you'd want to go
through that ordeal to mutilate a perfectly good C program is
a mystery to me.

SYS$COMMON:[SYSHLP.EXAMPLES.TCPIP]*QIO*

[johnso...@gmail.com]

On Tuesday, January 22, 2019 at 3:44:20 PM UTC-5, Marc Van Dyck wrote:

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

Why? If you don't do it - what happens?

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

If you don't feel comfortable with C - then it's going to be
hard to port something you can't read. Seems smarter to at
least learn C.

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

You will be happier if you can first master C and TCP/IP on Linux
first, then have a go at migrating that to VMS.

EJ

[Barratt, Chris (Health)]

Hi Marc,

In my previous job, we had a client/server setup where the servers accepted messages from TCPIP sockets, Decnet task-to-task and VMS mailboxes.
This was all written in Pascal and worked well (and still does).

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

It's worth doing some general reading up on network programming here, irrespective of the language used.
We used "Stevens : UNIX Network Programming, Ch 6 Berkeley sockets" for this. (a long time ago).

If you have never used the VMS QIO system calls before, it is also worth reading up on those.

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

"HP TCP/IP Services for OpenVMS, Sockets API and System Services Programming" is the manual you will need.
If you are using Multinet for TCPIP, there is a similar manual, if I remember correctly.

>2) Any coding examples availabe somewhere, or that someone would agree
>to share ? Preferably in Pascal, but I'll understand if only C is
>available...

No longer in a position to share. Sorry.

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

TCPIP$INETDEF.PAS

Cheers,
Chris.

[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

[Dave Froble]

On 1/22/2019 3:44 PM, Marc Van Dyck wrote:
> 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.

Welcome to the dark side ...

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

Why not? Have you tried it? That should be one of your earlier steps.
Who knows, it, or most of it, just might work. Not giving this a
chance just isn't too smart.

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

Do you have specifics? Others have mentioned that the VMS C-RTL might
have all that you need.

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

That is not a port. That is a re-write, and even perhaps a re-design.
Would not be my first, or second, or even third choice.

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

Some examples can help.

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

Others have mentioned the correct TCP/IP manual. I was able to muddle
through most of it.

> 2) Any coding examples availabe somewhere, or that someone would agree
> to share ? Preferably in Pascal, but I'll understand if only C is
> available...

I'll attempt to send you some of the stuff from when I was figuring this
out. They will be much better for learning that our actual production
stuff.

Note, if you need SSL/TLS and such, that is a different beast. I had
Steve write some stuff for me, since I detest C, can read it a bit,
cannot write it, and DON'T WANT TO!

Rather pertinent question, if using SSL, from whom, and what version.
They are not very compatible.

> 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 ?
>
> If you want to send me something, the address is
> marc dot gr dot vandyck at skynet dot be.
>
> Many thanks in advance for all your hints !
>
>


--

David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Robert A. Brooks]

On 1/22/2019 3:44 PM, Marc Van Dyck wrote:

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

What architecture?


--

-- Rob

[geze...@rlgsc.com]

On Tuesday, January 22, 2019 at 3:44:20 PM UTC-5, Marc Van Dyck wrote:

Marc,

I would also recommend not translating from C to PASCAL. It is generally a shorter path to learn C than to translate an entire codebase.

The standard socket calls are generally available on OpenVMS. One can also use the QIO-level calls, which allow asynchronous operation and ASTs. I have done both for various client situations in the past.

Translating the Linux system calls to the OpenVMS environment depends upon the system calls involved. Some are straightforward, others not so much.

If I can be of assistance, please let me know by email.

- Bob Gezelter, http://www.rlgsc.com
- Bob Gezelter, http://www.rlgsc.com

[Dave Froble]

On 1/22/2019 10:13 PM, geze...@rlgsc.com wrote:

> I would also recommend not translating from C to PASCAL. It is generally a shorter path to learn C than to translate an entire codebase.

I've read this more than once now in this thread. I've got to believe
that it's a claim from those already knowing C. To some extent, I ain't
buying it. Of course, Marc would have to be able to read the C code to
know what it's doing. But writing, no way.

Not that I recommend re-writing. If the code works, one doesn't have to
know C to compile and link it.

[Steven Schweda]

> [...] I've got to believe that it's a claim from those
> already knowing C. [...]

Of course it is. Because everyone these days knows C (or,
at least, believes that he does).

> [...] Of course, Marc would have to be able to read the C

> code to know what it's doing. But writing, no way.

If you can read the language well enough actually to
understand what the code does, then how could you not be able
to write such code?

> Not that I recommend re-writing. [...]

Then what, exactly, is your recommendation? Drop the
whole idea?

The point is that if C is a mystery and the IP socket RTL
is a mystery, then converting both to somethings else would
likely be more work and less likely to succeed than learning
enough C to deal with what must be working, existing C code.

Of course, it's tough to make specific recommendations
regarding invisible code to satisfy invisible requirements.

[Scott Dorsey]

Dave Froble <da...@tsoft-inc.com> wrote:
>On 1/22/2019 10:13 PM, geze...@rlgsc.com wrote:
>
>> I would also recommend not translating from C to PASCAL. It is generally a shorter path to learn C than to translate an entire codebase.
>
>I've read this more than once now in this thread. I've got to believe
>that it's a claim from those already knowing C. To some extent, I ain't
>buying it. Of course, Marc would have to be able to read the C code to
>know what it's doing. But writing, no way.

If you know Pascal, get a copy of "From Pascal to C" and study it. Within a
few days of fooling around you'll know C well enough to do the job.

I think you'll find that reverse-engineering someone else's code, especially
if it is poorly documented, is a lot harder than writing your own if you are
working in an unfamiliar language.

But really, we don't know what this code does. Maybe it doesn't do any real
IP stuff itself but just listens on a port, in which case it might just
build with minimal changes.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Simon Clubley]

On 2019-01-22, Marc Van Dyck <marc.gr...@invalid.skynet.be> wrote:
> 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 :
>
> 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.
>

As other people have effectively mentioned, I hope you aren't thinking
you need to use sys$qio() calls to do TCP/IP networking on VMS in C.

If that isn't the case, then what's the problem you are seeing ?

For example, does the code use fork() in the way it was intended to be used ?

Does the code require a fully functional select() call ?

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

If you understand C enough to be able to port it to Pascal, then you
understand C enough to be able to tweak the existing code (if that is
all that is needed).

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

Then you would have the same problems writing similar code on Linux.

Try reading some of the getting started guides for TCP/IP programming
on Linux, try the examples on Linux, and then try the same code on VMS.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[John Reagan]

Would it help if I tossed in a free "upcase" builtin for Pascal?

John

[John E. Malmberg]

On 1/22/2019 2:44 PM, Marc Van Dyck wrote:
> 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 :
>
> 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.

You need to use a search engine to find "The Open Group" and the syscall
name and look up the description of the call, and possibly the Linux
System Base.

The Open Group definitions on how the syscalls are suppose to work is
the "Official" standard. But beware, there are bugs in the way of
omissions in "The Open Group" documents, and some system calls are Linux
extensions. And the Linux System Base is very hard to read, because it
makes you follow lots of links to look up things.

And some Linux/Unix syscalls are not documented enough to know how to
simulate them on VMS. You basically have to look at the Linux source to
see what Linux did to implement them.

Many of the system calls do behave exactly as expected from their names.
Most software does not notice these special "features", but others
depend on them.

The VMS CRTL attempts to be compatible with "The Open Group". It is not
fully compatible at this time.

One issue with the VMS CRTL seen in porting programs that use TCPIP is
that Linux/Unix expects the socket related syscalls to work on all
compatible devices such as terminals and pipes, and the VMS CRTL only
supports them on sockets. This is commonly seen in client applications
ported from Linux. For server applications ported from Linux, usually
they expect fork() and get*uid()/set*uid() to work exactly as on Linux.

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

These days being able to write C code is almost a standard requirement
for program development.

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

That is in the HP TCP/IP documentation. The C and $QIO implementation
is documented in the same volume. The Process TCP/IP implements an
equivalent shared library and may have some extensions. I have not
compared the two of them.

But as others have pointed out, many sites are now requiring that all
TCP/IP traffic be encrypted, so instead of making syscalls on sockets or
$QIO calls you have to use an encryption library. And most of those
only have a documented C interface.

Now Pascal can call C code on VMS. Which also means that you should be
able to actually call CRTL routines from Pascal once you setup the
definitions.

Very old C code would have different link instructions for various
TCP/IP vendors for VMS. These days, no special linking is usually needed.

Fortunately there is almost a 1:1 correspondence for the C "socket" API
and the $QIO implementations. This was probably done to simplify
writing the C implementation.

If you encounter the writev() and readv() system calls in the original
code, these are not in the $QIO interface.

While they are in the VMS C library, they should be avoided if you are
trying to get the best throughput.

In Linux/Unix they pass a list of buffers to the TCP/IP driver that can
be used for DMA from the network device. This is so that you can setup
big transfers.

The last time I looked at the VMS CRTL, it simulated them by copying
them into or from a larger single buffer, which adds more delay to the
operation.

> 2) Any coding examples availabe somewhere, or that someone would agree
> to share ? Preferably in Pascal, but I'll understand if only C is
> available...

Have not done Pascal programming since late 80's.

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

Don't know.

Regards,
-John

[Craig A. Berry]

I will join the chorus of those saying to leave it in C. But if you
must, Neil Reick has examples of doing TCP/IP with $QIO calls in BASIC,
which might be easier to read for someone who knows no C:

<http://neilrieck.net/demo_vms_html/openvms_demo_index.html#ipstack>

He's made of tougher stuff than I am -- when I had to do TCP/IP from
BASIC I just wrote wrapper routines in C that presented dynamic string
descriptors to BASIC. If only there were an RTL that already did that.

[Dave Froble]

On 1/23/2019 1:19 AM, Steven Schweda wrote:
>> [...] I've got to believe that it's a claim from those
>> already knowing C. [...]
>
> Of course it is. Because everyone these days knows C (or,
> at least, believes that he does).

False. All it takes is one, and I don't use C.

>> [...] Of course, Marc would have to be able to read the C
>> code to know what it's doing. But writing, no way.
>
> If you can read the language well enough actually to
> understand what the code does, then how could you not be able
> to write such code?

It's one thing to read some code and try to understand it. It's quite
another to be able to think of how to implement things.

>> Not that I recommend re-writing. [...]
>
> Then what, exactly, is your recommendation? Drop the
> whole idea?

No, I'm with the rest of you, try to compile on VMs and see what
happens. It just might compile with no issues.

> The point is that if C is a mystery and the IP socket RTL
> is a mystery, then converting both to somethings else would
> likely be more work and less likely to succeed than learning
> enough C to deal with what must be working, existing C code.
>
> Of course, it's tough to make specific recommendations
> regarding invisible code to satisfy invisible requirements.
>

You got that right ...

[Dave Froble]

On 1/23/2019 8:27 AM, John Reagan wrote:
> Would it help if I tossed in a free "upcase" builtin for Pascal?
>
> John
>

Waste of your time, but, it is your time ...

If someone cannot call a STR$ routine, perhaps that someone should find
another activity, since programming is beyond their capabilities.

[osuv...@gmail.com]

On Tuesday, January 22, 2019 at 3:44:20 PM UTC-5, Marc Van Dyck wrote:

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

First thing to do is search the source code for the presence of fork calls. Some patterns centered around fork() don't work on VMS without a whole lot of effort. Network server daemons usually fall into that category.

[Dave Froble]

Actually, doing the whole thing in Basic using the QIO interface taught
me much more than if I just used the CRTL stuff. I'm a firm believer in
understanding what one is trying to do. The first programs weer
strictly a learning project. An "echo server" and a client. After that
implementing for production was rather easy.

[Bill Gunshannon]

Does anyone else find it rather humorous that he is trying
to convert C to Pascal when the first Open Source Pascal
compilers basically just converted the Pascal to C. I
suppose someone could write a program called "c2p". :-)

bill

[VAXman-]

In article <17676313-0733-4b9c...@googlegroups.com>, John Reagan <xyzz...@gmail.com> writes:
>Would it help if I tossed in a free "upcase" builtin for Pascal?

ROTFLMFAO!


--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

[VAXman-]

In article <q29qu2$g7r$1...@dont-email.me>, "John E. Malmberg" <wb8...@qsl.net_work> writes:
>On 1/22/2019 2:44 PM, Marc Van Dyck wrote:
>> 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 :
>>
>> 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.
>
>You need to use a search engine to find "The Open Group" and the syscall
>name and look up the description of the call, and possibly the Linux
>System Base.

OPEN is a codeword for UNIX. :P

[Arne Vajhøj]

On 1/23/2019 1:50 PM, VAX...@SendSpamHere.ORG wrote:
> In article <q29qu2$g7r$1...@dont-email.me>, "John E. Malmberg" <wb8...@qsl.net_work> writes:
>> On 1/22/2019 2:44 PM, Marc Van Dyck wrote:
>>> 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 :
>>>
>>> 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.
>>
>> You need to use a search engine to find "The Open Group" and the syscall
>> name and look up the description of the call, and possibly the Linux
>> System Base.
>
> OPEN is a codeword for UNIX. :P

The Open Group does several things.

Some like TOGAF certfications has nothing to do with Unix.

The relevant part here is called "Single UNIX Specification"
and it certainly relates to Unix.

:-)

Arne

[Arne Vajhøj]

On 1/23/2019 1:19 AM, Steven Schweda wrote:

>> [...] I've got to believe that it's a claim from those
>> already knowing C. [...]
>
> Of course it is. Because everyone these days knows C (or,
> at least, believes that he does).

You may be right that most (slightly less than everyone)
doing compiled to native languages will know C today.

But there are millions of developers out there not
knowing C - it is not a common skill among
Java, .NET, PHP, Python, JavaScript etc. developers.

Arne

[Arne Vajhøj]

On 1/23/2019 11:34 AM, Dave Froble wrote:
> On 1/23/2019 9:16 AM, Craig A. Berry wrote:
>> I will join the chorus of those saying to leave it in C.  But if you
>> must, Neil Reick has examples of doing TCP/IP with $QIO calls in BASIC,
>> which might be easier to read for someone who knows no C:
>>
>> <http://neilrieck.net/demo_vms_html/openvms_demo_index.html#ipstack>
>>
>> He's made of tougher stuff than I am -- when I had to do TCP/IP from
>> BASIC I just wrote wrapper routines in C that presented dynamic string
>> descriptors to BASIC.  If only there were an RTL that already did that.
>
> Actually, doing the whole thing in Basic using the QIO interface taught
> me much more than if I just used the CRTL stuff.  I'm a firm believer in
> understanding what one is trying to do.  The first programs weer
> strictly a learning project.  An "echo server" and a client.  After that
> implementing for production was rather easy.

Just note that the C socket API is a standard and VMS $QIO(W)
is not.

So general TCP/IP documentation and various support forums
are likely to describe things in terms of the C API.

Arne

[Dave Froble]

That, yes. But my info is that the CRTL stuff is is implemented using
the QIO stuff. So, I'm just cutting out the middleman.

The documentation does a decent job, even if it uses C examples. So, no
problem, right?

Well, yes, two. SSL/TLS isn't built in, if that's actually the way it
should work, and, I found the DEC/Compaq/HP TCP/IP to be lacking in some
ways.

[Dave Froble]

I find it sad that he wants to take working code (at least on Linux) and
re-implement it. I did that once for a customer, and I still feel they
were wrong, but, you know the two rules when dealing with customers.

[Dave Froble]

On 1/23/2019 1:50 PM, VAX...@SendSpamHere.ORG wrote:

> In article <q29qu2$g7r$1...@dont-email.me>, "John E. Malmberg" <wb8...@qsl.net_work> writes:
>> On 1/22/2019 2:44 PM, Marc Van Dyck wrote:
>>> 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 :
>>>
>>> 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.
>>
>> You need to use a search engine to find "The Open Group" and the syscall
>> name and look up the description of the call, and possibly the Linux
>> System Base.
>
> OPEN is a codeword for UNIX. :P
>

Yeah, and ain't that sad??

[Marc Van Dyck]

Marc Van Dyck wrote :
> 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 :
>
> 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.
>

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

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

> 2) Any coding examples availabe somewhere, or that someone would agree
> to share ? Preferably in Pascal, but I'll understand if only C is
> available...
>

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

> If you want to send me something, the address is
> marc dot gr dot vandyck at skynet dot be.
>
> Many thanks in advance for all your hints !

Thanks for all the answers. There were so many that I won't try to
answer all of them individually. But I see some questions coming
back regularly about the background of this work, so here goes :

This will be running on VSI OpenVMS V8.4-2 on Itanium blade systems.

The thing that I will need to port/rewrite is something that has been
written more than 10 years ago. It involves communicating between two
systems, and if one of the two will be VMS, the other one will remain
Linux and on this one nothing can and will be changed. So I will have
to re-implement, one way or another, exactly the same protocol. I think
it is just raw tcp, but I haven't had a chance to look at the code yet.
But in any case, migrating to TLS or IPv6 is out of question, as I
don't control what I'm talking to at the other end.

The application to be ported looks very much like System Watchdog,
the polycenter product that was sold to CA decades ago. We have one
thing like that, developped in-house, for Linux and Windows, and now
I'm looking at the possibility to have a VMS agent. Now, I do not
want to re-write a full-fledged agent, because we already have a
monitoring system in place (Cockpit, for those who know it). I just
need to interface it so that it talks to our central console. We
already
do that today, using MQ-Series for transport, but my company wants to
stop using this product. We tried using SNMP traps also, but this is
UDP
so no guaranteed delivery, and we have indeed lost alarm messages
sometimes. So our next attempt would be to carve out the transport
layer
of the Linux agent of our watchdog, which seems to work well, and port
it to VMS.

I understand what you say about the rewrite in Pascal but I won't give
up. I think I can read C well enough to understand what it does. But
I don't want to use it for what I write myself. And, by the way, I'm
60, will retire in 5 years max, so making myself more marketable has
much less priority than doing things that I enjoy.

From what I read in all your answers, it seems like TCP sockets will
probably be the way to go. So again, any code examples of that would
help me a lot, thank you very much in advance...

--
Marc Van Dyck

[Stephen Hoffman]

On 2019-01-23 20:56:53 +0000, Marc Van Dyck said:

> But in any case, migrating to TLS or IPv6 is out of question, as I
> don't control what I'm talking to at the other end.
>
> The application to be ported looks very much like System Watchdog, the
> polycenter product that was sold to CA decades ago.

Oh, that's hilarious.

[Bill Gunshannon]

On 1/23/19 2:47 PM, Dave Froble wrote:
> On 1/23/2019 1:50 PM, VAX...@SendSpamHere.ORG wrote:
>> In article <q29qu2$g7r$1...@dont-email.me>, "John E. Malmberg"
>> <wb8...@qsl.net_work> writes:
>>> On 1/22/2019 2:44 PM, Marc Van Dyck wrote:
>>>> 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 :
>>>>
>>>> 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.
>>>
>>> You need to use a search engine to find "The Open Group" and the syscall
>>> name and look up the description of the call, and possibly the Linux
>>> System Base.
>>
>> OPEN is a codeword for UNIX. :P
>>
>
> Yeah, and ain't that sad??
>

OpenVMS?

bill

[Stephen Hoffman]

On 2019-01-23 21:25:29 +0000, Stephen Hoffman said:

> On 2019-01-23 20:56:53 +0000, Marc Van Dyck said:
>
>> But in any case, migrating to TLS or IPv6 is out of question, as I
>> don't control what I'm talking to at the other end.
>>
>> The application to be ported looks very much like System Watchdog, the
>> polycenter product that was sold to CA decades ago.
>
> Oh, that's hilarious.

Hilarious: no TLS on a security-relevant connection. If that was not clear.



Port the existing Linux code to OpenVMS, using C.

Rewriting this code doubles the size of the source code pool, and
doubles the effort that'll then be required to actually start fixing
problems such as a lack of TLS. Rewriting this app in Pascal is
building up technical debt.

This Pascal code is going to be twisted into OpenVMS pretty deeply if
you want to avoid using the C sockets API, too.

And forget about upgrading the connection security from anything that
can't reasonably access the OpenSSL APIs on OpenVMS and Linux. That's
going to be a substantial effort around external API mapping, from
Pascal, and that beyond figuring out how the OpenSSL APIs work.

If you absolutely have to rewrite this app into a language other than
C, then use Python or Java or some other portable language, and aim to
use the same or conditionalized code everywhere.

As for pointers to documentation resources and examples, those have
been provided by various folks in this thread. Beej's for discussions
of C sockets. VSI for whatever examples they have available.
TCPIP$EXAMPLES for what's there. The Freeware.
https://beej.us/guide/bgnet/

Don't expect to find very good examples of using sockets or $qio on
OpenVMS, as all of what I've encountered was written to address a
specific example case or a subset case, and tends to lack (for
instance) DNS integration.

But you already have working Linux code, which is the best starting point.

The 21st century C book is good for folks that are familiar with older
versions of C, and there are various introductory books around. Here's
a reasonable (free) book on C:
http://icube-icps.unistra.fr/img_auth.php/d/db/ModernC.pdf

Other resources for C:
https://www.cprogramming.com/books/c.html

OpenVMS system services and RTL examples:
http://www.eight-cubed.com/examples.shtml

[Tom Wade]

On 2019-01-23 20:56, Marc Van Dyck wrote:

> I understand what you say about the rewrite in Pascal but I won't give
> up. I think I can read C well enough to understand what it does. But
> I don't want to use it for what I write myself. And, by the way, I'm
> 60, will retire in 5 years max, so making myself more marketable has
> much less priority than doing things that I enjoy.

I am in a similar position (and age). I code because I enjoy it, and C
is such an UGLY language !

I've never used Pascal, but coded mainly in Fortran-77, a little Basic
and in various assemblers and thoroughly enjoyed it. I've written one
program in C and hated it. Go for it. Life's too short.

Tom Wade
tom dot wade at tomwade dot eu

[Arne Vajhøj]

On 1/23/2019 2:44 PM, Dave Froble wrote:
> On 1/23/2019 2:03 PM, Arne Vajhøj wrote:
>> On 1/23/2019 11:34 AM, Dave Froble wrote:
>>> On 1/23/2019 9:16 AM, Craig A. Berry wrote:
>>>> I will join the chorus of those saying to leave it in C.  But if you
>>>> must, Neil Reick has examples of doing TCP/IP with $QIO calls in BASIC,
>>>> which might be easier to read for someone who knows no C:
>>>>
>>>> <http://neilrieck.net/demo_vms_html/openvms_demo_index.html#ipstack>
>>>>
>>>> He's made of tougher stuff than I am -- when I had to do TCP/IP from
>>>> BASIC I just wrote wrapper routines in C that presented dynamic string
>>>> descriptors to BASIC.  If only there were an RTL that already did that.
>>>
>>> Actually, doing the whole thing in Basic using the QIO interface
>>> taught me much more than if I just used the CRTL stuff.  I'm a firm
>>> believer in understanding what one is trying to do.  The first
>>> programs weer strictly a learning project.  An "echo server" and a
>>> client.  After that implementing for production was rather easy.
>>
>> Just note that the C socket API is a standard and VMS $QIO(W)
>> is not.
>>
>> So general TCP/IP documentation and various support forums
>> are likely to describe things in terms of the C API.
>
> That, yes.  But my info is that the CRTL stuff is is implemented using
> the QIO stuff.

I believe that is correct.

>   So, I'm just cutting out the middleman.
>
> The documentation does a decent job, even if it uses C examples.  So, no
> problem, right?

How many example are available using $QIO(W)? Probably dozens.

How many examples are available using socket API? Probably tens of
thousands.

Arne

[Dave Froble]

Dozens of good examples are better than thousands of bad examples ...

:-)

[VAXman-]

In article <q2e0sf$r3o$1...@dont-email.me>, Dave Froble <da...@tsoft-inc.com> writes:

>Dozens of good examples are better than thousands of bad examples ...
>
>:-)

One good example should be more than enough.

[jaybr...@gmail.com]

I'm entering this discussion a bit late, but I do have a high-level question. I have ported applications from OpenVMS to Linux, but was surprised that someone is going in the opposite direction. What is the investment that your organization wishes to retain? Is it the Itanium hardware? Perhaps you have a product for which it is advantageous to support OpenVMS?

Depending on the objective, would an OpenVMS virtual machine running on a Linux host serve any purpose here? Rather that porting the Linux application, you would run it on the host, and use virtualization to support the network interface. There would still be some hooks to code on the OpenVMS side but you would not need to port the entire application; it could be almost a black box.

Jay

[Marc Van Dyck]

jaybr...@gmail.com presented the following explanation :

We have 3 business critical applications, running on BL870-i4, millions
of lines of code, mostly cobol, porting effort estimated in tens of man
years. 3 production clusters, 3 others for disaster recovery, 3PAR
storage with inter-site replication, etc. Not the kind of stuff that
can
easily be migrated to another platform. And we also have stability and
reliability requirements that other platforms cannot entirely meet.
We already have long term plans to migrate to OpenVMS X86 in a couple
of
years.

--
Marc Van Dyck

[Arne Vajhøj]

On 1/27/2019 10:34 PM, jaybr...@gmail.com wrote:
> I'm entering this discussion a bit late, but I do have a high-level
> question. I have ported applications from OpenVMS to Linux, but was
> surprised that someone is going in the opposite direction. What is
> the investment that your organization wishes to retain? Is it the
> Itanium hardware? Perhaps you have a product for which it is
> advantageous to support OpenVMS?

Linux -> VMS is not that unusual.

But the typical context is:
* There is one or more primary applications running
on VMS - something business critical
* Either there is no plans to migrate off VMS or
the plans are far out in the future
* There is a need to get one or more supporting
applications that exists for Linux running on
VMS to add value to the primary application(s)
* Building the Linux C/C++ code on VMS turns out to be
very difficult:
- VMS compilers are behind current language standards
- often the *nix build processes uses some tools that
has not yet been ported to VMS
- code uses *nix specific features with no obvious
VMS counterpart

Arne

[jaybr...@gmail.com]

Theoretically, if an OpenVMS system could be used as a virtualization host, with a Linux guest, might some of these use cases be easier to solve?

[Arne Vajhøj]

> Theoretically, if an OpenVMS system could be used as a virtualization
> host, with a Linux guest, might some of these use cases be easier to
> solve?

I doubt it.

Most already have external Linux systems, I doubt that
having the Linux in a VM on the VMS system would make
a big difference.

Obviously YMMV.

Arne

[Stephen Hoffman]

On 2019-01-28 17:01:17 +0000, jaybr...@gmail.com said:

> Theoretically, if an OpenVMS system could be used as a virtualization
> host, with a Linux guest, might some of these use cases be easier to
> solve?

Other than the network speed improvements inherent with better locality
of the end-points, there's little difference between and OpenVMS guest
and a Linux guest co-resident, and a network among OpenVMS and Linux
servers running on separate server hardware. Not without
paravirtualization assists added into the virtualization environments.
And tweaking the apps to use those paravirtualized paths, if/as/when
necessary. Or tweaking the apps to use one of various RPCs.

If you're pondering OpenVMS theoretically running as the virtual
machine and configured with Linux guests, then that's just not
happening any time soon. If ever. And that still doesn't provide
particular benefits, short of adding paravirtualization assists.

And as for alternatives to virtualization, OpenVMS lacks any sort of
FUSE support, nor support for user-mode Linux, nor Wasm. Which means
you're maybe still headed toward running via Wasm here, and that's a
ways off in the OpenVMS universe. And Wasm still involves getting the
app data transferred between the apps and the app hosts.

So... no.

We're still going to occasionally be porting Linux and BSD Unix apps
onto OpenVMS. And occasionally RPC'ing or REST'ing or otherwise
wrapping some apps. Which then gets to the grumblings about OpenVMS
and the rather sorry start of C and the CRTL, and of SSIO, and of C++
support, and VSI has certainly been made aware of much of that.
Getting LLVM and Clang available on OpenVMS x86-64 will help
substantially, both with the C and C++ environments provided by Clang,
and with the potential for ports of various other languages that are
based on LLVM.

Wasm, et al:

https://github.com/rossberg/wasm-c-api
https://github.com/rianhunter/wasmjit
https://github.com/emscripten-core/emscripten
https://tbfleming.github.io/cib/
https://bellard.org/jslinux/
https://github.com/cloudflare/cloudflare-workers-wasm-demo
https://github.com/rhysd/vim.wasm

[IanD]

In regards to C code for VMS and having examples, Mark Daniels WASD web server is written in C and the code is available (check the licensing, I'm fairly certain he open sourced it)

https://wasd.vsm.com.au/wasd/

I have not looked at it in a couple of years since I sadly do not deal with VMS anymore, but he's got C codee that makes use of tcp routines, websocket stuff and SSL. Might find useful examples?

Don't shoot the messenger as to the usefulness of having examples in C for VMS, the extent that I looked at his code years ago was out of interest only

[John Forkosh]

Marc Van Dyck <marc.gr...@invalid.skynet.be> wrote:
> <<snip>>

> The thing that I will need to port/rewrite is something that has been
> written more than 10 years ago. It involves communicating between two
> systems, and if one of the two will be VMS, the other one will remain
> Linux and on this one nothing can and will be changed. So I will have
> to re-implement, one way or another, exactly the same protocol. I think
> it is just raw tcp, but I haven't had a chance to look at the code yet.
> But in any case, migrating to TLS or IPv6 is out of question, as I
> don't control what I'm talking to at the other end.

> <<snip>>

Probably of no help to you nowadays, but take a look at
https://en.wikipedia.org/wiki/Excelan
"...The company offered a line of Ethernet 'front end processor' boards
for Multibus, VMEbus, Q-Bus, Unibus ... that integrated the cards into
a variety of operating system environments, including many flavors of
UNIX, RSX-11, VMS, and DOS."

If you could get a card and its accompanying software >>for your Itanium
bus<<, it would be an almost transparent port, at least the tcp/ip part.
I used that card in an 11/780 during a 1988-89 contract for Chase bank.
Mostly udp datagrams, and it was almost 100% identical/transparent to
native networking calls.
--
John Forkosh ( mailto: j...@f.com where j=john and f=forkosh )

[Marc Van Dyck]

John Forkosh used his keyboard to write :

Yeah, doubt very much that they have a model that fits in a mezzannine
slot...

--
Marc Van Dyck