I tried to compile the MAILC program from Lars Janssen and Jeff Artz,
v 2.2 (2005) on our NS2000. There is no "C" compiler, but a CCOMP. I
used the program successfully a 8-11 years ago on an S-Series, but
that was a few employers ago, so I don't have the object.
There is no object output due to the errors.
I'm not a developer, so don't know how to resolve the warning and
errors. I just need to start sending emails. :-)
Is there a newer version for TNS/E?
Here is the output of warnings and errors:
$SYSTEM SENDMAIL 71> Ccomp/IN MAILC/SENDMAIL; RUNNABLE, SUPPRESS,
SYMBOLS, WIDE
$SYSTEM SENDMAIL 71..
TNS/E C - T0549H01 - 30JUL2010 (Sep 24 2010 14:01:10)
(C)2004 - (C)2010 Hewlett Packard Development Company, L.P.
#pragma RUNNABLE, WIDE, XMEM, SYMBOLS, INSPECT, ENV COMMON,
SAVEABEND
^
"\NS02.$SYSTEM.SENDMAIL.SNDMLSRC", line 4.000: warning(666): this
pragma is
only supported on the command line
#pragma RUNNABLE, WIDE, XMEM, SYMBOLS, INSPECT, ENV COMMON,
SAVEABEND
^
"\NS02.$SYSTEM.SENDMAIL.SNDMLSRC", line 4.000: warning(652): this
pragma has
no effect
#pragma RUNNABLE, WIDE, XMEM, SYMBOLS, INSPECT, ENV COMMON,
SAVEABEND
^
"\NS02.$SYSTEM.SENDMAIL.SNDMLSRC", line 4.000: warning(666): this
pragma is
only supported on the command line
#pragma RUNNABLE, WIDE, XMEM, SYMBOLS, INSPECT, ENV COMMON,
SAVEABEND
^
"\NS02.$SYSTEM.SENDMAIL.SNDMLSRC", line 4.000: warning(666): this
pragma is
only supported on the command line
#pragma RUNNABLE, WIDE, XMEM, SYMBOLS, INSPECT, ENV COMMON,
SAVEABEND
^
"\NS02.$SYSTEM.SENDMAIL.SNDMLSRC", line 4.000: warning(666): this
pragma is
only supported on the command line
#pragma SEARCH "$system.ztcpip.libinetw"
^
"\NS02.$SYSTEM.SENDMAIL.SNDMLSRC", line 8.000: warning(666): this
pragma is
only supported on the command line
u_short sin_port;
^
"\NS02.$SYSTEM.ZTCPIP.INH", line 165.000: error(114): identifier
"u_short" is
undefined
u_short sin_port;
^
"\NS02.$SYSTEM.ZTCPIP.INH", line 180.000: error(114): identifier
"u_short" is
undefined
caddr_t iov_base;
^
"\NS02.$SYSTEM.ZTCPIP.UIOH", line 37.000: error(114): identifier
"caddr_t" is
undefined
u_short sa_family; /* address family */
^
"\NS02.$SYSTEM.ZTCPIP.SOCKETH", line 149.000: error(114): identifier
"u_short"
is undefined
char __ss_pad1[_SS_PAD1SIZE]; /* 6 byte pad to alignment
field */
^
"\NS02.$SYSTEM.ZTCPIP.SOCKETH", line 187.000: error(114): identifier
"u_short"
is undefined
u_short sp_family; /* address family */
^
"\NS02.$SYSTEM.ZTCPIP.SOCKETH", line 206.000: error(923): "u_short" is
not a
type name
u_short sp_protocol; /* protocol */
^
"\NS02.$SYSTEM.ZTCPIP.SOCKETH", line 207.000: error(923): "u_short" is
not a
type name
#include <cextdecs(AWAITIOX,CLOSE,SETMODE,FILENAME_DECOMPOSE_)>
^
"\NS02.$SYSTEM.SENDMAIL.SNDMLSRC", line 319.000: catastrophic
error(1003):
could not open source file "cextdecs"
0 remarks were issued during compilation.
6 warnings were issued during compilation.
8 errors were detected during compilation.
Compilation terminated.
Compiler statistics
phase CPU seconds elapsed time file name
CCOMP \NS02.$SYSTEM.SYSTEM.CCOMP
CCOMBE 0.1 00:00:00 \NS02.$SYSTEM.SYSTEM.CCOMBE
total 0.1 00:00:02
All processes executed in CPU 01 (NSE-W)
Swap volume: \NS02.$SYSTEM
STOPPED: $Y2KJ
CPU time: 0:00:00.005
2: Process terminated with fatal errors or diagnostics
Thank you for any help you can provide,
Eby
CCOMP is part is NMC, Native Mode C-Compulir, while C is the non-native
C-Compiler
> used the program successfully a 8-11 years ago on an S-Series, but
> that was a few employers ago, so I don't have the object.
>
> There is no object output due to the errors.
>
> I'm not a developer, so don't know how to resolve the warning and
> errors. I just need to start sending emails. :-)
These behave differently and many inf not all the errors you got stem from
these differences.
> Is there a newer version for TNS/E?
Not sure, Ron Bowden used so have one, check www.bsi2.com
<snip>
Bye, Jojo
Wolfgang's email was not as clear as he usually is. Maybe he was in a hurry today. So let me answer, too.
The C source you have is intended to be compiled by the TNS C compiler, not the native mode compiler. The TNS C compiler is still available for the TNS/E system. I think it is installed by default on a standard TNS/E system. If it is missing from your system, maybe someone intentionally removed it for some reason, or maybe renamed it. Perhaps you could ask the system manager or other people at your site why the TNS C compiler is not present.
There is a version of the sendmail program that someone has modified to compile with a native mode compiler, but it is an old version which is missing some of the later enhancements to the program. I have not made a list of what is missing in that native mode version. I could send you that source file if you want to try it.
Jeff made an update to sendmail in November 2010 to correct an error. That version is 2.3. If you want that source, I could send you that file. It still is for TNS C, not for native mode C.
Programs compiled by TNS C are exactly the same no matter which system they are compiled on, so if there really is no TNS C compiler on your TNS/E system, and if you have access to another NonStop system, even a TNS/R system, you could compile the sendmail program with the TNS C compiler on that other system and copy the object file to your TNS/E system.
Converting the source file so it will compile with the native mode C compiler probably would not be a big job for someone familiar with C on the NonStop system, but I don't have access to a system so I cannot do it. In a pinch, I probably could do it via email, but that would be slow. Maybe someone with access to a NonStop system will volunteer.
You will need to include the EXTENSIONS pragma on the command line.
Funny, I just got around to compiling the new version myself on Friday
on our blade. I used the native compiler ccomp but had to insert a
line into the source:
#define CCE 0
Cheers, Pete
Keith,
I did not send an answer, I am not the C guy. I think you meant JoJo.
Wolfgang
The ITUGLIB team tried to compile the current sendmail version
recently but had little success. We're going to give it a go using c99.
http://mysite.verizon.net/jartz/personal/sendmail_v2_3.txt
As noted in earlier posts, you need to include the EXTENSIONS pragma
on the command line (and for nmc, add #define CCE 0).
Note also that the (hard-coded) default IP addresses should be changed
before you compile.
The C language is the same for all platforms, only the compilers are
different. The SENDMAIL C source 2.3 should compile just fine with any
compiler (though I have not tested C++ or CCOMP (no Itanium system
access)), but personally I would make sure that all warnings are
examined/eliminated, as there MAY be issues with the various C
compiler's view of how many bits an int should have...
I recommend deleting the following source #pragma line:
#pragma RUNNABLE, WIDE, XMEM, SYMBOLS, INSPECT, ENV COMMON, SAVEABEND
These pragmas should instead be placed on the command line, like so:
> [ c | nmc ] / in sendmail, out $s.#sm / <object>; runnable, wide, xmem, extensions, symbols, inspect, env common
For nmc, add ", define CCE 0" to the command line as well (may be
there for C also, but will then generate a warning that CCE has been
redefined).
The C compiler emits no warnings, no errors
The nmc compiler emits 40 warnings (no errors)
SENDMAIL uses the Guardian (NonStop OS) API, and does NOT compile
properly under OSS without extensive prior tweaking...
Buena suerte!
Henry Norman
MicroTech Consulting
https://sites.google.com/site/microtechnonstop/
PS. Many thanks to Jeff Artz (Jeff dot Artz at gmail dot com), the
current HP NonStop Server SENDMAIL caretaker!
No, it was me. And yes, I was in a hurry ;-)
Bye, Jojo
Wolfgang,
Oops, my mistake. I am sorry for the mistake. I do not know why I mentioned the wrong person.
Keith
>eby wrote:
>> Hello All,
>>
><snip>
>Converting the source file so it will compile with the native mode C compiler probably would not be a big job for someone familiar with C on the NonStop system, but I don't have access to a system so I cannot do it. In a pinch, I probably could do it via email, but that would be slow. Maybe someone with access to a NonStop system will volunteer.
For trivial programs that can be true.
For non-trivial programs that use unadorned -int- declarations it can
become a big job, particularly when testing message passing and/or
files with other programs. -int- in TNS C is 16 bits in size in the
absence of the WIDE pragma. -int- is 32 bits wide in the native
mode compilers. Consequently all record structes containing them
will differ in size. If adorned with the -unsigned- attribute this
size difference will change the modulo value for rollover to zero
when the variable exceeds UINT_MAX.
I would never recommend the non-native C compiler for any development
due to its lack of ISO standards compliance and its clumsy interface
to the sockets library.
Oz
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?