Hello (again) from Gregg C Levine (I won't state the obvious.) John you've just pointed out the reason why I don't like that family of machines, and its descendants. Also COBOL for the same reason.
As for Assembler, I do. It turns out I became very good at it, during the 8086, and 80286 days. Wrote code that could solve many a problem, that refused to be solved, in a higher level language, example Pascal. Who here recalls the Borland family of products from that age? ------------------- Gregg C Levine [EMAIL PROTECTED] ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke."� Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda ) > -----Original Message----- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of > John Campbell > Sent: Wednesday, October 29, 2003 9:52 AM > To: [EMAIL PROTECTED] > Subject: Re: [LINUX-390] Memory access faults. > > I recall the words of one sage: > > "Never test for an error you don't know how to handle." > > I've also heard a story about NASA's message switching network (when it was > on UNIVAC 494s) about losing sync and all nodes reporting "the system is > red". > > Even "impossible" errors happen. I've also seen some ludicrous levels of > trust in code from College graduates, who would use long pointer > dereferences over and over again... and not have a local copy of the > ultimate pointer for the end-structure. > > "If you do not pay attention to pointers they won't pay attention to you." > > -------------------- > John R. Campbell, Speaker to Machines (GNUrd) {813-356|697}-5322 > Adsumo ergo raptus sum > MacOS X: Because making Unix user-friendly was easier than debugging > Windows. > ----- Forwarded by John Campbell/Tampa/IBM on 10/29/2003 09:48 AM ----- > > "Hall, Ken (IDS > ECCS)" To: [EMAIL PROTECTED] > <[EMAIL PROTECTED]> cc: > Sent by: Linux on Subject: Re: [LINUX-390] Memory access > faults. > 390 Port > <[EMAIL PROTECTED] > IST.EDU> > > > 10/29/2003 08:35 > AM > Please respond to > Linux on 390 Port > > > > > > > Well, actually, so do I, but we're a vanishing species. > > > -----Original Message----- > > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of > > Paul Hanrahan > > Sent: Tuesday, October 28, 2003 6:12 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [LINUX-390] Memory access faults. > > > > > > I do > > > > -----Original Message----- > > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On > > Behalf Of Hall, > > Ken (IDS ECCS) > > Sent: Tuesday, October 28, 2003 3:06 PM > > To: [EMAIL PROTECTED] > > Subject: Re: Memory access faults. > > > > > > Recovery is only as good as the language framework allows it to be. > > Compilers insulate you from the data and the hardware, and > > reduce your level > > of control over how errors are handled. > > > > But that's part of what you're buying by using a compiler in the first > > place: Not to have to worry about all those "little details". > > > > Assembler programs have access to interrupt exits that allow recovery > > routines to get control. An infinitely smart programmer > > could conceivably > > write enough code to fix or recover from ANY failure, but how > > many of THOSE > > are there? And who writes in assembler anymore anyway? > > > > > -----Original Message----- > > > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] > > Behalf Of > > > David Boyes > > > Sent: Tuesday, October 28, 2003 2:52 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: [LINUX-390] Memory access faults. > > > > > > > > > > The problem with laying this at the feet of the application > > > > programmer is that they are not perfect, and when the > > program fails > > > > it actually the end user that suffers. > > > > > > Unfortunately, that's about the only place it *can* go. Users can't > > > (or shouldn't be able to) change the code on the fly, or, if they > > > can, they're > > > better than the developer -- or at least, a lot more bored > > > and have way too > > > much free time. > > > > > > Methinks that it mostly results from not probing your > > environment at > > > startup to determine what the limitations are, and then doing more > > > rigorous checking > > > that you don't violate those limits during operation. Way too many > > > programmers assume infinite resources and don't cope with > > > failure to acquire > > > same. > > > > > > While we're airing pet peeves: why do people assume that changing > > > programming languages will somehow fix this problem? It's just as > > > possible to write rotten Java as rotten C or Fortran (in fact, it's > > > possible to write > > > bad Fortran in *any* programming language...8-)), and IDE's > > > and all the > > > other stuff doesn't fix bad programming practices any more > > > than a fancy > > > grease gun fixes seized bearings. It helps, but fused is > > still fused. > > > > > > (yes, it's been Tuesday all over. grump.) > > > > > > -- db > > > > >
