I thought I’d try building the latest source code for C-Kermit from
https://www.kermitproject.org/ckdaily.html on OpenVMS VAX
and Alpha. The release notes seem to suggest 9.0.305-04
should compile under OpenVMS.

I’m getting missing modules GET_RMS_DEFAULTS and ISABSOLUTE
when linking (using the $@ckvker “O” build procedure - after I fixed an
error with Multinet include clashes with a #include <time.h>).

The CKVFIO.C module is missing these routines (which are in the older
C-Kermit 9.0.302 sources). The latest one appears to have changed
to add support for ODS5 volumes.

On a wild hunch that someone here may have been working on
the revised OpenVMS module (CKVFIO.C) - perhaps Steven Schweda
or David Hittner. Is the version that Frank da Cruz has on the
Kermit web site the latest?

Has anyone else tried to get this compiled - before I dive in and try
to fix this?

Tony

The last thing I tried seemed to call its version "9.0.305 Alpha.02".
Various changes/corrections to that kit:

http://antinode.info/ftp/kermit/v9r0_305_Alpha02/
ftp://antinode.info/kermit/v9r0_305_Alpha02/

> [...] The release notes seem to suggest 9.0.305-04 should compile
> under OpenVMS.

With any luck, at least the source-file corruption in that kit might
be fixed (again?).

There's still a serious bug in (at least) CKHTTP.C:

fp[n] = fopen("NLA0:","r"); /* CK wants a fp, give it one */

I don't know which sub-genius had that flash of inspiration. (The
compiler likes it, at least.) I assume that correcting it would require
some serious changes to the file-I/O scheme.

> [...] I fixed an error with Multinet include clashes with a #include
> <time.h>).

Details? Did you specify Multinet explicitly, instead of relying on
its TCPIP emulation?

> On a wild hunch that someone here may have been working on
> the revised OpenVMS module (CKVFIO.C) - perhaps Steven Schweda
> or David Hittner. Is the version that Frank da Cruz has on the
> Kermit web site the latest?
>
> Has anyone else tried to get this compiled - before I dive in and try
> to fix this?
>
> Tony

The current 9.0.305 sources does not currently compile on OpenVMS. Frank da Cruz lost his ability to compile on OpenVMS 10 or so years ago.

I'm working on consolidating Steve Schweda's updates and a patch for OpenVMS x86_64 with the latest 9.0.305 kit.

Give me a couple more weeks to finish and submit to Frank.

David Hittner

On Friday, October 29, 2021 at 12:02:34 AM UTC+11, Steven Schweda wrote:
> The last thing I tried seemed to call its version "9.0.305 Alpha.02".
> Various changes/corrections to that kit:
>
> http://antinode.info/ftp/kermit/v9r0_305_Alpha02/
> ftp://antinode.info/kermit/v9r0_305_Alpha02/

Thanks Steven. I looked at these and indeed there are quite a few changes.

As you mention below, some of the coding is quite ugly!

> > [...] The release notes seem to suggest 9.0.305-04 should compile
> > under OpenVMS.
>
> With any luck, at least the source-file corruption in that kit might
> be fixed (again?).
>
> There's still a serious bug in (at least) CKHTTP.C:
>
> fp[n] = fopen("NLA0:","r"); /* CK wants a fp, give it one */
>
> I don't know which sub-genius had that flash of inspiration. (The
> compiler likes it, at least.) I assume that correcting it would require
> some serious changes to the file-I/O scheme.
>
> > [...] I fixed an error with Multinet include clashes with a #include
> > <time.h>).
>
> Details? Did you specify Multinet explicitly, instead of relying on
> its TCPIP emulation?

I've just let the ckvker.com DCL build file detect I'm using Multinet.

There's existing comments in ckcmai.c regarding a clash with Multinet
and the inclusion of <sys/time.h>.

This causes a compilation error with incompatible type for the 5th parameter to
the select() routine. The default expects a "struct timeval" type, whereas Multinet
uses "void". To fix this I included the Multinet version of time.h from the
multinet_root:[multinet.include.sys] directory in ckcmai.c (using #ifdef MULTINET
conditional).

Tony

On Saturday, October 30, 2021 at 12:26:33 PM UTC+11, David Hittner wrote:

> The current 9.0.305 sources does not currently compile on OpenVMS. Frank da Cruz lost his ability to compile on OpenVMS 10 or so years ago.
>
> I'm working on consolidating Steve Schweda's updates and a patch for OpenVMS x86_64 with the latest 9.0.305 kit.
>
> Give me a couple more weeks to finish and submit to Frank.

