: C-Kermit IA64 Build error

Discussion:

(too old to reply)

Art

2017-02-13 19:54:44 UTC

In support of our efforts to migrate from Alpha ES47's (OpenVMS
v8.3) to Itanium rx2800 i4's (OpenVMS v8.4), I retrieved the
C-Kermit "VMS Complete" kit from:

http://www.kermitproject.org/ck90.html ...

in the "Download and Build from Source Code" section:

ftp://ftp.kermitproject.org/kermit/archives/ckv302.zip

I UNZIP'ed as instructed with the -a switch and executed the
build command procedure. The procedure encountered an error and
failed. Any insight?

Details of what I have, actually did and saw:
---------------------------------------
$ cc/version
VSI C V7.4-001 on OpenVMS IA64 V8.4-2
---------------------------------------
$ netcu show version
TCPware(R) V6.0-0 Copyright (c) Process Software

OpenVMS version V8.4-2 booted on 11-DEC-2016 14:04:50.00,
running on a HP rx2800 i4 (1.73GHz/20.0MB).
---------------------------------------
$ dir

Directory $1$DGA121:[KERMIT]
CKV302.ZIP;1
Total of 1 file.
---------------------------------------
$ unzip -a ckv302.zip
Archive: $1$DGA121:[KERMIT]CKV302.ZIP;1
inflating: CK_CRP.C [text]
inflating: CK_DES.C [text]
inflating: CK_SSL.C [text]
inflating: CK_SSL.H [text]
inflating: CKCASC.H [text]
inflating: CKCDEB.H [text]
inflating: CKCFN2.C [text]
inflating: CKCFN3.C [text]
inflating: CKCFNS.C [text]
inflating: CKCFTP.C [text]
inflating: CKCKER.H [text]
inflating: CKCLIB.C [text]
inflating: CKCLIB.H [text]
inflating: CKCMAI.C [text]
inflating: CKCMDB.C [text]
inflating: CKCNET.C [text]
inflating: CKCNET.H [text]
inflating: CKCPRO.C [text]
inflating: CKCPRO.W [text]
inflating: CKCSIG.H [text]
inflating: CKCSSL.H [text]
inflating: CKCSYM.H [text]
inflating: CKCTEL.C [text]
inflating: CKCTEL.H [text]
inflating: CKCUNI.C [text]
inflating: CKCUNI.H [text]
inflating: CKCXLA.H [text]
inflating: CKUAT2.H [text]
inflating: CKUATH.C [text]
inflating: CKUATH.H [text]
inflating: CKUCMD.C [text]
inflating: CKUCMD.H [text]
inflating: CKUCNS.C [text]
inflating: CKUCON.C [text]
inflating: CKUDIA.C [text]
inflating: CKUFIO.C [text]
inflating: CKUPTY.C [text]
inflating: CKUPTY.H [text]
inflating: CKUSCR.C [text]
inflating: CKUSIG.C [text]
inflating: CKUSIG.H [text]
inflating: CKUTIO.C [text]
inflating: CKUUS2.C [text]
inflating: CKUUS3.C [text]
inflating: CKUUS4.C [text]
inflating: CKUUS5.C [text]
inflating: CKUUS6.C [text]
inflating: CKUUS7.C [text]
inflating: CKUUSR.C [text]
inflating: CKUUSR.H [text]
inflating: CKUUSX.C [text]
inflating: CKUUSY.C [text]
inflating: CKUVER.H [text]
inflating: CKUXLA.C [text]
inflating: CKUXLA.H [text]
inflating: CKVCON.C [text]
inflating: CKVCVT.C [text]
inflating: CKVFIO.C [text]
inflating: CKVIOC.C [text]
inflating: CKVIOC.H [text]
inflating: CKVOLD.C [text]
inflating: CKVRMS.H [text]
inflating: CKVRTL.C [text]
inflating: CKVRTL.H [text]
inflating: CKVTIO.C [text]
inflating: CKVVMS.H [text]
inflating: CKWART.C [text]
inflating: COPYING.TXT [text]
inflating: CKAAAA.TXT [text]
inflating: CKVINS.TXT [text]
inflating: CKCBWR.TXT [text]
inflating: CKVBWR.TXT [text]
inflating: CKCPLM.TXT [text]
inflating: CKCCFG.TXT [text]
inflating: CKUTUTOR.TXT [text]
inflating: CKVKER.COM [text]
inflating: CKVOLD.COM [text]
inflating: CKVKER.MMS [text]
inflating: CKVKER.HLP [text]
inflating: CKERMIT70.TXT [text]
inflating: CKERMIT80.TXT [text]
inflating: CKERMIT90.TXT [text]
inflating: CKERMIT.INI [text]
inflating: CKERMOD.INI [text]
inflating: OCKERMIT.INI [text]
inflating: OCKERMOD.INI [text]
$
---------------------------------------
I read some of the build command procedure which describes the
parameters that can be passed in. Nothing seemed obvious that I
should set so:

