phil@amdcad.UUCP (Phil Ngai) (01/20/87)
In the Jan 19, 1987 San Jose Mercury News, MIPS Computer Systems is
advertising for a COBOL compiler engineer. Oh well, I guess it has to
happen even to the best of us.
Don't forget to get some CICS types too, while you're at it.
--
Social security is welfare for the elderly.
Phil Ngai +1 408 749 5720
UUCP: {ucbvax,decwrl,hplabs,allegra}!amdcad!phil
ARPA: amdcad!phil@decwrl.dec.competel@teksce.SCE.TEK.COM (Pete Lancashire) (01/21/87)
In article <14392@amdcad.UUCP>, phil@amdcad.UUCP (Phil Ngai) writes: > In the Jan 19, 1987 San Jose Mercury News, MIPS Computer Systems is > advertising for a COBOL compiler engineer. Oh well, I guess it has to > happen even to the best of us. > > Don't forget to get some CICS types too, while you're at it. > > -- > Social security is welfare for the elderly. > > Phil Ngai +1 408 749 5720 > UUCP: {ucbvax,decwrl,hplabs,allegra}!amdcad!phil > ARPA: amdcad!phil@decwrl.dec.com We had a talk by MIPS, they were very proud of their COBOL, I don't blame them. They used *modern* compiler construction instead of rehashing an oldie. I'm sitting in front of my SUN trying to take data off an IBM EBCDIC tape getting the data, sorting it, etc. Wish I had a good, fast COBOL right now. Pete Lancashire petel@teksce.SCE.TEK.COM Tektronix, Inc.
grr@cbmvax.cbm.UUCP (George Robbins) (01/22/87)
In article <14392@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes: >In the Jan 19, 1987 San Jose Mercury News, MIPS Computer Systems is >advertising for a COBOL compiler engineer. Oh well, I guess it has to >happen even to the best of us. Care to suggest a better procedural language for "data processing" applications programming? For all it's faults COBOL is pretty effective for what it was intended for... C is nice, but pictures rival printf's when formating print lines and other boring things. >Don't forget to get some CICS types too, while you're at it. Don't laugh at it unless you can hack it too... Then laugh with the rest of us fools who have done IBM work and survived. ----- No please, please gimme back my unix guru badge - I promise never not to say dirty words like IBM, COBOL, DP, DASDI, CHANNEL PROGRAM, IOCS, VIRTUAL MEMORY.. -- George Robbins - now working for, uucp: {ihnp4|seismo|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
wallach@convex.UUCP (01/23/87)
well i guess everyone has their price.
aglew@ccvaxa.UUCP (01/24/87)
>/* Written 1:18 am Jan 22, 1987 by grr@cbmvax.UUCP in ccvaxa:comp.arch */ >In article <14392@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes: >>In the Jan 19, 1987 San Jose Mercury News, MIPS Computer Systems is >>advertising for a COBOL compiler engineer. Oh well, I guess it has to >>happen even to the best of us. >Care to suggest a better procedural language for "data processing" >applications programming? How about PL/1? >For all it's faults COBOL is pretty effective for what it was >intended for... C is nice, but pictures rival printf's when >formating print lines and other boring things. Talking about which - has anybody got a picture formatting package for C? Pictures are damned nice at times. It could probably be wired into printf formats like this: printf("%P[$$$,$$$,$$$,$$9.99]",number); Andy "Krazy" Glew. Gould CSD-Urbana. USEnet: ihnp4!uiucdcs!ccvaxa!aglew 1101 E. University, Urbana, IL 61801 ARPAnet: aglew@gswd-vms.arpa
tuba@ur-tut.UUCP (01/25/87)
grr@cbmvax.UUCP (George Robbins) writes: >C is nice, but pictures rival printf's when formating print >lines and other boring things. For my usual rates, I'll code you a picture(3) library that will look and feel like the real thing, interface to your favorite 4GL, and run at least as fast on a Unix-based 68000 as the COBOL code on an IBM machine costing 10 times as much to buy, operate, and waste programmer time on. Or has somebody already done this? -- jon -- Jon Krueger Department of Necessary Evil University of Rochester uucp: {seismo, allegra, decvax}!rochester!ur-tut!tuba BITNET: TUBA@UORDBV
dibble@rochester.UUCP (01/26/87)
In article <984@ur-tut.UUCP>, tuba@ur-tut.UUCP (Jon Krueger) writes: > grr@cbmvax.UUCP (George Robbins) writes: > >C is nice, but pictures rival printf's when formating print > >lines and other boring things. > > For my usual rates, I'll code you a picture(3) library that will look > and feel like the real thing, interface to your favorite 4GL, and run > at least as fast on a Unix-based 68000 as the COBOL code on an IBM > machine costing 10 times as much to buy, operate, and waste programmer > time on. Or has somebody already done this? That would be very impressive! IBM 370 machines have hardware assists for formatting numeric output and more powerful instructions than the 68000 for handling bcd (they call it packed) numbers. Is the trick here that you are comparing the absolute top-of-the-line 68000 box to the bottom of the IBM mainframe line? Maybe you have one of the lobotomized distributed computers in mind? A version of printf could accept pictures and generate the right output, but it wouldn't get you the right "look and feel," at least not from the programmer's viewpoint. The COBOL move corresponding command is an important part of the "feel" of PIC output. I used to use it to compile an output line from fields out of several records. I would think it would be difficult to add move corresponding to a 4GL with a library. The last thing I want on my Unix machine is a library that supports COBOL-style PIC format conversion, but I'd love to know how you'd get the function and the speed. Especially the speed. Peter Dibble
mash@mips.UUCP (01/26/87)
Gee whiz!! It's amazing what happens when you go away for a week; truly
berserk outbreaks on the net [in comp.arch, of all places]. For some
reason my colleague Larry Weber [who runs the languages effort here, i.e.,
group who did all that zingy compiler technology] has chosen not to comment
on this. However, I'm in a touchy mood [having been required to play
airline-guessing games to escape the snow in Washington], hence:
1. The MIPS R2000 wasn't particularly built to run COBOL fast.
We didn't even take the small steps that the HP-Spectrum did to help it.
I can't think of a single thing that we've sacrificed in favor of
good COBOL-ness. REALLY, REALLY, WE'RE INNOCENT OF EXPECTING THAT:
2. Some of our customers/prospects discovered [to our astonishment, in some
cases inventing amazing uses of some of our instructions] that the R2000
actually looked like a fine COBOL engine (!!??!!) This mostly comes from
fast subroutine calls, some sneaky code-generation, and the effects you
get from serious optimizing compiler technology, and the fact [documented
by the Spectrum folks] that COBOL environments are mostly systems-type code
that don't really spend much time doing decimal operations.
3. I know this may be astonishing out there in UNIX-land, but much of the
world out there really uses COBOL, and it's often portable enough to move
to new architectures. When a whole bunch of large customers tell you that
you need COBOL, you at least listen to them. Sometimes they say things like
"we really like your C, FORTRAN, PASCAL, etc, but we really need one
architecture to cover both technical and commercial markets, so when will
COBOL be available?" [You have noticed thjat DEC supports COBOL?]
4. Consider the current state of microprocessor languauges, as compared to
minicomputer/mainframe compilers:
a) The micro vendors have [often/sometimes] not invested upfront in
high-quality optimizing compilers that use common components,
compatible runtimes [where possible], etc. The result is often
a large gaggle of different compilers, runtimes, etc, in quality
ranging from excellent to awful, which are supplied by combinations
of microprocessor vendors, compiler vendors, and systems vendors.
b) There are some fine compiler vendors out there; nevertheless,
the confusion factor doesn't particularly help systems integrators
or end users, who just want to g et a job done with a minimum of fuss.
5. Personally, I don't ever expect to write COBOL code, but I sure think it's
important to have a good compiler for it that meshes well with our systems,
and I'd much rather have Larry's [fine] compiler group doing it than to have
our customers having to build complex 3rd-party deals to get what they
need. I'd much rather have 1 good COBOL system that people can count on.
Thus, these comments are not particularly in favor of COBOL per se, but
simply recognition of reality: any general-purpose computer vendor will
need COBOL sooner or later, so it might as well be good.
Well, enough specific comments. Let me observe that one of UNIX's strengths
has been the following combination:
a) Elegant, insightful advances that looked beyond the state of the art.
b) Willingness of people to adapt it as needed, even to environments
otherwise alien, un-purist, or backward.
c) Reduction of the "gulp factor", i.e., people avoid new technologies
that make them discard everything they have. They'd much rather move
what they have, then convert it to newer technology over time.
UNIX has snuck into a lot of environments this way, like when we helped
UNIX let people edit COBOL and PL/I code and send it to IBM systems
years ago [unpure! but it helped people get their work done, and many
of the next round of projects was UNIX-based...]
Well, enough..... and shame on you, Steve W: how can you give us a hard time
when you guys have put so much effort into doing well by that other nasty old
language, FORTRAN? :-) As you say, everyone has their price. :-)
--
-john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD: 408-720-1700, x253
USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086tuba@ur-tut.UUCP (01/27/87)
I wrote: >> For my usual rates, I'll code you a picture(3) library that will look >> and feel like the real thing, interface to your favorite 4GL, and run >> at least as fast on a Unix-based 68000 as the COBOL code on an IBM >> machine costing 10 times as much to buy, operate, and waste programmer >> time on. Or has somebody already done this? dibble@rochester.ARPA (Peter C. Dibble) replies: >That would be very impressive! IBM 370 machines have hardware assists for >formatting numeric output and more powerful instructions than >the 68000 for handling bcd (they call it packed) numbers. I write: Yes, as do VAX-11/750's. Turns out some execute faster in software emulation on Microvax II's. RISC proponents like to offer similar examples of their load-store boxes outperforming CISCs on tasks microcoded into the CISC instruction set. >Is the trick here that you are comparing the absolute top-of-the-line >68000 box to the bottom of the IBM mainframe line? Well...I'm depending heavily on the true cost of IBM mainframe cycles. If IBM were to cut prices on its hardware and software, I couldn't quite do it. But as costs stand now, I think I can buy a stripped M68000-based Unix box for $5K to $15K. Let's assume it will break irreparably and its company go out of business in 1 year, after the fashion of those nasty little start-ups. You may therefore take $50K to $150K and start shopping IBM. Include costs of monthly rental of operating system and tools. Identify the target hardware with these constraints, drag out your COBOL code, time its execution, and I'll take that as a fair number to meet or beat. >Maybe you have one of the lobotomized distributed computers in mind? Not sure what's meant here. >A version of printf could accept pictures and generate the right output, >but it wouldn't get you the right "look and feel," at least not from >the programmer's viewpoint. > >The COBOL move corresponding command is an important part of the "feel" >of PIC output. I used to use it to compile an output line from fields >out of several records. I would think it would be difficult to add >move corresponding to a 4GL with a library. You may have me here. Tell you what. Supposing I ever code a picture(3), I'll happily submit both environments to the business oriented programmer, and accept her verdict on whether it feels the same to her. >The last thing I want on my Unix machine is a library that supports >COBOL-style PIC format conversion, but I'd love to know how you'd get >the function and the speed. Especially the speed. Mainly by constraining the IBM side to one costing ONLY ten times as much. In a pinch, I'd ask, reasonably I think, that the timing test be done on execution of a real COBOL program, not a 370 assembler code executing the IBM instructions directly. -- Jon Krueger Department of Necessary Evil University of Rochester uucp: {seismo, allegra, decvax}!rochester!ur-tut!tuba BITNET: TUBA@UORDBV
phil@amdcad.UUCP (01/27/87)
Well, I see no one disputes my method (newspaper job openings) of
finding out what various vendors are planning...
--
Paul Slansky: Those who believe that President Reagan had to have known about
secret fund diversions to the Contras are overlooking Reagan's hard-won
reputation for knowing practically nothing.
Phil Ngai +1 408 749 5720
UUCP: {ucbvax,decwrl,hplabs,allegra}!amdcad!phil
ARPA: amdcad!phil@decwrl.dec.combzs@bu-cs.UUCP (01/28/87)
From: phil@amdcad.UUCP (Phil Ngai) >Well, I see no one disputes my method (newspaper job openings) of >finding out what various vendors are planning... A few years ago I used to go thru the Sunday Boston Globe help wanted ads and count up the various flavors of programming jobs advertised as some indicator of something (mostly, the growth of UNIX as "real".) I would hang the results on my office door. The CIA or NSA or some such has been known to analyze for-sale ads in Russian newspapers to infer various things, especially in smaller towns (like the rate of movement in and out of certain classes of people.) It's a fine way to infer things, I've done it on net.jobs and discovered things. We all noticed here a year ago or so when Wang started advertising for UNIX systems people... -Barry Shein, Boston University
greg@utcsri.UUCP (Gregory Smith) (02/18/87)
In article <28200006@ccvaxa> aglew@ccvaxa.UUCP writes: >Talking about which - has anybody got a picture formatting package >for C? Pictures are damned nice at times. It could probably be >wired into printf formats like this: > > printf("%P[$$$,$$$,$$$,$$9.99]",number); > >Andy "Krazy" Glew. Gould CSD-Urbana. USEnet: ihnp4!uiucdcs!ccvaxa!aglew >1101 E. University, Urbana, IL 61801 ARPAnet: aglew@gswd-vms.arpa The problem here is that COBOL pictures are designed to be nice to look at but are not the best representation for controlling run-time conversion. The best way might be a preprocessor, which would convert from: printf( "total: %p\n", PIC($$$,$$$,$$$,$$9.99), number ); to: static struct { char *pic_background; short pic_dp,pic_flags } _pics[]={ ... { "000 ", 2, _PIC_LEFT_DOLLAR | _PIC_COMMAS }, ... }; ... printf( "total: %p\n",&_pics[6], number ); ...or something like that. The intended meaning of all this is left as an exercise :-) -- ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg Have vAX, will hack...