Thanks David. I'll leave you to do your updates.

I am happy to do some testing for you using Process Software's Multinet V5.5 on both VAX
and Alpha.

I also managed to get C-Kermit 9.0.305-04 sources to build under macOS Catalina x86_64
and Big Sur/Monterey M1 with a slight tweak to what looked like a corrupted ckcdeb.h
file. I'll forward details about this directly to Frank.

Tony

Changes which should clear the problems involving MAXPATHLEN, and
some other lame code, and restore the VMS-specific functions missing
from ckvfio.c (again):

http://antinode.info/ftp/kermit/v9r0_305_Alpha04/
ftp://antinode.info/kermit/v9r0_305_Alpha04/

The v9r0_305_Alpha04 ckvker.com has changes which are not all bad,
and I haven't merged it yet, but the v9r0_305_Alpha02/ckvker.com should
work for now. When I get bored, ...

The (my) original expectation was that all uses of MAXPATHLEN would
be replaced by CKMAXPATH, but I failed to make the required changes to a
couple of files which weren't used on VMS. And then someone added more
uses of MAXPATHLEN, rather than CKMAXPATH, to code which _is_ used on
VMS.

The SSL stuff still has problems. I haven't looked closely at why,
but it seems to want X509_CRL_get0_nextUpdate(), which, so far as I can
tell, was new in OpenSSL 1.1.1, so a LINK with an older OpenSSL run-time
gets a %ILINK-I-UDFSYM. But OpenSSL 1.1.1 makes a bunch of structures
opaque, so compilation using the modern header files gets many
%CC-W-INCOMPDEREF and %CC-E-NEEDMEMBER where the code expects to fiddle
directly with those structures. Someone who knows more about OpenSSL
than how to build it might need to look into that.

On 2021-10-29, dthi...@gmail.com <dthittner@gmail.com> wrote:
>
> The current 9.0.305 sources does not currently compile on OpenVMS. Frank da Cruz lost his ability to compile on OpenVMS 10 or so years ago.
>

Would working on Kermit qualify as hobbyist use ?

If so, he could run an emulated Alpha system under the VSI hobbyist licence.

Unfortunately, that's about the best he could do for free as there are
no free full system emulators for Itanium I am aware of. (Ski is _NOT_
a full system emulator).

However, allowing him to build the code even on Alpha could help with
identifying general VMS issues in the code.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On Monday, November 1, 2021 at 2:18:46 PM UTC-4, Simon Clubley wrote:
> On 2021-10-29, dthi...@gmail.com <dthi...@gmail.com> wrote:
> >
> > The current 9.0.305 sources does not currently compile on OpenVMS. Frank da Cruz lost his ability to compile on OpenVMS 10 or so years ago.
> >
> Would working on Kermit qualify as hobbyist use ?
>
> If so, he could run an emulated Alpha system under the VSI hobbyist licence.
>
> Unfortunately, that's about the best he could do for free as there are
> no free full system emulators for Itanium I am aware of. (Ski is _NOT_
> a full system emulator).
>
> However, allowing him to build the code even on Alpha could help with
> identifying general VMS issues in the code.
>
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.

i have a bunch of RX1620s available cheap if an Itanium is needed. I also have an older RX system in the "office" enclosure that is extremely quiet available as well.

Let me know if anyone needs one.

Dan

On 11/1/21 2:18 PM, Simon Clubley wrote:
> On 2021-10-29, dthi...@gmail.com <dthittner@gmail.com> wrote:
>>
>> The current 9.0.305 sources does not currently compile on OpenVMS. Frank da Cruz lost his ability to compile on OpenVMS 10 or so years ago.
>>

He used to build the VAX version on systems I ran at the University.

>
> Would working on Kermit qualify as hobbyist use ?
>
> If so, he could run an emulated Alpha system under the VSI hobbyist licence.

I think Frank is pretty much retired at this point.

>
> Unfortunately, that's about the best he could do for free as there are
> no free full system emulators for Itanium I am aware of. (Ski is _NOT_
> a full system emulator).
>
> However, allowing him to build the code even on Alpha could help with
> identifying general VMS issues in the code.

I haven't looked at Kermit development in years (I still
use it quite a bit on older systems to move things around.)

If I could get an emulated system up with functional networking
I might be able to fiddle with it again.

bill

> Would working on Kermit qualify as hobbyist use ?

If it doesn't, then I could be in trouble.