$ show default
$1$DGA121:[KERMIT]
$ net_option = "TCPWARE"
$ @ckvker
Starting $1$DGA121:[KERMIT]CKVKER.COM;1 on VMSTD1 at 13-FEB-2017 14:34:05.04
Using MMS utility
DECC compiler found

Operating System: OpenVMS(tm) IA64

Network option override = TCPWARE
Large file support enabled
Compiling Kermit sources ...
CCOPT = " /unsigned_char/PREFIX_LIBRARY_ENTRIES=(AL,EX=ioctl)/def=(TCP WARE,DEC_TCPIP,DECC,VMS_V84,VMSSHARE,NEWFTP ,_LARGEFILE_SOURCE,
_LARGEFILE ,VMSV60,VMSV70,VMSV80,TCPSOCKET)"
Kermit Source Path = $1$DGA121:[KERMIT]
Building WERMIT 9.0.302 with:
shareable libs and Process Software TCPware network support at 13-FEB-2017 14:34:05.09

Compiling $1$DGA121:[KERMIT]CKCFN2.C
Compiling $1$DGA121:[KERMIT]CKCFN3.C
Compiling $1$DGA121:[KERMIT]CKCFNS.C
Compiling $1$DGA121:[KERMIT]CKCFTP.C
Compiling $1$DGA121:[KERMIT]CKCLIB.C
Compiling $1$DGA121:[KERMIT]CKCMAI.C
Compiling $1$DGA121:[KERMIT]CKCNET.C
Compiling $1$DGA121:[KERMIT]CKWART.C
Linking CKWART
LINK /nodebug/nomap ckwart.obj,aux.opt/opt
CKWART K:CKCPRO.W CKCPRO.C
16 states, 74 actions
Compiling CKCPRO.C
Compiling $1$DGA121:[KERMIT]CKCTEL.C
Compiling $1$DGA121:[KERMIT]CKCUNI.C
Compiling $1$DGA121:[KERMIT]CKUATH.C
Compiling $1$DGA121:[KERMIT]CKUCMD.C
Compiling $1$DGA121:[KERMIT]CKUDIA.C
Compiling $1$DGA121:[KERMIT]CKUSCR.C
Compiling $1$DGA121:[KERMIT]CKUSIG.C
Compiling $1$DGA121:[KERMIT]CKUUS2.C
Compiling $1$DGA121:[KERMIT]CKUUS3.C
Compiling $1$DGA121:[KERMIT]CKUUS4.C
Compiling $1$DGA121:[KERMIT]CKUUS5.C
Compiling $1$DGA121:[KERMIT]CKUUS6.C
Compiling $1$DGA121:[KERMIT]CKUUS7.C
Compiling $1$DGA121:[KERMIT]CKUUSR.C
Compiling $1$DGA121:[KERMIT]CKUUSX.C
Compiling $1$DGA121:[KERMIT]CKUUSY.C
Compiling $1$DGA121:[KERMIT]CKUXLA.C
Compiling $1$DGA121:[KERMIT]CKVCON.C
Compiling $1$DGA121:[KERMIT]CKVFIO.C
Compiling $1$DGA121:[KERMIT]CKVIOC.C
Compiling $1$DGA121:[KERMIT]CKVRTL.C
Compiling $1$DGA121:[KERMIT]CKVTIO.C

