If we had the C compiler, I would use it. Of course, I wouldn't have learned how to create DLLs use LE enabled HLASM, either. Yes, I've done that. As far as compiled HLLs are concerned, I've always loved PL/I. I would probably like the PL/X (or whatever) that IBM uses for much of their software development too. I use C, but not C++, on Linux/Intel some. But I prefer Perl because I'm generally doing "ad hoc" reports. And Perl is, for me, very nice for that.
-- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Bernd Oppolzer > Sent: Wednesday, September 05, 2012 10:47 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Strings (hijacked from: The IBM zEnterprise EC12 > announcment) > > Good point. > > Many of you out there seem to dislike C for such reasons like that > discussed here: you have to take more responsibility for manageing > the lengths of the used buffers etc. - but the same people often like > ASSEMBLER, where the chance to put errors in your program is > much higher. > > My opinion is: if you handle C carefully and you know about its > pitfalls, > it can be a really great implementation language for software that is > targetted not far from the operating system, that is, tools, compilers, > parsers, db systems, embedded applications etc. - but it works also > for commercial or scientific application systems. One of its biggests > strengths is portability. I work with C now for almost 20 years > (and with PL/1, ASSEMBLER, Fortran, Pascal, even COBOL, REXX etc.), > and I like C very much. It is possible to write secure programs in C, > if you follow some rules, for example when using string functions. > > C++ is another thing - I would strongly recommend to make a > difference. > There are too much strange things happening "under the cover", and I > don't like it, if the programming language does things that I'm not > aware of. > > Kind regards > > Bernd > > > > Am 05.09.2012 17:10, schrieb Anne & Lynn Wheeler: > > paulgboul...@aim.com (Paul Gilmartin) writes: > >> You, Lynn, and John G. are correct to distrust null-terminated > strings. > > re: > > http://www.garlic.com/~lynn/2012l.html#67 Strings (hijacked from: The > IBM zEnterprise EC12 announcment) > > > > in lots of discussions about C language string&buffer conventions > being > > one the primary sources of programming errors ... there were > analogous > > with careful drivers never having accidents and therefor there are no > > need for bumpers, safety glass, crash zones, seatbelts, padded > > dashboards, airbags, etc. > > > > the more straight-forward analysis is that buffer length management > is > > left to the programmer ... always having to manually manage whether > the > > implicit length (of null terminated string) fits within target > storage > > area. I've compared it to assembler language programming where a > major > > manual effort on the programmer was managing register contents ... > and > > mis-managed register contents has been major assembler programming > error > > ... especially in complex programs with large number of code paths > > ... and at any particular point in execution ... did all possible > > execution paths correctly initialize registers. > > > > It turns out that one of the benifits attributed for moving to > > C-programming ... is it allows system level programming while > > alleviating manual effort of the programmer managing the register > > contents. However, it has trade-off the elimination of the manual > > register content management effort with the buffer length manual > > management effort. > > > > Long ago and far away (in the very earliest days of rexx before > released > > to customers)... I wanted to demonstrate the power of REXX ... and > > selected IPCS ... which was a large, assembler implemented > application. > > Objective was to completely re-implemented IPCS in REXX ... working > > half-time over 3month period ... with the new implementation having > ten > > times the function and with ten times the performance (some coding > > slight of hand to make an application in REXX run ten times faster > than > > corresponding application in assembler). I finished early ... so I > > started doing analysis of kinds of failures and their failure > signatures > > ... developing an augmented library of IPCS procedures that could be > > automated to look for the various kinds of failure scenarios. Misc. > > past posts mentioning DUMPRX > > http://www.garlic.com/~lynn/submain.html#dumprx > > > > I had assumed that it would be released to customers as IPCS > replacement > > ... which never happened for whatever reason ... although it > eventually > > came to be used by all internal datacenters and nearly all customer > > support PSRs. I eventually managed to get approval for making > > presentation at user group meetings about how it was implemented ... > and > > within a couple of months, similar implementations started to appear > > from other vendors. > > > > Two of the most common were 1) anomolous code path failure to > establish > > register contents (required at later point) and 2) dangling buffer > > pointers (aka asynchronous operation using pointer to storage area > that > > was no longer active ... the particular storage area no longer active > > and/or re-allocated for some other purpose). > > > > Most higher-level languages eliminate manual programmer effort in > > managing register contents. One of the characteristics claimed for > > languages like Java & LISP is having eliminated programmer manual > > managed storage ... no only doesn't have C-language buffer length > like > > problems ... but also has eliminated dangling pointer problems. > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