You could ask, but I doubt that Frank is looking for a new (another?)
hobby computer/OS to manage. He seems to be willing to let others do
the VMS development (with variable results, I'd say).

> http://antinode.info/ftp/kermit/v9r0_305_Alpha04/
> ftp://antinode.info/kermit/v9r0_305_Alpha04/

The latest builder there (ckvker.com) might actually work now. But,
for SSL support, you'd seem to need OpenSSL 1.1.1 (or later). I haven't
tried it yet on a VSI system, so no bets there. Now that heating season
has returned here, I might be able to justify trading some natural gas
for rx2660 power, until I make the changeover on my main rx2600.

On Tuesday, November 2, 2021 at 3:35:12 PM UTC+11, Steven Schweda wrote:
> > http://antinode.info/ftp/kermit/v9r0_305_Alpha04/
> > ftp://antinode.info/kermit/v9r0_305_Alpha04/
>
> The latest builder there (ckvker.com) might actually work now. But,
> for SSL support, you'd seem to need OpenSSL 1.1.1 (or later). I haven't
> tried it yet on a VSI system, so no bets there. Now that heating season
> has returned here, I might be able to justify trading some natural gas
> for rx2660 power, until I make the changeover on my main rx2600.

Thanks Steven. Much appreciated.

These source files build without SSL support for me under
Compaq OpenVMS VAX V7.3 and VSI OpenVMS AXP V8.4-2L1.

I've only tested a couple of file transfers using server mode
to both Kermit-11 running under RSTS/E and to Kermit-80 on
an 8-bit Z80 running CP/M plus. I'll do some more testing later
this evening. I've not gone down the OpenSSL rabbit hole yet.

Tony

> These source files build without SSL support for me [...]

What could go wrong? Most of the non-builder problems (and some of
the builder problems) were lost/ignored changes, so easy enough to find
and re-fix.

> [...] I've not gone down the OpenSSL rabbit hole yet.

That's where the serious fun should be found. (Especially if you try
to use the (doomed) HTTP[S] code.)

My long-neglected rx2660 seems to have VSI VMS V8.4-2L1 installed,
but all its old Community PAKs have expired, so I'll try to get it
updated to -2L3 when the new Community PAKs arrive. Then I should be
able to try some VSI [Open]SSL kits against the latest ckvker.com. But,
as I've said, I'd expect anything older than OpenSSL 1.1.1 to fail, so
I'd expect only the new VSI SSL111 kit to have a chance.

Because almost every OpenSSL version from every origin uses different
logical names and/or .EXE/.OLB names, until I try it, I would not be
amazed by an error (or more) with that SSL111 kit. Should be easy to
make any needed adjustments, however. (I hope.)

On Saturday, October 30, 2021 at 8:14:31 PM UTC+11, Tony Nicholson wrote:

[snip]
> I also managed to get C-Kermit 9.0.305-04 sources to build under macOS Catalina x86_64
> and Big Sur/Monterey M1 with a slight tweak to what looked like a corrupted ckcdeb.h
> file. I'll forward details about this directly to Frank.

I've been in touch with Frank da Cruz and supplied the macOS patches. He's
apparently updated some files on September 19th - but not yet published them
(the 9.305alpha04 ones are two days prior to this). Given that Frank concedes
he's "pushing 80" (years old) soon - he would like to get as many issues
resolved before uploading the next version. He's happy for us to assist
with providing updates (and reading between the lines) I don't think he
wishes to check the many different platforms for C-Kermit that he would
have in the past - including setting up an OpenVMS system.

He's also looking for testimonials from people who still use Kermit. Apparently
Columbia University are considering removing the Kermit stuff from their
web pages at http://www.columbia.edu/kermit/archive.html

Tony

> I've been in touch with Frank da Cruz and supplied the macOS patches.
> [...]

Did you try it with my (not-entirely-VMS-specific) changes for
9.0.305 Alpha.04? There are multiple ways to eliminate the MAXPATHLEN
problems, but I prefer my scheme, which largely eliminates MAXPATHLEN.

Around here, the Mac compiler has a whole pile of warnings. They
might be mostly unimportant, but the compiler-suggested changes should
be harmless everyplace. And there are some things which look actually
bad, like, for example:

ckcuni.c:8272:11: warning: use of logical '&&' with constant operand
[-Wconstant-logical-operand]
if (c && 0xff80) /* 7 bits */
^ ~~~~~~
ckcuni.c:8272:11: note: use '&' for a bitwise operation
if (c && 0xff80) /* 7 bits */
^~
&
ckcuni.c:8272:11: note: remove constant to silence this warning
if (c && 0xff80) /* 7 bits */
~^~~~~~~~~
1 warning generated.

Someone ought to inspect these things, at least.

