[comp.lang.c] C on IBM MVS or VM/CMS

kam@dlogics.UUCP (Kevin Mitchell) (11/29/89)

We're considering porting some software to IBM machines running
MVS or VM/CMS. If you know any good information about C compilers
on these machines, please comment.

Thanks.


-- 
Kevin A. Mitchell                (312) 266-4485
Datalogics, Inc                  Internet: kam@dlogics.UUCP
441 W. Huron                     UUCP: ..!uunet!dlogics!kam
Chicago, IL  60610               FAX: (312) 266-4473

bks@alfa.berkeley.edu (Brad Sherman) (12/01/89)

In article <249@dlogics.UUCP> kam@dlogics.UUCP (Kevin Mitchell) writes:
| We're considering porting some software to IBM machines running
| MVS or VM/CMS. If you know any good information about C compilers
| on these machines, please comment.

We're currently involved with a port (about 30K lines of C) to CMS.
After cursory  experiments with SAS C, IBM C and WATCOM (i.e. 
U. of Waterloo) C, we are using WATCOM.

This decision was based purely on the completeness of the library.

Any comments from others who have ported to the IBM mainframe enviroment
would be very welcome.

A couple of questions that this port has produced:

	Close() is a void function in WATCOM.
	Is this reasonable?

	Open() cannot take a third argument (mode).
	As permissions are a non-sequitor under CMS
	this is reasonable, but could someone explain
	to me how this argument can be optional in
	a traditional C environment? ( i.e. what is
	happening on the stack? )
--
    Brad Sherman (bks@alfa.berkeley.edu)

eager@netcom.UUCP (Michael Eager) (12/01/89)

kam@dlogics.UUCP (Kevin Mitchell) writes:
>We're considering porting some software to IBM machines running
>MVS or VM/CMS. If you know any good information about C compilers
>on these machines, please comment.



I ported a version of Spice consisting of several hundred modules 
and about 110,000 lines of C from Sun to MVS using the compiler
which IBM provides (I can't seem to remember who really makes the 
compiler).  There were a number of problems:  the MVS compiler is
ANSI-ish, the Sun is K&R; I needed to translate all [ to ??( and 
] to ??) (who would have thought that trigraphs were actually 
useful?); and I had to eliminate multiple definitions of global
variables (Sun just merges the definitions).

There is a second compiler available for MVS & VM, I believe by 
Lattice.  I have not used it, but the documentation appears to be
significantly better than the IBM compiler and there appear to be
more of the common library routines.

-- Mike Eager
Eager Consulting, 481 Century Drive, Campbell, CA 95008 (408) 378-8820

gwyn@smoke.BRL.MIL (Doug Gwyn) (12/02/89)

In article <1989Dec1.000456.29060@agate.berkeley.edu> bks@alfa.berkeley.edu (Brad Sherman) writes:
>Close() is a void function in WATCOM.  Is this reasonable?

It's not UNIX-compatible, but it's reasonable.

>Open() cannot take a third argument (mode).  As permissions are a
>non-sequitor under CMS this is reasonable, but could someone explain
>to me how this argument can be optional in a traditional C environment?

In general it cannot be; this was yet another in a continuing series of
C function interface design botches introduced into UNIX through the
years.  When AT&T decided to add O_CREAT functionality to the existing
(2-argument) open() system call, they made the kernel look at a third
argument if and only if O_CREAT were set in the second argument.  This
happened to work on VAX, PDP-11, and 3B UNIX implementations, but as is
well known it might not work in other environments.

UNIX applications developers who were concerned about this botch had
to guess how to deal with it.  Some of us assumed that open() would
be officially a 3-argument function, and modified older 2-argument
usage to provide a third argument (normally 0).

IEEE 1003.1 had to address this problem, and their solution was to
specify open() as a variadic function.

ORCUTT@cc.utah.edu (12/03/89)

We have some people in our group that are writing C
on a 3090, with the IBM-supplied compiler.  They
mentioned that the compiler accepts "[" and "]"
as produced by our tn3270 running on a UNIX box,
but that these characters display as "*" or something
on a real 3270 terminal.  Evidently, though,
the editor (X) and the compiler can both see the
characters, search for them, and compile them...