staff@cadlab.sublink.ORG (Alex Martelli) (09/13/90)
meissner@osf.org (Michael Meissner) writes: >Reality check time -- as far as I know, there is no C compiler for the >AS/400. It would be an interesting experience, in a sick sort of way >from what little I've heard about the internals of this beast. Also, I don't know either, but I do know that IBM is *COMMITTED* to release a C for AS/400, as well as a Fortran - both of these languages are a crucial part of the Common Programming Interface (CPI) of Standard Application Architecture (SAA), and AS/400 is "the heart of SAA" (with OS/2 being the feet and VM and MVS together the head, I guess). >up until last year or so, C had real little penetration in the 370 >market placem, except on Amdahl's version of unix. Little but sometimes crucial, as in SPSS (Statistical Package for the Social Sciences - IBM wouldn't sell many new 370-like beasts to Universities without the humanity depts. plugging for them because of it...), the REXX-Compiler for VM by IBM itself, the prototype dictation-driven 'voice typewriter' by Jelinek et al in Yorktown, etc. That's not really the point though - the point is, rather, that if you have a beautiful portable C application, and relish the thought of getting the beeg moola application SW on mainframes goes for, you'd BETTER think about problems related to portability to non-ASCII machines. What equivalent economic incentive is there to push you to worry about portability to one's complement machines? -- Alex Martelli - CAD.LAB s.p.a., v. Stalingrado 45, Bologna, Italia Email: (work:) staff@cadlab.sublink.org, (home:) alex@am.sublink.org Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434; Fax: ++39 (51) 366964 (work only; any time of day or night).
meissner@osf.org (Michael Meissner) (09/21/90)
In article <268@cadlab.sublink.ORG> staff@cadlab.sublink.ORG (Alex Martelli) writes: | meissner@osf.org (Michael Meissner) writes: | >Reality check time -- as far as I know, there is no C compiler for the | >AS/400. It would be an interesting experience, in a sick sort of way | >from what little I've heard about the internals of this beast. Also, | | I don't know either, but I do know that IBM is *COMMITTED* to release | a C for AS/400, as well as a Fortran - both of these languages are a | crucial part of the Common Programming Interface (CPI) of Standard | Application Architecture (SAA), and AS/400 is "the heart of SAA" | (with OS/2 being the feet and VM and MVS together the head, I guess). Ok, it looks like I have not kept up with the annoucements. Also, I think I was originally thinking of the Sytem 38 rather than the AS/400. From what little I know of the System 38, I think it would be a C hostile machine (it has a single level memory, pointers much bigger than integers, EBCDIC, etc.). I assumed that the AS/400 would have the same 'features', since it's being touted as the System 38 replacement. However, what little I read of the trades, indicates that SAA is more of a promise than a complete story. Some pieces are there, and some aren't..... | >up until last year or so, C had real little penetration in the 370 | >market placem, except on Amdahl's version of unix. | | Little but sometimes crucial, as in SPSS (Statistical Package for the | Social Sciences - IBM wouldn't sell many new 370-like beasts to | Universities without the humanity depts. plugging for them because | of it...), the REXX-Compiler for VM by IBM itself, the prototype | dictation-driven 'voice typewriter' by Jelinek et al in Yorktown, | etc. That's not really the point though - the point is, rather, | that if you have a beautiful portable C application, and relish the | thought of getting the beeg moola application SW on mainframes goes | for, you'd BETTER think about problems related to portability to | non-ASCII machines. What equivalent economic incentive is there to | push you to worry about portability to one's complement machines? Actually, I tend to think that it is absurd to think about getting a huge payback from new mainframe software these days. Yes, in the olden days of yore, software licenses went for quite a bit of change, but with the advent of relatively cheap PC software, it's having an effect of driving prices down. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Do apple growers tell their kids money doesn't grow on bushes?
karl@haddock.ima.isc.com (Karl Heuer) (09/22/90)
In article <268@cadlab.sublink.ORG> staff@cadlab.sublink.ORG (Alex Martelli) writes: >the point is, rather, that if you have a beautiful portable C application, >and relish the thought of getting the beeg moola application SW on mainframes >goes for, you'd BETTER think about problems related to portability to >non-ASCII machines. Ideally, yes. Though if you inherit a bunch of ASCII-specific code, it may well turn out that the path of least resistance is to use an implementation that emulates ASCII via transliteration inside the I/O calls. (Provided the application distinguishes between text and binary fopen()...) Karl W. Z. Heuer (karl@kelp.ima.isc.com or ima!kelp!karl), The Walking Lint
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/22/90)
In article <18089@haddock.ima.isc.com> karl@kelp.ima.isc.com (Karl Heuer) writes: >Ideally, yes. Though if you inherit a bunch of ASCII-specific code, it may >well turn out that the path of least resistance is to use an implementation >that emulates ASCII via transliteration inside the I/O calls. Or, the application could explicitly map between the native host character set and ASCII. I've found the following "functions" useful over the years: /* integer (or character) arguments and value: */ #define fromhostc( c ) (c) /* map host char set to ASCII */ #define tohostc( c ) (c) /* map ASCII to host char set */ The definitions of these are, of course, tailored to the environment. The above are the trivial versions when the native character set is already ASCII. In an EBCDIC environment they would index a translation table (much like the typical implementation of the <ctype.h> macros).