while ((n--) && xx_inc(2) >= 0) ; /* Ignore Warning - see comments */
.......................^
%CC-I-QUESTCOMPARE, In this statement, the unsigned expression "(--ttxbn> =0?(unsigned)(ttxbuf[ttxbp++]&0X00000000000000FF):txbufr (..
))" is being compared with a relational operator to a constant whose value is not greater than zero. This might not be wh
at you intended.
at line number 921 in file $1$DGA121:[KERMIT]CKVTIO.C;1
Compiling $1$DGA121:[KERMIT]CK_CRP.C
Compiling $1$DGA121:[KERMIT]CK_SSL.C
Linking WERMIT
LINK /exec=wermit.exe KERMIT.OPT/OPTION
%ILINK-F-OPENIN, error opening SYS$COMMON:[TCPWARE]UCX$IPC.OLB; as input
-RMS-E-FNF, file not found
%MMS-F-ABORT, For target WERMIT.EXE, CLI returned abort status: %X1789109C.
$
---------------------------------------
In the meantime I retrieved a pre-built binary, but it's for OpenVMS v8.3-1H1 / UCX 5.6 . The user says it "works" so we're good for now but was interested in a "proper" version for our environment.

Any insight as to what may be wrong?

Thanks in advance,
Art

Craig A. Berry

2017-02-13 20:36:12 UTC

Permalink

Post by Art
Compiling $1$DGA121:[KERMIT]CK_CRP.C
Compiling $1$DGA121:[KERMIT]CK_SSL.C
Linking WERMIT
LINK /exec=wermit.exe KERMIT.OPT/OPTION
%ILINK-F-OPENIN, error opening SYS$COMMON:[TCPWARE]UCX$IPC.OLB; as input
-RMS-E-FNF, file not found
%MMS-F-ABORT, For target WERMIT.EXE, CLI returned abort status: %X1789109C.
$

Hunt around for that file by a different name, perhaps with TCPIP in the name rather than UCX, or try removing it from your linker options file and see how far you get without it. In a previous century it was necessary to link to different networking libraries for different network stacks, but as far as I know that all moved into the CRTL eons ago.

Paul Sture

2017-02-13 22:11:30 UTC

Permalink

Post by Art
In support of our efforts to migrate from Alpha ES47's (OpenVMS
v8.3) to Itanium rx2800 i4's (OpenVMS v8.4), I retrieved the
http://www.kermitproject.org/ck90.html ...
ftp://ftp.kermitproject.org/kermit/archives/ckv302.zip
I UNZIP'ed as instructed with the -a switch and executed the
build command procedure. The procedure encountered an error and
failed. Any insight?
---------------------------------------

The compilation error isn't the cause.

Post by Art
while ((n--) && xx_inc(2) >= 0) ; /* Ignore Warning - see comments */
.......................^
%CC-I-QUESTCOMPARE, In this statement, the unsigned expression "(--ttxbn> =0?(unsigned)(ttxbuf[ttxbp++]&0X00000000000000FF):txbufr (..
))" is being compared with a relational operator to a constant whose value is not greater than zero. This might not be wh
at you intended.
at line number 921 in file $1$DGA121:[KERMIT]CKVTIO.C;1
Compiling $1$DGA121:[KERMIT]CK_CRP.C
Compiling $1$DGA121:[KERMIT]CK_SSL.C
Linking WERMIT

The problem is here. The build procedure is expecting to find UCX$IPC.OLB
in SYS$COMMON:[TCPWARE]

Post by Art
LINK /exec=wermit.exe KERMIT.OPT/OPTION
%ILINK-F-OPENIN, error opening SYS$COMMON:[TCPWARE]UCX$IPC.OLB; as input
-RMS-E-FNF, file not found
%MMS-F-ABORT, For target WERMIT.EXE, CLI returned abort status: %X1789109C.

Bearing in mind that I have never even installed TCPWARE, an educated
guess says that there is either an option to install UCX$IPC.OLB at
TCPWARE installation time, which wasn't taken, OR it has been
subsequently deleted, OR (hopefully) you do have [TCPWARE]UCX$IPC.OLB
but it's sitting in SYS$SPECIFIC, not SYS$COMMON.

--
A supercomputer is a device for turning compute-bound problems into
I/O-bound problems. ---Ken Batcher

Steven Schweda

2017-02-13 22:28:08 UTC