On Wednesday, November 3, 2021 at 4:04:35 PM UTC+11, Steven Schweda wrote:

> Did you try it with my (not-entirely-VMS-specific) changes for
> 9.0.305 Alpha.04?

Yes I did - and I've just sent you an e-mail regarding this.

> Around here, the Mac compiler has a whole pile of warnings.
[snip]
> Someone ought to inspect these things, at least.

Agreed. I'll look into this.

Tony

That && at ckcuni.c:8272 should probably be &
It might only matter for Japanese Roman ISO 646, which could be why no one noticed it yet.

On Wednesday, November 3, 2021 at 5:04:35 AM UTC, Steven Schweda wrote:
> > I've been in touch with Frank da Cruz and supplied the macOS patches.
> > [...]
>
> Did you try it with my (not-entirely-VMS-specific) changes for
> 9.0.305 Alpha.04? There are multiple ways to eliminate the MAXPATHLEN
> problems, but I prefer my scheme, which largely eliminates MAXPATHLEN.
>
> Around here, the Mac compiler has a whole pile of warnings. They
> might be mostly unimportant, but the compiler-suggested changes should
> be harmless everyplace. And there are some things which look actually
> bad, like, for example:
>
> ckcuni.c:8272:11: warning: use of logical '&&' with constant operand
> [-Wconstant-logical-operand]
> if (c && 0xff80) /* 7 bits */
> ^ ~~~~~~
> ckcuni.c:8272:11: note: use '&' for a bitwise operation
> if (c && 0xff80) /* 7 bits */
> ^~
> &
> ckcuni.c:8272:11: note: remove constant to silence this warning
> if (c && 0xff80) /* 7 bits */
> ~^~~~~~~~~
> 1 warning generated.
>
> Someone ought to inspect these things, at least.

> That && at ckcuni.c:8272 should probably be &

_Very_ probably. As the compiler suggested.

> It might only matter for Japanese Roman ISO 646, which could be why no one noticed it yet.

You don't need to test the code if your compiler identifies the
error. Unless, of course, the compiler also reports dozens of
camouflage complaints, and the fellow in charge of the code doesn't see
the value in making the changes needed to clear them. Everything's
complicated.

On Sunday, November 7, 2021 at 3:31:01 PM UTC+13, Steven Schweda wrote:
> You don't need to test the code if your compiler identifies the
> error.

There is never an excuse for not testing the code. You can never have too much testing of the code.

You know the old saying “no work of art is ever finished, it is only abandoned”? That applies to code-testing protocols, too.

On Sunday, November 7, 2021 at 1:31:01 PM UTC+11, Steven Schweda wrote:
> > That && at ckcuni.c:8272 should probably be &
> _Very_ probably. As the compiler suggested.
> > It might only matter for Japanese Roman ISO 646, which could be why no one noticed it yet.
> You don't need to test the code if your compiler identifies the
> error. Unless, of course, the compiler also reports dozens of
> camouflage complaints, and the fellow in charge of the code doesn't see
> the value in making the changes needed to clear them. Everything's
> complicated.

Keep watch for a C-Kermit 9.0.305 Alpha 05 release...

Steven and myself have gotten code fixes to Frank da Cruz that he's
incorporated into the source code. I've just finished testing this new
release from OpenVMS VAX and Alpha; macOS Catalina and Monterey;
and from a Raspberry Pi. As soon as Frank hears back from others
that have contributed patches, he''ll announce it (and I'll forward a
copy of the announcement here to comp.os.vms).

Tony

On Monday, November 8, 2021 at 8:21:27 AM UTC+11, Tony Nicholson wrote:

> Keep watch for a C-Kermit 9.0.305 Alpha 05 release...

Frank da Cruz has just released this version for regular distribution.

It's available in the usual place at

https://www.kermitproject.org/ckdaily.html

See the "voluminous update history" link for release information.

I'm using this latest version under OpenVMS VAX and Alpha, as well
as macOS and Raspberry PiOS-32 (Debian 10) Linux.

Tony

On 11/16/2021 4:14 PM, Tony Nicholson wrote:
> On Monday, November 8, 2021 at 8:21:27 AM UTC+11, Tony Nicholson wrote:
>
>> Keep watch for a C-Kermit 9.0.305 Alpha 05 release...
>
> Frank da Cruz has just released this version for regular distribution.
>
> It's available in the usual place at
>
> https://www.kermitproject.org/ckdaily.html

Thanks, Tony!

--
Hunter
------
Hunter Goatley, Process Software, http://www.process.com/
goathunter@goatley.com http://hunter.goatley.com/