Dump reading is a lost art: For newbies it was one of the principal ways to learn how to debug assembler code. As you became more experienced is was more of a "to do" if you encountered problems. Never like using those Abend Aid "do-me squaggies" .. Just ridiculously cumbersome.
C/++ on a mainframe is rare .. If you have had the luxury of using both you are one of the lucky few.. as wading through the manual C/C++ set is a time consuming effort. You'd also have to be able to decipher the macro coding since most macro (RACF comes to mind ) will generate both C and Assembler code. Worst of all You'd have to know USS and Unix (XPG4 anyone ..?? ) inside out, no small feat either. Your candidate profile should include those who an code marco's ( ye olde SETA, SETB, SETC), Dump Reading , GTF Tracing,,, and C/C++ which does not mean cursory skill on z/OS, as SSL programmer and TCIP Programmer guides have specific coding styles. There are no crutches for mainframe C/C++ programmers .. sorry guy's you either know it or you don't. Object programming does not lend itself well to TCPIP programming, unless you are using Java on z/OS but that's another story. Good Luck; T'dell Sparks: Retired aug/2013 Not interested in working anymore.. I had enough -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of John Gilmore Sent: Friday, July 26, 2013 9:48 AM To: [email protected] Subject: Re: 3 job openings for mainframe Assembler/C programmers, dump readers I agree with Ed Jaffe that 'Attitude has a lot to do with it.' I think, however, that attitudes are is often reflections of skills and experiences. Those who 1) have learned to read dumps and 2) have had the habit of reading them reinforced by successes in extracting valuable diagnostic information from them are very likely to use them. Others are likely to try to avoid using them. Dump reading is often, of course, premature. I have seen programmers studying dumps in situations in which brief examination of their source programs by someone else quickly disclosed their errors. EJ's second point, that some programmers write more reliable routines than others, is another important one, but I will leave its discussion for another day. John Gilmore, Ashland, MA 01721 - USA