Permalink

Post by Paul Sture
The compilation error isn't the cause.

Well, duh. "/* Ignore Warning - see comments */" was
supposed to be a clue.

Post by Paul Sture
The problem is here. [...]

Actually, it's in the DCL script, ckvker.com, which
creates the LINK options file:

[...]
$ if net_option .eqs. "TCPWARE"
$ then
$ net_name = "Process Software TCPware"
$ write optf "tcpware:ucx$ipc.olb/library"
$ net_option = "TCPWARE,DEC_TCPIP"
[...]

Note that there's some version sensitivity for UCX/TCPIP:

[...]
$ ucxv5=0
[...]
$ if f$search("SYS$LIBRARY:TCPIP$IPC_SHR.EXE") .nes. "" then ucxv5 = 1
[...]
$ if net_option .eqs. "DEC_TCPIP" !+1.24
$ then
$ net_name = "DEC TCP/IP Services for OpenVMS(tm)"
$ if non_vax.eq.0
$ then
$ if ucxv5
$ then
$ write optf "sys$library:tcpip$ipc_shr.exe/share" !1.31
$ else write optf "sys$library:ucx$ipc.olb/library"
$ endif
$ endif !-1.24
[...]

No doubt, something similar could be arranged for TCPware,
if anyone knew what the right file spec would be. (I can
only guess.) I haven't looked at this stuff for a long time,
so I don't know who's maintaining what how well these days,
but, when you determine the ideal fix, you might try to feed
it back.

Steven Schweda

2017-02-13 22:46:23 UTC

Permalink

[...] I don't know who's maintaining what how well these
days, [...]

Hmmm. A closer look (at the "Newer developments" link)
http://www.kermitproject.org/ckdaily.html
suggests that things are still being done. (And, for a good
time, there's a version 9.0.304 now.)
What? No SSL? Where's your sense of adventure?

John E. Malmberg

2017-02-13 23:40:45 UTC

Permalink

You should only need to specify the ucx$ipc.olb if and only if you are
building on VAX/VMS 5.5-1 or earlier using the VAX C compiler.

That tells you the last time someone updated the build procedure.

Specifying the ucx$ipc.olb for VAX/VMS 5.5-2 and later will likely cause
problems.

With that obvious bug in the build procedure, there are probably others.

Regards,
-John
***@qsl.net_work

t***@glaver.org

2017-02-14 09:23:58 UTC

Permalink

Post by Steven Schweda
No doubt, something similar could be arranged for TCPware,
if anyone knew what the right file spec would be. (I can
only guess.) I haven't looked at this stuff for a long time,
so I don't know who's maintaining what how well these days,
but, when you determine the ideal fix, you might try to feed
it back.

It has been a _very_ long time (decades) since I worked on VMS C-Kermit, and
there are certainly some questionable things in there that can be attributed to
me. That's due to a number of things, including deciding to fix all of the file
I/O while out sick with the flu and a high fever (and got told "tag - you're
it!" when I tried to turn my changes over to the prior maintainer). It was also
a testbed platform for "file type labeled" and a number of other things, which
could have been implemented more elegantly if I wasn't prototyping the very
first implementations of them.

Having said that, this one isn't my fault. I made the decision that since all of
the commonly-available TCP/IP stacks for VMS emulated DEC's UCX* (which is pro-
nounced "yucks!"), I'd only use functions available in the UCX libraries. This
led to some contortions around poll/select and other poorly-implemented UCX-
isms, but did mean that there weren't a bunch of #ifdef's for different TCP/IP
stacks. Other people added build support for various stacks other than MultiNet
and UCX (the two I had to test with). Bear in mind that this was back on a VAX
with VAX C 3.3 - lots of things outside of the C-Kermit code have changed a
great deal since then.

* I believe that some of the execeptions were CMU/Tek and Wollongong, but my
memory on this is fuzzy.

Arne Vajhøj

2017-02-13 22:31:22 UTC

Permalink

Post by Paul Sture

Post by Art
In support of our efforts to migrate from Alpha ES47's (OpenVMS
v8.3) to Itanium rx2800 i4's (OpenVMS v8.4), I retrieved the

The problem is here. The build procedure is expecting to find UCX$IPC.OLB
in SYS$COMMON:[TCPWARE]

