c9h@psuecl.bitnet (12/13/89)
I just can't believe it. If I hadn't seen it with my own eyes, I seriously
doubt that I would. IBM C/370 is *not* case sensitive. This is just for
starters. Let me give you some advice. NEVER, EVER use C/370 if there is
*ANY* way you can avoid it, ESPECIALLY if you like K&R2. People, this com-
piler is BAD (Broken As Designed). I strongly encourage you to get Waterloo
C (WATC) if you want to program in C on an IBM mainframe.
--
- Charles Martin Hannum II "Klein bottle for sale ... inquire within."
(That's Charles to you!) "To life immortal!"
c9h@psuecl.{bitnet,psu.edu} "No noozzzz izzz netzzzsnoozzzzz..."
c9h@eclx.psu.edu "Mem'ry, all alone in the moonlight ..."
c9h@hcx.psu.edu
cmh@psuecl2.bitnetted@ultra.com (Ted Schroeder) (12/14/89)
c9h@psuecl.bitnet writes: >I just can't believe it. If I hadn't seen it with my own eyes, I seriously >doubt that I would. IBM C/370 is *not* case sensitive. This is just for >starters. Let me give you some advice. NEVER, EVER use C/370 if there is >*ANY* way you can avoid it, ESPECIALLY if you like K&R2. People, this com- >piler is BAD (Broken As Designed). I strongly encourage you to get Waterloo >C (WATC) if you want to program in C on an IBM mainframe. Well, not exactly. IBM C/370 is case sensitive AS long as the data is local. I'm sure that globals are not case sensitive in Waterloo C either since the linker/loader doesn't support case. It also doesn't support the "_" character and symbols can only be 8 chars long. ("_" chars get turned into the "@" char automatically by the compiler). By the way, I've done a pretty major port of a Unix device driver for our product into VM and have had not a single issue with the compiler. Now the loader, that I've got my opinions about, but let's not bad mouth the compiler when it's the rest of the IBM support you're really pissed about. Ted Schroeder ted@Ultra.com Ultra Network Technologies ...!ames!ultra!ted 101 Daggett Drive San Jose, CA 95134 408-922-0100 Disclaimer: I don't even believe what I say, why should my company?
swh@hpcupt1.HP.COM (Steve Harrold) (12/14/89)
Re: C/370 case sensitivity? I cannot speak from actual experience, since I don't have access to IBM's C/370, but are you sure when you say that the compiler does not respect case? In what sense is case ignored? To quote from "IBM Systems Application Architecture: Common Programming Interface: C Reference", p/n SC26-4353-0, page 33: "For identifiers that represent internal data objects, IBM C compilers view uppercase and lowercase letters as different symbols. Thus 'PROFIT' and 'profit' represent different internal data objects. "For identifiers that represent external data objects, uppercase and lowercase letters may be viewed as equivalent symbols. IBM compilers will recognize a minumum of 7 significant characters for external identifiers. Thus on some compilers, 'STOCKONHAND' and 'stockonorder' will represent the same external data object because the 7 significant characters of both identifiers are identical and the case is ignored." These two paraprahs are merely being explicit about the ANSI standard. What ARE the sprecifics of your complaint about the C/370 compiler???
c9h@psuecl.bitnet (12/14/89)
In article <1989Dec13.173114.10295@ultra.com>, ted@ultra.com (Ted Schroeder) writes: > c9h@psuecl.bitnet writes: > > Well, not exactly. IBM C/370 is case sensitive AS long as the data is local. > I'm sure that globals are not case sensitive in Waterloo C either since the > linker/loader doesn't support case. It also doesn't support the "_" character > and symbols can only be 8 chars long. ("_" chars get turned into the "@" char > automatically by the compiler). Funny ... Maybe Waterloo C knows something ... Perhaps it has a better way to handle this ... Hell, I don't know. All I know is that *it* doesn't bitch and moan when I have too identifiers varying only in case. > By the way, I've done a pretty major port of a Unix device driver for our > product into VM and have had not a single issue with the compiler. Now the > loader, that I've got my opinions about, but let's not bad mouth the compiler > when it's the rest of the IBM support you're really pissed about. Your *damned* right I'm pissed. Our people ordered the manual(s) with the compiler (oh, about seven or eight months ago), and the manuals still aren't here. BTW: I just checked. WATC *is*, in every aspect, case sensitive. -- - Charles Martin Hannum II "Klein bottle for sale ... inquire within." (That's Charles to you!) "To life immortal!" c9h@psuecl.{bitnet,psu.edu} "No noozzzz izzz netzzzsnoozzzzz..." c9h@eclx.psu.edu "Mem'ry, all alone in the moonlight ..." c9h@hcx.psu.edu cmh@psuecl2.bitnet
jbeard@quintus.UUCP (Jeff Beard) (12/15/89)
<c9h@psuecl.bitnet (Charles Martin Hannum II) writes: >I just can't believe it. If I hadn't seen it with my own eyes, I seriously >doubt that I would. IBM C/370 is *not* case sensitive. This is just for >starters. Let me give you some advice. NEVER, EVER use C/370 if there is >*ANY* way you can avoid it, ESPECIALLY if you like K&R2. People, this com- >piler is BAD (Broken As Designed). I strongly encourage you to get Waterloo >C (WATC) if you want to program in C on an IBM mainframe. > >-- We now see two flavors of IBM/C: the originals ala Whitesmiths which were programs 5713-AAG/H and the SAA compliant 5688-039/040. Precisely which are you flaming? PS: after working on porting Unix C code to system/370 for three years, and after exhausting 4 compilers, I settled upon SAS/C for two important reasons (at least to me and my company) 1) the code generated was reentrant and could therefore by used to write DSCC (shared library) fuctions 2) by proper factoring of system dependencies (as in file names, etc) code written on VM could be moved to MVS and without recompilation, be link-edit with confidence of exactlt equivalent behavior! -- ====== Opinions are the possession of the speaker and to assert otherwise is plagiarism. Jeff Beard, Quintus Computer Systems, Inc. e-mail ...!amdahl!sun!quintus!jbeard phone (415) 965-7700
exspes@gdr.bath.ac.uk (P E Smee) (12/15/89)
In article <1989Dec13.173114.10295@ultra.com> ted@ultra.com (Ted Schroeder) writes: >("_" chars get turned into the "@" char >automatically by the compiler). Under VM/CMS it is also pretty nearly impossible to use any of the 'special' characters {}[]|, and conversion to trigraphs is pretty much required. (Problem is that while both XEDIT and C/370 have extended EBCDIC codes for these characters, they use different ones.) >loader, that I've got my opinions about, but let's not bad mouth the compiler >when it's the rest of the IBM support you're really pissed about. I did a port of a fairly specialized tape-reading program onto VM/CMS about 8 months ago, and found the biggest problem was with the libraries. Under CMS, at least, a lot of what you'd expect to find in the standard libraries wasn't there; and a lot of what was didn't work. Never did get 'rewind' to work on a tape, for example. (Though it would happily 'rewind' my terminal, whatever that means.) In the end I had to write a REXX (script) to make a disk image of a tape, and then run the C prog over that image. -- Paul Smee, Univ of Bristol Comp Centre, Bristol BS8 1TW, Tel +44 272 303132 Smee@bristol.ac.uk :-) (..!uunet!ukc!gdr.bath.ac.uk!exspes if you MUST)
c9h@psuecl.bitnet (12/16/89)
In article <1290@quintus.UUCP>, jbeard@quintus.UUCP (Jeff Beard) writes: > We now see two flavors of IBM/C: the originals ala Whitesmiths > which were programs 5713-AAG/H and the SAA compliant 5688-039/040. > > Precisely which are you flaming? C/370 is IBM's latest incarnation of C for the system/370, and many of their mainframes of course. I'm using it on a 3090-600(S or E, I don't recall) and a 4381. It sucks. About the special characters (namely braces and brackets): CMS doesn't appear to have much of a problem with them. XEDIT will display brackets if I use SET APL ON, and CMS 5.5 seems to handle the braces correctly with a couple of SET OUTPUT commands, but CMS 5 (on the 4381) is giving me Hell over it. It would be *really* nice if I could use standard C notation. Any suggestions? BTW: I suspect the manuals say something about this, but we have yet to receive them ... (IBM, are you listening? This is Penn State. Send the G** d***ed manuals!!) -- - Charles Martin Hannum II "Klein bottle for sale ... inquire within." (That's Charles to you!) "To life immortal!" c9h@psuecl.{bitnet,psu.edu} "No noozzzz izzz netzzzsnoozzzzz..." c9h@eclx.psu.edu "Mem'ry, all alone in the moonlight ..." c9h@hcx.psu.edu cmh@psuecl2.bitnet Disclaimer: The opinions expressed herein belong exclusively to me, and not to Penn State, the Center for Academic Computing (fondly known as the CACastocracy B-), the Engineering Copmuter Lab, or the University Scholars Program.
exspes@gdr.bath.ac.uk (P E Smee) (12/18/89)
In article <72683@psuecl.bitnet> c9h@psuecl.bitnet writes: >In article <1290@quintus.UUCP>, jbeard@quintus.UUCP (Jeff Beard) writes: >> We now see two flavors of IBM/C: the originals ala Whitesmiths >> which were programs 5713-AAG/H and the SAA compliant 5688-039/040. >> >> Precisely which are you flaming? > >C/370 is IBM's latest incarnation of C for the system/370, and many of their >mainframes of course. I'm using it on a 3090-600(S or E, I don't recall) >and a 4381. It sucks. > >About the special characters (namely braces and brackets): CMS doesn't >appear to have much of a problem with them. XEDIT will display brackets >if I use SET APL ON, and CMS 5.5 seems to handle the braces correctly with >a couple of SET OUTPUT commands, but CMS 5 (on the 4381) is giving me Hell *I* was flaming 5713-AAH; our IBM people have never indicated that there is an official alternative. (We *are* looking into the C on the 'Waterloo' tapes.) Apropos special characters, I may have been the tiniest bit over-critical. If you are using a fairly new 3270 on a directly attached terminal controller, you CAN get at most of the 'special' characters. If you are using an oldish 3270, or are attached via an X-29-ish network connection, you can't sensibly. We have 3 of the former, all in the Ops bridge, and a humungous lot of the latter, and you can probably tell from my postings which I was using. (The older 3270's are even worse, in that the keycaps don't match the keyboard layout as defined by what you get when you hit the keys. I'm told we can't reconfigure their controller to fix that, because then the printer hooked to the same SNA channel won't work. However, I'm getting a bit far afield now.) -- Paul Smee, Univ of Bristol Comp Centre, Bristol BS8 1TW, Tel +44 272 303132 Smee@bristol.ac.uk :-) (..!uunet!ukc!gdr.bath.ac.uk!exspes if you MUST)
kbreinho%peruvian.utah.edu@cs.utah.edu (Keith Breinholt) (12/19/89)
In article <1989Dec15.095803.416@gdt.bath.ac.uk> exspes@gdr.bath.ac.uk (P E Smee) writes: >Under VM/CMS it is also pretty nearly impossible to use any of the 'special' >characters {}[]|, and conversion to trigraphs is pretty much required. >(Problem is that while both XEDIT and C/370 have extended EBCDIC codes >for these characters, they use different ones.) The key in this scenario is to use a terminal or terminal emulator that sends the right characters (i.e. 3270 emulation). Once the right characters are sent there is no problem with {}[]| and other 'special' characters. Keith L. Breinholt usiklb@vm.usi.utah.edu or kbreinho@wildflower.utah.edu
mcdonald@aries.scs.uiuc.edu (Doug McDonald) (12/19/89)
In article <1989Dec18.113044.10445@gdt.bath.ac.uk> exspes@gdr.bath.ac.uk (P E Smee) writes: >In article <72683@psuecl.bitnet> c9h@psuecl.bitnet writes: >>C/370 is IBM's latest incarnation of C for the system/370, and many of their >>mainframes of course. I'm using it on a 3090-600(S or E, I don't recall) >>and a 4381. It sucks. >> >*I* was flaming 5713-AAH; our IBM people have never indicated that >there is an official alternative. (We *are* looking into the C on the >'Waterloo' tapes.) > This seems so simple: there is a set of STANDARD, world-wide character codes, that are used on essentially all computers in the world except one benighted variety: ASCII and its 256 bit European extensions. All of these have the printing codes from 32 to 126 the same. IBM: simply use these for all uses on your mainframes. So simple. Or: when specifying a new computer you are going to buy, specify that these are the codes that will be used for all operations. Doug McDonald
dricejb@drilex.UUCP (Craig Jackson drilex1) (12/19/89)
In article <1989Dec18.232929.23080@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: >In article <1989Dec18.113044.10445@gdt.bath.ac.uk> exspes@gdr.bath.ac.uk (P E Smee) writes: >>In article <72683@psuecl.bitnet> c9h@psuecl.bitnet writes: >>>C/370 is IBM's latest incarnation of C for the system/370, and many of their >>>mainframes of course. I'm using it on a 3090-600(S or E, I don't recall) >>>and a 4381. It sucks. >>> >>*I* was flaming 5713-AAH; our IBM people have never indicated that >>there is an official alternative. (We *are* looking into the C on the >>'Waterloo' tapes.) > >This seems so simple: there is a set of STANDARD, world-wide >character codes, that are used on essentially all computers in the >world except one benighted variety: ASCII and its 256 bit European >extensions. All of these have the printing codes from 32 to 126 >the same. > >IBM: simply use these for all uses on your mainframes. > >So simple. > >Or: when specifying a new computer you are going to buy, >specify that these are the codes that will be used for all >operations. > >Doug McDonald The major reason why EBCDIC is incompatible with ASCII is that it *predates* ASCII. EBCDIC was put to be sometime around 1964-66; ASCII didn't gel until around 1968. By then, EBCDIC was in wide use. (Also, IBM had some other criteria: EBCDIC can be derived from punch card codes more easily than ASCII, for example.) We've had quite a bit of experience with ASCII characters that EBCDIC doesn't like, as we ported some Burroughs ALGOL programs to IBM by writing a compiler. (Burroughs uses EBCDIC, but a different version than IBM's; it maps one-to-one onto ASCII.) To the best of my knowledge, all 3270-like terminals other than the 3277 can display square brackets. The problem is that they respond to the hex codes '41' and '42', rather than 'AD' and 'BD', which seem to be the EBCDIC "standard". With appropriate CMS SET INPUT and SET OUTPUT commands, it can be quite easy to deal with these characters. (If you want to type them in, you need six commands: SET INPUT '`' -> 'AD' (or some similar character, SET INPUT '41' -> 'AD', and SET OUTPUT 'AD' -> '41'. (Plus equivalent translates for right-square-bracket.) As for specifying that ASCII should be used in all operations, feel free. If that results in a computer that costs more, doesn't have the software you need, or doesn't have the performance (CPU or I/O) you need, feel justified. (If you're counting beans on large amounts of data (>20 GB), one or more of the above clauses may be true.) Incidentally, IBM would be happy to meet that requirement: they'd just quote AIX/370. :-) -- Craig Jackson dricejb@drilex.dri.mgh.com {bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}