From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_05,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 111d6b,328622178ec8b832 X-Google-Attributes: gid111d6b,public X-Google-Thread: 10d15b,328622178ec8b832 X-Google-Attributes: gid10d15b,public X-Google-Thread: 114809,a03ae7f4e53958e1 X-Google-Attributes: gid114809,public X-Google-Thread: 1014db,a03ae7f4e53958e1 X-Google-Attributes: gid1014db,public X-Google-Thread: 1094ba,a03ae7f4e53958e1 X-Google-Attributes: gid1094ba,public X-Google-Thread: 103376,8775b19e3c68a5dc X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,a03ae7f4e53958e1 X-Google-Attributes: gid109fba,public From: "Frank A. Adrian" Subject: Re: Which language pays most -- C++ vs. Java? Date: 1998/01/29 Message-ID: <6aqs75$d03$1@client3.news.psi.net>#1/1 X-Deja-AN: 320376518 References: <67et6o$dql@bgtnsc03.worldnet.att.net> <67ktrg$ibk@bgtnsc03.worldnet.att.net> <883319809snz@genesis.demon.co.uk> <68bt2p$d48@lotho.delphi.com> <34a991f0.2379476@news.diac.com> <68dm0i$brv1@news.fiberlink.net> <01bd198f$4050d960$68c8b5cc@dhite.unicomp.net> <34B71B71.1EFDCAD8@ix.netcom.com> <34B8DC0F.BA0554DB@acm.org> <01bd1ebd$8580b9a0$b2684bc2@xzSys> <34BA520B.534F@mail.state.wi.us> <6alu5l$onm$1@owl.slip.net> <01bd2c2a$69b107a0$9f684bc2@xzSys> <01bd2c45$f7ff6f40$7261b693@HP5079Q> <34D0A9F7.4768@beyond-software.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Organization: First DataBank Newsgroups: comp.lang.java.misc,comp.lang.c,comp.lang.c++,comp.lang.fortran,comp.lang.cobol,comp.lang.smalltalk,comp.lang.ada Date: 1998-01-29T00:00:00+00:00 List-Id: Wayne L. Beavers wrote in message <34D0A9F7.4768@beyond-software.com>... >Joe Gwinn wrote: >> >> I don't expect programmers to learn engineering anytime soon, but there is >> one big problem I do have with most programmers -- they are ignorant of >> assembly code and the internals of generated code, runtime systems, >> operating systems, etc. This ignorance causes serious problems; it simply >> isn't enough to know only the surface of . Some learn >> these things on the job, but most don't. > >I disagree. There really is no reason for a COBOL programmer working on >Accounts Payable applications to know how to shoot a 64 meg stand alone >dump of an MVS/ESA system in a hard loop or disabled wait. Why would a >COBOL programmer be interested in analyzing a GTF trace? Why would a >COBOL programmer examine CCW chains? No reason. > >That's why we have systems programmers. > >I know a fair amount about the internals of MVS and VM operating >systems. I can shoot dumps and trace tables well enough. What I can not >do is design business applications. I don't know much at all about >accounting, manufacturing, transportation, retail, finance, etc. I >started out as an Electronic Engineering major and switched to Computer >Science in my junior year, a long time ago. > >Of course today the average systems programmer no longer has the skills >to shoot stand alone dumps. They just call IBM and get the fix and put >it on. For the few of us around that can still diagnose systems problems >we all have new titles now. Last time I looked I was a "Software >Engineer", according to my business cards. I guess I have a simple answer to people who believe that programmers SHOULD have this or that or the other skill. I just ask them if they're willing to pay extra for it. They tend to not want to. So my question to the earlier poster is, "How much more than the going rate for a COBOL application program- mer who is just a COBOL application programmer are you willing to pay for one who knows the physical register architecture of the IBM 3xx line and the inter- nals of MVS?" And I guess we all SHOULD be omniscient, too, but I don't see anyone willing to pay extra for that. -- Frank A. Adrian First DataBank frank_adrian@firstdatabank.com (W) franka@europa.com (H) This message does not necessarily reflect those of my employer, its parent company, or any of the co-subsidiaries of the parent company.