Or the installation script is very old and TCPWARE changed from
UCX$IPC.OLB to TCPIP$IPC.OLB ??

No - I don't know TCPWare either, so I am just guessing.

Arne

David Froble

2017-02-14 03:29:33 UTC

Permalink

Post by Paul Sture

The compilation error isn't the cause.

The problem is here. The build procedure is expecting to find UCX$IPC.OLB
in SYS$COMMON:[TCPWARE]

It seems to me that a simple DIRECTORY <system drive>:[*...]*ipc.olb would eb a
bit helpful. Don't know about TCPWARE, but since V5, the VMS IP product has
been called TCPIP*.

Stephen Hoffman

2017-02-14 16:02:47 UTC

Permalink

In support of our efforts to migrate from Alpha ES47's (OpenVMS v8.3)
to Itanium rx2800 i4's (OpenVMS v8.4), I retrieved the C-Kermit "VMS
...
%ILINK-F-OPENIN, error opening SYS$COMMON:[TCPWARE]UCX$IPC.OLB; as input

That port is ancient, or there's a build bug, or maybe both.

Many of these older ports to OpenVMS accrued substantial complexity,
dealing with the compatibility problems and omissions that existed in
now-ancient OpenVMS versions. Things have gotten better by V8.4,
though there are still some big gaps in support and the standards
compliance isn't where anybody wants it — all as JR can attest. I'd
likely look to extract all of the old porting-related hooks and
conditionals and rest of the OpenVMS-specific giblets and re-port the
code, this targeting OpenVMS V8.4 and later and current C. Might even
be able to eliminate most or all of the conditionals around the
installed IP network transport too, as most of that should be
transparent across IP stacks now.

If you just want to hack around the edges with what you have, find out
if that OLB is even necessary any more — it looks like you're in the
VAX C build path for TCPware, and VAX C V3.2 was the last of that K&R C
pre-ANSI/ISO-C compiler series, and DEC C (ANSI/ISO C) replaced VAX C
most of thirty years ago. (Expunging VAX C support tends to expose
latent errors. The newer DEC/Compaq/HP/HPE/VSI C compilers are much
better at spotting questionable or incorrect code. Though as was
recently discussed in another thread, not all of such code. I'd
probably fix that diagnostic while re-porting that, too.)

It's a code-slog, yes.

--
Pure Personal Opinion | HoffmanLabs LLC

Steven Schweda

2017-02-14 22:49:53 UTC

Permalink

Post by Stephen Hoffman
That port is ancient, or there's a build bug, or maybe
both.

The VMS builders are mostly old, with changes to
accommodate newer systems, but the number of Kermit
developers who run TCPware has (apparently) been vanishingly
small, and those without it (I, for example) may have been
reluctant to make changes to any TCPware-specific code,
having no way to test such changes.

My guess would be that the TCPware stuff in ckvker.com
involving *IPC.OLB could be changed to look more like the
corresponding stuff for UCX/TCPIP. For example:

$ if f$search("TCPWARE:UCX$IPC.OLB") .nes. ""

v.:

$ if (f$search("SYS$LIBRARY:UCX$ACCESS_SHR.EXE") .nes. "") -
.or. (f$search("SYS$LIBRARY:TCPIP$ACCESS_SHR.EXE") .nes. "")

and:

$ write optf "tcpware:ucx$ipc.olb/library"

v.:

$ if ucxv5
$ then
$ write optf "sys$library:tcpip$ipc_shr.exe/share" !1.31
$ else write optf "sys$library:ucx$ipc.olb/library"

But, of course, I know nothing about what needs to be
included in the LINK options file for different versions of
TCPware, nor how these things might depend on the TCPware
version (nor how to determine that, either), so I'm unlikely
to do more than make the suggestion.

I assume that, with all this helpful advice, you've
already got it working in your own case.

Post by Stephen Hoffman
[...] I'd probably fix that diagnostic while re-porting
that, too.)

If it were easy to do in a portable way, then it might
already have been done ("[...] see comments */").
Traditionally, Kermit development goals have included not
breaking stuff on old systems. This can make that re-porting
job more difficult, but it does offer other advantages,
especially for users with those old systems.